通过

将数据复制到 Azure Database for MySQL - 灵活服务器

  • 项目

适用于： Azure Database for MySQL - 灵活服务器

可以通过数据传入复制将数据从外部 MySQL 服务器同步到 Azure Database for MySQL 灵活服务器实例中。 外部服务器可以处于本地、虚拟机中、Azure Database for MySQL 单台服务器中或是其他云提供商托管的数据库服务。 数据传入复制以基于二进制日志 (binlog) 文件位置或基于 GTID 的复制为基础。 要了解有关 binlog 复制的详细信息，请参阅 MySQL 复制。

注意

仅支持通过基于 GTID 的复制为启用了高可用性的服务器配置数据传入复制。

何时使用数据传入复制

可以考虑使用数据传入复制的主要场景有：

  • 混合数据同步：借助复制中数据，可以在本地服务器和 Azure Database for MySQL Flexible 服务器之间同步数据。 此同步有助于创建混合应用程序。 如果有现有的本地数据库服务器，但想要将数据移到更靠近最终用户的区域，那么此方法很有吸引力。
  • 多云同步：对于复杂的云解决方案，使用复制中数据在 Azure Database for MySQL Flexible 服务器和不同云提供程序之间同步数据，包括虚拟机和托管在这些云中的数据库服务。
  • 迁移：客户可将开源工具（如 MyDumper/MyLoader）和数据传入复制配合使用，在最短时间内进行迁移。 通过数据传入复制，可以选择性地将生产负载从源数据库切换到目标数据库。

对于迁移方案，请使用 Azure 数据库迁移服务 (DMS)。

限制和注意事项

不会复制的数据

不会复制源服务器上的 mysql 系统数据库。 此外，不会复制对源服务器上的帐户和权限所做的更改。 如果在源服务器上创建帐户，并且此帐户需要访问副本服务器，则在副本服务器手动创建相同的帐户。 若要了解系统数据库中的表，请参阅 MySQL 手册。

已启用高可用性 (HA) 的服务器支持数据传入复制

只能通过基于 GTID 的复制来支持已启用高可用性 (HA) 的服务器的数据传入复制。

使用 GTID 进行复制的存储过程在所有已启用 HA 的服务器上均可用，其名称为 mysql.az_replication_change_master_with_gtid。

筛选器

参数 replicate_wild_ignore_table 为副本服务器上的表创建复制筛选器。 若要从 Azure 门户修改此参数，请导航到用作副本的 Azure Database for MySQL 灵活服务器实例，然后选择“服务器参数”以查看/编辑 replicate_wild_ignore_table 参数。

要求

  • 源服务器版本必须至少是 MySQL 5.7 版。

  • 建议为源服务器版本和复制服务器版本提供相同的版本。 例如，两者必须同时是 MySQL 5.7 版或 MySQL 8.0 版。

  • 建议在每个表中使用主键。 如果表中没有主键，则可能会面临复制缓慢的问题。

  • 源服务器应使用 MySQL InnoDB 引擎。

  • 用户必须有合适的权限在源服务器上配置二进制日志记录和创建新用户。

  • 在副本应用这些更改之前，不得清除源服务器上的二进制日志文件。 如果源是 Azure Database for MySQL 灵活服务器，请了解如何为灵活服务器或单一服务器配置 binlog_expire_logs_seconds

  • 如果源服务器启用了 SSL，请确保为域提供的 SSL CA 证书已包含在 mysql.az_replication_change_master 存储过程中。 请参阅以下示例和 master_ssl_ca 参数。

  • 请确保托管源服务器的计算机在端口 3306 上允许入站和出站流量。

  • 在公开访问的情况下，请确保源服务器具有公共 IP 地址、DNS 可公开访问，或者源服务器具有完全限定的域名 (FQDN)。 如果你有专用终结点并禁用了公共访问，则不支持数据传入复制

  • 使用专用访问（VNet 集成），确保源服务器名称可以解析，并且可从运行 Azure Database for MySQL 灵活服务器实例的 VNet 访问。 （有关详细信息，请访问 Azure 虚拟网络中资源的名称解析）。

生成的不可见主键

对于 MySQL 8.0 及更高版本，默认为所有 Azure Database for MySQL 灵活服务器实例启用生成的不可见主键 (GIPK)。 MySQL 8.0 及更高版本的服务器将不可见列 my_row_id 添加到该列上的表和主键，其中创建 InnoDB 表时没有显式主键。 此功能启用后，可能会影响某些数据传入复制用例，如下所示：

  • 如果源服务器在没有主键的表上创建主键，则数据传入复制失败并出现复制错误：“错误 1068 (42000): 定义了多个主键”。 若要缓解此问题，请运行以下 sql 命令，跳过复制错误并重新开始数据传入复制。

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • 如果源服务器将 auto_increment 列添加为唯一键，则数据传入复制失败并出现复制错误：“错误 1075 (42000): 表定义不正确；只有一个 auto 列，必须将它定义为键”。 若要缓解此问题，请运行以下 sql 命令，将“sql_generate_invisible_primary_key”设置为“关”，跳过复制错误并重新开始数据传入复制。

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • 如果当“sql_generate_invisible_primary_key”设置为“开”时源服务器运行任何其他不受支持的 SQL，数据传入复制会失败。 例如，创建分区表。 在这种情况下，缓解方法是将“sql_generate_invisible_primary_key”设置为“关”，并重新开始数据传入复制。

后续步骤