序

今天上线一个 binlog监听和 分发到 业务端的中间系统, 刚上线 告诉我 ReplicationSlot延迟 比较大

。。。。不要这么搞啊 ，我刚想缓缓。。。。

背景

阿里云数据库配置了 slot 延迟256M就发送监控信息，这不，触发了。。。线上现在有大数据的 slot和 我的binlog 新服务的slot

出问题 现在只能先想想新上的服务了。。。。。。

问题定位

binlog 服务

我首先去 binlog的服务 写个脚本 查下 error，（有监控，但是我还是习惯再去看一遍 哈哈），查出 没有异常

我的slot一直在 几十kb 到十几兆浮动

这个查询结果是 从下面语句得出

select pg_replication_slots.*, pg_current_wal_lsn(), pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_insert_lsn(), restart_lsn)) as delay_size from pg_replication_slots;

我遇到一个95M延迟的，binlog slot 显示1m以内的误差

也正常情况

方案调研

到这了，我想知道 当时slot 延迟的是哪个slot导致的，我心里 对自己写的还是很自信，不应该出问题 哈哈

毕竟用了 阿里云

正常情况 感觉阿里云应该有啊，找了一会，没找到，走起，问问阿里云的人

这就是告诉我 现在没有这个功能呗。。。。好吧

解决办法

解决办法： 1 下次监听到了 我们执行下 上面的sql

1.1 如果是binlog slot 延迟，就要加大 binlog 接收能力，看参数 应该可以提高每次拉取的size

1.2 如果不是，我们再继续看

2 配置 prometheus 针对每一个slot

binlog 开发的时候 容易忽视的点

跑在线上 好好的告诉我 slot延迟

后台 跑的很正常，但是触发了 slot延迟的监控，收到了报警，一看 是我的binlog slot报错了，但是执行一次 我监控的表 执行一个语句 就slot正常了

想到是不是可能 没有我监控的表 修改了，我没有处理导致的落后

在官网找到了 下面这段话

大概意思是：

正在跟踪的数据库中有许多更新，但只有很少一部分更新与连接器捕获更改的表和模式相关。这种情况可以通过周期性心跳事件轻松解决。设置heartbeat.interval.ms连接器配置属性。

用这个保持心跳，就可以了，不会让slot 延迟太多

控制连接器向Kafka主题发送心跳消息的频率。默认行为是连接器不发送心跳消息。

当正在跟踪的数据库中有许多更新，但只有极少数更新与连接器正在捕获更改的表和模式相关时，就需要使用心跳消息。在这种情况下，连接器像往常一样从数据库事务日志中读取数据，但很少向Kafka发出更改记录。

这意味着没有偏移量更新提交到Kafka，连接器没有机会将检索到的最新LSN发送到数据库。数据库保留WAL文件，其中包含连接器已经处理过的事件。发送心跳消息使连接器能够将最新检索到的LSN发送到数据库，从而允许数据库回收不再需要的WAL文件所使用的磁盘空间。