PostgreSQL复制生产就绪了吗？

PostgreSQL本机复制与MySQL相比如何？

我知道异步复制受支持的时间长于同步，这是最近的。在实际项目中使用同步可靠吗？

生产准备好了吗？

是的，它已经可以投入生产并被广泛使用。Heroku的追随者例如基于PostgreSQL的内置异步复制，AWS RDS备用数据库和只读副本也是如此。流复制几乎在PostgreSQL中普遍使用。

复制的设置并不是很漂亮，但是repmgr之类的工具在此方面有所帮助，并且在每个主要发行版中它的改进都在缓慢进行。pg_basebackup使用流复制（并从另一个备用数据库复制）复制系统副本的能力是很大的帮助。

通常，只有在正式生产之前，该功能才会在PostgreSQL中发布。像任何软件一样，都会发生错误，但是通常会在发现错误后立即对其进行修复。真正的主要新功能有时会在.0版本之后发现错误和问题，但如果这样，则将其修复是当务之急。错误不仅仅存在。

我不知道流复制存在任何严重问题-同步还是异步-相当长一段时间都没有看到任何报告。在引入的主要版本的.0版本中，它们的稳定性低于Pg的通常标准，但它们很快就成熟了，并且已经完全可以投入生产。

（更新：9.3.4之前的新9.3版本中存在一个特定错误，在某些情况下确实会导致复制问题； 9.3的用户应立即更新到9.3.4。较旧的版本不受影响。）

我要提及的唯一警告是同步复制的一个小细节：如果您提交给主服务器，则在提交等待副本确认之前，在提交后取消查询，即使在复制之前，它也被视为已提交给主服务器。通过等待副本回复时重新启动主服务器，可以达到相同的效果。实际上，这是无关紧要的，但这是我能想到的唯一问题。

与MySQL比较？

Pg的本地复制与MySQL的完全不同。

MySQL使用逻辑复制，在逻辑复制中，它发送对表数据，表结构等进行的逻辑更改，然后副本应用这些更改。

PostgreSQL的复制是较低级别的（在9.5及以下版本中；将来的版本可能还会添加逻辑复制）。它发送表中更改的块。它更简单，更容易解决，并在副本服务器上增加了较低的负载，但是消耗了更多的网络带宽，并且在主服务器上需要更多的存储空间来保存尚未复制的更改。最好将其配置为将流复制与WAL归档回退配合使用，从而使其配置比MySQL更为复杂。它复制了VACUUM活动之类的低级更改，而不仅仅是元组更改，从而使副本的磁盘状态与主磁盘相同。它不能只复制一个数据库。整个系统必须被复制，如果您拥有一个大型，高流量和不重要的数据库以及一个小型，低流量和重要的数据库，这可能会令人沮丧。

总而言之，这取决于您要使用它做什么。

我认为PostgreSQL的复制对于用于备份，高可用性和灾难恢复的副本要好得多。与时间点恢复（PITR）结合使用时尤其如此。

另一方面，它对于只读报告副本不是那么好，因为在运行长事务时需要延迟复制数据的应用，这意味着您需要让它取消运行时间很长的查询，或者大大落后于主数据库，主服务器上的磁盘空间更多，并迫使它继续努力以保持速度。

目前正在进行中的工作是在PostgreSQL中启用逻辑复制，在PostgreSQL中复制表结构，表内容等的逻辑更改，而不是复制磁盘上的状态。Pg的目录设计和对用户定义的所有内容的支持使这项工作变得非常复杂。9.4的一些基础工作已经到位，但是在9.6或更高版本之前不太可能使用完全逻辑复制。