搭建tidb备库,先pitr恢复,再用cdc同步增量数据异常

【 TiDB 使用环境】生产环境
【 TiDB 版本】v7.1.3
【复现路径】
准备搭建tidb的备库,考虑到之前的版本cdc创建时,延时过大会导致cdc大概率起不来,所以这次采取了这种策略:

  1. 主库部署br log 增量备份
  2. 主库进行全库备份
  3. 备库进行pitr全库+增量恢复,并后续进行了多次的pitr的增量恢复,均未发现异常,都显示恢复成功

4.主库建立cdc,同步增量数据到备库
5. cdc建立后各种报错
6. 继续有pitr增量恢复,还是可以成功。

【遇到的问题:问题现象及影响】

特别是错误中提到 WIND_TB_OBJECT_6489_OPLOG主键冲突,我这张表压根连主键都没有,只有几个普通索引, 分区表

1 个赞

我看报错是duplicate entry 意思是重复的值,虽然后边写了primary,可能只是一种报错的体现。
TiCDC最佳实践要求表有有效索引,其实就是主键或者飞控唯一索引。有没有可能你的表里因为没有主键导致有重复数据出现了,可以把所有列group by 一下,看看是否有重复值。
TiCDC 简介 | PingCAP 文档中心

1 个赞

tidb有隐形主键吧?是不是rowid

1 个赞

使用CDC是不是没有获取到主库的同步起始位置?

1 个赞

此表为分区表,记录日志的流水表,未设置主键和唯一性索引,cdc同步启用了force-replicate 用来支持没有主键和唯一性索引的表同步

1 个赞

这个感觉有可能

1 个赞

这个不应该,tso都是根据下游恢复成功时restore-to输出的来设置的

1 个赞

下游集群恢复后的 tidb_rowid 是多少?

可以通过执行 SQL: show table test.t next_row_id; 查看

1 个赞

没有主键会有问题,_tidb_rowid可能重了。数据也不能保障准确的

1 个赞

这个返回值主备库一致: 958148143, 好像和上面的报错的主键有点远

1 个赞

CDC 日志中能看到报错的那条 DML 语句么?
是 Insert 还是 update?

2 个赞

日志中没看到,但针对这张表我们只有insert操作,没有更新和删除

1 个赞

可否简短的描述下 schema,以及对应恢复步骤。我们尝试复现下

  1. 所有组件版本 version 默认都是 7.1.3。 :white_check_mark:
  2. 表结构(没有主键和唯一索引),以及 insert 语句。 :white_check_mark:
  3. 搭建上下游集群的步骤?
  4. 文中描述的进行多次恢复,那么选取日志备份的时间点分别是多少?
2 个赞

报错写的是Primary 跟rowid 没关系吧

1 个赞

rowid?

1 个赞
  1. 测试了一下,和是否分区表,表有没有主键都没关系,因为我屏蔽了上面报错的表之后,其他的有主键的非分区表也报类似错误
  2. 表结构没有什么特殊的,测试结果看感觉任何一张表都会报错
  3. 上下游集群的配置完全一致,包括硬件和系统参数, 之前在v6.1.1的版本,主备环境是运行过一段时间的,后来cdc报错无法维持,就把备库停了,这次恢复之前是先把备库清空的
    4.每次pitr恢复成功后,都会有 restore-to 记录恢复结束点tso, 拿这个tso作为下次pitr的start-tso
1 个赞

tso+1试试

1 个赞

还是不行

1 个赞

你好,想再次确认一下,创建 changefeed 的时候,操作的步骤是先停止 pitr, 然后用 pitr 的 restore-to 的时间作为 changefeed 的 startTs 吗?

@porpoiselxj 你好!能否帮忙整理一个完整的最小复现步骤?比如包括建表、导入数据等等。如果我们能在内部复现这个问题,就可能更快的定位根本原因。