专栏首页数据库架构之美为什么要慎用replication slot?

为什么要慎用replication slot?

复制槽概念

复制槽(replication slot)在postgresql9.4版本中被引入,引入之初是为了防止备库需要的xlog日志在主库被删除,主库会会根据备库返回的信息确认哪些xlog已不再需要,,才能进行清理。同时主库不会移除那些导致恢复冲突的行,关于恢复冲突,前面有一篇文章讲到过可以通过设置hot_standby_feedback、max_standby_streaming_delay等参数进行预防,但是这些参数只有在主备关系正常时才能起到作用,而replication slot能够确保在主备断连后主库的xlog仍不被清理。

复制槽分为物理复制槽physical replication slot和逻辑复制槽logic replication slot。物理复制槽一般结合流复制一起使用,能够很好的保证备库需要的日志不会在主库删除,本文重点讨论逻辑复制槽。

Logic replication slots一般被用于逻辑异步复制,一个很好的应用就是用于异构数据库之间的逻辑复制。大致原理是将源端xlog进行解码,解析成具体sql,然后到目标端进行回放。支持逻辑解码需要将wal_level设置为logic,logic会在replica的基础上增加一些信息以支持逻辑解码,该模式会增大wal日志的数量,尤其是大量的update,delete操作的库。

逻辑复制槽的出现算是一个创新,相当于官方将xlog解码功能提供到源码中,这是做逻辑同步工具公司的福音,公司只需要使用pg_recvlogic等逻辑解码工具或pg_logic_slot_get_changes()等SQL接口函数将xlog解析成sql文本在目标端回放即可。

需要关注的问题

对于逻辑复制槽,有下面几点需要注意:

①一个逻辑复制槽只能解码一个database,但是一个database可以有多个复制槽进行解码,同一个复制槽可能同时有多个接收端进行订阅。

②复制槽的消息只发送一次,同时它不关心接收端的状态,如果接收端执行失败,那么复制槽不会向前推进,接收端成功后继续从上次失败的位点继续进行消费。

③不支持DDL、列存、压缩表的解码,DDL一般需要需要创建额外的触发器来进行处理,但可以做到表级订阅。

④逻辑复制不能保证数据不丢失,不能用作数据容灾,但是可以用于数据迁移,在主库有大事务的情况下延迟较大。

⑤不使用的复制槽一定要及时删除。

慎用replication slot

上面的第五点是需要特别注意的,也是我说慎用replication slot的原因。笔者在生产环境多次遇到因为逻辑复制槽造成xlog堆积的问题。我们知道当主备断连的时候逻辑槽会保证主库不清理xlog,这样就会造成xlog堆积。其实不仅是主备断连,当主库没有更新业务的时候,主库的xlog也不会清理,有些人可能会说了,主库都没有业务了,根本就不会生成xlog,那么也不会有xlog堆积的问题了,看似解释很完美,但是我们试想下面这个场景。

如果是多租户的环境呢?如果我在使用一个集群,比如pgxc,集群上有多个数据库,我们为了保证rpo接近0,使用了逻辑复制的方案,其中有两个库都需要同步,需要建立两个逻辑槽。如果其中一个业务很繁忙,每天有大量的跑批操作,但是另一个库不是那么繁忙,或者说在节假日的时候没有业务,这时就需要特别小心了。因为两个库其实共用的是一份xlog日志,其中一个库很麻烦产生大量的xlog,但是另一个库没有业务,会造成该库的逻辑槽的restart_lsn始终不往前推进,这样就造成主库的xlog没法删除,最终造成主库的磁盘爆掉。笔者生产环境中曾经遇到过xlog堆积好几万个的情况,好在当时磁盘容量够大,没有发生事故。

最佳实践

所以在生产环境中如果使用replication slot,有下面几点建议:

①可以增加xlog日志个数的监控,当xlog数量超过正常值时通知dba查找原因。

②做好对每个复制槽同步状态的监控,出现某个槽同步状态异常要及时处理,同步异常会造成lsn不向前推进。

③对于业务很空闲但是数据需要同步的库,可以自定义脚本,定期更新无用表,手工推进lsn。

④如果xlog已经堆积很多磁盘马上要爆炸的情况下,在考虑应急删掉复制槽之前要评估剩余空间是否还有足够富余,因为即使删掉复制槽,xlog也不是马上就会清理,删掉后主库vacuum也会产生较多xlog日志,一定要做好评估。

⑤增加pg_replication_slot()视图中restart_lsn的监控,对于落后较大和长期不推进的lsn进行告警。

好吧,加油吧。

本文分享自微信公众号 - 数据库架构之美(databasekernel),作者:数据库架构之美

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-11-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 我们使用PostgreSQL的物理复制槽做什么?

    不知道是否有人关注到下面这个错误日志,在一个异步流复制的环境中,我们在主库看到如下日志:

    数据库架构之美
  • PostgreSQL的元组、页面结构及索引查找原理

    我们知道postgresql数据库通过数据多版本实现mvcc,pg又没有undo段,老版本的数据元组直接存放在数据页面中,这样带来的问题就是旧元组需要不断地进行...

    数据库架构之美
  • 史上最全-oracle12c pdb迁移实践

    Oracle在12c版本引入了多租户的概念,在一个cdb的根容器下可以创建多个pdb供不同用户使用,cdb中主要保存数据库元数据,而pdb中保存用户数据,各个p...

    数据库架构之美
  • 8篇CVPR2019论文开源合集(含3D目标检测/目标跟踪/语义分割和实例分割)

    本文将分享收集到的CVPR 2019 已开源paper,并将内容同步上传到 CVPR2019-Code上。如果想第一时间了解开源代码,那么大家 star/for...

    Amusi
  • 【答疑释惑】指针的奥妙

    从一个指针的例子说起,head指向链表的头: 1.ptr=head; head=NULL; 2.ptr2=head; head=head->next; head...

    程序员互动联盟
  • 【观点】英国BBC的大数据之路:用户本位、去中介化与大数据化

    作者:李继东 中国传媒大学广播电视研究中心研究员、博士,《全球传媒蓝皮书》、《国际传媒蓝皮书》、《国际传播蓝皮书》执行主编。 近来,BBC 新闻与时事部主任、新...

    小莹莹
  • session跟踪失效的问题和分析(57天)

    最近碰到一个奇怪的问题,在生产和其他比较正式的环境中进行sql trace都没问题,但就是测试环境的数据库不知道怎么的, 设置sql_trace,开启诊断事件,...

    jeanron100
  • 只需4秒,这个算法就能鉴别你的LV是真是假

    导语:假冒奢侈品制造这个屡禁不止的灰色产业,每年给正品商家和消费者造成上千亿的损失,对企业和消费者造成伤害。作为全球奢侈品巨头,LVMH 对假冒奢侈品的打击十分...

    AI科技大本营
  • Valgrind 使用入门

    Valgrind 是一套类似于 gprof 的动态检测的工具集,由于使用方便,不需修改目标程序源码,输出清晰图文并茂等优势,常被用作后台(特别是linux后台)...

    王纯
  • css3动画效果

    transform:2D变形: 通过 CSS3 转换,我们能够对元素进行移动、缩放、转动、拉长或拉伸。转换方法:translate()/rotate()/sca...

    用户3159471

扫码关注云+社区

领取腾讯云代金券