[toc]
1 背景
【2023-06-15 12:56:01】业务反馈ticdc没有日志同步到kafka，于是我就查看了一下ticdc任务状态，发现已经出现异常，但是奇怪的是没有发出告警。
本文就简单记录一下，包括问题现象，问题解决，以及问题分析及规避，仅供参考。
2 问题定位
可以看到是因为数据包太大导致同步失败，但是dba并没有收到相关告警。
3 问题恢复
现在首要任务就先恢复业务，于是想着重建任务，重建过程中发现GC已经过期了
2023-06-15 13:02:58 这个时间点完成了重建任务，并开始追堆积的数据。
重建任务后，可定位到丢失数据的时间段：
- 报错点位：442142592159449107
- 重新新建任务同步开始点位：442168771222437888
现在登录到pd将tso换成时间，如下：
可以知道大概丢失了28小时的日志。
4 问题排查
现在排查一下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内部根本没有这个任务，所以这个任务报错就不会被触发告警。
5 总结
如何规避这类问题呢，我能想到的规避问题的方式就是：
- 1、做完新建，或者其他更新之类的操作，挨个reload一遍cdc节点。
tiup cluster reload clustername -R cdc
- 2、添加任务后主动触发一次告警。
比如同步数据从十分钟前的tso开始同步，这样就会触发延迟告警。
- 3、定期巡检cdc任务的状态。
tiup cdc:v4.0.13 cli changefeed list --pd="http://xxx:xxx"
6 写在最后
本文对cdc任务报错但未触发告警问题做了简单的记录，并分析，仅代表个人想法，各公司的业务场景也不一样，还可能碰上其他未知的问题，本文所有内容仅供参考。