CDC:ErrMySQLTxnError]MySQL txn error: Error 8141

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

【 TiDB 使用环境】生产环境
【 TiDB 版本】V6.5.5
主备集群使用cdc进行数据同步，cdc报错导致同步链路中断，报错信息：

image
image2527×469 30.9 KB

"code": "CDC:ErrChangefeedUnretryable",
        "message": "[CDC:ErrReachMaxTry]reach maximum try: 8, error: [CDC:ErrMySQLTxnError]MySQL txn error: Error 8141: assertion failed: key: 7480000000006eb78d5f69800000000000003f0419b322f5cf0566d003a40000001216bfa8, assertion: Exist, start_ts: 453107210747641857, existing start ts: 0, existing commit ts: 0: [CDC:ErrMySQLTxnError]MySQL txn error: Error 8141: assertion failed: key: 7480000000006eb78d5f69800000000000003f0419b322f5cf0566d003a40000001216bfa8, assertion: Exist, start_ts: 453107210747641857, existing start ts: 0, existing commit ts: 0"
2
  1. 这个同步任务应该是无法恢复了，需要手动进行重建。
  2. checkpoint 卡住的时间是 14:10, 但是错误的报出时间是 17:40, 看起来似乎是别的原因先导致同步中断。
  3. 这个错误的具体含义参考这里：https://docs.pingcap.com/zh/tidb/stable/troubleshoot-data-inconsistency-errors#error-8141 ，可以确认下下游 TiDB 是不是一切正常。

如果需要进一步调查确定原因，需要提供 cdc 的日志和相关时间段的监控截图。

3

请问下这个下游的 TiDB 集群是用 BR 恢复出来的吗？如果是的话可能是因为下游这行数据的索引数据在恢复的时候丢失了，需要对相关表在下游重建下索引。

执行类似如下的 SQL 来确认对应的表，然后重建索引。

select tidb_decode_key('7480000000006eb78d5f69800000000000003f0419b322f5cf0566d003a40000001216bfa8');
4

中断最开始的原因是下游tidb节点的4000端口不通，修改为4001端口之后，checkpoint 推进了一会，然后报这个错误。下游数据库是通过br恢复的，是需要在下游数据库执行select tidb_decode_key(‘7480000000006eb78d5f69800000000000003f0419b322f5cf0566d003a40000001216bfa8’);然后重建索引吧。我这边试下

6

已解决，非常感谢
select tidb_decode_key(‘7480000000006eb78d5f69800000000000003f0419b322f5cf0566d003a40000001216bfa8’); 找出对应的表，执行：ADMIN CHECK TABLE *** ，删除有问题的索引，重新启动changefeed，现已恢复正常

1 个赞
7
  1. 检查数据一致性：
  • 确认主备集群的数据是否一致。可以使用TiDB提供的工具，如tidb-controller-manager的syncer功能，来检查数据的一致性。
  1. 检查事务日志：
  • 检查主集群的事务日志，确认是否有事务日志丢失或者损坏的情况。
  1. 检查CDC配置：
  • 确认CDC的配置是否正确，特别是关于事务日志的配置。
  1. 重启CDC服务：
  • 有时候重启CDC服务可以解决一些临时的问题。
1 个赞