MySQL 到 Azure Database for MySQL 的数据迁移 - MySQL 一致性备份
MySQL 一致性备份是一项新功能，允许用户对 MySQL 服务器进行一致性备份，而不会因为正在进行的 CRUD（创建、读取、更新和删除）操作而失去源数据完整性。 无需通过此功能将源服务器设置为只读模式即可实现事务一致性。
当前实现
在当前实现中，用户可以在脱机迁移期间启用“使源服务器只读”选项。 选择此选项可在迁移过程中禁止对源服务器进行写入/删除操作，从而维护目标数据库的数据完整性。 将源服务器作为迁移过程的一部分设置为只读时，选择将应用于所有源服务器的数据库，而不管是否选择它们进行迁移。
缺点
使源服务器只读会阻止用户修改数据，使数据库无法执行任何更新操作。 但是，如果未启用此选项，则有可能在迁移期间进行数据更新。 因此，迁移的数据可能不一致，因为数据库快照将在不同的时间点读取。
一致性备份
一致备份允许数据迁移继续和维护数据一致性，无论源服务器是否设置为只读。 若要启用一致备份，请选择“[预览] 启用事务一致性”选项。
选中“启用事务一致性”后，即使流量继续发向源服务器，也可以在目标上保持数据一致性。
撤消日志
撤消日志可实现可重复读取，并帮助生成迁移所需的快照。 撤消日志是与单个读写事务关联的撤消日志记录的集合。 撤消日志记录包含有关如何撤消事务对聚集索引记录的最新更改的信息。 如果另一个事务需要将原始数据视为一致的读取操作的一部分，则会从撤消日志记录中检索未修改的数据。 事务一致性是通过可重复读取的隔离级别以及撤消日志实现的。 在执行“选择”查询 (进行迁移) 时，源服务器会检查表的当前内容，将其与撤消日志进行比较，然后从开始迁移的时间点回滚所有更改，然后再将结果返回到客户端。 撤消日志不是用户控制的，默认情况下处于启用状态，并且不提供任何 API 供用户控制。
一致备份的工作原理
启动迁移时，服务会使用读取锁刷新源服务器上的所有表，以获取时间点快照。 此刷新已完成，因为全局锁比尝试锁定单个数据库或表更可靠。 因此，即使未迁移服务器中的所有数据库，它们也会被锁定，作为设置迁移过程的一部分。 迁移服务启动可重复读取，并将当前表状态与快照的撤消日志的内容组合在一起。 获取服务器宽锁并生成多个迁移连接后，会生成快照。 创建用于迁移的所有连接后，将释放表上的锁。
迁移线程用于对所有事务执行可重复读取的迁移，源服务器会隐藏脱机迁移中的所有新更改。 在迁移期间，单击 Azure 数据库迁移服务 (DMS) 门户 UI 中的特定数据库会显示迁移中所有表（已完成或正在进行）的迁移状态。 如果有连接问题，数据库的状态将更改为重试，如果迁移失败，会显示错误信息。
启用可重复读取，以便在迁移期间保持可撤消日志可访问，这会增加源上所需的存储，因为长期的连接。 请务必注意，迁移运行的时间越长，发生的表更改就越多，撤消日志的更改历史记录会更加广泛。 迁移时间越长，运行速度就越慢，因为用来检索未修改数据的撤消日志会更长。 这也会增加源服务器上的计算要求和负载。
二进制日志
二进制日志（或 binlog）是脱机迁移完成后向用户报告的项目。 当服务在读取锁定期间生成迁移线程时，迁移服务会记录初始 binlog 位置，因为在服务器解锁后，binlog 位置可能会更改。 当迁移服务尝试获取锁并设置迁移时，bin 日志位置会显示状态等待数据移动启动...。
binlog 保留源服务器中所有 CRUD 操作的记录。 DMS 门户 UI 显示二进制日志文件名和位置，他们与一致快照源上获取锁的时间一致，这不会影响脱机迁移的结果。 binlog 位置在 UI 上更新，只要可用，用户就不必等待迁移结束。
此 binlog 位置可与数据传入复制或第三方工具一起使用， 例如 Striim 或 Attunity），以便根据需要将 binlog 更改重播到其他服务器。
定期删除二进制日志，因此，如果以后使用更改数据捕获 (CDC) 来迁移源上的迁移后更新，用户必须采取必要的预防措施。 在源服务器上配置 binlog_expire_logs_seconds 参数以确保在副本提交更改之前不会清除二进制日志。 如果为非零，会在binlog_expire_logs_seconds秒后清除二进制日志。 转换成功后，可以重置值。 用户需要利用 binlog 中的更改来执行联机迁移。 用户可以利用 DMS 来提供数据的初始种子设定，然后将这些数据与所选 CDC 解决方案相结合，实现最短的停机时间迁移。
先决条件
若要通过一致性备份成功完成迁移，请执行以下操作：
确保尝试使用读取锁刷新表的用户具有 RELOAD 或 FLUSH 权限。
使用 mysql 客户端工具确定是否在源服务器上启用了 log_bin。 默认情况下不会始终打开 Bin 日志，应检查是否在开始迁移之前启用该日志。 mysql 客户端工具用于通过运行以下命令来确定是否在源上启用 log_bin：SHOW VARIABLES LIKE “log_bin”;
注意
在 Azure Database for MySQL 单一服务器（最多支持 4TB）中，默认未启用 log_bin。 但是，如果提升源服务器的只读副本，然后删除只读副本，该参数会设置为 ON。
- 在源服务器上配置 binlog_expire_logs_seconds 参数以确保在副本提交更改之前不会清除二进制日志。 成功转换后，可以重置该值。
已知问题和限制
与一致备份相关的已知问题和限制大致分为两类：锁定和重试。
注意
迁移服务为所有工作线程运行 START TRANSACTION WITH CONSISTENT SNAPSHOT 查询以获取服务器快照。 但仅 InnoDB 支持此功能。 在此处了解详细信息。
锁
通常，获取锁的过程非常简单，此过程需要几秒钟到几分钟才能完成。 但是，在某些情况下，尝试在源服务器上获取锁定可能会失败。
存在长期查询可能会导致不必要的停机，因为 DMS 可能会锁定表的子集，然后超时，等待最后几个变得可用。 在开始迁移之前，请运行 SHOW PROCESSLIST 命令检查是否有长期操作。
如果源服务器在请求锁时遇到大量写入更新，则锁无法轻松获取，在锁定等待超时后可能会失败。 这种情况发生在表中的批处理任务时，这可能会导致拒绝对锁的请求。 如前所述，请求的锁是整个服务器的单个全局级锁，因此，即使单个表或数据库正在处理，锁定请求必须等待正在进行的任务结束。
另一个限制与从 RDS 源服务器迁移有关。 RDS 不支持刷新具有读取锁的表，并且 LOCK TABLE 查询在后台的所选表上运行。 由于表单独锁定，锁定过程可能不太可靠，锁可能需要更长的时间才能获取。
重试
迁移会处理暂时性连接问题，并且通常为此预先预配其他连接。 我们查看迁移设置，尤其是源上的并行读取操作数，并应用一个因素（通常大约为 1.5），并提前创建尽可能多的连接。 这样一来，该服务可确保我们可以并行运行操作。 在任何时间点，如果连接丢失或服务无法获取锁，该服务将使用预配的剩余连接重试迁移。 如果所有预配的连接都用尽，导致时间点同步丢失，则必须从头开始重启迁移。 如果成功和失败，此脱机迁移服务将执行所有清理操作，用户不必执行任何显式清理操作。