您能否帮助我了解为什么在完全重新同步后，在从属服务器上收到“ PRIMARY键的重复项”。

基本上，“ mysqldump”几乎整个晚上都在运行，然后还原过程花费了几个小时，所以当我启动从站时，它比主站晚了约63874秒。

从属服务器是只读的（read_only），并且在重新同步过程中没有任何写操作，因此我不明白为什么会有重复的键。

二进制日志格式在主数据库上设置为MIXED。

用于备份数据库的命令：

mysqldump --opt --single-transaction -Q --master-data=2 db | bzip2 -cz > db.sql.bz2

从属服务器仅使用以下选项从主控服务器（db-> db_backup）复制一个数据库：

replicate-wild-do-table = db_backup.%
replicate-rewrite-db = db->db_backup

方面1：复制

我不认为

replicate-wild-do-table = db_backup.%
replicate-rewrite-db = db->db_backup

永远在一起。

其他人也想知道

• Jun 14, 2012：配置了MySQL复制，但无法正常工作
• Jun 13, 2012：mysql复制期间'replicate-rewrite-db'和'replicate-do-db'有什么区别？
• May 31, 2012：MySQL复制-重写-db不起作用

该问题源于订单复制规则的处理。根据有关复制规则的MySQL文档：

如果指定了任何--replicate-rewrite-db选项，则会在测试--replicate- *过滤规则之前应用它们。

甚至复制-rewrite-db上的MySQL文档都说：

在测试--replicate- *规则之前，已完成数据库名称转换。

该replicate-wild-do-table重写后执行。如果此排序以某种方式将INSERT强制插入到已经有数据的表中，就不足为奇了。

您可能会问数据是如何到达那里的？

方面＃2：mysqldump

这样做mysqldump --single-transaction似乎是及时转储数据的最佳方法。不幸的是，mysqldump --single-transaction有一个致命弱点：ALTER TABLE。如果表受制于任何ALTER TABLE命令，例如DROP TABLE和CREATE TABLE，可能会破坏mysqldump试图进行转储的事务的完整性。截断表（在MySQL Universe中为DDL）并删除和添加索引可以也同样具有破坏性。

您可以从MySQL Performance Blog的“ 最佳保存的MySQLDump Secret”中找到有关此信息的更多信息。我实际上在过去的问题中解决了这一点，该问题描述了12条可能破坏mysqldump事务完整性的命令：MySQL备份InnoDB

警告

• 我个人将二进制格式切换为STATEMENT
• 就像我在MySQL备份InnoDB中所说的那样，您应该有另一个专门用于执行mysqldumps的从属服务器（没有任何复制过滤器）。
• 落后63000秒钟以上？您应该研究并行表转储：如何优化大型数据库的mysqldump？

结语

由于重写规则或mysqldump的隔离被覆盖，这两个方面中的一个或两个都可能导致在mysqldump期间不应该存在的行滑入。

建议

自从mysqldump开始以来，我将对所有中继日志进行mysqlbinlog转储，以查看Slave将处理的所有INSERT，并查看这些行是否已存在于Slave上。如果这样做，您可能会做两件事：

1：跳过所有重复键错误

只需将其添加到从站上的my.cnf

[mysqld]
slave-skip-errors=1062
skip-slave-start

并重启mysql。然后跑START SLAVE;

所有重复键错误都会被绕过。当Seconds_Behind_Master变为0时，删除这些行并重新启动mysql。

2：下载percona工具

您需要的工具是

• pt表校验和
• pt表同步

使用这些来找到从站中的差异，然后更正它们

在直接插入从站的代码中检查插入查询。我们只能从奴隶那里读取。写查询应定向到主服务器。