会不会是执行SQL的客户端设置autocommit=0导致查的是快照数据？

与TiCDC上下游数据同步延迟有关，可以参考TICDC Changefeed相关监控指标： https://docs.pingcap.com/zh/tidb/dev/monitor-ticdc 正常同步不会有非常大的延迟。

canal-json消息的es字段不是全局唯一的，但是全局递增的，还是需要业务侧消费数据时去重。

应该是需要在 ts-map 里面找到距离暂停DC1 CDC任务之前最近的一对上下游tso，拿下游 tso 在 DC4 创建新的CDC任务，然后在业务侧自己处理CDC数据去重。

4 * 4 方阵~ [image]

为TiDB点赞~

许愿能在有生之年看到TiDB实现跨星球高可用，hhhhh~

https://docs.pingcap.com/zh/tidb/v5.1/monitor-ticdc 可以从 Server 和 Changefeed 两个维度对监控指标设置告警规则。 https://docs.pingcap.com/zh/tidb/v5.1/ticdc-alert-rules 提供了一些通用告警规则。

如果ticdc实例宕机，由于ticdc集群本身支持高可用，会在重新选举owner节点之后，将宕机实例的changefeed迁移到其他实例上。

在TiCDC的changefeed中添加 --sync-point，–sync-interval 这两个配置项，可获取到上下游关联的TSO。

已将解决办法整理成博文：https://tidb.net/blog/982a95c6

需要获取到上下游关联的TSO

是的，监控上下游延迟，以及基于TSO做一些数据校验

谢谢！可以发下文档链接吗？

看源码是支持的： https://github.com/pingcap/tiflow/blob/master/cdc/sink/mysql/mysql_syncpoint_store.go#L201 需要通过下游的tidb_cdc.syncpoint_v1表进行查询。

按业务模型设计的表结构有可能需要使用JSON字段存储Object数据, 并使用JSON函数做高效SQL查询, 需要JSON类型支持

+1 TiDB 6 in Action

已报名~~ [baoming]

挎包不错