由于MySQL 5.6支持将于下个月结束，我们正在准备迁移。
数据库托管在AWS Aurora上，如果我们只是简单地将引擎升级到5.7，我们可以在线进行（RDS Aurora支持蓝/绿升级），或者我们可以使用5.7创建一个新的数据库，并使用DMS与CDC进行实时复制。
现在，复杂的是我们还想将许多表的数据类型从INT更改为BIGINT，因为我们很快就会用完空间。
为此，我们正在探索两种方法：
1.拍摄原始数据库的快照（不拍摄binlog位置），将其恢复到新的5.7数据库集群，运行ALTER TABLE以更改主键数据类型，并启动从原始数据库到新数据库的实时复制。
1.创建一个新的5.7空数据库。使用新的BIGINT数据类型创建表，然后从原始数据库开始复制以填充表。
在这两种方法中，有一些不明确的地方，我希望得到建议：
- 在方法（#1）中，现有索引将被重新索引到新的BIGINT类型，作为
ALTER TABLE命令的一部分。然而，考虑到表的大小，这可能需要很长时间（非常长的时间）。 - 然而，使用方法（#2），我们不确定现有索引会发生什么。我们是否必须删除所有现有索引，然后用新的数据类型重新索引？
有没有其他更有效的方法来实现这一点？我们计划在新数据库与原始数据库速度相同时进行切换，因此这两种方法的停机时间相同。
我不确定哪种方法可以保证在更改数据类型时保持数据完整性？
谢谢你。
1条答案
按热度按时间tv6aics11#
复制不会填充空表。它只复制更改，而不是初始数据。您仍然必须先执行解决方案1。
我建议使用免费工具pt-online-schema-change来修改表。它实际上比使用ALTER TABLE要花费 * 更长的时间 *，但不会出现停机时间。它允许您在修改表的同时继续阅读表。因此时间长度不会让人紧张。此外，使用此解决方案，您不需要使用副本。您可以在主服务器上进行更改。在我的上一份工作中，我们每周使用pt-online-schema-change运行数百个更改。
这种解决方案的唯一缺点是，它要求在进程的开始和结束时刻对表进行独占访问，除非您倾向于让长时间运行的事务抑制这一点，否则这不是问题。
像任何新工具一样，您应该在非生产示例上测试它，直到您确信自己知道如何使用该工具。不要在生产数据上第一次尝试任何工具！
这两种解决方案都将更改所有辅助索引，作为更改主键索引的一部分。无论采用哪种方法，这都将自动发生。