drainer报meet causality.DetectConflict exec now

🪐 TiDB 技术问题 备份&数据迁移
1

【 TiDB 使用环境】生产\测试环境\ POC
生产环境

【 TiDB 版本】
5.1.x

【遇到的问题】
drainer日志大量报如下日志，请问有影响吗，是什么意思？
meet causality.DetectConflict exec now

【复现路径】做过哪些操作出现的问题
【问题现象及影响】
【附件】

  • 相关日志、配置文件、Grafana 监控（https://metricstool.pingcap.com/)
  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息
  • TiDB-Overview 监控
  • 对应模块的 Grafana 监控（如有 BR、TiDB-binlog、TiCDC 等）
  • 对应模块日志（包含问题前后 1 小时日志）

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

2

有冲突了，最好缩小一下范围，看看哪些表产生了冲突

3

上游tidb集群的确有写写冲突，但是为什么会影响draienr同步到下游集群？而且下游集群监控上并没有写写冲突。其实这个问题主要对drainer同步速度造成了影响，同步速度很慢。谢谢

4

如果方便的话麻烦提供下 Drainer 日志。

上游tidb集群的确有写写冲突，但是为什么会影响draienr同步到下游集群？

背景：Drainer 为了提高同步效率，会使用多个“线程”（即 goroutine）并发写下游 MySQL。

由于会并发写，所以 Drainer 需要对上游的事务进行冲突检查，不然会导致下游出现冲突，导致同步性能降低。
当出现冲突时，Drainer 就会报 meet causality.DetectConflict exec now。

而且下游集群监控上并没有写写冲突。其实这个问题主要对drainer同步速度造成了影响，同步速度很慢。谢谢

由于冲突在 Drainer 侧提前检查并规避了，所以下游不会出现写写冲突。
Drainer 冲突检测比下游的冲突检测代价要小很多，但如果上游的写入模式是对热点更新，那还是会导致同步变慢，整体同步的速度接近于下游热点更新的速度上限。

5

1、drainer日志没有过多信息，基本都是 meet causality.DetectConflict exec now。
2、通过以上大佬们的答复，再加分析集群监控分析可以得知：上游tidb集群大量写冲突导致了drainer同步速度变慢，导致drainer同步延迟增加，多谢。
还有一个疑问，想问下
对于tidb集群的热点写入，我们容易排查。但是对于这里提到的热点更新，一般如何分析？是否有对应监控或者什么日志来协助分析？
从tidb监控来看，replace这类sql明显大量增多，导致了以上问题的发生。

6

对于tidb集群的热点写入，我们容易排查。但是对于这里提到的热点更新，一般如何分析？是否有对应监控或者什么日志来协助分析？

TiDB 文档提供了热点相关的最佳实践，推荐阅读

7

多谢。

8

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。