随着连接到源的副本数量的增加，负载虽然很小，但也会增加，因为每个副本都使用到源的客户端连接。此外，由于每个副本都必须接收源二进制日志的完整副本，因此源上的网络负载也可能增加并造成瓶颈。
如果您使用连接到一个源的大量副本，并且该源也忙于处理请求（例如，作为横向扩展解决方案的一部分），那么您可能希望提高复制过程的性能。
提高复制过程性能的一种方法是创建更深层次的复制结构，使源能够仅复制到一个副本，并让其余副本连接到该主副本以满足其各自的复制要求。图 17.3 “使用附加复制源提高性能”中显示了此结构的示例 。
为此，您必须按如下方式配置 MySQL 实例：
源 1 是所有更改和更新都写入数据库的主要源。两台源服务器都启用了二进制日志记录，这是默认设置。
源 2 是服务器源 1 的副本，它为复制结构中的其余副本提供复制功能。源 2 是唯一允许连接到源 1 的机器。源 2
--log-slave-updates启用了该选项（这是默认设置）。使用此选项，来自 Source 1 的复制指令也将写入 Source 2 的二进制日志，以便随后可以将它们复制到真正的副本。Replica 1、Replica 2 和 Replica 3 充当 Source 2 的副本，并从 Source 2 复制信息，这些信息实际上包括在 Source 1 上记录的升级。
上述解决方案减少了主源上的客户端负载和网络接口负载，当用作直接数据库解决方案时，这应该会提高主源的整体性能。
如果您的副本无法跟上源上的复制过程，可以使用多种选项：
如果可能，将中继日志和数据文件放在不同的物理驱动器上。为此，设置
relay_log系统变量以指定中继日志的位置。如果读取二进制日志文件和中继日志文件的大量磁盘 I/O 活动是一个问题，请考虑增加
rpl_read_size系统变量的值。此系统变量控制从日志文件中读取的最小数据量，如果文件数据当前未被操作系统缓存，增加它可能会减少文件读取和 I/O 停顿。请注意，为从二进制日志和中继日志文件读取的每个线程分配了此值大小的缓冲区，包括源上的转储线程和副本上的协调器线程。因此，设置较大的值可能会对服务器的内存消耗产生影响。如果副本比源慢得多，您可能希望将复制不同数据库的责任分配给不同的副本。请参阅 第 17.4.6 节，“将不同的数据库复制到不同的副本”。
如果您的源使用事务并且您不关心副本上的事务支持，请在副本上使用
MyISAM或其他非事务引擎。请参阅 第 17.4.4 节，“使用具有不同源和副本存储引擎的复制”。如果您的副本不作为源，并且您有一个潜在的解决方案来确保您可以在发生故障时启动源，那么您可以禁用系统变量
log_replica_updates（从 MySQL 8.0.26 开始）或log_slave_updates（在 MySQL 之前） 8.0.26) 在副本上。这可以防止 “哑”副本也将它们已执行的事件记录到自己的二进制日志中。