上游删表重建,BR pitr 导致下游出现了多张表

【TiDB 使用环境】生产环境
【TiDB 版本】6.5.4
【操作系统】centos7
【部署方式】机器部署(48核 256G 3T nvme)* 6

上游集群通过 br pitr备份到对象存储,并每6小时恢复到下游集群一次。

发现在上游删表重建后,下游出现了 库名.表名完全一样的表

{
"select * from INFORMATION_SCHEMA.TABLES where table_name='citation'": [
	{
		"TABLE_CATALOG" : "def",
		"TABLE_SCHEMA" : "doi",
		"TABLE_NAME" : "citation",
		"TABLE_TYPE" : "BASE TABLE",
		"ENGINE" : "InnoDB",
		"VERSION" : 10,
		"ROW_FORMAT" : "Compact",
		"TABLE_ROWS" : 0,
		"AVG_ROW_LENGTH" : 0,
		"DATA_LENGTH" : 0,
		"MAX_DATA_LENGTH" : 0,
		"INDEX_LENGTH" : 0,
		"DATA_FREE" : 0,
		"AUTO_INCREMENT" : null,
		"CREATE_TIME" : "2025-03-12 15:05:09",
		"UPDATE_TIME" : null,
		"CHECK_TIME" : null,
		"TABLE_COLLATION" : "utf8mb4_bin",
		"CHECKSUM" : null,
		"CREATE_OPTIONS" : "",
		"TABLE_COMMENT" : "引文",
		"TIDB_TABLE_ID" : 13148,
		"TIDB_ROW_ID_SHARDING_INFO" : "NOT_SHARDED",
		"TIDB_PK_TYPE" : "CLUSTERED",
		"TIDB_PLACEMENT_POLICY_NAME" : null
	},
	{
		"TABLE_CATALOG" : "def",
		"TABLE_SCHEMA" : "doi",
		"TABLE_NAME" : "citation",
		"TABLE_TYPE" : "BASE TABLE",
		"ENGINE" : "InnoDB",
		"VERSION" : 10,
		"ROW_FORMAT" : "Compact",
		"TABLE_ROWS" : 0,
		"AVG_ROW_LENGTH" : 0,
		"DATA_LENGTH" : 0,
		"MAX_DATA_LENGTH" : 0,
		"INDEX_LENGTH" : 0,
		"DATA_FREE" : 0,
		"AUTO_INCREMENT" : null,
		"CREATE_TIME" : "2025-03-13 14:34:21",
		"UPDATE_TIME" : null,
		"CHECK_TIME" : null,
		"TABLE_COLLATION" : "utf8mb4_bin",
		"CHECKSUM" : null,
		"CREATE_OPTIONS" : "",
		"TABLE_COMMENT" : "引文",
		"TIDB_TABLE_ID" : 13238,
		"TIDB_ROW_ID_SHARDING_INFO" : "NOT_SHARDED",
		"TIDB_PK_TYPE" : "CLUSTERED",
		"TIDB_PLACEMENT_POLICY_NAME" : null
	}
]}

这个问题与 tispark Multiple entries with same key如何删除INFORMATION_SCHEMA.TABLES表里的数据 是同一情况。
现在是数据无法写入该表,影响备份。

我感觉你是br 的pitr当成是mysql binlog那种用法了。

br一直要求下游集群做恢复的时候是空集群,且不能有任何写入。

你6个小时就br pitr恢复一次,其实就是6个小时追赶一下上游的数据库的状态。
这个需求应该考虑ticdc做。而不是br做。

我们有ticdc和br两套备份。

官网上写的pitr可以如此使用

你们 br pitr 每 6 小时追一下增量,是怎么做的?
命令发来看看。

截取了部分恢复日志

看下恢复日志呢

上面发了任务开始时的日志,这一段是任务结束时的日志。
查询其它历史日志也没有报错。

没有报错么。

没有任何报错。。

感觉是不是记录的br日志里面,没有表重建这些日志条目啊。可以找个环境测试验证一下(删除、创建表),验证能否增量恢复,是不是这个引起。

应该不是,肯定是有表重建这条日志条目的,不然下游不能出现两个创建时间

cdc使用有什么问题么?为啥用这么麻烦方式

1 个赞

3楼已经说了,我们有ticdc和br两套备份。
场景:如果误删了数据或库表,ticdc同步到下游,且已经超过了gc时间。那仍然可以在br备份的集群中把数据恢复回来。

1 个赞

有点奇怪啊

重启下呢。

br-pitr备份是后台任务。查看状态是正常的,查询最早和最近的可恢复时间点 也都是正常。且我每次定时脚本恢复的时候,时间肯定是在 最早 和 最近 的时间范围之内的。

有没有可能是br备份的时候,表删除这样的tikv变更记录没有收集

删除后的信息有可能保留在备份表里,重启试下。

试了下,不行。