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

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

配置 Cloud SQL for MySQL 来源

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

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

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

  2. 如果源数据库包含引用 mysql、performance_schema、information_schema、ndbinfo 或 sys 系统架构中的表的对象，请确保副本数据库也包含这些系统架构表。

    如果副本数据库没有这些表，您的迁移作业可能会失败，并显示 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 for MySQL 同构迁移不会迁移用户账号和登录信息。如果来源包含由用户账号使用 DEFINER 子句定义的元数据，则可能会阻止迁移。

  3. 如果源数据库包含引用 mysql、performance_schema、information_schema、ndbinfo 或 sys 系统架构中的表的对象，请确保副本数据库也包含这些系统架构表。

    如果副本数据库没有这些表，您的迁移作业可能会失败，并显示 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 for MySQL 同构迁移不会迁移用户账号和登录信息。如果来源包含由用户账号使用 DEFINER 子句定义的元数据，则可能会阻止迁移。

  3. 如果源数据库包含引用 mysql、performance_schema、information_schema、ndbinfo 或 sys 系统架构中的表的对象，请确保副本数据库也包含这些系统架构表。

    如果副本数据库没有这些表，您的迁移作业可能会失败，并显示 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 for MySQL 同构迁移不会迁移用户账号和登录信息。如果来源包含由用户账号使用 DEFINER 子句定义的元数据，则可能会阻止迁移。

  2. 如果源数据库包含引用 mysql、performance_schema、information_schema、ndbinfo 或 sys 系统架构中的表的对象，请确保副本数据库也包含这些系统架构表。

    如果副本数据库没有这些表，您的迁移作业可能会失败，并显示 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 for MySQL 同构迁移不会迁移用户账号和登录信息。如果来源包含由用户账号使用 DEFINER 子句定义的元数据，则可能会阻止迁移。

  2. 如果源数据库包含引用 mysql、performance_schema、information_schema、ndbinfo 或 sys 系统架构中的表的对象，请确保副本数据库也包含这些系统架构表。

    如果副本数据库没有这些表，您的迁移作业可能会失败，并显示 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 设置为足够长的时间段，以支持数据库迁移。通常，一周就足够了。

      如需了解详情，请参阅在 Azure Database for MySQL 中配置服务器参数以及 Microsoft 文档中的 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 迁移入门。