配置 MySQL 源数据库以进行持续迁移

本页面介绍了如何为连续同构 MySQL 迁移配置以下来源数据库实例：

配置 Cloud SQL for MySQL 来源

如需为迁移过程配置 Cloud SQL for MySQL 来源实例，请执行以下操作：

  1. 检查来源数据库是否包含由具有 DEFINER 子句的用户定义的元数据 。请参阅 验证具有 DEFINER 子句的元数据。

    Database Migration Service 不会迁移同构 MySQL 迁移的用户账号和登录信息。包含由具有 DEFINER 子句的用户账号定义的元数据的来源可能会阻止迁移。

  2. 如果来源数据库包含引用 表的对象，请确保副本数据库也包含这些系统mysqlperformance_schemainformation_schemandbinfosys 架构表。

    如果副本数据库没有这些表，迁移作业可能会 失败，并显示 Unknown table in system schema 。

  3. 在来源数据库上启用并配置二进制日志。

    在 Cloud SQL for MySQL 中，当您使用时间点恢复 (PITR) 时，系统会自动启用二进制日志记录。您可以使用 Cloud SQL 中提供的系统标志配置日志格式 和保留期限。 请执行以下操作：

    1. 在实例上启用 PITR。此功能会自动 启用二进制日志记录。在 Cloud SQL 中，无法在不使用 PITR 的情况下启用二进制日志记录 。请参阅 Cloud SQL 文档中的 时间点恢复 (PITR)。
    2. 使用 Cloud SQL 标志调整日志记录配置。 如需了解详情，请参阅 Cloud SQL 文档中的配置数据库标志 。
      1. Database Migration Service 要求将 binlog_format 设置为 ROW。您无需调整此设置， Cloud SQL for MySQL 会自动将 binlog_format 标志设置为 ROW.
      2. 将 日志保留期限设置为足够长的时间段，以支持 数据库迁移。一般来说，一周就足够了。 请使用以下标志之一：
        • MySQL 5.6 - 5.7：expire_logs_days
        • MySQL 8.0 及更高版本：expire_logs_days、 binlog_expire_logs_seconds

  4. 在实例中创建专用的迁移用户账号。 请参阅 Cloud SQL 文档中的 创建用户。请确保：

    • 您允许专用用户账号从任何主机 (host=%) 进行连接。
    • 账号的密码长度不超过 32 个字符。 如需详细了解 MySQL 用户密码长度限制， 请参阅 MySQL Bug #43439。

  5. 为专用迁移用户账号分配必要的权限。 对于连续迁移，所需权限的完整列表取决于 您是提供自己的转储文件，还是使用 Database Migration Service 代管式转储功能：

    代管式转储

    如果您希望 Database Migration Service 自动对您的 来源数据库进行完整转储，请为用户账号分配以下权限：

    手动转储

    如果您提供使用 mysqldump 创建的自己的转储文件，则需要提供 CDC 阶段所需的权限：

配置自行托管的 MySQL 来源

如需为迁移过程配置自行托管的 MySQL 来源实例，请执行以下操作：

  1. 确保所有表（系统数据库中的表除外） 使用 InnoDB 存储引擎。 如果您使用其他存储引擎，可能需要转换表。 如需了解详情，请参阅 将表从 MyISAM 转换为 InnoDB。
  2. 检查来源数据库是否包含由具有 DEFINER 子句的用户定义的元数据 。请参阅 验证具有 DEFINER 子句的元数据。

    Database Migration Service 不会迁移同构 MySQL 迁移的用户账号和登录信息。包含由具有 DEFINER 子句的用户账号定义的元数据的来源可能会阻止迁移。

  3. 如果来源数据库包含引用 表的对象，请确保副本数据库也包含这些系统mysqlperformance_schemainformation_schemandbinfosys 架构表。

    如果副本数据库没有这些表，迁移作业可能会 失败，并显示 Unknown table in system schema 。

  4. 将 server-id 设置配置为 1 或更大的值。如需了解详情，请参阅 复制和二进制日志记录选项和变量。

  5. 确保将 GTID_MODE 设置为 ON 或 OFF，不支持其他值。

    在以下情况下，Database Migration Service 要求将 GTID_MODE 设置为 ON ：

    如需详细了解 GTID_MODE，请参阅 全局交易 ID 系统变量。

  6. 在来源数据库上启用并配置二进制日志。请执行以下操作：

      • 在来源数据库上启用二进制日志。
      • 将 binlog_format 设置为 'ROW'。 请参阅基于行的二进制日志记录。
      • 将 日志保留期限设置为足够长的时间段，以支持 数据库迁移。一般来说，一周就足够了。 请使用以下标志之一：
        • MySQL 5.5 - 5.7：expire_logs_days
        • MySQL 8.0：expire_logs_days、binlog_expire_logs_seconds

  7. 在实例中创建专用的迁移用户账号。 请参阅 账号管理语句。请确保：

    • 您允许专用用户账号从任何主机 (host=%) 进行连接。
    • 账号的密码长度不超过 32 个字符。 如需详细了解 MySQL 用户密码长度限制， 请参阅 MySQL Bug #43439。

  8. 为专用迁移用户账号分配必要的权限。 对于连续迁移，所需权限的完整列表取决于 您是提供自己的转储文件，还是使用 Database Migration Service 代管式转储功能：

    代管式转储

    如果您希望 Database Migration Service 自动对您的 来源数据库进行完整转储，请为用户账号分配以下权限：

    手动转储

    如果您提供使用 mysqldump 创建的自己的 转储文件，则需要提供 CDC 阶段所需的权限：

配置 Amazon RDS for MySQL 来源

如需为迁移过程配置 Amazon RDS for MySQL 来源实例，请执行以下操作：

  1. Amazon RDS for MySQL 默认使用 InnoDB 存储引擎，但也允许使用其他存储引擎。 确保所有表（系统数据库中的表除外）都使用 InnoDB 存储引擎。 如果您使用其他存储引擎，可能需要转换表。 如需了解详情，请参阅 将表从 MyISAM 转换为 InnoDB。
  2. 检查来源数据库是否包含由具有 DEFINER 子句的用户定义的元数据 。请参阅 验证具有 DEFINER 子句的元数据。

    Database Migration Service 不会迁移同构 MySQL 迁移的用户账号和登录信息。包含由具有 DEFINER 子句的用户账号定义的元数据的来源可能会阻止迁移。

  3. 如果来源数据库包含引用 表的对象，请确保副本数据库也包含这些系统mysqlperformance_schemainformation_schemandbinfosys 架构表。

    如果副本数据库没有这些表，迁移作业可能会 失败，并显示 Unknown table in system schema 。

  4. 确保将 GTID_MODE 设置为 ON 或 OFF，不支持其他值。 Amazon RDS for MySQL 默认使用 GTID_MODE = OFF 。

    在以下情况下，Database Migration Service 要求将 GTID_MODE 设置为 ON ：

    • 当您 迁移到已启用 读取副本 的现有目标实例时。
    • 如果您计划手动创建转储文件并在迁移作业中提供这些文件 。

    如需详细了解 GTID_MODE，请参阅 全局交易 ID 系统变量。

  5. 验证并配置来源数据库上的二进制日志。请执行以下操作：

    1. 确保您的实例使用自动备份。只有在启用自动备份后，Amazon RDS 才会生成二进制日志。如需了解详情，请参阅 Amazon RDS 文档中的启用自动备份 。

    2. 将日志保留期限设置为足够长的时间段，以支持 数据库迁移。一般来说，一周就足够了。 请参阅 Amazon RDS 文档中的 设置和显示二进制日志配置。

    3. 重启服务器，使您所做的更改生效。

  6. 在实例中创建专用的迁移用户账号。 请参阅 账号管理语句。请确保：

    • 您允许专用用户账号从任何主机 (host=%) 进行连接。
    • 账号的密码长度不超过 32 个字符。 如需详细了解 MySQL 用户密码长度限制， 请参阅 MySQL Bug #43439。

  7. 为专用迁移用户账号分配必要的权限。 对于连续迁移，所需权限的完整列表取决于 您是提供自己的转储文件，还是使用 Database Migration Service 代管式转储功能：

    代管式转储

    如果您希望 Database Migration Service 自动对您的 来源数据库进行完整转储，请为用户账号分配以下权限：

    手动转储

    如果您提供使用 mysqldump 创建的自己的 转储文件，则需要提供 CDC 阶段所需的权限：

配置 Amazon Aurora for MySQL 来源

如需为迁移过程配置 Amazon Aurora for MySQL 来源实例，请执行以下操作：

  1. 检查来源数据库是否包含由具有 DEFINER 子句的用户定义的元数据 。请参阅 验证具有 DEFINER 子句的元数据。

    Database Migration Service 不会迁移同构 MySQL 迁移的用户账号和登录信息。包含由具有 DEFINER 子句的用户账号定义的元数据的来源可能会阻止迁移。

  2. 如果来源数据库包含引用 表的对象，请确保副本数据库也包含这些系统mysqlperformance_schemainformation_schemandbinfosys 架构表。

    如果副本数据库没有这些表，迁移作业可能会 失败，并显示 Unknown table in system schema 。

  3. 确保将 GTID_MODE 设置为 ON 或 OFF，不支持其他值。 Amazon Aurora for MySQL 默认使用 GTID_MODE = OFF 。

    在以下情况下，Database Migration Service 要求将 GTID_MODE 设置为 ON ：

    如需详细了解 GTID_MODE，请参阅 全局交易 ID 系统变量。

  4. 在来源数据库上启用并配置二进制日志。请执行以下操作：

    1. 为 MySQL 数据库启用二进制日志记录。

    2. 将日志保留期限设置为足够长的时间段，以支持 数据库迁移。一般来说，一周就足够了。 请参阅 设置和显示二进制日志配置。

    3. 重启服务器，使您所做的更改生效。

  5. 在实例中创建专用的迁移用户账号。 请参阅 账号管理语句。请确保：

    • 您允许专用用户账号从任何主机 (host=%) 进行连接。
    • 账号的密码长度不超过 32 个字符。 如需详细了解 MySQL 用户密码长度限制， 请参阅 MySQL Bug #43439。

  6. 为专用迁移用户账号分配必要的权限。 对于连续迁移，所需权限的完整列表取决于 您是提供自己的转储文件，还是使用 Database Migration Service 代管式转储功能：

    代管式转储

    如果您希望 Database Migration Service 自动对您的 来源数据库进行完整转储，请为用户账号分配以下权限：

    手动转储

    如果您提供使用 mysqldump 创建的自己的 转储文件，则需要提供 CDC 阶段所需的权限：

配置 Microsoft Azure Database for MySQL 来源

如需为迁移过程配置 Microsoft Azure Database for MySQL 来源实例，请执行以下操作：

  1. 检查来源数据库是否包含由具有 DEFINER 子句的用户定义的元数据 。请参阅 验证具有 DEFINER 子句的元数据。

    Database Migration Service 不会迁移同构 MySQL 迁移的用户账号和登录信息。包含由具有 DEFINER 子句的用户账号定义的元数据的来源可能会阻止迁移。

  2. 如果来源数据库包含引用 表的对象，请确保副本数据库也包含这些系统mysqlperformance_schemainformation_schemandbinfosys 架构表。

    如果副本数据库没有这些表，迁移作业可能会 失败，并显示 Unknown table in system schema 。

  3. 确保将 GTID_MODE 设置为 ON 或 OFF，不支持其他值。 Microsoft Azure Database for MySQL 默认使用 GTID_MODE = OFF 。

    在以下情况下，Database Migration Service 要求将 GTID_MODE 设置为 ON ：

    如需详细了解 GTID_MODE，请参阅 全局交易 ID 系统变量。

  4. 验证并配置来源数据库上的二进制日志记录设置。 请执行以下操作：

    1. 默认情况下，Microsoft Azure Database for MySQL 会启用二进制日志记录。您无需启用此功能，但请确认该功能已启用。如需了解详情，请参阅 Microsoft 文档。

    2. 将 binlog_expire_logs_seconds 设置为足够长的时间段，以支持数据库迁移。一般来说，一周就足够了。 足够了。

      如需了解详情，请参阅 Microsoft 文档中的在 Azure Database for MySQL 中配置服务器参数以及 binlog_expire_logs_seconds 参数。

    3. 重启服务器，使您所做的更改生效。

  5. 检查 require_secure_transport 设置的值。

    默认情况下，Microsoft Azure 数据库要求所有传入 连接都使用 SSL/TLS 加密。根据 require_secure_transport 值，在您 创建来源连接配置文件时使用以下加密设置之一：

    • 如果 require_secure_transport 设置为 on，请选择 基本版 、TLS 或 mTLS 。
    • 如果 require_secure_transport 设置为 off，请选择无 。

  6. 在实例中创建专用的迁移用户账号。 请参阅 账号管理语句。请确保：

    • 您允许专用用户账号从任何主机 (host=%) 进行连接。
    • 账号的密码长度不超过 32 个字符。 如需详细了解 MySQL 用户密码长度限制， 请参阅 MySQL Bug #43439。

  7. 为专用迁移用户账号分配必要的权限。 对于连续迁移，所需权限的完整列表取决于 您是提供自己的转储文件，还是使用 Database Migration Service 代管式转储功能：

    代管式转储

    如果您希望 Database Migration Service 自动对您的 来源数据库进行完整转储，请为用户账号分配以下权限：

    手动转储

    如果您提供使用 mysqldump 创建的自己的 转储文件，则需要提供 CDC 阶段所需的权限：

后续步骤

如需获取有关同构 Cloud SQL for MySQL 迁移的完整分步迁移演练，请参阅 Cloud SQL for MySQL 迁移使用入门。