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

[porpoiselxj]

【 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主键冲突，我这张表压根连主键都没有，只有几个普通索引， 分区表

[春风十里 (Ti D Ber F Vf Ce7m B)]

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

[TIDB-Learner]

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

[dba远航 (Ti D Ber M Lo7 Bqhk)]

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

[porpoiselxj]

@春风十里

致有重复数据出现了，可以把所有列group by 一下，看看是否有重复

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

[porpoiselxj]

这个感觉有可能

[porpoiselxj]

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

[luancheng]

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

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

[Soysauce520]

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

[porpoiselxj]

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

[luancheng]

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

[porpoiselxj]

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

[luancheng]

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

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

[kkpeter (Upstream889)]

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

[双开门变频冰箱 (Ti D Ber 2 Qq Dt F0 O)]

rowid？

[porpoiselxj]

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

[zhanggame1 (Ti D Ber G I13ecx U)]

tso+1试试

[porpoiselxj]

还是不行