How to Optimize PostgreSQL Logical Replication

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

你可能感兴趣的:(How to Optimize PostgreSQL Logical Replication)