随着连接到源的副本数量的增加，负载虽然很小，但也会增加，因为每个副本都使用到源的客户端连接。此外，由于每个副本都必须接收源二进制日志的完整副本，因此源上的网络负载也可能增加并造成瓶颈。
如果您使用连接到一个源的大量副本，并且该源也忙于处理请求（例如，作为横向扩展解决方案的一部分），那么您可能希望提高复制过程的性能。
提高复制过程性能的一种方法是创建更深层次的复制结构，使源能够仅复制到一个副本，并让其余副本连接到该主副本以满足其各自的复制要求。图 16.3 “使用附加复制源提高性能”中显示了此结构的示例 。
为此，您必须按如下方式配置 MySQL 实例：
源 1 是所有更改和更新都写入数据库的主要源。应在此机器上启用二进制日志记录。
Source 2 是 Source 1 的副本，它为复制结构中的其余副本提供复制功能。Source 2 是唯一允许连接到 Source 1 的机器。Source 2 也启用了二进制日志记录，并且启用了
log_slave_updates系统变量，因此来自 Source 1 的复制指令也被写入 Source 2 的二进制日志，这样它们就可以被复制到真正的复制品。Replica 1、Replica 2 和 Replica 3 充当 Source 2 的副本，并从 Source 2 复制信息，这些信息实际上包括在 Source 1 上记录的升级。
上述解决方案减少了主源上的客户端负载和网络接口负载，当用作直接数据库解决方案时，这应该会提高主源的整体性能。
如果您的副本无法跟上源上的复制过程，可以使用多种选项：
如果可能，将中继日志和数据文件放在不同的物理驱动器上。为此，设置
relay_log系统变量以指定中继日志的位置。如果副本比源慢得多，您可能希望将复制不同数据库的责任分配给不同的副本。请参阅 第 16.3.5 节，“将不同的数据库复制到不同的副本”。
如果您的源使用事务并且您不关心副本上的事务支持，请在副本上使用
MyISAM或其他非事务引擎。请参阅 第 16.3.3 节，“使用具有不同源和副本存储引擎的复制”。如果您的副本不充当源，并且您有一个潜在的解决方案来确保您可以在发生故障时启动源，那么您可以禁用
log_slave_updates副本上的系统变量。这可以防止“哑” 副本也将它们已执行的事件记录到自己的二进制日志中。