How to Optimize PostgreSQL Logical Replication
逻辑复制（Logical Replication）或Pglogical是表级别的复制。两者都是基于WAL的复制机制，允许在两个实例之间复制指定表的WAL。这两个看起来让人迷惑，到底有什么区别呢？Logical Replication是PostgreSQL10.0引入的内置新特性，而pglogical则是一个插件。PG10版本之前可以使用该插件进行逻辑复制，通过持续发展，pglogical的所有特性都集成到了Logical Replication中。换句话说，pglogical插件变成了Logical Replication。Logical Replication最基本的优势在于不用安装任何插件，安装插件受限的环境中，可以推荐使用该逻辑复制。
本博客关注优化Logical Replication。这意味着，优化方法可以同时应用于pglogical以及Logical Replication。
作为DBA，这种复制机制和其他基于触发器的复制机制来说更加可靠，性能更改。逻辑复制的表，发生变化的数据通过WAL记录可以实时复制，这样更加高效并且也没那么复杂。所有其他复制机制都是基于触发器的，这可能会带来性能和维护方面的调整，随着逻辑复制的出现，对基于触发器复制的依赖几乎消失了。
其他博客详细描述了如何配置逻辑复制：
https://severalnines.com/blog/overview-logical-replication-postgresql。
本博客关注如何优化。
优化逻辑复制
首先，Logical Replication的行为和流复制非常像，唯一不同的是流复制对整个database进行复制，而Logical Replication仅复制指定的表。使用逻辑复制时，需要预见一些挑战。
下面我们看下影响逻辑复制的因素。
影响逻辑复制性能的因素
优化逻辑复制时保证无缝复制不会中断非常重要，在搭建前需要注意几个问题：
1）复制表中数据类型
2）复制表或者部分复制表上写事务的频繁性
3）基础设施的容量
4）参数的配置必须最优
以上因素对逻辑复制有较大影响，下面我们详细说明。
逻辑复制数据类型
理解逻辑复制表的数据类型非常重要。如果表存储的是large text或二进制对象，并且又遇到大规模事务，那么由于基础设施资源的限制，复制就会被拖慢。基础设施的容量必须满足处理如此规模的数据。
复制表的活跃性
在复制非常活跃的表时，可能由于IO性能问题、死锁等导致复制落后于同步。这肯能使数据库看起来不太健康。如果需要复制的表比较多并且数据需要复制到多个阶段，那么可能需要很高的CPU使用率，并需要更过的CPU。
基础设施的容量
当使用逻辑复制时，首先需要考虑基础设置的容量。如果需要复制大量表，那么需要充足的CPU。
当需要复制大量表时，可以进行分组并使用并行复制。此时也需要多个CPU用于并行复制。如果数据变化比较频繁，也会影响复制的性能。
优化配置参数
使用逻辑复制功能，需要调优配置参数：
wal_level=’logical’
max_wal_senders=10 # greater than number of subscribers (or replicas)
max_replication_slots=10 # greater than number of subscribers (or replicas)
max_worker_processes=10 # greater than number of subscribers (or replicas)
max_logical_replication_workers # greater than number of subscribers (or replicas)
max_sync_workers_per_subscription # depends on number of tables being replicated
max_wal_senders
max_wal_senders配置值需要大于备机个数。如果数据需要复制到多个节点，那么max_wal_senders就开始起作用，因此这个参数调整到最优很重要。
max_replication_slots
通常，数据的变化会写入到WAL文件中，被称为WAL记录。WAL sender进程会将这些WAL日志发送到备机，备机的wal receiver进程接收这些WAL，然后订阅节点回放这些WAL。
Checkpoint后，可以将pg_xlog/pg_wal中不需要的wal文件删除。如果这些WAL没有在订阅节点回放完时，将这些主机上的文件删除，那么复制就会中断。提供复制槽，可以确保当订阅节点还需要时，主机上的文件不被删除。建议对于每个订阅节点都配置一个复制槽。
max_worker_processes
配置最优的worker进程数也很重要。这依赖于服务最大能够拥有多少进程。在多CPU的环境中才会有效。max_worker_processes通过使用多个CPU核，促使进程以更快的方式完成任务。当使用逻辑复制时，这个参数可以帮助worker进程复制更快。还有一个max_logical_worker_processes参数，指定使用多少worker进程复制数据。
max_logical_worker_processes
这个参数指定最多需要多少logical worker进程复制数据。max_logical_worker_processes的进程隶属于max_worker_processes，比max_worker_processes小。多CPU的环境，复制到多个订阅节点，这个参数才有意义。默认值是4，最大值依赖于系统支持最多worker进程数。
max_sync_workers_per_subscription
这个参数指定每个订阅最多需要多少同步进程。初始数据同步期间，同步进程开始工作，使用整个从那时候可以确保同步更快。目前，一个表只能配置一个同步进程，这意味着多个表可以并行同步。默认值是2，这个值隶属于max_logical_worker_processes。
其他参数包括：wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval，当然这几个参数不会影响发布节点。
结论
在复杂的大规模数据库系统中，复制指定表是常见的需求。逻辑复制可以用于业务报告和数据仓库。作为一个DBA，我认为由于逻辑复制部署简单，非常适合这样的场景。配置调优逻辑复制，需要大量的计划、架构、测试。为了确保复制系统的有效性和可用性，使用逻辑复制时需要评估实时复制的数据量。综上所述，PG10及其之后的版本可以使用逻辑复制，而之前的版本可以使用pglogical。
原文
https://severalnines.com/blog/how-optimize-postgresql-logical-replication
