配置来源

MySQL   |  PostgreSQL   |  PostgreSQL 到 AlloyDB

概览

Database Migration Service 支持从源数据库到 Cloud SQL 目标数据库的一次性和持续迁移。

MySQL 支持的源数据库包括：

• Amazon RDS 5.6、5.7、8.0
• 自行管理的 MySQL（在本地或由您完全控制的任何云端虚拟机上）5.5、5.6、5.7、8.0
• Cloud SQL for MySQL 5.6、5.7、8.0、8.4
• Amazon Aurora 5.6、5.7、8.0
• Microsoft Azure Database for MySQL 5.7、8.0

对于 MySQL 8.0 源，Database Migration Service 还支持以下次要版本：8.0.18、8.0.26、8.0.27、8.0.28、8.0.30、8.0.31、8.0.32、8.0.33、8.0.34、8.0.35、8.0.36、8.0.37、8.0.39、8.0.40。

如需配置源数据库，请完成以下步骤：

1. 对于 Cloud SQL 来源：如果您要从使用专用 IP 连接的 Cloud SQL 实例迁移到使用非 RFC 1918 地址 IP 范围的 Cloud SQL 实例，请将非 RFC 1918 范围添加到来源 Cloud SQL 实例的网络配置中。请参阅 Cloud SQL 文档中的配置授权网络。
2. 在将数据从源数据库迁移到目标数据库之前，请务必在完全转储阶段停止所有数据定义语言 (DDL) 写入操作。 您可以使用 脚本来验证 DDL 操作是否已停止。迁移进入 CDC 阶段后，您可以恢复 DDL 操作。
3. 确保源数据库不包含用户使用 DEFINER 子句定义的元数据。请参阅 创建和运行包含带有 DEFINER 子句的元数据的 MySQL 迁移作业。
4. 如果您的源数据库包含引用 mysql、performance_schema、information_schema、ndbinfo 或 sys 系统架构中表的对象，请确保副本数据库也包含这些系统架构表。

   如果复制数据库没有这些表，您的迁移作业可能会失败并显示 Unknown table in system schema 错误。

5. 您必须将 server-id 选项设置为 1 或更大的值。如需了解详情，请参阅复制和二进制日志记录选项和变量。
6. 将 GTID_MODE 设置为 ON 或 OFF，以配置全局事务 ID (GTID) 日志记录。 不支持 ON_PERMISSIVE 的 GTID_MODE 值。

   您应使用的值取决于迁移要求：

   • 如果您 迁移到已启用读取副本的现有目标实例，请将 GTID_MODE 设为 ON。
   • 如果您使用手动转储来迁移数据，请将 GTID_MODE 设置为 ON。
   如需详细了解 GTID_MODE，请参阅 全局交易 ID 系统变量。

7. 您必须将用于连接到源数据库的用户账号配置为接受来自任何位置（主机 = %）的连接。您可以在后续步骤中限制此用户的访问权限。

   为了降低危害数据库其他方面的可能性，我们建议您为此目的创建一个单独的账号。

   迁移和转储有四种类型的组合：

   • 类型 1：持续迁移和托管式转储
   • 类型 2：持续迁移和手动转储
   • 类型 3：一次性迁移和托管式转储
   • 类型 4：一次性迁移和手动转储

   下面的标签页列出了每种迁移与转储组合的权限。

   类型 1

   您配置的用户账号必须具有以下权限：

   • REPLICATION SLAVE
   • EXECUTE
   • SELECT
   • SHOW VIEW
   • REPLICATION CLIENT
   • RELOAD
   • TRIGGER
   • （仅适用于从 Amazon RDS 和 Amazon Aurora 迁移） LOCK TABLES

   MySQL 8.0 或更高版本：为获得最佳性能，请确保您未向此账号授予 BACKUP_ADMIN 权限。

   如需详细了解权限，请参阅 MySQL 提供的权限。如需详细了解用户账号，请参阅 MySQL 用户账号格式。

   类型 2

   您配置的用户账号必须具有以下权限：

   • REPLICATION SLAVE
   • EXECUTE

   如需详细了解权限，请参阅 MySQL 提供的权限。如需详细了解用户账号，请参阅 MySQL 用户账号格式。

   类型 3

   您配置的用户账号必须具有以下权限：

   • SELECT
   • SHOW VIEW
   • TRIGGER
   • （仅适用于从 Amazon RDS 和 Amazon Aurora 迁移） LOCK TABLES
   • （仅适用于从设置了 GTID_MODE = ON 的来源的迁移）RELOAD

   MySQL 8.0 或更高版本：为获得最佳性能，请确保您未向此账号授予 BACKUP_ADMIN 权限。

   如需详细了解权限，请参阅 MySQL 提供的权限。如需详细了解用户账号，请参阅 MySQL 用户账号格式。

   类型 4

   无需任何权限。

   如需详细了解权限，请参阅 MySQL 提供的权限。如需详细了解用户账号，请参阅 MySQL 用户账号格式。

8. 在配置二进制日志之前，请确保您已：
   • 在源数据库上启用二进制日志。
   • 使用基于行的二进制日志记录。
   • 将二进制日志保留足够长的时间，以支持数据库迁移。通常，一周就足够了。

   如需配置二进制日志，请展开相应来源的部分：

   自行托管的 MySQL

   根据您的 MySQL 版本，指定足够的时间来进行复制：

   • MySQL 5.5 - 5.7：expire_logs_days
   • MySQL 8.0：expire_logs_days、binlog_expire_logs_seconds

   Microsoft Azure Database for MySQL

   Microsoft Azure Database for MySQL 默认启用二进制日志记录。您无需启用它。如需了解详情，请参阅 Microsoft 文档。

   配置以下必需参数：

   1. 将 binlog_expire_logs_seconds 设置为足够长的时间，以支持数据库迁移。

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

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

   Amazon RDS

   对于 Amazon RDS，您可以通过配置 binlog retention hours 参数在参数组中设置基于行的配置。此参数用于指定 Amazon RDS 应保留二进制日志文件的时长（以小时为单位）。

   如需在 Amazon RDS 中设置二进制日志的保留期限，请使用 mysql.rds_set_configuration 存储过程，并指定足够的时间来进行复制。例如：

   call mysql.rds_set_configuration('binlog retention hours',168);

   您可以为此参数设置的最大值为 168 小时（或 7 天）。

   Amazon Aurora

   对于 Amazon Aurora，请按以下步骤操作：

   1. 为 MySQL 数据库启用二进制日志记录功能。
   2. 设置二进制日志的保留期限：

      mysql> call mysql.rds_set_configuration('binlog retention hours', 168);

      输入此命令是因为您需要将系统配置为将二进制日志保留至少 7 天（或 168 小时），以确保正确复制。
   3. 重启服务器，使您所做的更改生效。
9. 所有表（系统数据库中的表除外）都使用 InnoDB 存储引擎。

   如需详细了解 InnoDB，请参阅 InnoDB 存储引擎。如需详细了解如何转换为 InnoDB，请参阅将表从 MyISAM 转换为 InnoDB。

10. 用于连接到源数据库的用户账号的密码不得超过 32 个字符。这是 MySQL 复制特有的问题。

    如需详细了解 MySQL 用户密码长度限制，请参阅 MySQL 错误 43439。

11. 仅适用于 Microsoft Azure Database for MySQL 源：检查 require_secure_transport 设置的值。

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

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