主页 / dba / 问题 / 45518
Accepted
HTF
Asked: 2013-07-02 06:10:08 +0800 CST

MySQL 复制：“主键的重复条目”

  • 772

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

基本上'mysqldump'几乎整晚都在运行，然后恢复过程花了几个小时，所以当我启动从属服务器时，它比主服务器晚了~63874秒。

从服务器是只读的（read_only），在重新同步过程中没有任何写入，所以我不明白为什么会有重复的密钥。

二进制日志格式在 master 上设置为 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
mysql replication

2 个回答

  1. Best Answer

    方面#1：复制

    我不这么认为

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

    永远在一起。

    其他人也对此感到疑惑

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

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

    甚至关于 replicate-rewrite-db 的 MySQL 文档也说：

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

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

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

    方面 #2：mysqldump

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

    您可以从 MySQL 性能博客的Best Keep MySQLDump Secret中找到更多信息。实际上，我在过去的一个问题中解决了这一点，该问题描述了 12 个可以破坏 mysqldump 事务完整性的命令：MySQL 备份 InnoDB

    警告

    结语

    由于重写规则或 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工具

    您需要的工具是

    使用这些来找出 Slave 中的差异，然后纠正它们

    • 14

  2. 检查直接插入从属的代码中的插入查询。我们只能从奴隶读取。写查询应该定向到master。

    • 0

相关问题