前言
在这篇文档中[1]，我们了解了物理复制和逻辑复制的区别，本章内容主要聚焦于逻辑复制的使用场景，当了解了适用场景后，会使得业务架构更加灵活。
场景一：数据汇总与拆分
当多个独立的业务库需要将数据汇总到数据仓库，以便于进行后续分析的场景，逻辑复制是非常适合的。一是不需要额外的组件来支撑，二是可以做到实时同步。 对于数据拆分的场景，由于逻辑复制的粒度可以到表级别，可以将一个数据库按照表的粒度拆分到不同的数据库实例中。
场景二：数据库迁移
PostgreSQL 提供了原生的迁移工具 pg_dump，适用于数据量小的一次性迁移，最大的缺点就是业务停机时间长，性能较差。反观逻辑复制，可以实现实时的增量迁移，业务上停机时间更短。
场景三：数据库升级
在数据库版本升级升级过程中，除了就地升级和逻辑的导入导出，由于逻辑复制可以跨大版本的特性，也可以作为数据库版本升级的方案。
场景四：多云场景
在多云场景中，物理复制是很难实现的，有如下几点原因：
- 不同云厂商提供的 PostgreSQL 版本不同
- 云厂商会根据自身 RDS 提供的功能特性，对内核进行不同程度的修改，导致物理复制可能不兼容。
- 由于安全，架构等原因，云厂商通常不会开放物理复制接口
对于逻辑复制则不存在这样的问题，通常可以很好的支持上述物理复制很难覆盖的场景。
总结
由于逻辑复制的诸多优点，可以为业务架构提供更多的可能性。可以在备库可读可写，数据库迁移，版本升级等场景中发挥作用。
参考文档
[1] 如果您有其他问题，欢迎您联系火山引擎技术支持服务
