16.3.6 提高复制性能

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

如果您使用大量连接到一个源的副本，并且该源也正在忙于处理请求(例如，作为横向扩展解决方案的一部分)，那么您可能希望提高复制过程的性能。

改善复制过程性能的一种方法是创建一个更深的复制结构，该复制结构可使源仅复制到一个副本，而其余副本则可根据其各自的复制要求连接到该主副本。 图 16.3，“使用附加的复制源来提高性能”中显示了此结构的示例。

图 16.3 使用其他复制源提高性能

为此，必须按以下方式配置 MySQL 实例：

• 源 1 是将所有更改和更新都写入数据库的主要源。应在此计算机上启用二进制日志记录。

• 源 2 是源 1 的副本，它为复制结构中的其余副本提供复制功能。源 2 是唯一允许连接到源 1 的计算机。源 2 还启用了二进制日志记录，并且启用了log_slave_updates系统变量，因此来自源 1 的复制指令也被写入源 2 的二进制日志，以便可以将它们复制到 true 的副本。

• 副本 1，副本 2 和副本 3 充当源 2 的副本，并复制来自源 2 的信息，该信息实际上由登录到源 1 的升级组成。

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

如果您的副本在跟上源上的复制过程时遇到问题，则有许多可用的选项：

• 如果可能，请将中继日志和数据文件放在不同的物理驱动器上。为此，设置relay_log系统变量以指定中继日志的位置。

• 如果副本比源慢得多，则可能需要划分将不同数据库复制到不同副本的责任。参见第 16.3.5 节“将不同的数据库复制到不同的副本”。

• 如果您的源使用事务，并且您不关心副本上的事务支持，请在副本上使用MyISAM或其他非事务引擎。参见第 16.3.3 节“将复制与不同的源和副本存储引擎一起使用”。

• 如果您的副本不充当源，并且有适当的解决方案来确保在发生故障时可以调出源，则可以在副本上禁用log_slave_updates系统变量。这样可以防止“哑”副本也将已执行的事件记录到自己的二进制日志中。