我有一个主 – 主复制系统。 但是，由于自动增量问题，我得到复制错误…并停止复制。
有人告诉我这样做：
stop slave; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; start slave; 它没有工作。 然后他们告诉我做：
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2;
它没有工作。 然后为了testing它，我做了：
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 99999;
它开始，但不更新。 我在DB1上创build了一个表…并且它不在DB2上显示…
下面是我的DB1和DB2的显示状态（我把它们打在一起）：
mysql> show master status\G *************************** 1. row *************************** File: mysql-bin.000605 Position: 2019727 Binlog_Do_DB: Binlog_Ignore_DB: 1 row in set (0.00 sec) mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: Master_User: Master_Port: Connect_Retry: 60 Master_Log_File: mysql-bin.000605 Read_Master_Log_Pos: 2008810 Relay_Log_File: mysqld-relay-bin.001731 Relay_Log_Pos: 10176595 Relay_Master_Log_File: mysql-bin.000470 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 4255373725 Exec_Master_Log_Pos: 10176458 Relay_Log_Space: 135062517347 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 1376343 1 row in set (0.00 sec)
我如何解决这个问题，让他们再次同步备份？ 谢谢。
你真的不知道你在做什么。 首先，你应该得到一个数据转储，以防止任何forms的腐败。
所以你正在使用一个主 – 主复制，对吧？
这听起来很奇怪，因为你只提供一个SLAVE状态和一个MASTER状态，但是我们需要MASTER和两个SLAVE状态输出。 此外，没有replicate_ignore_ *语句，这看起来不像Master-Master复制。 另外，从属状态中没有错误语句。 他们会显示任何复制错误。
如何解决这个问题：从每个主服务器获得一个干净的转储，并将其插入另一个主服务器。 这是在mysql手册中描述的，这里是简短的版本：
mysql> FLUSH TABLES WITH READ LOCK; $> mysqldump -uroot -p<pass> --opt --all-databases | gzip --fast > dump_master1.sql.gz mysql> UNLOCK TABLES;
记住：不要只是执行一个人告诉你的命令！ 先查看手册，然后检查它的function。 将你的SKIP_SLAVE_COUNTER设置为9999就是你的新创build的表没有出现在你的slave上的原因，因为它跳过了9999个sql语句，这可能还没有发生！ 通常情况下，您不会将SKIP_SLAVE_COUNTER设置为1，然后执行START SLAVE，如果有新错误，请参阅SHOW SLAVE STATUS。
如果您需要重置从站，并且您有一个具有主数据信息的好转储（带有–master-data选项的mysqldump），则可以使用最后一个转储进行重新同步：
连接到MySQL的奴隶并发出：
STOP SLAVE; RESET SLAVE; CHANGE MASTER to MASTER_USER='master user', MASTER_PASSWORD='master user password';
在从站上，从最后一个主转储重新加载从属数据库：
gzip -dc masterdump.sql.gz |mysql --user=username --password=password
重新启动从站：
START SLAVE
如果一切顺利，从站将从您加载的最后一个转储的位置开始复制。 这可能需要一些时间，所以请检查SECONDS BEHIND MASTER等待它赶上。
Seconds_Behind_Master：1376343
这就是为什么你没有看到你创build的数据库，因为奴隶仍然搅动通过主人二进制日志。 当它在主控制器后面0秒时，您将开始看到您复制到从属装置的更改。
如果一切都失败，请从服务中删除“坏”主服务器，转储并恢复数据库的新干净副本。 按照“添加其他主”的常用步骤来执行此操作。
尝试查看是否不是防火墙问题。 尝试停止并重新启动从站。 这：Slave_IO_Running：是Slave_SQL_Running：是的，一切似乎都没问题…你可以通过复制设置吗？
请注意，通过跳过99,999个日志事件，主站和从站将很可能不包含相同的数据。 您可以使用mk-table-checksum脚本来检查主内容和从属内容。
我从来不会一次跳过一个以上的事件，并且总是试图了解任何复制错误的原因。 如果我连续得到几个/许多复制错误，通常是其他问题的症状（例如，损坏的表/磁盘）。