使用GCP Database Migration Service迁移800G MySQL库出现1062复制错误

• 全量dump未启用一致性快照：针对InnoDB引擎的大库，如果导出时未加--single-transaction参数，2天多的导出窗口内源库的写入操作会导致同一行被多次写入dump文件，后续增量同步时Binlog的写入事件就会和已导入的行触发主键冲突。
• DMS默认dump逻辑缺陷：GCP DMS默认的全量导出逻辑对超大库的事务边界处理存在适配问题，若源库存在长时间未提交的事务，dump捕获的Binlog起始位点会发生偏移，导致增量阶段重复执行已经包含在全量dump中的写入操作。
• 非事务引擎的干扰：如果报错的pacsdb.content_item表使用MyISAM等非事务引擎，--single-transaction参数不会生效，导出期间的写入会直接导致dump文件包含重复数据。
• 隐性触发器写入：虽然已经调整了触发器、视图的定义者，若源库存在行级触发器在导出期间写入目标表，也会导致全量dump已包含对应行，增量同步时重复触发写入。

• 手动执行符合GCP规范的全量dump，推荐使用以下参数：

mysqldump -u[源库用户名] -p[源库密码] --databases pacsdb \
--single-transaction --quick --lock-tables=false \
--master-data=2 --flush-logs \
--triggers --routines --events \
--skip-definer \
> full_dump.sql

其中--master-data=2会在dump文件头部记录精确的Binlog起始位点，--skip-definer自动将所有对象的定义者替换为root@%规避权限问题，--quick适配大库导出降低内存占用。

• 手动将dump文件导入GCP Cloud SQL实例后，使用DMS的仅增量同步模式创建迁移任务，指定dump文件中记录的Binlog位点作为同步起始点，避免全量阶段重复导出。
• 若确认冲突行和源端数据完全一致，可在DMS任务的「高级设置」->「错误处理」中添加规则，跳过Error_code 1062的主键重复错误，该方案适合冲突行数极少的场景。
• 迁移前暂停源库非必要的定时写入任务，尽量选择业务低峰期启动全量导出，压缩dump总耗时，减少导出窗口内的写入干扰。

内容的提问来源于stack exchange，提问作者Renato Melo