使用“启用事务一致性”的脱机方案运行复制更改迁移，使企业能够在数据库保持正常运行的同时将其数据库迁移到 Azure。 换句话说，可以使用最短的停机时间完成关键应用程序迁移，限制对服务级别可用性的影响以及对最终客户造成的不便。
备注
本文包含对术语“从属”的引用，这是 Microsoft 不再使用的术语。 在从软件中删除该术语后，我们会将其从本文中删除。
必须使用“启用事务一致性”运行脱机迁移方案，才能获取 bin 日志文件和位置以复制传入更改。 DMS 门户 UI 显示二进制日志文件名和位置，他们与一致快照源上获取锁的时间一致。 可以在复制更改迁移中使用此值以流式传输传入更改。
运行复制更改迁移时，当目标几乎赶上源服务器时，请停止源数据库的所有传入事务，并等待所有挂起的事务已应用到目标数据库。 要确认目标数据库在源服务器上是最新的，请运行查询“SHOW MASTER STATUS;”，然后将该位置与上次提交的 binlog 事件进行比较（显示在“迁移进度”下）。 当两个位置相同时，目标已赶上所有更改，你可以开始直接转换。
当前实现基于从源服务器流式处理 binlog 更改并将其应用于目标服务器。 与数据传入复制一样，这更易于设置，并且不需要在源服务器和目标服务器之间建立物理连接。
服务器可以将 Binlog 作为包含二进制数据的流发送，如此处所述。 客户端可以指定要用于启动流的初始日志位置。 日志文件名称描述日志位置、该文件中的位置，以及可选的 GTID（全局事务 ID）（如果源中启用了 gtid 模式）。
数据更改作为“行”事件发送，其中包含各个行的数据（更改之前和/或之后，具体取决于操作类型，即插入、删除或更新）。 然后，使用 BINLOG 语句以原始格式应用行事件：MySQL 8.0 参考手册：：13.7.8.1 BINLOG 语句。 但对于 DMS 迁移到 5.7 服务器，DMS 不会像 BINLOG 语句那样应用更改（因为 DMS 没有进行此操作的必要权限），而是会将行事件转换为 INSERT、UPDATE 或 DELETE 语句。
若要成功完成复制更改迁移，请确保满足以下先决条件：
- 使用选择的 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 更改复制。 复制功能支持将初始加载后发生并记录在二进制日志的数据定义和管理语句复制到目标中。
- 复制更改时不支持重命名数据库或表。