### 17.4.7提高复制性能

随着连接到源的副本数量的增加，负载虽然很小，但也会增加，因为每个副本都使用到源的客户端连接。此外，由于每个副本必须接收源二进制日志的完整副本，源上的网络负载也可能会增加，并造成瓶颈。

如果您正在使用大量连接到一个源的副本，而该源也在忙于处理请求（例如，作为横向扩展解决方案的一部分），则可能需要提高复制过程的性能。

提高复制过程性能的一种方法是创建一个更深层次的复制结构，使源能够仅复制到一个副本，并使其余副本能够连接到此主副本以满足其各自的复制需求。该结构的示例如所示[图17.3，“使用其他复制源提高性能”](replication-solutions-performance.html#figure_replication-performance).

[](<>)

**图17.3使用额外的复制源来提高性能**

<img alt="The server MySQL Source 1 replicates to the server MySQL Source 2, which in turn replicates to the servers MySQL Replica 1, MySQL Replica 2, and MySQL Replica 3." src="images/subsource-performance.png" height="238" width="370" />

为了实现这一点，您必须按如下方式配置MySQL实例：

-   Source 1是将所有更改和更新写入数据库的主要源。在两个源服务器上都启用了二进制日志记录，这是默认设置。

-   源2是服务器源1的副本，它为复制结构中的其余副本提供复制功能。源2是唯一允许连接到源1的机器。来源2有[`--日志从属更新`](replication-options-binary-log.html#sysvar_log_slave_updates)选项已启用（这是默认设置）。使用此选项，来自源1的复制指令也会写入源2的二进制日志，这样就可以将它们复制到真正的副本中。

-   副本1、副本2和副本3充当到源2的副本，并从源2复制信息，这实际上包括登录到源1的升级。

    上述解决方案减少了主源上的客户端负载和网络接口负载，当用作直接数据库解决方案时，这将提高主源的整体性能。

    如果您的复制副本无法跟上源上的复制过程，则有许多可用选项：

-   如果可能，将中继日志和数据文件放在不同的物理驱动器上。为此，请设置[`中继日志`](replication-options-replica.html#sysvar_relay_log)指定中继日志位置的系统变量。

-   如果重磁盘I/O活动用于读取二进制日志文件和中继日志文件是一个问题，请考虑增加[`rpl_读取_大小`](replication-options-replica.html#sysvar_rpl_read_size)系统变量。此系统变量控制从日志文件读取的最小数据量，当操作系统当前未缓存文件数据时，增加该变量可能会减少文件读取和I/O暂停。请注意，为每个读取二进制日志和中继日志文件的线程分配一个大小为该值的缓冲区，包括源上的转储线程和副本上的协调器线程。因此，设置较大的值可能会影响服务器的内存消耗。

-   如果复制副本的速度比源副本慢得多，则可能需要分担将不同数据库复制到不同复制副本的责任。看见[第17.4.6节，“将不同的数据库复制到不同的副本”](replication-solutions-partitioning.html).

-   如果您的源代码使用事务，而您不关心副本上的事务支持，请使用`米萨姆`或者复制品上的另一个非交易引擎。看见[第17.4.4节，“使用不同源和副本存储引擎的复制”](replication-solutions-diffengines.html).

-   如果您的复制副本不是源，并且您有一个潜在的解决方案，可以确保在发生故障时启动源，那么您可以禁用系统变量[`日志副本更新`](replication-options-binary-log.html#sysvar_log_replica_updates)（来自MySQL 8.0.26）或[`日志_slave _更新`](replication-options-binary-log.html#sysvar_log_slave_updates)（MySQL 8.0.26之前）在副本上。这可以防止“哑”复制副本也将其执行的事件记录到自己的二进制日志中。
