Srg*_*man 16 postgresql replication
PostgreSQL 本机复制与 MySQL 相比如何？
我知道支持异步复制的时间比最近的同步更长。在实际项目中使用同步可靠吗？
Cra*_*ger 31
是的，它已准备好投入生产并被广泛使用。例如，Heroku 追随者基于 PostgreSQL 的内置异步复制，AWS RDS 备用数据库和只读副本也是如此。流复制几乎普遍用于 PostgreSQL。
复制的设置并不是很可爱，但是像repmgr这样的工具对此有所帮助，并且随着每个主要版本的发布，它的改进都很缓慢。pg_basebackup 使用流式复制获取系统副本（并从另一个备用数据库执行此操作）的能力是一个很大的帮助。
一般来说，一个特性在生产准备好之前不会在 PostgreSQL 中发布。错误会发生，就像在任何软件中一样，但它们通常在被识别后不久就会修复。真正重要的新功能有时会在 .0 版本之后发现错误和问题，但如果是这样，修复它们是一个高优先级；错误不只是遗留下来。
我不知道流复制有任何严重的问题 - 同步或异步 - 也有一段时间我没有看到任何报告。在引入它们的主要版本的 .0 版本中，它们不如 Pg 的通常标准稳定，但它们都很快成熟并且完全可以投入生产。
（更新：9.3.4 之前的新 9.3 版本中存在一个特定错误，在某些情况下确实会导致复制问题；9.3 的用户应立即更新到 9.3.4。旧版本不受影响。）
我想提到的唯一警告是同步复制的一个小细节：如果您在主服务器上提交，然后在等待副本确认的同时在提交后取消查询，即使在复制之前，它也会被视为已在主服务器上提交。通过在等待副本回复的同时重新启动主服务器，您可以获得相同的效果。实际上，这无关紧要，但这是我能想到的唯一问题。
Pg 的本地复制与 MySQL 的完全不同。
MySQL 使用逻辑复制发送对表数据、表结构等所做的逻辑更改，然后副本应用这些更改。
PostgreSQL 的复制级别较低（在 9.5 及以下版本；未来版本可能还会添加逻辑复制）。它发送表中更改的块。它更简单，更容易正确，并且对副本服务器施加的负载较低，但会消耗更多网络带宽，并且需要在主服务器上有更多存储空间来保存尚未复制的更改。最好配置为使用流复制和 WAL 归档回退，使其配置比 MySQL 更复杂。它复制低级更改，如 VACUUM 活动，而不仅仅是元组更改，使副本的磁盘状态与主服务器的磁盘状态保持相同。不能只复制一个数据库；必须复制整个系统，如果您有一个大的、高流失率和不重要的数据库和一个小的、低流失率和重要的数据库，这可能会令人沮丧。
总而言之，这取决于你想用它做什么。
我认为 PostgreSQL 的复制对于用于备份、高可用性和灾难恢复的副本来说要好得多。当与时间点恢复 (PITR)结合使用时尤其如此。
另一方面，它不适合只读报告副本，因为在运行长事务时需要延迟复制数据的应用意味着您需要让它取消非常长时间运行的查询或大大落后于主，消耗主机上的更多磁盘空间并迫使它更加努力地跟上。
在 PostgreSQL 中启用逻辑复制的工作正在进行中，其中表结构、表内容等的逻辑更改被复制，而不是它们在磁盘上的状态。Pg 的目录设计和对用户定义的一切的支持使这成为一项相当复杂的任务。9.4 的一些基础工作已经就位，但在 9.6 或更高版本之前不太可能使用完整的逻辑复制。