PostgreSQL 物理复制和逻辑复制有什么区别？

简化版

PostgreSQL 物理复制是按存储层和 WAL 记录复制整个数据库集群的数据变化，常用于主备高可用和读扩展。逻辑复制是按表级别发布和订阅数据变更，复制的是逻辑层面的 INSERT、UPDATE、DELETE，常用于部分表同步、跨版本迁移、数据分发。物理复制更像整库镜像，逻辑复制更像选择性数据同步。

详细版

两者区别可以这样看：

对比项	物理复制	逻辑复制
复制粒度	整个数据库集群或实例级数据变化	数据库对象级，常见是表
复制内容	WAL 物理变化	逻辑数据变更
常见用途	主备高可用、只读副本	数据迁移、部分同步、数据分发
版本要求	通常要求环境更一致	可用于更灵活的版本迁移场景
订阅端可写性	备库通常只读	订阅端是普通库，但同步表写入要谨慎

面试回答要强调：物理复制适合高可用复制，逻辑复制适合按业务对象做数据同步。

完整版教学

一、物理复制是什么

物理复制可以理解为把主库的底层数据变化通过 WAL 传给备库，备库重放这些 WAL，保持和主库一致。

它常见于：

主从架构；
读写分离；
故障切换；
灾备；
只读报表查询。

物理复制的优点是成熟、完整、适合整库一致复制。缺点是粒度较粗，通常不是为“只同步某几张表”设计的。

二、逻辑复制是什么

逻辑复制基于发布和订阅模型。发布端指定要发布哪些表，订阅端订阅这些变更。

简单示例：

CREATE PUBLICATION pub_order FOR TABLE orders;
CREATE SUBSCRIPTION sub_order
CONNECTION 'host=... dbname=... user=... password=...'
PUBLICATION pub_order;

它关注的是逻辑数据变化，比如某表插入、更新、删除了哪些行，而不是底层数据页怎么变化。

三、物理复制适合高可用

如果目标是主库故障后快速切换到备库，物理复制更常见。因为它复制范围完整，备库状态接近主库整体状态。

典型架构是：

一个主库接受写入；
一个或多个备库接收 WAL；
备库用于只读查询或故障接管；
监控复制延迟和故障状态。

要注意复制延迟。异步复制下，主库提交成功后备库可能还没完全追上；强同步配置能提高一致性，但会影响写入延迟和可用性。

四、逻辑复制适合迁移和分发

逻辑复制适合：

只同步部分表；
拆库迁移；
跨版本升级；
把业务数据同步到分析库；
多系统之间分发数据变更。

但逻辑复制也有边界，比如表结构变更需要额外处理，冲突和主键设计要谨慎，订阅端对同步表的写入容易制造一致性问题。

五、选择时看目标而不是看名字

如果你要的是“备库能完整接管主库”，优先考虑物理复制。如果你要的是“只把订单表同步到另一个库”，逻辑复制更匹配。

工程上还要关注：

是否允许数据延迟；
是否需要跨版本；
是否只同步部分数据；
是否需要故障切换；
订阅端是否还会被其他业务写入。

六、常见误区与追问

目标	更适合	原因
主备高可用、故障接管	物理复制	整库级、状态完整
部分表同步、拆库迁移	逻辑复制	表级发布订阅
跨版本升级和数据分发	逻辑复制	粒度更灵活

记忆钩子：物理复制像“整库镜像”，逻辑复制像“表级数据订阅”。先问目标是高可用接管，还是选择性同步。

比如一个主库每秒产生 50MB WAL，物理备库需要持续接收并重放这些 WAL，延迟超过 10 秒时只读查询可能读到旧数据；逻辑复制如果只发布 orders 和 payments 两张表，传输粒度更小，但表结构变更、主键、冲突处理就要单独治理。

误区：逻辑复制可以直接替代高可用主备。 逻辑复制适合数据同步和迁移，不等价于完整实例级故障接管。
误区：物理复制可以只同步某几张表。 物理复制粒度通常是实例/集群级，不是按业务表灵活选择。
误区：复制没有延迟。 异步复制一定可能延迟，延迟大小取决于 WAL 生成、网络、重放速度和负载。
追问：逻辑复制为什么要求关注主键？ 订阅端需要识别 UPDATE/DELETE 影响哪一行，没有稳定主键会让同步和冲突处理更复杂。
追问：订阅端能不能写同步表？ 技术上订阅端是普通库，但对同步表写入容易产生冲突和数据分叉，通常要严格限制。
追问：物理复制和 WAL 有什么关系？ 物理复制依赖 WAL 传输和重放，备库通过重放主库 WAL 追赶状态。

七、加强记忆

物理复制记成“整库级、WAL 重放、主备高可用”，逻辑复制记成“表级发布订阅、逻辑变更、迁移和分发”。面试时先说复制粒度，再说使用场景，最后补充延迟、冲突和结构变更这些工程风险。

简化版

详细版