TiDB v5.1.2 版本 TiCDC 不同步及 checkpointTs 不推进的问题排查

网友投稿 503 2024-03-20



问题现象

环境

集群版本:v5.1.2

TiDB v5.1.2 版本 TiCDC 不同步及 checkpointTs 不推进的问题排查

Tidb server:16c 32g 7台

Ticdc 机器:16c 64g 2台高可用

问题发生版本:v4.0.9 v4.0.13 v5.1.2

Tidb server 发生oom后,ticdc checkpointTs 不向前推进,尝试pause changefeed后未恢复,尝试使用tiup重启cdc组件后未恢复。

检查ticdc日志出现大量warning日志:

[2022/01/30 11:17:55.761 +08:00] [WARN] [region_worker.go:377] ["region not receiving resolved event from tikv or resolved ts is not pushing for too long time, try to resolve lock"] [regionID=40982339] [span="[7480000000000016ffa05f72f000000019ff3a9b7b0000000000fa, 7480000000000016ffa05f72f000000019ff7319ad0000000000fa)"] [duration=17m21.65s] [lastEvent=93.273628ms] [resolvedTs=430836713476849684]

[2022/01/30 11:17:55.771 +08:00] [WARN] [region_worker.go:743] ["The resolvedTs is fallen back in kvclient"] ["Event Type"=RESOLVED] [resolvedTs=430836713699672811] [lastResolvedTs=430836984350245604] [regionID=31134532]

TiDB server oom监控

Tidb cdc监控

问题排查

TiDB server oom原因排查

从相关慢查询中

初步排查结果是研发当时查询dashboard慢查询页面导致tidb server发生oom

dashboard的慢查询页面导致oom,从4.0版本到5.1.2版本,曾经多次发生,目前版本还存在该问题,在未来的版本中会得到修复。

目前的缓解方案:

尽可能减少 slow-log 文件的数量比如定期做 slow log 的归档删除或设置 log.file.max-days,调大 slow query 的阈值log.slow-threshold。

在查询时选择时间范围选小一点,比如一小时以内,并尽量避免多人并发查询 slow query 。

查询时尽量不要使用order by排序功能。

目前tidb在分析oom问题上提供了一个oom tracker工具,能将当时的top memory sql以及heap统计到tidb server的tmp目录下以供分析,较以前版本来说,排查问题相对简单容易很多。

TiCDC 问题排查

从监控中可以看到,在tidb server oom后,部分tikv节点中resolved-lag增大

通过cdc研发人员确认,tidb在事务中对相关表加乐观或悲观锁,当tidb server oom后,相关锁未正常释放,且region merge会阻塞resolveLock功能,导致lock无法释放

在最新的5.1.4版本中,已经修复了该问题

问题处理

5.1.4版本及之后版本

tidb server oom后cdc进程checkpointTs 不向前推进问题可以得到解决,不需要特别进行处理。

5.1.4之前的版本需要手动处理

Workaround:

上一次出现类似问题,使用select count(*) from tb_name,通过对表做count操作来释放相关锁。

也有可能会遇到 count 表后没有恢复的情况。

如果是悲观锁的话,select count 无法解锁,也有可能锁存在于 index 上,select 需要使用 use index,即每一个 index 都 count 一次。

如何判断count后锁是否被释放

当count(*)后启动changefeed进程且cdc log中出现大量"The resolvedTs is fallen back in kvclient"日志时,说明锁未被释放。释放锁之前建议暂停问题链路,问题链路会导致正常链路checkpointTs也不向前推进的情况。

问题修复:kv client 触发 resolved lock 的逻辑有问题,不能及时触发,详见:

https://github.com/pingcap/tiflow/issues/2867

相关信息

fallback resolvedTs event skips the lock resolving unexpectly · Issue #3061 · pingcap/tiflow · GitHub

https://github.com/tikv/tikv/pull/11991

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:TiDB TiCDC 的应用实践
下一篇:TiDB v5.2.3 版本内存使用率高的几个案例分析
相关文章