使用中间复制服务器实现 Amazon RDS for MySQL 和 Amazon Aurora M

---

使用 Amazon RDS 和 Amazon Aurora MySQL 实现高级复制功能

关键要点

在本文中，我们将介绍如何利用中间复制服务器在 MySQL 兼容数据库如 Amazon Aurora MySQL 兼容版和 Amazon RDS for MySQL之间使用高级复制功能。这些技术能够实现多源复制和复制过滤，使得用户可以灵活地管理其数据库环境。

在本篇文章中，我们将展示如何在 MySQL 兼容数据库如 Amazon Aurora MySQL 兼容版 集群或 Amazon RDS for MySQL 实例之间使用先进的复制功能。

我们将讨论 Amazon RDS 和 Amazon Aurora 提供的两种复制能力：多源复制和复制过滤。多源复制仅在 Amazon RDS for MySQL8035 及以上小版本与 5744 及以上小版本中得到支持，但在撰写本文时，Aurora 不支持此功能。接下来，我们将使用在 Amazon Elastic Compute CloudAmazon EC2上运行的中间 MySQL 复制实例中继服务器来实现这些功能。

MySQL 二进制日志复制概述

MySQL 复制拓扑开始于一个主数据库服务器接收写入流量，并将相应的复制事件记录在 二进制日志或 binlog中。二进制日志事件描述了在主服务器上发生的所有更改。副本连接到主服务器，下载二进制日志，并按照顺序在本地应用这些事件，以便与主服务器保持同步。

在最常见的场景中，主服务器记录所有更改，每个副本从单个主服务器接收并应用所有更改。这在大多数情况下是足够的，但在高级用例中，副本可能需要量身定制的操作，而不仅仅是主数据库的一对一镜像。

解决方案概述

多源复制 允许来自多个 MySQL 兼容源的数据复制到单个目标副本。多源复制可以促进多种用例，包括：

魔方网络服务加速器

用例类型描述效率与成本优化将几个未充分利用的单租户数据库迁移到一个多租户集群中数据集管理在多租户系统中移动租户便利性将多个数据集拼接在一起用于分析或提取、转换和加载 (ETL) 目的

在我们的解决方案中，我们使用中间复制实例，它读取来自多个源的二进制日志流并生成一个可以被 Amazon Aurora MySQL 或 Amazon RDS for MySQL 消费的单一复制流。

以下图表展示了多个 MySQL 数据库实例作为源，使用中间实例复制到另一个 MySQL 实例的过程。

复制过滤 允许数据库管理员在复制中排除架构或表。该配置灵活多变：您可以列出应被复制的对象并忽略其他所有对象，也可以列出应被忽略的对象并复制其他所有对象。您还可以选择在源或目标上应用过滤规则。

复制过滤在以下情况下会非常有用：

当副本不需要包含所有架构或表时，可以减少开销并提高复制性能在分片或多租户数据库中管理分片或租户，其中可以使用过滤来复制或忽略属于特定分片或租户的对象从包含特定于厂商的架构或表的托管数据库迁移时，这些对象干扰复制并必须被排除

复制过滤在 Amazon Aurora MySQL 和 Amazon RDS for MySQL 中部分支持。有关详细信息，请查阅 Amazon RDS 用户指南 和 Amazon Aurora 用户指南。截至撰写时，功能限制包括：

每个复制过滤参数有 2000 个字符的限制复制过滤器中不支持逗号在 Amazon RDS for MySQL 中，binlogdodb 和 binlogignoredb 参数不受支持在 Amazon Aurora MySQL 中，过滤仅支持 Aurora MySQL 版本 3mysql 架构中的表不能被忽略

本文所述的解决方案允许您绕开这些限制。

BLACKHOLE 存储引擎 是在表级别实现复制过滤的另一种方法。在这种方法中，转换为 BLACKHOLE 引擎的表会忽略所有写入并且不包含任何数据。 二进制日志格式STATEMENT 或 ROW决定了复制记录是否被写入到二进制日志，因此决定了中间复制实例是否继续发送这些记录。这篇文章为了完整性包含了 BLACKHOLE 的例子，但由于 BLACKHOLE 行为的相对复杂性，我们建议尽可能使用复制过滤参数。

以下图显示了一个 MySQL 数据库实例作为源，并利用使用 BLACKHOLE 引擎的中间实例复制到另一个 MySQL 实例。

您可以单独使用上述复制功能，也可以在同一个中间复制实例上同时运行过滤、多源复制和 BLACKHOLE 表。中间实例作为处理层，从二进制日志源复制，应用所需的操作多源聚合、过滤，并生成自己新的二进制日志。这些新的二进制日志流可以被 Amazon Aurora MySQL 或 Amazon RDS for MySQL 消费。

前置条件

实现此解决方案需要以下组件：

作为复制源主服务器和目标副本使用的 MySQL 服务器。我们的示例使用 Amazon RDS for MySQL 作为源，使用 Amazon Aurora MySQL 作为目标。此解决方案也可以与其他 MySQL 兼容数据库一起使用，例如从外部 MySQL 或 MariaDB 数据库迁移到 Amazon Aurora MySQL 或 Amazon RDS for MySQL。一台 EC2 实例，用于安装中间 MySQL 复制服务器。允许 MySQL 源与目标及 EC2 实例之间复制连接的网络连接和安全配置。

请注意，为了使复制在整个链中可靠工作，所有 MySQL 服务器必须在版本和配置方面兼容。例如，MySQL 支持向下一个更高的主要版本例如，57 到 80进行复制，但不官方支持从更高的主要版本到较低的主要版本的复制。同样， gtidmode 配置必须跨所有服务器兼容。

在本文章中，测试数据库开始时为空，并且在复制配置之前没有接收任何写入流量。因此，不需要在服务器之间同步二进制日志位置，我们可以使用当前的位置而不产生复制冲突。在实际迁移场景中，如果中间和目标服务器通过物理备份或逻辑转储来获取，必须确保二进制日志位置正确。

文中提供的示例已经使用 MySQL 80 和 Amazon Aurora MySQL 版本 3与 MySQL 80 兼容进行了测试。

准备复制源

作为复制源的 MySQL 服务器必须满足以下配置要求：

启用二进制日志并设置为 ROW 格式。服务器需保留足够的二进制日志以维护复制连续性。例如，如果副本是从主服务器的备份中创建的，那么主服务器必须保留从备份时间开始创建的二进制日志，并且这些 binlog 不能在被副本处理之前被删除。网络和安全配置允许来自中间 EC2 实例的 MySQL 连接。拥有带有 REPLICATION SLAVE 权限的 MySQL 用户帐户，用于接受来自中间服务器的复制连接。

具体步骤会根据您是使用托管 MySQL 服务还是自我管理数据库而有所不同。

如果您没有现有 MySQL 服务器可用于测试此解决方案，可以通过完成以下步骤来配置一个或多个 RDS for MySQL 实例：

创建 RDS 数据库实例。因为我们演示多源复制，所以在这个示例中我们使用两个实例。

确保在两个实例上启用自动备份，这也会启用二进制日志。

使用 MySQL 客户端连接到每个实例，将二进制日志保留期限设置为 72 小时，并创建一个拥有 REPLICATION SLAVE 权限的复制用户：

sqlCALL mysqlrdssetconfiguration(binlog retention hours 72)CREATE USER replusersource@ IDENTIFIED BY password GRANT REPLICATION SLAVE ON TO replusersource@

准备在 Amazon EC2 中的中间 MySQL 实例

完成以下步骤以配置中间 MySQL 实例：

启动 EC2 实例，使用 Amazon Linux 2 操作系统。

配置 MySQL 80 包仓库：

bashsudo yum install https//devmysqlcom/get/mysql80communityreleaseel75noarchrpm

安装 MySQL 80 服务器包：

bashsudo amazonlinuxextras install epel ysudo yum y install mysqlcommunityserver

确认 MySQL 已安装并初始化，获取需要连接到 MySQL 的管理员密码：

bashsystemctl status mysqld sudo grep temporary password /var/log/mysqldlog

连接到 MySQL，并创建一个具有 REPLICATION SLAVE 权限的复制用户：

sqlCREATE USER repluserintermediate@ IDENTIFIED BY password GRANT REPLICATION SLAVE ON TO repluserintermediate@

此时，您可以根据需要进行额外的 MySQL 配置更改。至少，验证以下前置条件：

启用二进制日志logbin 设置，并设置为 ROW 格式binlogformat 设置。这应该是 MySQL 80 的默认值。为从复制源接收的更改启用二进制日志logreplicaupdates 设置，或在 8026 之前版本中使用 logslaveupdates 设置。将 serverid 变量设置为在整个复制链中唯一的值。RDS for MySQL 实例和 Aurora MySQL 集群会自动将该变量设置为半随机值，因此您可以为 EC2 服务器选择 2 或 99 等任何值。

本示例不需要高级的 MySQL 调优，但生产用例可能需要根据实例规模、MySQL 缓冲区、缓存和其他配置值进行调整，以影响服务器的性能和行为。

准备 Amazon Aurora MySQL 中的复制目标

目标准备步骤取决于项目的性质。迁移项目可能会根据备份创建目标数据库；其他项目可能会在创建后以空数据库开始并填充数据。

如果您尚未具备可以用作此解决方案的目标数据库，可以 创建新的 Aurora MySQL 集群。确保使用与中间 EC2 实例的 MySQL 版本兼容的 主要引擎版本。例如，如果在 EC2 实例上使用 MySQL 80，则使用 Amazon Aurora MySQL 版本 3。

将复制配置从 Amazon RDS for MySQL 到 Amazon EC2

现在我们将配置两台 RDS for MySQL 源实例与前面创建的中间 MySQL 服务器之间的多源复制。

多源复制使用复制通道的概念，每个通道连接到不同的二进制日志源。请注意，MySQL 不会对来自多个源的更改执行自动冲突解决，这意味着更改必须在不冲突的情况下进行复制。

使用 CHANGE REPLICATION SOURCE TO 语句配置每个通道。在 MySQL 的 8023 之前版本中，等效命令是 CHANGE MASTER TO。

本示例涉及两台 RDS for MySQL 源实例，因此设置需要创建两个复制通道。

要配置多源复制，请完成以下步骤：

连接到每个 RDS for MySQL 源实例并获取二进制日志坐标

在 sourcemysqlinstance1 上，使用以下代码：

sqlmysqlgt show master status  File                        Position  BinlogDoDB  BinlogIgnoreDB  ExecutedGtidSet  mysqlbinchangelog000001  914                                                           1 row in set (001 sec)

在 sourcemysqlinstance2 上，使用以下代码：

sqlmysqlgt show master status   File                        Position  BinlogDoDB  BinlogIgnoreDB  ExecutedGtidSet    mysqlbinchangelog000001  866                                                           1 row in set (001 sec)

连接到 Amazon EC2 中的中间 MySQL 服务器并配置复制通道，每个源一个通道：

使用以下代码从 sourcemysqlinstance1 进行复制：

sqlchange master to masterhost=sourcemysqlinstance1xxxuseast1rdsamazonawscom masteruser=replusersource masterpassword=password masterlogfile=mysqlbinchangelog000001 masterlogpos= 914 for channel source1

使用以下代码从 sourcemysqlinstance2 进行复制：

sqlchange master to masterhost=sourcemysqlinstance2xxxuseast1rdsamazonawscom masteruser=replusersource masterpassword=password masterlogfile=mysqlbinchangelog000001 masterlogpos= 866 for channel source2

验证中间服务器上的复制是否启动并运行以下示例输出已简化：

sqlmysqlgt

---