database - 流复制和逻辑复制的区别

Question

有人能告诉我更多关于 PostgreSQL 中物理复制和逻辑复制之间的区别吗？

Answer 1

TL;DR:逻辑复制发送逐行更改，物理复制发送磁盘块更改。逻辑复制更适合某些任务，物理复制更适合其他任务。
请注意，在 PostgreSQL 12(更新时的当前版本)中，逻辑复制稳定可靠，但非常有限。如果您要问这个问题，请使用物理复制。

流式复制可以是逻辑复制。这一切都有些复杂。
WAL 运输与流媒体
在 PostgreSQL 中有两种主要的方式将数据从 master 发送到 replica:

WAL-shipping 或连续归档，从 pg_xlog 复制单个预写日志文件由 archive_command在主服务器上运行到其他位置。一个 restore_command在副本的 recovery.conf 中配置在副本上运行以获取文件，以便副本可以重放 WAL。
这是用于时间点复制 (PITR) 的内容，用作连续备份的方法。
不需要到主服务器的直接网络连接。复制可能会有很长的延迟，尤其是没有 archive_timeout放。 WAL 传送不能用于同步复制。

流式复制，其中每个更改在发生时直接通过 TCP/IP 连接发送到一个或多个副本服务器。副本必须具有主服务器在其 recovery.conf 中配置的直接网络连接。的 primary_conninfo选项。
只要副本足够快以跟上，流式复制几乎没有延迟。它可用于同步复制。您不能对 PITR1 使用流复制，因此它对于连续备份没有多大用处。如果你在主服务器上删除一个表，糟糕，它也会被删除到副本上。

因此，这两种方法具有不同的目的。
异步与同步流
最重要的是，还有同步和异步流复制:

在异步流复制中，当 master 更快/更忙时，允许副本及时落后于 master。如果 master 崩溃，您可能会丢失尚未复制的数据。
如果异步副本落后于主节点太远，如果 max_wal_size，主节点可能会丢弃副本所需的信息。 (以前称为 wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's pg_wal (was pg_xlog)如果 max_wal_size 可能会填满并停止主服务器工作，直到磁盘空间被释放为止太高或使用了插槽。

在同步复制中，在副本确认收到事务之前，主节点不会完成提交。如果 master 崩溃并且您必须故障转移到副本，您永远不会丢失数据。主节点永远不会因为副本延迟而丢弃副本所需的数据或填满其 xlog 并耗尽磁盘空间。作为交换，如果副本出现问题，它会导致主节点变慢甚至停止工作，并且由于网络延迟，它总是对主节点产生一些性能影响。
当有多个副本时，一次只有一个是同步的。见 synchronous_standby_names .

您不能进行同步日志传送。
您实际上可以将日志传送和异步复制结合起来，以防止在落后太多时必须重新创建副本，而不会影响主服务器。这是许多部署的理想配置，结合监控副本在主服务器后面的距离以确保其在可接受的灾难恢复限制范围内。
逻辑与物理
最重要的是，我们有逻辑与物理流复制，如 PostgreSQL 9.4 中所介绍的:

在物理流复制中，更改几乎是在磁盘块级别发送的，例如“在关系 12311 的磁盘页 18 的偏移量 14 处，写入了十六进制值为 0x2342beef1222 的元组......”。
物理复制发送一切:PostgreSQL 安装中每个数据库的内容，每个数据库中的所有表。它发送索引条目，当您 VACUUM FULL 时发送整个新表数据。 ，它会为回滚的事务发送数据等。因此它会产生大量“噪音”并发送大量多余数据。它还要求副本完全相同，因此您不能执行任何需要事务的操作，例如创建临时表或未记录的表。查询副本会延迟复制，因此需要取消对副本的长时间查询。

作为交换，在副本上应用更改既简单又高效，并且副本与主副本可靠地完全相同。 DDL 是透明复制的，就像其他一切一样，因此不需要特殊处理。它还可以在大事务发生时流式传输，因此即使发生大的更改，在 master 上提交和在副本上提交之间也几乎没有延迟。
物理复制已经成熟、经过充分测试并被广泛采用。

逻辑流复制是 9.4 中的新增功能，可以在更高级别和更有选择性地发送更改。

它一次只复制一个数据库。它只发送行更改，并且只发送已提交的事务，而不必发送真空数据​​、索引更改等。它可以选择性地只发送数据库中某些表的数据。这使得逻辑复制的带宽效率更高。
在更高级别上操作还意味着您可以在副本数据库上执行事务。您可以创建临时表和未记录的表。如果你愿意，即使是普通的 table 。您可以使用任何您喜欢的外部数据包装器、 View 、创建函数。如果查询运行时间过长，也无需取消查询。
逻辑复制也可以用于在 PostgreSQL 中构建多主复制，这是使用物理复制无法实现的。
但是，作为交换，它(目前)不能在发生大交易时进行流式传输。它必须等到他们提交。因此，在 master 上提交的大事务和应用于副本之间可能会有很长的延迟。
它严格按照提交顺序重放事务，因此小的快速事务可能会卡在大事务后面并延迟很长时间。
DDL 不会自动处理。您必须自己保持主表和副本之间的表定义同步，或者使用逻辑复制的应用程序必须有自己的工具来做到这一点。要做到这一点可能很复杂。
应用过程本身也比“在我被告知的地方写一些字节”更复杂。与物理复制相比，它在副本上占用的资源也更多。
当前的逻辑复制实现并不成熟或广泛采用，或者特别容易使用。
选择太多，告诉我该怎么做
呼。很复杂吧？我什至没有深入了解延迟复制的细节，插槽， max_wal_size 、时间线、推广方式、Postgres-XL、BDR 和 multimaster 等。
那你该怎么办？
没有唯一的正确答案。否则 PostgreSQL 将只支持这种方式。但是有一些常见的用例:
对于备份和灾难恢复使用 pgbarman为您制作基础备份并保留 WAL，提供易于管理的连续备份。您仍然应该定期服用 pg_dump备份作为额外的保险。
为了实现零数据丢失风险的高可用性，请使用流式同步复制。
为了获得低数据丢失风险和更好性能的高可用性，您应该使用异步流复制。要么为回退启用 WAL 归档，要么使用复制槽。使用 Icinga 等外部工具监控副本落后于主副本的距离。
引用

continuous archiving and PITR

high availability, load balancing and replication

replication settings

recovery.conf

pgbarman

repmgr

wiki: replication, clustering and connection pooling