向下游tidb集群同步binlog,延迟逐渐增加,如何定位问题

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

你好,请收集反馈完整的 pump 和 drainer 的监控信息:

(1) chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl

(2) 鼠标焦点置于 Dashboard 上,按 ?可显示所有快捷键,先按 d 再按 E 可将所有 Rows 的 Panels 打开,需等待一段时间待页面加载完成。

(3) 使用这个 full-page-screen-capture 插件进行截屏保存

1、监控 Drainer Event 看到这段时间存在批量 delete 和 update 等 DML 操作,可能是造成同步延迟高的原因,建议先调大 txn-batch 和 worker-count 参数;

2、监控 Execution time 比较高,也可能是下游执行比较慢,检查下游 TiDB 集群的负载和慢查询日志,是否有性能问题。

调整后的参数,txn-batch:2000; worker-count:128 下游有一台机器时不时的负载会升高,既是pd,tidb也是tikv。 下图是根据slow_query 表按照 query_time 排序。延迟还在增大,已经超过35个小时。

image

slow_query 主要是 select 查询,没有发现 drainer 同步过来的 DML,方便的话传一下修改配置后的 drainer 日志,检查其中记录的 sql 执行时间。

drainer.log (17.6 KB)

日志显示看到 worker-count: 128 参数已经生效,下面显示 table has no any primary key and unique index,检查同步的表是否有主键或唯一索引;如果没有,在同步时为了保证事务的顺序,无法将事务拆分到不同的线程中,不能有效利用 worker count 提高并发,同步性能会大大下降,建议为表增加主键或唯一键。