黄东旭解析 TiDB 的核心优势
462
2024-02-22
[toc]
【2023-06-15 12:56:01】业务反馈ticdc没有日志同步到kafka,于是我就查看了一下ticdc任务状态,发现已经出现异常,但是奇怪的是没有发出告警。
本文就简单记录一下,包括问题现象,问题解决,以及问题分析及规避,仅供参考。
??
?
可以看到是因为数据包太大导致同步失败,但是dba并没有收到相关告警。
现在首要任务就先恢复业务,于是想着重建任务,重建过程中发现GC已经过期了
??
?
2023-06-15 13:02:58 这个时间点完成了重建任务,并开始追堆积的数据。
??
?
重建任务后,可定位到丢失数据的时间段:
报错点位:442142592159449107
重新新建任务同步开始点位:442168771222437888
现在登录到pd将tso换成时间,如下:
??
?
可以知道大概丢失了28小时的日志。
现在排查一下cdc为什么没有报错,或者说alertmanager为什么没有告警。
通过下面的告警信息可以发现刚重建完cdc任务,alaertmanager就告警说延迟过大了,所以应该可以排除alertmanager故障,就是说告警通道正常。
??
?
现在排查cdc节点的日志,总共三个cdc节点。下面挨个排查
第一个节点
??
?
第二个节点
??
?
第三个节点
??
?
可以发现三个节点在故障期间【2023-06-13 15:08:57至2023-06-14 18:53:22】都没有日志记录下来,所以我猜想,是不是任务没有被注册到cdc里面呢。
之前就遇到过,删除报错的cdc任务后,alertmanager还是会一直报错【cdc错误的任务】,需要重启cdc节点才会停止报错,所以这次的问题是不是也是类似的,cdc内部根本没有这个任务,所以这个任务报错就不会被触发告警。
如何规避这类问题呢,我能想到的规避问题的方式就是:
1、做完新建,或者其他更新之类的操作,挨个reload一遍cdc节点。
tiup cluster reload clustername -R cdc2、添加任务后主动触发一次告警。
比如同步数据从十分钟前的tso开始同步,这样就会触发延迟告警。
3、定期巡检cdc任务的状态。
tiup cdc:v4.0.13 cli changefeed list --pd="http://xxx:xxx"本文对cdc任务报错但未触发告警问题做了简单的记录,并分析,仅代表个人想法,各公司的业务场景也不一样,还可能碰上其他未知的问题,本文所有内容仅供参考。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。