(DMS) 将数据“按原样”复制到 Aurora MySQL，然后借助自定义转换脚本将其转换为与新应用程序版本兼容。
我们使用架构比较工具来比较开发和 UAT 环境中的源架构和目标架构。根据这些差异，我们创建了针对转换后的 SQL Server 架构运行的 SQL 脚本。这种多管齐下的方法促进了迁移过程的顺利和成功，确保了迁移数据的兼容性和完整性。
执行
我们的实施过程涉及几个关键步骤：
在无服务器架构上选择带有 MySQL 8.x 的 Aurora：这一决定为我们现代化的数据库环境奠定了基础。
PHI 数据的转换：我们采取了额外的预防措施，以确保在迁移过程中 PHI 数据的安全转换。用于加密/解密 PHI 数据的脚本。
模式转换和数据类型：将 SQL Server 模式和数据类型适配到 Aurora MySQL 是一项细致的任务，涉及修复日期时间格式、自动增量和缺失索引。许多对象必须重命名和更改，以解决数据类型和列名的差异。我们还必须用新数据预先填充查找表，创建触发器、函数、存储过程、视图和索引。
利用 DMS 进行数据迁移：我们尝试利用 AWS DMS 进行数据迁移。但是，在利用转换规则处理具有不同数据类型的列、必须重命名的表、blob 和文本数据时，我们遇到了问题。
分阶段方法：我们将迁移分为几个阶段，从开发、UAT、预生产 波斯尼亚和黑塞哥维那电报数据 阶段开始，最后切换到生产阶段。这种方法使我们能够彻底验证每个步骤。
模式比较和数据验证：我们在模式比较和数据验证方面投入了大量精力，以确保数据完整性。
与开发团队的合作：与开发团队密切合作以修复 SQL 和对象对于成功迁移至关重要。
查询优化：查询优化和重新访问嵌套视图、存储过程和函数对于性能优化至关重要。
切换规划：多次迭代的切换规划帮助我们顺利执行了最终的迁移。
数据库最佳实践：在整个迁移过程中，我们遵循数据库最佳实践，以促进无缝过渡。
结果和反馈
我们的努力最终成功从本地 SQL Server 迁移到 Aurora MySQL。此迁移涵盖数据库和全栈应用程序。多个团队之间的协作是我们成功的关键因素。迁移后，我们的重点转移到稳定性和性能调整，以及强大的备份和恢复实践。