我有复制设置如下
Master A ----> Slave B ------> Slave C \-------> Slave D \------> Slave E - H 我使用这个设置，因为我需要在办公室服务器（即从属C）的本地副本。 我不希望对主站A造成额外的负担，因为它已经接收到从站连接的所有插入和额外负载。
所以我设置了多级复制。 主机A复制到从机B，而从机B又从主机到从机C.
从A – > B复制完美。 来自B – > C的复制随着“重复密钥”错误而不断出现。 我在服务器B中启用了中继日志以启用从B到C的复制。
有没有人遇到过这个问题？
主/从B my.cnf如下：
# Replication setup log-bin=/var/log/mysql/mysql-bin server-id=2 sync_binlog=0 binlog_format=mixed log-slave-updates replicate-same-server-id = 0 expire_logs_days=15
有什么我做错了吗？
如果您正在获取重复的键错误，那么正在向slave C写入（有可能），或者您在master上执行非确定性插入/更新操作（不太可能）以MIXED格式复制。 有sync_binlog = 0设置可能会导致一些问题，但他们可能会是罕见的，只发生在服务器崩溃。 如果确实是非确定性查询导致问题，则可能需要考虑binlog_format = ROW。
无论如何，首先你需要处理同步数据。 最简单的方法是从B的新备份开始，并确保将CHANGE MASTER更改为正确的二进制日志坐标。 如果从备份中恢复是不可能的，那么您可以使用maatkit.org中的工具（如mk-table-sync）进行调查。 这是一个复杂的工具，但如果你不处理数据结核病，我会去最近的备份。
然后，确保在my.cnf中将C设置为read_only
[mysqld] read_only
并在服务器上运行
SET GLOBAL read_only=1;
但是，请记住，read_only不适用于具有SUPER权限的用户，因此请确保除root用户外没有人拥有该访问权限，并且您正在使用非特权用户查询数据库。
老实说，只有7个奴隶，我会跳过多层次的设置的复杂性，只保持在一个单一的水平。 每个从机的开销并不昂贵，除非您正在处理主机上非常慢的networking连接。 你有证据表明二进制日志stream向奴隶造成性能下降？
我第二次read_only在奴隶。 如果没有别的，这是一个健康检查。 你确定server_ids全都不一样吗？ 显示实际的重复键错误也可能有帮助（如果可以的话）。 C或B上是否会有一些stream浪的触发器？ 调查产生错误的表。 主服务器上有多less个数据库？ 他们都被复制了吗？