任何人都可以告诉我更多关于PostgreSQL中物理复制和逻辑复制之间的区别吗？
TL; DR：逻辑复制发送逐行更改，物理复制发送磁盘块更改。对于某些任务，逻辑复制更好，对于其他任务则是物理复制。
从9.5开始，逻辑复制还不成熟。如果您问这个问题，请使用物理复制。
流复制可以是逻辑复制。这有点复杂。
在PostgreSQL中有两种主要方法可以将数据从主数据库发送到副本服务器：
pg_xlog通过在主服务器上运行的archive_command复制到其他位置。在副本的restore_command中配置的recovery.conf在副本上运行以获取存档，因此副本可以重放WAL。
这是用于时间点复制（PITR）的，它用作连续备份的方法。
主服务器不需要直接网络连接。复制可能会有很长的延迟，特别是没有设置archive_timeout。 WAL运输不能用于同步复制。recovery.conf的primary_conninfo选项中配置的直接网络连接。
只要副本足够快以便跟上，流式复制很少或没有延迟。它可以用于同步复制。您不能将流复制用于PITR1，因此它不能用于连续备份。如果你在主服务器上删除一个表，那么它也会丢弃在副本上。因此，这两种方法有不同的目的。
最重要的是，有同步和异步流复制：
wal_keep_segments太低且没有使用插槽，则主服务器可能会丢弃副本所需的信息，这意味着您必须从头开始重新创建副本。或者，如果pg_xlog太高或使用了插槽，主控制器的wal_keep_segments可能会填满并阻止主机工作，直到释放磁盘空间为止。synchronous_standby_names。您无法进行同步日志传送。
实际上，您可以将日志传送和异步复制相结合，以防止在副本落后太多时重新创建副本，而不会有影响主服务器的风险。这是许多部署的理想配置，同时监控副本在主服务器后面的距离，以确保它在可接受的灾难恢复限制范围内。
最重要的是，我们有PostgreSQL 9.4中引入的逻辑与物理流复制：
VACUUM FULL时发送全新的表数据，它为回滚的事务发送数据等。因此它会产生大量的“噪音”并发送大量过多的数据。它还要求副本完全相同，因此您无法执行任何需要事务的操作，例如创建临时表或未记录的表。查询副本会延迟复制，因此需要取消副本上的长查询。
作为交换，在副本上应用更改是简单而有效的，并且副本与主服务器可靠地完全相同。 DDL透明地复制，就像其他所有东西一样，因此它不需要特殊处理。它还可以在发生大事务时对其进行流式处理，因此即使对于大的更改，在主服务器上提交和在副本服务器上提交也几乎没有延迟。
物理复制是成熟的，经过充分测试并被广泛采用。唷。复杂，对吧？我甚至没有详细介绍延迟复制，插槽，wal_keep_segments，时间表，促销如何工作，Postgres-XL，BDR和多主管等。
那你该怎么办？
没有一个正确的答案。否则PostgreSQL只会支持这种方式。但是有一些常见的用例：
对于备份和灾难恢复，使用pgbarman进行基本备份并为您保留WAL，从而提供易于管理的连续备份。您仍应定期使用pg_dump备份作为额外保险。
对于具有零数据丢失风险的高可用性，使用流式同步复制。
对于具有低数据丢失风险和更高性能的高可用性，您应该使用异步流复制。要么启用WAL归档以进行回退，要么使用复制槽。使用Icinga等外部工具监控副本在主服务器后面的距离。