AWS Aurora MySQL 5.6迁移至5.7并修改主键数据类型的高效方案咨询

方案2的索引处理 #

• 新建5.7空库时，直接按原表结构（仅将主键类型改为BIGINT）创建新表，原表的非主键索引可同步定义，无需删除重建。
• 注意事项：若原表有依赖主键的二级索引（如联合索引包含主键）或外键关联，需同步将关联字段类型改为BIGINT，避免类型不匹配。
• 若用工具（如mysqldump、DMS）自动生成表结构，务必校验索引字段类型与新主键的兼容性，防止出现索引失效或数据插入失败。

更高效的替代方案 #

方案A：Aurora快照 + 在线DDL工具（pt-online-schema-change/gh-ost） #

1. 基于原5.6集群创建快照，记录对应binlog位置，恢复至新5.7集群。
2. 在新集群上使用pt-online-schema-change或gh-ost执行主键类型变更：
   • 这类工具采用临时表增量同步、原子切换表名的方式完成DDL，不会锁表，且避免了原生ALTER TABLE一次性重建大表索引的高耗时问题。
   • 操作顺序建议：先恢复快照，再执行在线DDL，最后启动CDC同步（从快照记录的binlog位置开始），确保增量数据能无缝同步到变更后的表中。

方案B：AWS DMS全量+增量同步时直接转换字段类型 #

1. 提前在新5.7库创建好所有主键为BIGINT的表结构（包含原表所有索引、约束）。
2. 配置DMS迁移任务：
   • 全量阶段：通过DMS表映射规则，将原库INT类型主键自动转换为BIGINT。
   • 增量阶段：开启CDC同步，确保原库后续写入的增量数据正确同步至新库。
   • 优势：无需在新库执行任何DDL，全量迁移时直接完成类型转换，流程更简洁，且DMS的CDC同步可靠性高。

数据完整性对比 #

两个拟定方案均可保障数据完整性，但需注意操作细节：

• 方案1：
  • 只要快照的binlog位置记录准确，CDC从该位置启动同步，即可保证增量数据与新库变更后的表结构兼容（INT最大值完全在BIGINT范围内，无类型溢出问题）。
  • 风险：原生ALTER TABLE重建大表索引会占用大量IO资源，可能导致新集群性能下降，甚至引发CDC同步延迟。
• 方案2：
  • 只要新表结构完整复刻原表的索引、约束，且使用DMS这类支持全量+增量衔接的工具，数据完整性可完全保障。
  • 风险：手动创建表结构时若遗漏索引或约束，会导致数据一致性问题，建议通过工具生成并校验表结构。

结论：优先推荐方案B（DMS全量+增量类型转换），效率更高且出错概率低；若依赖Aurora快照能力，方案A（快照+在线DDL）是更优替代。数据完整性方面，规范操作下两个方案均达标，但方案B的可靠性更突出。

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