迁移阶段和注意事项

8 分钟

成功的迁移须平衡多个阶段的注意事项。

迁移阶段

迁移的发生可分为几个阶段。首先，规划迁移范围：发现和评估数据库资源、业务要求（如停机时间）以及迁移失败时的回退计划。然后，准备迁移，预配适当的资源并在源环境和目标环境之间建立连接。设置迁移方法并准备好资源后，通常需要在过渡环境中执行试运行，以在生产迁移之前发现问题。最后，执行最终迁移，并验证其当前进度和成功完成。

本模块重点介绍准备 (2) 和最终迁移 (4、5) 阶段。

迁移注意事项

你应评估应用程序停机时间、版本兼容性、网络和安全性、性能、成本和业务连续性的要求。

应用程序故障时间

你应考虑的首要问题之一是你的业务场景可以接受多长的停机时间。对该问题的回答将强烈限制你可用的迁移选项。

最佳停机时间是用户注意不到的停机时间。实际上，迁移是复杂的过程，有关本模块中注意事项的决策将决定所需的停机时间。权衡包括可用性与迁移的成本和风险。鉴于将停机时间降低到几分钟甚至几秒所带来的复杂性，测试假设并确定可接受的迁移停机时间非常重要。

脱机迁移

使用脱机迁移时，你必须关闭应用程序以移动数据库。这可以保证在迁移过程中不会对数据产生任何更改。但是，此方法需要关闭数据库才能完成数据导出。至少，停机时间将与传输数据的时长相当。脱机迁移涉及：

断开所有应用与源数据库的连接。
导出源数据库的内容。
将源数据导入目标数据库。
导入完成后，将应用程序重新连接到目标数据库。

某些应用程序在低流量期间有计划性维护时段。这些时段是执行脱机迁移的绝佳时机。

增量脱机迁移通过在使应用程序脱机之前移动大量数据来减少停机时间。首先，迁移完整数据库备份。然后，将自上一次迁移以来添加的更改迁移到数据库。如果迁移这些新更改所需的时间符合可接受的停机时间，请使应用程序脱机以冻结数据并完成迁移。你可能会发现，一个迁移增量就足以将停机时间减少一个数量级或更多，尤其是对于有多年历史的数据库而言。对于大型和繁忙数据库，可能需要迁移多个增量才能达到可接受的停机时间。

联机迁移

使用联机迁移时，可以通过在迁移期间将源服务器中的更改复制到目标服务器，然后在复制完全同步时切换到目标服务器，从而大大减少甚至消除停机的需求。

有时，停机时间是不理想的，甚至不可接受。在这种情况下，关闭应用程序来“冻结”数据库状态是不现实的。相反，在正常运行期间，源数据库会被复制到目标数据库中。当目标完全赶上源时，应用程序会切换到目标数据库。

联机迁移要求你：

开始将源数据库复制到目标数据库。
当目标数据库赶上时，通过暂停应用程序或启用只读模式强制写入失败来冻结源数据库。
当目标数据库 100% 赶上更改时，请关闭目标中的复制。
将所有客户端重定向到目标数据库并恢复运行。
关闭旧源数据库。

比较联机和脱机迁移

虽然脱机迁移需要停机，但之前讨论的增量迁移技术大大减少了停机时间。多个增量可将最终迁移缩小到一天的数据量或更少。 Azure DMS 等自动化服务通过执行一系列更小的迁移来最大程度地减少停机时间。如果网络设置阻止了自动化，也可以手动执行增量脱机迁移。

联机迁移跨数据库和应用程序团队协调微妙的操作。客户端应用程序必须进行工具化，从而正常地响应写入失败，以避免迁移期间数据丢失。客户端还必须支持连接到新的数据库服务器，而不会中断用户体验。如果此应用程序工具尚不存在，则构建起来可能相当昂贵。

版本兼容性

大多数应用程序操作都与 MySQL 升级兼容。但是，在某些情况下，应用程序组件或数据库使用情况可能仅适用于某些 MySQL 版本。

检查所有应用程序组件是否都与目标数据库版本兼容。请考虑将版本升级与重新定位或重新配置数据库的迁移区分开。例如，如果从本地 MySQL 5.7 迁移到运行 MySQL 8.0 的 Azure Database for MySQL 灵活服务器，请考虑从本地迁移到运行 MySQL 5.7 的 Azure Database for MySQL 灵活服务器，然后就地从 5.7 升级到 8.0。

网络和安全性

数据库迁移需要将数据从源数据库传输到目标。此过程的发生方式和速度在很大程度上取决于两个网络之间的连接。如果无法建立从源到目标的实时连接，则需要以另一种方式传输物理数据文件，例如通过中间工作站或服务器。在这种情况下，请确保有足够的磁盘空间来存储每个系统上的快照。

在迁移期间考虑安全要求也至关重要。你需要对源数据库和目标数据库具有适当的身份验证和权限。你可能还需要创建服务帐户来执行部分或全部迁移步骤，然后在完成后移除其访问权限。

无论源数据库是在本地还是位于另一个云提供商上，网络设置通常都不允许外部连接。你需要配置网络以允许与 Azure 建立连接。

如果源数据库在本地且数据量很大，则通过常规 Internet 连接移动 TB 级的数据可能会不切实际的缓慢。在此场景中，请考虑在你的网络和 Azure 之间设置 Azure ExpressRoute 连接。

即使使用 ExpressRoute，它所在的连接也可能为其他流量提供服务，并且两者可能会相互干扰。根据争用情况，对现有应用程序和迁移过程的性能影响可能会很大。

性能

数据库迁移是调整基础结构大小来增加容量的绝佳机会。你的数据库使用情况可能会受益于 CPU、RAM 或 I/O 资源的增加。

预配目标服务器之前，请考虑当前的数据库使用情况。监视性能指标（如 CPU 使用率）以及预测增长和 SLA，以确定是否应分配更大的计算大小。相反，你可能会发现容量已过度分配，减小规模可以降低成本。

成本

迁移到 Azure 时，可以利用透明定价。通过你所选的 SKU 和其他参数（例如冗余和高可用性），Azure 定价计算器让你可以在规划期间估算迁移后成本。你还可以使用计算器来为权衡提供信息，例如可用性与成本之间的权衡。

业务连续性

数据库迁移是审查业务连续性指标和目标的好时机。更改备份保留策略或转移到异地冗余备份或高可用性可能是合适的。考虑你的历史运行时间与 SLA 和中断恢复时间。迁移还提供了从物理数据文件建立新数据库的实际示例，这可为灾难恢复计划提供信息。