br数据恢复和ticdc任务数据冲突问题

vcdog · 2023 年9 月 15 日 04:10

【 TiDB 使用环境】测试环境
【 TiDB 版本】主库：v6.5.0 从库：v6.1.5
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
1.使用br备份主库集群全量数据，记录backupTS
2.关闭及删除主库到从库集群之间的cdc任务同步（其中，有一个任务：bj-tj-others任务忘记关闭和remove）
3.销毁从库集群，重新部署新集群，版本为：v6.1.5
4.使用主库的全量备份数据，恢复到新的从库集群中
5.重新创建cdc的同步任务（其他任务都正常，其中，新创建的任务：bj-to-tj-others和之前的bj-tj-others任务冲突，这两个任务中同步的表完全相同）
6.查看cdc组件日志中，发现有报错：RROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY'（这个报错是因为2个任务冲突造成的，可以理解）
7.运行1天后，研发人员发现数据表中，存在2条主键相同的记录

问题：
1.这2条重复的记录，是如何产生的，可以排除bj-tj-others任务和bj-to-tj-others任务冲突，如果有冲突，只会报主键冲突，插入失败。
2.可能是因为bj-tj-others任务一直在开启状态，即使销毁了从库集群，重新部署，在br恢复时，会先创建表结构，如果是bj-tj-others任务先对业务库进行了写入，br再进行导入时，会忽略直接写入。（目前，看到的现象是这样）
3.但是，经过查看官方文档，在 v6.1.3 及之后版本，系统能自动判断下游是否存在重复数据，safe-mode 默认更改为 false ，当系统判断下游无重复数据时，会直接同步 INSERT 和 UPDATE 语句。

所以，现在比较迷惑，这2个主键重复的记录，是怎么产生的？

【资源配置】
【附件：截图/日志/监控】

WalterWj · 2023 年9 月 15 日 05:03

ticdc 写入是逻辑写入，理论上不可能发生多个主键的情况，绕不开 tidb-server 的检查的。

一般你这种是这个表索引数据不一致了，你 admin check table 检查下对应表。你这个表大概率需要重做。

一般出现表数据和索引数据不一致，场景是 Lightning 导入失败，br 恢复导入失败，也就是导入了部分数据，但是有部分数据没进去。会发生你这种情况。

你 br 恢复的时候有其他写入么？

像风一样的男子 · 2023 年9 月 15 日 05:16

数据索引不一致的bug吧
https://docs.pingcap.com/zh/tidb/stable/sql-statement-admin-recover
(https://docs.pingcap.com/zh/tidb/v6.1/troubleshoot-data-inconsistency-errors#error-8223)

TiDBer_oHSwKxOH · 2023 年9 月 15 日 05:50

感觉是其他bug

vcdog · 2023 年9 月 15 日 06:26

我单独使用br备份的主库的全量备份数据，尝试恢复到一个新的集群里，主库和这个新集群之间，没有开启cdc的任务同步，br恢复是可以成功的。

WalterWj · 2023 年9 月 15 日 06:28

那感觉和 cdc 无关，应该就是 br 备份还原之后数据就有问题，你复现下看看。

vcdog · 2023 年9 月 15 日 06:30

这个是在新节点集群使用Br恢复后，进行查询返回的结果。

WalterWj · 2023 年9 月 15 日 06:31

admin check 下表

vcdog · 2023 年9 月 15 日 06:36

admin check进行中。。。，这个表并不大，花费时间不短啊！

WalterWj · 2023 年9 月 15 日 06:39

admin check 的算法有点问题，后续会优化。

vcdog · 2023 年9 月 15 日 06:40

目前，能想到的办法如下：
1.整个从库集群重新使用br恢复，这个比较消耗时间，业务侧不允许。
2.把出问题的几张核心大表，从从库集群中使用Dumpling导出，再修改表结构去掉主键约束，只保留普通索引，再导入到mysql中，通过在mysql中查询对主键字段查重。
3.然后，再对从库集群对应数据进行处理。
4.比较担心的一个问题是，如果bt-tj-others任务中涉及到上百个表，每个都进行判断处理也是有些吃力。

WalterWj · 2023 年9 月 15 日 06:44

我感觉你从库恢复本身 br 恢复就没成功。

vcdog · 2023 年9 月 15 日 06:52

从库集群，恢复后，把cdc任务同步拉起来。同步任务追上后，再通过脚本比较主从库集群的数据count数量是一致的。从库集群是只多不少。

Billmay表妹 · 2023 年9 月 15 日 07:03

这是个已知的 bug 吗？

WalterWj · 2023 年9 月 15 日 07:03

从库集群是只多不少什么意思？理论上不应该一样的么。

WalterWj · 2023 年9 月 15 日 07:05

感觉不像，ticdc 是逻辑写，不可能导致下游主键重复的。之后 lighting local 模式，tispark 回写和 br 这种不过 tidb-server 的检测的、直写 tikv 的有概率出现这种问题，而且是写入异常的情况下。

像风一样的男子 · 2023 年9 月 15 日 07:05

是不是br导入的时候有数据写入？

vcdog · 2023 年9 月 15 日 07:22

br恢复时，原来的那个bj-tj-others任务下的上百张表，应该还在正常同步数据，进行写入操作。

vcdog · 2023 年9 月 15 日 07:25

我的猜测是：在br进行恢复时，那个bj-tj-others任务一直在运行同步中，数据表结构在br恢复时，会先创建表结构，此时，如果有数据同步下发到下游从库集群。cdc会优选把这条记录写入到对应的表中，然后，br在恢复时，忽略重启主键，直接插入。

WalterWj · 2023 年9 月 15 日 07:27

br 恢复的时候不能有其他方法的数据写入的。