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