教程：使用 DMS 复制更改方案从 MySQL 联机迁移到 Azure Database for MySQL 灵活服务器
注意
本文包含对术语“从属”的引用，这是 Microsoft 不再使用的术语。 在从软件中删除该术语后，我们会将其从本文中删除。
可以使用 Azure 数据库迁移服务 (DMS) 将本地或其他云服务 MySQL 服务器迁移到 Azure Database for MySQL 灵活服务器。DMS 是一个完全托管的服务，旨在实现从多个数据库源到 Azure 数据平台的无缝迁移。 在本教程中，我们使用 DMS 复制更改迁移活动将示例数据库从本地 MySQL 服务器联机迁移到 Azure Database for MySQL - 灵活服务器（两者均运行版本 5.7）。
使用“启用事务一致性”的脱机方案运行复制更改迁移，使企业能够在数据库保持正常运行的同时将其数据库迁移到 Azure。 换句话说，可以使用最短的停机时间完成关键应用程序迁移，限制对服务级别可用性的影响以及对最终客户造成的不便。
本教程介绍以下操作：
- 在 DMS 中创建 MySQL 复制更改迁移项目。
- 运行复制更改迁移。
- 监视迁移。
- 执行迁移后步骤。
先决条件
要完成本教程，需要：
使用选择的 MySQL 命令行工具确定是否在源服务器上启用了log_bin。 默认情况下，Binlog 并非始终都已启用，因此请在开始迁移之前验证它是否已启用。 若要确定是否在源服务器上启用了 log_bin，请运行以下命令：SHOW VARIABLES LIKE 'log_bin'。
确保用户在目标服务器上拥有"REPLICATION_APPLIER"或"BINLOG_ADMIN"权限，以便能够应用 binlog。
确保用户在目标服务器上拥有"REPLICATION SLAVE"权限。
确保用户在源服务器上具有"REPLICATION CLIENT"和"REPLICATION SLAVE"权限，以便能够读取和应用 bin 日志。
使用“启用事务一致性”运行脱机迁移方案，从而获取 bin 日志文件和位置。
如果目标是迁移复制更改，请在源服务器上配置binlog_expire_logs_seconds参数，从而确保在副本提交更改之前不会清除 binlog 文件。 建议至少经过两天后再开始。 成功切换后，可以重置该值。
限制
在准备迁移时，请务必考虑以下限制。
执行复制更改迁移时，目标服务器上的数据库名称必须与源服务器上的名称相同。
支持仅限于 ROW binlog 格式。
仅当已选择 DMS UI 上的“为所选对象复制数据定义和管理语句”选项时，才支持 DDL 更改复制。 复制功能支持将初始加载后发生并记录在二进制日志的数据定义和管理语句复制到目标中。
复制更改时不支持重命名数据库或表。
创建复制更改迁移项目
若要创建复制更改迁移项目，请执行以下步骤。
在 Azure 门户中，选择“所有服务”，搜索 Azure 数据库迁移服务，然后选择“Azure 数据库迁移服务”。
在搜索结果中，选择为运行初步联机迁移而创建的 DMS 实例，然后选择“+ 新建迁移项目”。
在“新建迁移项目”页上指定项目名称，在“源服务器类型”选择框中选择“MySQL”，在“目标服务器类型”选择框中选择“Azure Database For MySQL 灵活服务器”，在“迁移活动类型”选择框中选择“复制更改”，然后选择“创建并运行活动”。
配置迁移项目
若要配置 DMS 迁移项目，请执行以下步骤。
在“选择源”屏幕上，输入源服务器名称、服务器端口、用户名和源服务器密码。
选择“下一步：选择目标>>”，然后在“选择目标”屏幕上，根据订阅、位置和资源组查找目标服务器。 会自动填充用户名，然后提供目标灵活服务器的密码。
选择“下一步：选择 binlog>>”，然后在“选择 binlog”屏幕上，输入在之前运行联机迁移方案期间捕获的 binlog 文件名和 binlog 位置。
选择“下一步：选择数据库>>”，然后在“选择数据库”选项卡上，选择要迁移的服务器数据库对象。
选择“下一步: 选择表>>”来导航到“选择表”选项卡。选择要迁移的所有表。
针对架构迁移进行配置后，请选择“查看并开始迁移”。
只有在尝试对失败的迁移进行故障排除时，才需要导航到“配置迁移设置”选项卡。
在“摘要”选项卡上的“活动名称”文本框中指定迁移活动的名称，然后查看摘要，确保源和目标详细信息与前面指定的信息匹配。
选择“开始迁移”。
迁移活动窗口随即出现，活动的“状态”为“正在初始化” 。 表迁移开始时，“状态”将更改为“正在运行” 。
监视迁移
监视“落后于源的秒数”，当它接近 0 时，请导航到迁移活动屏幕顶部的“开始切换”菜单选项卡，开始进行直接转换。
在准备好执行直接转换之前，请按照直接转换窗口中的步骤操作。 完成所有步骤后，选择“确认”，然后选择“应用”。
完成直接转换后，就可以执行迁移后验证和步骤了。
执行迁移后活动
迁移完成后，请务必完成以下迁移后活动。
针对目标数据库执行应用程序的性能测试，以验证迁移。
更新连接字符串以指向新的灵活服务器。
确保应用程序持续正常运行后，删除源服务器。
若要清理 DMS 资源，请执行以下步骤：
- 在 Azure 门户中，选择“所有服务”，搜索 Azure 数据库迁移服务，然后选择“Azure 数据库迁移服务”。
- 从搜索结果中选择你的迁移服务实例，然后选择“删除服务”。
- 在确认对话框中的“键入数据库迁移服务名称”文本框内指定实例名称，然后选择“删除”。
迁移最佳做法
执行迁移时，请务必考虑以下最佳做法。
在发现和评估过程中，利用一些关键数据来帮助迁移，包括服务器 SKU、CPU 使用率、存储大小、数据库大小和扩展用法等。
在为生产迁移之前执行测试迁移：
- 测试迁移是重要的操作，可确保涵盖数据库迁移的各个方面，包括应用程序测试。 最佳做法是在开始时完全出于测试目的来运行迁移。 在新启动的迁移以最小延迟进入“复制数据更改”阶段后，将灵活服务器目标设为正在运行的测试工作负载。 使用该目标测试应用程序，以确保获得预期的性能和结果。 如果要迁移到更高的 MySQL 版本，请测试应用程序兼容性。
- 测试完成后，可以迁移生产数据库。 此时需要确定生产迁移的日期和时间。 理想情况下，此时的应用程序使用率较低。 涉及的所有利益干系人都应随时有时间参与并准备就绪。 需要对生产迁移进行密切监视。 对于联机迁移，复制必须在执行切换之前完成，以防止数据丢失。
重定向所有依赖应用程序来访问新的主数据库，并将源服务器设为只读。 然后，打开应用程序供生产使用。
应用程序在目标灵活服务器上开始运行后，请密切监视数据库性能，以确认是否需要进行性能优化。