有人能告诉我更多关于PostgreSQL中物理复制和逻辑复制之间的区别吗？
答案 0 :(得分：72)
TL; DR ：逻辑复制发送逐行更改，物理复制发送磁盘块更改。对于某些任务，逻辑复制更好，对于其他任务则是物理复制。
从9.5开始，逻辑复制还不成熟。如果您提出这个问题，请使用物理复制。
流式复制可以是逻辑复制。这有点复杂。
在PostgreSQL中有两种主要方法可以将数据从主数据发送到副本：
WAL-shipping 或连续归档，其中pg_xlog从archive_command复制单个预写日志文件在主人身上跑到其他地方。在副本的restore_command中配置的recovery.conf在副本上运行以获取存档，以便副本可以重播WAL。
这是用于时间点复制（PITR）的内容，它用作连续备份的方法。
主服务器不需要直接网络连接。复制可能会有很长的延迟，尤其是在没有设置archive_timeout的情况下。 WAL运输不能用于同步复制。
流式复制，其中每次更改都会直接通过TCP / IP连接发送到一个或多个副本服务器。副本必须与主人在recovery.conf primary_conninfo选项中配置的直接网络连接。
只要副本足够快以便跟上，流式复制几乎没有延迟。它可用于同步复制。您不能将流复制用于PITR 1 ，因此它不能用于连续备份。如果你把一张桌子放在主人身上，哎呀，它也会掉在副本上。
因此，这两种方法有不同的目的。
除此之外，还有同步和异步流式复制：
在异步流复制中，当主服务器更快/更忙时，允许副本及时落在主服务器之后。如果主服务器崩溃，您可能会丢失尚未复制的数据。
如果异步副本远远落后于主节点，则如果wal_keep_segments太低且没有使用插槽，主节点可能会丢弃副本所需的信息，这意味着您必须从头开始重新创建副本。或者，如果pg_xlog太高或使用了插槽，主人的wal_keep_segments可能会填满并阻止主人工作，直到释放磁盘空间。
在同步复制中，主服务器未完成提交，直到副本确认已收到事务 2 。如果主服务器崩溃并且您必须故障转移到副本，则永远不会丢失数据。由于副本延迟，主服务器永远不会丢弃副本所需的数据或填满其xlog并耗尽磁盘空间。作为交换，如果副本有问题，它可能导致主节点减速甚至停止工作，并且由于网络延迟，它总是会对主节点产生一些性能影响。
当有多个副本时，一次只有一个是同步的。请参阅synchronous_standby_names。
您无法进行同步日志传送。
实际上，您可以将日志传送和异步复制相结合，以防止在副本过多的情况下重新创建副本，而不会有影响主服务器的风险。这是许多部署的理想配置，同时监控副本在主服务器后面的距离，以确保它在可接受的灾难恢复限制范围内。
在 之上我们有逻辑 vs 物理流复制，如PostgreSQL 9.4中所介绍的那样：
在物理流复制中更改在近乎磁盘块级别发送，如＆＃34;在关系12311的磁盘页面18的偏移量14处，写入带有十六进制值0x2342beef1222的元组。 ..＆＃34;
物理复制发送所有内容：PostgreSQL安装中每个数据库的内容，每个数据库中的所有表。它发送索引条目，它在您VACUUM FULL时发送全新的表数据，它为回滚的事务发送数据等。因此它会产生大量的噪声＆＃34;并发送大量多余的数据。它还要求副本完全相同，因此您无法执行任何需要事务的操作，例如创建临时表或未记录的表。查询副本会延迟复制，因此需要取消副本上的长查询。
作为交换，在副本上应用更改非常简单有效，并且副本与主服务器可靠地完全相同。 DDL透明地复制，就像其他所有东西一样，因此它不需要特殊处理。它还可以在发生大事务时对其进行流式传输，因此即使对于大的更改，主服务器上的提交和副本服务器之间的提交也几乎没有延迟。
物理复制已经成熟，经过充分测试并被广泛采用。
逻辑流复制，9.4中的新内容，在更高级别发送更改，并且更具选择性。
一次只复制一个数据库。它仅发送行更改，仅针对已提交的事务，并且不必发送真空数据，索引更改等。它可以选择性地仅为数据库中的某些表发送数据。这使逻辑复制更多带宽效率更高。
在更高级别操作还意味着您可以在副本数据库上执行事务。您可以创建临时和未记录的表。如果你愿意，甚至是普通的桌子。您可以使用外部数据包装器，视图，创建函数，无论您喜欢什么。如果查询运行时间过长，则无需取消查询。
逻辑复制也可以用于在PostgreSQL中构建多主复制，这是使用物理复制无法实现的。
但作为交换，它不能（当前）在发生大流量时进行流式传输。它必须等到它们提交。因此，在提交主服务器和应用于副本的大事务之间可能会有很长的延迟。
它严格按提交顺序重放事务，因此小型快速事务可能会滞后于大事务并被推迟一段时间。
DDL不会自动处理。您必须自己保持主表和副本之间的表定义同步，或者使用逻辑复制的应用程序必须拥有自己的工具才能执行此操作。要做到这一点可能很复杂。
申请过程本身比＃34更复杂;写一些字节，我告诉＆＃34;同样。它在副本上也需要比物理复制更多的资源。
当前的逻辑复制实现尚未成熟或广泛采用，或者特别易于使用。
呼。复杂，对吧？我甚至没有详细了解延迟复制，广告位，wal_keep_segments，时间表，推广工作方式，Postgres-XL，BDR和多主管等等。
那么你应该做什么？
没有一个正确答案。否则PostgreSQL只会支持这种方式。但是有一些常见的用例：
对于备份和灾难恢复使用pgbarman进行基本备份并为您保留WAL，从而提供易于管理的连续备份。您仍应定期pg_dump备份作为额外保险。
高可用性，零数据丢失风险使用流同步复制。
对于具有低数据丢失风险和更高性能的高可用性，您应该使用异步流复制。要么启用WAL归档以进行回退，要么使用复制槽。使用Icinga等外部工具监控副本在主服务器后面的距离。