对于热点问题，我上面发的监控图可以看到，抖动的时候是所有的tikv cpu 都飙升的。 年前不操作了，年后回来再看。多谢！

监控上看昨晚7点之后就很少波动了，到了23:00 左右有一波突增的请求，抖动就又起来了 [图片] [图片] 今天上午看着还是有抖动的现象。 [图片] 今天上午的一个慢查询情况 [图片] 这次看着是读取到缓存了，但是还是慢 [图片] 另外也问下胡杨同学的那个问题： 最大可见数和最大遇到的版本数分别代表什么意思？ 我现在的gc_life_time 设置了20m，为啥还是这么多版本？ [图片]

好的，多谢多谢。明天我再看看。我看最近三个小时已经没有大的抖动了

手动查看的执行计划和表结构如下： [图片] 表的健康度如下： [图片] 手动执行 [图片] 那个时间点我在慢日志里看到的是几分钟内2000多次的请求，对应的dashboard 上topsql 就是下图 [图片] 我的判断就是tbl_device_phone_log 相关的 sql 请求量大导致的coprocessor 比较忙，具体的原理分析不出来 不知道是不是跟我之前设置的两天的GC 导致扫描的历史版本过多导致的。运行一晚上，明天我再看看监控。 [图片]

我们mysql 上下游都是5.7的，通过dm 同步的。你们是啥版本的mysql，是校验的主从架构吗 ？

这个我看到了，明确说明不支持mysql – tidb 的在线校验，不知道mysql - mysql 的行不行。因为群里有哥们说可以，所以需要跟官方再确认下。我测试的结果是会卡主的

[tidb@db-tidb-238-146 tidb-toolkit]$ bin/sync_diff_inspector --version App Name: sync_diff_inspector v2.0 2.0版本的

已协同网络组的同学排查到原因： 1.我们买的阿里云的云服务器是没有开通外网网关的 2.在配置了公司自己的代理后，这个代理是有很多访问限制的。因此也是报错 解决办法： 阿里云同学开通了主机的外网访问网关。问题解决

1.最开始部署的是2.0.6, 后来升级到了2.0.7 。具体时间点记不住了 2.是开启过relay log。目前我们每个同步任务都会打开relay-log 我把今天操作的时间点梳理下: 1.查看worker 的状态，显示有一个free 的worker [%E5%9B%BE%E7%89%87] 2.创建了一个同步任务 worker 中对应的日志为: [2021/12/10 17:33:39.695 +08:00] [INFO] [relay.go:683] ["flush meta finished"] [component="relay log"] [meta="master-…

好的。我下周再让他们把其他的参数都调整一下。多谢

我上面的描述可能不太清楚哈。 第一次是将kafka 的那个参数 message.max.bytes 从一个较小的值调整到了10M(不是从12M 调整到了10M), 调整之前多大我不清楚 下图是维护人员调整完的截图 [%E5%9B%BE%E7%89%87] 当时cdc 的延迟在很短的时间内就消除了延迟，没想到晚上又开始延迟了 [%E5%9B%BE%E7%89%87] 我下周一再让他们调整下kafka 其他的几个参数 另外还有一个疑问，如果是kafka 消费慢，应该是只有checkpoint 有延迟，为啥上图中的Processor Resolved ts lag 也很大呢 ，我下…

完蛋，又延迟了。还是麻烦给看看我上面的配置有没有优化的空间吧，感觉要救不活了

腾讯云最大的这个值是12M. 之前不知设置的多少，维护人员改成10M 后延迟下来了。但是今天又特么延迟了，还在排查

应该怎么标注，之前是可以设置为有用。我自己这个怎么弄？ [%E5%9B%BE%E7%89%87]

==========> 目前问题已基本定位到了。 我们使用的下游kafka 是腾讯云的, 参数 message.max.bytes 最大是12M. 当前这个参数设置的额值较小。 我们创建的changefeed 的max-message-bytes=1048576 设置为10M,如果超过这个值就会报错message too large. 联系了kafka 的维护人员将腾讯云kafka 的message.max.bytes 设置为10M, ticdc 同步瞬间追平了。问题解决 [%E5%9B%BE%E7%89%87]

https://asktug.com/t/topic/153141 https://asktug.com/t/topic/122900

应该是我要同步的表数量太多了。一共一万多。已反馈官方的老师进行确认了 我重新创建了两个表的同步，就正常了

刚才复现了下那个index 的问题 在上游执行了修改字段的操作 alter table sbtest1 modify column pad varchar(90); 从varchar 100 到 varchar90 tidb-server 日志输出如下 [2021/07/29 17:43:50.585 +08:00] [ERROR] [conn.go:801] ["connection running loop panic"] [conn=1771] [lastSQL="DELETE FROM `oom`.`sbtest1` WHERE `id` = 280594 LIMIT 1;"…

今天又遇到了这个问题 [ { "id": "tidboom-task", "summary": { "state": "normal", "tso": 426470011965276162, "checkpoint": "2021-07-21 15:53:08.515", "error": { "addr": "192.168.149.156:8302", "code": "CDC:ErrProcessorUnknown", "message": "[CDC:ErrMySQLT…