ITPub博客

首页 > 数据库 > PostgreSQL > How to Optimize PostgreSQL Logical Replication

How to Optimize PostgreSQL Logical Replication

翻译 PostgreSQL 作者:yzs87 时间:2019-06-12 22:28:48 0 删除 编辑

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


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31493717/viewspace-2647463/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
专注于MySQL、Aerospike、PostgreSQL数据库

注册时间:2017-10-03

  • 博文量
    74
  • 访问量
    46862