在亚马逊RDS上介绍多源复制 数据库博客

亚马逊 RDS for MySQL 多源复制介绍

撰稿：Chelluru V N S S Vidyadhar 和 Steve Abraham 日期：2024年2月6日

关键要点

在本文中，我们将介绍 Amazon RDS for MySQL 的多源复制功能。这一新特性为数据库提供了灵活性与扩展性，支持从多个源数据库实例接收并应用二进制日志事件。文章将深入探讨其用例、最佳配置实践以及具体的实现案例。

2009 年，Amazon 关系数据库服务Amazon RDS首次推出时，就支持 MySQL 作为其首个数据库引擎。自那时起，客户的使用场景不断增长和演变。Amazon RDS for MySQL 一直以来支持对多个目标的复制，如今更是支持多源复制。

在这篇文章中，我们将详细讨论 Amazon RDS for MySQL 的多源复制，其使用案例、配置最佳实践和示例使用案例的逐步演示。

多源复制简介

MySQL 多源复制 是一种复制拓扑，允许 MySQL 数据库实例从多个源数据库实例接收和应用二进制日志事件。在这种拓扑中，副本会为每个源数据库实例利用一个不同的通道，来接收二进制日志事件并进行应用。

每个通道使用其自己的 I/O 线程来接收来自相应源的二进制日志事件，并将这些事件记录在通道的中继日志中。之后，通道将使用其 SQL 线程将中继日志中的更改应用到目标数据库。此外，我们可以在全局和通道级别版本 80 或更高应用复制过滤器，以按照应用需求复制特定的更改子集。

以下图像展示了多源复制拓扑结构。

您可以在同一区域甚至不同区域的数据库实例之间配置多源复制。数据库实例可以在同一个 AWS 账户或不同的 AWS 账户中。

多源复制的用例

多源复制可以应用于多种场景，以下是一些常见的用例。

合并分片

多源复制的主要用例是数据合并。当数据量过大或者流量过高时，可能需要将数据分片到多个数据库实例上。当数据或流量减少时，或许有必要减少这种配置中的分片数量。在这种情况下，您可以利用多源复制将多个分片的数据合并为一个。

合并 SaaS 租户

在软件即服务SaaS应用中，租户管理是一个重要问题。较大的租户通常会有独立的数据库实例，而较小的租户则会共享一个数据库实例。随着业务的变动，这些租户的数据可能会增长或缩减，因此能在这两种模式之间灵活切换变得至关重要。在之前使用独立数据库实例的工作负载情况中，您可以使用多源复制将这些工作负载迁移到一个合并的数据库实例中。

数据分析

企业通常需要从多个源生成报告。通过多源复制，可以创建一个接收来自多个源的实时更新的报告数据库，从而降低对分散于多个数据库实例中的数据进行分析的复杂性。

选择性备份

某些应用策略要求对特定数据进行长期保留，以便进行客户报告根据需求。保持完整的快照并不总是具备经济效益，尤其是当数据分散于多个数据库实例时。在整个数据库实例规模庞大的情况下，实际需要保留的数据仅限于特定表。在这些情况下，您可以使用多源复制并应用复制过滤器，将所需的表从多个源复制到单个数据库，并根据您的需求在单个数据库中维护所需数据集的长期保留。

最佳实践与注意事项

在多源复制的配置与操作中，有许多最佳实践与考虑因素。接下来的部分将深入探讨这些最佳实践。

副本引擎版本

您的多源副本数据库实例的引擎版本必须与复制拓扑中所有源数据库实例的最高引擎版本相同或更高。例如，如果源数据库 1 运行的是引擎版本 8034，而源数据库 2 运行的是 8035，建议多源副本使用 8035 或更高版本。同样，运行 57 主要版本的源数据库实例可以复制到运行 80 主要版本的 RDS for MySQL 数据库实例。

副本数据库实例配置

将 RDS for MySQL 数据库实例配置为多源副本时，资源配置CPU、内存、网络至关重要，以确保复制正常运行并且能够处理来自多个源数据库实例的工作负载。

需要考虑每个源数据库实例的常规工作负载及潜在的工作负载模式变化。为副本数据库实例分配足够的 CPU 和内存，对于从多个源数据库实例中应用更改并维持可接受的复制延迟至关重要。多源副本数据库实例接收到的数据量取决于工作负载和源数据库实例的配置例如，binlogformat 设置为 ROW 会产生更多数据。因此，确保多源副本数据库实例的类别提供所需的网络吞吐量是必要的，因为副本数据库实例将从多个源数据库实例接收数据二进制日志。

建议初始配置时从所有已配置源数据库实例中使用的最高数据库实例类型开始。此外，您应该持续监测复制延迟、CPU 利用率、内存使用情况和网络接收及传输的吞吐量，以识别任何资源争用并相应地调整数据库实例类别。所有这些指标都可以通过 Amazon CloudWatch 实例级指标 进行监控。

副本存储配置

配置为多源副本的数据库实例必须有足够的存储空间，以容纳来自多个源数据库实例的数据以及处理某些空间密集型操作。必须计算所有源数据库实例数据的总大小，并考虑数据增长预测，以确保分配给数据库实例的存储容量充足。例如，如果您有 2 个源数据库实例，每个数据库实例有 500 GB 的数据，您将需要超过 1 TB 的存储空间。如果您预计这些数据库实例在接下来的 12 个月中会增长到每个 750 GB，您可能希望分配 15 TB 的存储。此外，还需要额外的存储来计算在 ALTER TABLE、索引创建和磁盘临时表使用等操作过程中的临时存储需求。

为了确保多源复制数据库实例的高效性能，建议为副本数据库实例使用预置 IOPS SSDio1存储。这样可以提供低延迟，并根据工作负载需求调整 IOPS 数量。起初，可以考虑将 IOPS 设置为所有源数据库实例中使用的 IOPS 总和。在持续监控复制延迟、IOPS 使用情况和磁盘排队深度的同时，识别任何资源争用，并相应地调整数据库实例的分配 IOPS。

此外，每当对任何源数据库实例进行存储分配更改时，请确保多源副本数据库实例也有足够的存储分配。

在配置复制过滤器时，请根据要复制到副本数据库实例的数据量考虑存储空间。存储分配因素取决于初始复制的数据量及其增长速度。与数据相关的工作负载需要根据各自的存储配置适当处理因为 IOPS 取决于存储类型。

建议 启用存储自动扩展功能，其分配容量至少比副本数据库实例当前的存储值高 50。这样可以根据需要动态调整容量，避免存储不足导致的复制失败。

启用副本的只读模式

强烈建议启用副本的只读参数，以防止在副本上进行任何写操作。这有助于防止在副本上意外写入，从而导致复制失败或数据不一致。

配置复制过滤器

在仅需复制特定数据的情况下，复制过滤器提供必要的机制。使用多源复制时，您可以在全局级别或通道级别配置复制过滤器。

复制过滤器必须适当配置，以避免在从多个源进行复制时产生冲突。如果不同的源使用同样的模式命名约定，可以考虑使用 replicaterewritedb 参数将数据复制到相应的不同数据库中。

在 DB 参数组 中修改复制过滤器时，所有受影响通道的副本 SQL 线程会重新启动，以动态应用更改。如果修改全局过滤器，则所有复制通道都会重新启动。

与全局过滤器相关的配置首先应用，然后在数据库实例上应用通道特定的过滤器。通道级别的过滤器将覆盖全局过滤器。

例如，当 replicateignoredb 配置为 db1、channel22db2 时，这意味着数据库 db1 在全局层面将被忽略，而数据库 db2 在通道级别channel22将被忽略。在此情况下，复制将忽略 db1 的所有通道，除了 channel22，而仅 channel22 将忽略 db2。当我们指定任何通道级别的复制过滤器时，它们将覆盖全局级别的复制过滤器。以下截图将更详细地展示这一点。

启用多线程复制

对于涉及多个表的多次更新的工作负载，多线程复制可能会提供性能上的提升。要启用多线程复制，需要将 replicaparallelworkers或 slaveparallelworkers参数设置为大于 1 的值。多线程复制设置为全局级别，配置适用于所有复制通道。如果配置为值 N，则每个通道将分配 N 个线程，并且每个通道的副本数据库实例将配置一个协调线程来管理它们。

由于 replicaparallelworkers或 slaveparallelworkers参数适用于每个通道，因此很重要的是理解此参数不适用于所有复制通道没有单一的最佳值，因为最优工作线程数依赖于您的具体工作负载、资源、已配置的通道数，以及各自源数据库实例的二进制日志配置。持续监测和调整是保持多源复制最优性能的关键。

当您配置参数以适用于大多数通道时，必须考虑几个因素。

首先，建议将活动工作线程的数量配置为小于或等于 CPU 核心数的两倍。例如，假设您的多源副本使用 r58xlarge，具有 32 个虚拟 CPU，同时副本正在从 8 个不同的通道中复制数据。在这种情况下，配置 replicaparallelworkers或 slaveparallelworkers最多为 4，可以在每个线程在副本上执行工作时有效利用数据库实例的 CPU 资源。如果同一个副本用于执行任何读取操作，应将副本线程减少到较低的值，以提供一些资源分配给读取操作。这样，您可以有效利用 CPU 资源而不产生资源争用。

其次，数据库实例需要足够的内存，以便将大部分工作数据集保留在内存中以便快速访问。即使启用并行复制，复制工作所使用的线程数量也相较于源数据库实例有限。如果副本不用于那些需要额外连接内存进行连接、排序等的只读操作，则可以将 innodbbufferpoolsize 参数的大小从默认值增加，以分配更多内存给缓冲池，从而保留大量数据在内存中以提升性能。此外，还应持续监视数据库实例上的内存和交换利用率，以避免资源争用。要实现更好的性能，始终选择合适的数据库实例类别和配置，以确保交换利用率最低。

最后，识别跨多个通道的各自线程正在运行的潜在工作，并相应地重新配置 replicaparallelworkers或 slaveparallelworkers。在以下示例中，数据库实例配置为多源副本并从三个不同的源数据库实例复制数据，同时配置有 replicaparallelworkers 设置为 8。但是，当我们观察到各自的工作线程运行的事务数量时，发现每个通道”9999 的事务由一个工作线程处理，而 channel99 和 channel22 的大部分事务则由两个工作线程处理。在这种情况下，将并行工作线程数量配置为 2 将有助于优化大多数通道的工作负载，并被视为理想值。

sqlSELECT achannelname rw1threadid AS replicaworkerthreadid ts1countstar AS numberoftrxexecuted ROUND((ts1countstar / sumcountstar) 100 2) AS percentoftrxexecutedbyworkerFROM( SELECT rwchannelname SUM(tscountstar) AS sumcountstar FROM performanceschemaeventstransactionssummarybythreadbyeventname AS ts JOIN performanceschemareplicationapplierstatusbyworker AS rw ON tsthreadid = rwthreadid GROUP BY rwchannelname) AS aJOIN performanceschemareplicationapplierstatusbyworker AS rw1 ON achannelname = rw1channelnameJOIN performanceschemaeventstransactionssummarybythreadbyeventname AS ts1 ON rw1threadid = ts1threadid

将 replicaparallelworkers或 slaveparallelworkers配置为默认值4，并根据资源利用率和所需的工作线程数量相应地调整这些值，以满足最大数量通道的工作负载。

优化写入吞吐量

副本数据库实例重放来自多个源的写入，因此优化副本上的写入吞吐量非常重要。要实现这一点，您可以使用 RDS 优化写入 特性。启用 RDS 优化写入可以提高副本数据库实例上的写入事务性能，多达两倍的写入事务吞吐量对于最小化复制延迟是至关重要的。此外，建议使用最新的 80 次要版本8035 及更高版本，其能提供高达三倍的写入吞吐量。

优化读取吞吐量

多源复制最常见的用例之一是报告和分析。鉴于这些工作负载的读取数量较多，利用 RDS 优化读取 特性是很重要的，这可以使查询处理速度提高至两倍。为了利用此特性，请确保您正在使用具有实例存储的实例类型，例如 dbm5d 或 dbm6gd。优化读取将自动启用。

监控复制

要确保副本与其多个源保持同步，可以运行 SHOW SLAVE STATUS 命令，以查看所有通道的复制状态。或者，您也可以运行 SHOW SLAVE STATUS FOR CHANNEL channelname 来获取单一通道的复制状态。

每个通道的复制延迟也会记录到 Amazon CloudWatch。您可以通过使用实例标识符和复制通道名称来查找 ReplicationChannelLag 指标。请注意，ReplicationChannelLag 特定于 DBInstanceIdentifier多源副本数据库实例和 ReplicationChannelName。您可以在 CloudWatch 中查看多源复制通道的 ReplicationChannelLag 指标。

定期监控复制延迟与其他资源，以确保副本数据库实例的配置与性能最佳，是一个好的实践。要了解有关 Amazon RDS for MySQL 的更多最佳实践，请参考 [Amazon RDS for MySQL 的参数配置最佳实践，第