【 TiDB 使用环境】生产环境
【 TiDB 版本】7.5.4
【遇到的问题：问题现象及影响】
在之前我们使用 TIDM v5.3.0 版本来做 TIDB 合表任务, 通过使用 column-mappings 来对id做值映射, 很容易的可以解决不同表ID冲突的问题, 现准备新部署一套环境7.5.4版本的, 发现 column-mappings 不给用了. 看了一下最新的文档要么去掉主键, 要么使用联合主键. 除了这些还有没有什么简单的方式, 实现低版本类似于ID值映射的功能.
【原有配置】
column-mappings:
tables:
schema-pattern: “db”
table-pattern: “table_[0-9]*”
expression: “partition id”
source-column: “id”
target-column: “id”
arguments: [“1”, “db”, “table”, “_”]
【报错的日志】
{
“result”: false,
“msg”: “[code=20064:class=dm-master:scope=internal:level=high], Message: column-mapping is not supported since v6.6.0, Workaround: Please use extract-table/extract-schema/extract-source to handle data conflict when merge tables. See https://docs.pingcap.com/tidb/v6.4/task-configuration-file-full#task-configuration-file-template-advanced”,
“sources”: [
],
“checkResult”: “”
}
主要是为了解决合表的时候ID冲突的问题, 之前版本分表ID直接映射到合表ID, 分表ID即使一样, 最终映射到合表的ID也不一样, 保证了ID的唯一性. 这个文档我看了新版本每个合表还要新增字段. 成本有点高. 而且也没法直接解决ID冲突的问题. 所以想问问有没有和老版本类似的做法。
主要是为了解决合表的时候ID冲突的问题, 之前版本分表ID直接映射到合表ID, 分表ID即使一样, 最终映射到合表的ID也不一样, 保证了ID的唯一性. 这个文档我看了新版本每个合表还要新增字段. 成本有点高. 而且也没法直接解决ID冲突的问题所以想问问有没有和老版本类似的做法。
最好的办法上游直接不重复，用分布式序号生成算法，如 Snowflake 算法
分表ID即使一样, 最终映射到合表的ID也不一样
映射的问题是，两个库id都不一样，迁移是迁移了，怎么溯源呢？迁移出错都要看上半天。
而且万一要从合表迁回分表又该怎么办呢？多加个字段的意思就是你迁回来也能迁回去，还能溯源。
1 个赞
好吧 改造成本有点高
好的 我想了解一下就是实践中, 建议怎么解决分表合表ID冲突的问题
1 个赞
分批次迁移：对于大型表，可以考虑分批次进行数据迁移，并在每次迁移时应用一致性的ID映射规则；或者使用临时表：先将数据迁移到一个临时表中，在这个过程中应用所需的ID映射逻辑，然后通过批量更新操作将处理后的数据转移到最终的目标表中，不过代价都不小
1 个赞
你好 这个有 示例 或 文档 吗 新版本怎么用一致性的ID映射规则.