使 Amazon RDS 迁移顺利进行的 8 个专业提示

RDS迁移的残酷事实是，它们永远不会顺利进行，但这并不意味着它们必须是火车残骸。Mission 已将无数公司迁移到 RDS，我们学到了很多关于可能出错的地方以及如何避免这些陷阱的知识，或者至少为它们做好准备，以最大限度地减少项目进度的麻烦和中断。

这是最重要的一课：计划事情不要100%按计划进行。顺利迁移的关键是不要期望一切都完美无缺;它能够与拳头一起滚动，在可以做到的地方领先一步，并在出现问题时做出有效反应。问题并不意味着有人搞砸了;它们是将数据库迁移到云中不可避免的部分。

考虑到这一点，我们有一些提示可以与您分享，这些提示应该可以帮助您提前解决最可能的问题领域。

RDS 提示 #1：将您的数据视为最有价值的资产（因为它可能是！

对于许多企业来说，他们的数据是他们最宝贵的资产，但许多公司在备份和备份过程中偷工减料。我的意思是，我明白了：这是一件很容易推迟的事情，因为您有更紧迫的事情要处理（而且您正在计划迁移！你很忙！但是考虑到迁移中负面结果的范围，我敢打赌，你很难想出比丢失或损坏公司数据更糟糕的事情。

因此，在执行其他任何操作之前，请确保您的备份坚如磐石。对于我们在 RDS 外部管理的每个数据库，我们每周至少手动检查一次备份，以确保它们没有失败。在开始迁移之前，请确保备份已经过测试，并且定期监视备份过程。请记住：备份对每个企业都是必不可少的，但未经测试的备份几乎没有实际价值。

RDS 提示 #2：给自己时间进行迁移

锁定备份后，您可以开始考虑实际迁移到 RDS。首先要考虑的是这个过程，从开始到结束，需要多长时间。根据我们的经验，您应该计划至少四周的开始到结束 – 这是假设您确切地知道自己在做每一步，并且您的旅程异常顺利。因此，从一开始就给自己一个休息时间并计划更长的时间，这样您就不会觉得自己在第 1 天落后于计划。

RDS 提示 #3：更多数据 = 更多时间迁移（可能更多）

规划 RDS 迁移时要考虑的最重要问题之一是数据库的大小。您需要迁移的越少，整个过程最终就越容易（和更快）。这似乎很明显，但记住这一点非常重要，因为您也许可以稍微帮助自己。

考虑这个真实世界的示例，说明为什么考虑数据库的大小很重要。我有一个朋友在一家正在迁移到 RDS 的大型在线零售商工作。他们的数据库已经膨胀到超过一TB。您可以看到原因：他们的整个产品目录都在那里，包括他们不再出售的存档商品。他们确实在为大型数据库而苦苦挣扎，而且在假日购物季之前迁移到 RDS 的时间有限，他们处于枪口之下。（将其添加到 RDS 噩梦场景列表中：您为零售商工作，无法获得支持假日购物的数据库。绝对不是一个好的结果！

我朋友的解决方案很简单：只迁移您需要的内容。通过从数据库中删除已停产的项目，他们能够将数据库的大小减少 75%！将数据库列入减肥计划不仅意味着他们有时间赶上迁移截止日期，而且还提高了整体网站性能，因为搜索花费的时间要少得多！

RDS 提示 #4：最大限度地减少停机时间，但设定切合实际的目标

如果您询问技术团队以外的人您在迁移期间可以承受多少停机时间，到目前为止，您会听到的最常见的答案是“无”。好的，是的，我明白了：我们都希望在零停机时间的情况下进行迁移。

零停机迁移绝对是可行的，但它们也肯定更复杂。如果您能承受一些停机时间，一个好方法是现实地计划它。作为一般经验法则，数据集越大，您应该预期和计划的停机时间就越多。导出/导入是迁移数据的最简单方法，但应测试运行导出/导入并对其进行计时，以查看该过程需要多长时间。这将为您提供合理的初始停机时间估计。同样，不要根据最佳情况制定计划;在你设定的期望中要合理。

如果无法选择停机时间，则需要配置实时流式传输复制直接转换。这个过程有很多工具和选项——MySQL、Postgres、bucardo、Oracle Data Pump，仅举几例——如果本机选项无法正常工作，您可以随时回退到 Amazon 的数据库迁移服务（简称 DMS）。

关于导入的最后一点：确保关闭多可用区以及所有备份和复制 – 您要做的最后一件事是在整个云基础架构中部署功能失调的数据库！导入它，然后重新打开所有这些东西。

RDS TIp #5：版本注意事项和不兼容性

迁移到 Aurora 有一些怪癖，其中一个主要问题是版本考虑。如果可能，我们始终建议在执行迁移时保持使用主要版本。如果出于某种原因您无法做到这一点，由于与版本相关的特性，您应该期望在迁移上花费额外的时间和精力。或者更好的是，在开始迁移之前升级（或降级）您的数据库以匹配 Aurora 中的内容。

使用本机 MySQL 复制从 MySQL 迁移到 RDS 时，您需要设置 bin 日志配置以符合 RDS 的要求。更重要的是，请确保您的备份点是最新的，以防您需要执行回滚。如果您使用 Amazon DMS 执行迁移，请确保在开始迁移之前实施任何其他源配置更改，例如 bin 日志格式和过期日志编号，这确实需要重新启动。否则，您将在迁移失败后争分夺秒地实施这些更改。

许多较旧的解决方法和临时修复不适用于 RDS。例如，RDS 不允许使用超级权限。如果您的 mysqldump 包含需要超级用户权限的命令，则需要更新该备份文件才能将其放入 RDS。

RDS 提示 #6：AWS DMS 和数据类型的怪癖

当它运行良好时，AWS的数据库迁移服务（DMS）是天赐之物，但它是AWS发布的更挑剔的工具之一。DMS可用于从一个数据库平台移动到另一个数据库平台，并且它擅长于数据类型较少的相对简单的数据集。但请注意：DMS 在尝试标准化列数据类型时，最终可能会转换它们。

DMS 确实可以节省一些时间，但前提是/如果它有效。AWS 正在努力消除对数据类型转换的需求，但目前，您需要在开始迁移之前查阅主列表，并且需要定期检查主列表的更新。如果您的数据类型不在列表中，则可能应该完全远离 DMS，除非您确信这些更改不会影响您的应用程序功能。

RDS 提示 #7：查看现有的许可、工具和第三方产品障碍

如果没有适当的规划，许可问题将变成主要的迁移障碍或可能的重大意外成本。许可是一项昂贵的投资，坦率地说，像甲骨文这样的公司并没有让迁移到云变得容易。如果您已经投资，我们强烈建议您在使用 Oracle Microsoft或 RDS 数据库类型时使用 BYOL（自带许可证），而不是浪费投资和购买新许可证。一定要花时间做一个完整的TCO（总拥有成本）细分，看看哪种许可方法最经济有意义。

关于在云中运行应用程序或工具的注意事项：由于 RDS 在数据库服务器上没有操作系统，因此您无法直接在数据库中运行任何应用程序或工具。相反，您需要在其他地方配置它们，例如在 EC2 实例中。对于引用这些可执行文件的任何过程也是如此。Oracle和Microsoft数据库通常就是这种情况。

RDS 提示 #8：获取所需的 RDS 支持

RDS 和 DMS 的最大好处之一是它们都是来自亚马逊云科技的托管产品。许多首次迁移者试图仅依靠 AWS 开发人员支持，但根据我们的经验，这不太可能足够。AWS 业务级别支持非常值得额外投资，如果您从一开始就使用它，您将节省大量时间和麻烦。

那么，RDS值得吗？

绝对。是的。100%.

毫无疑问，迁移到 RDS 有一个学习曲线，但迁移到 RDS 将为您的组织带来非常实际的好处。借助 RDS，您可以期望看到总拥有成本 （TCO） 的改善、正常运行时间的延长、性能的提高和数据库备份成本的降低。与运行您可能更熟悉的数据库软件的 EC2 实例相比，您在保持数据库正常运行、正确备份、同步到副本和监控数据库方面所花费的工作量远远超过了 RDS 的额外成本。花时间攀登学习曲线，你不会后悔的！

通过安排 30 分钟的 SA 按需部署来开始您的 RDS 迁移，您可以在其中与我或我们的其他工程师讨论您需要采取哪些步骤来准备迁移 – 只需让他们知道 Kiril 发送给您！

8 Pro Tips for Making an Amazon RDS Migration Go Smoothly (missioncloud.com)