☰

主从场景中的 mk-table-sync：更改未复制到从属

tag-icon • tag-icon mysql mysql-replication master-slave maatkit
主从场景中的 mk-table-sync：更改未复制到从属

我一直在使用 mk-table-sync 在 mysql 5.1 上将表从主服务器同步到从服务器。不幸的是，虽然可以正确检测到差异，但在主服务器上进行的修改（DELETE、REPLACE 等）似乎没有传播到从服务器。SHOW SLAVE STATUS 不会显示连接问题。

基本上，做

mk-table-sync -v  --execute --databases=forum --sync-to-master 
h=localhost,D=forum,t=user
# Syncing D=forum,h=localhost,t=user
# DELETE REPLACE INSERT UPDATE ALGORITHM START    END      EXIT DATABASE.TABLE
#      0       7      0      0 Chunk     14:35:00 14:35:01 2    forum.user

反复给出总是相同的结果，而对从属而言没有实际的改变。

登录从服务器：

http://pastebin.com/kxuxks1P

登录主服务器：

http://pastebin.com/kVjEWEdL

对主数据库和复制数据库中所有其他表执行的 DELETE 操作也是如此。

有任何想法吗？

提前致谢

答案1

说实话，我从来不信任 mk-table-sync 的 --execute 参数。我总是改用 --print。

替换此

mk-table-sync -v  --execute --databases=forum --sync-to-master h=localhost,D=forum,t=user

如果你启用了二进制日志记录

echo "SET SQL_LOG_BIN=0;" > DBChanges.sql
mk-table-sync -v  --print --databases=forum --sync-to-master h=localhost,D=forum,t=user >> DBChanges.sql

或者如果从站没有二进制日志记录

mk-table-sync -v  --print --databases=forum --sync-to-master h=localhost,D=forum,t=user > DBChanges.sql

这样，您就可以看到在从属服务器上安全运行的实际 SQL。

更新时间 2011-05-31 12:57

“有趣。如果我错了请纠正我，但在主服务器上运行的查询不应该通过复制传播到从服务器上吗？我不太明白为什么没有发生这种情况”

这是一个合理的问题。但是，想想 MySQL 复制的工作方式。当主服务器上的 SQL 语句完成后，它将记录在主服务器的二进制日志中。从服务器的 I/O 线程读取主服务器二进制日志中的任何新条目，并将它们附加到从服务器的最后一个中继日志中。从服务器的 SQL 线程将中继日志条目作为 FIFO 队列读取，并按照记录的顺序处理 SQL 语句。如果从服务器的配置中有 log-slave-updates 和 log-bin，则 SQL 语句完成后将记录在从服务器的二进制日志中。

关于 MySQL 复制的闲谈已经足够了。

现在，为什么主服务器不复制到从服务器？

以下是您可以探索的一些可能性：

可能性 #1：网络延迟导致主服务器的 binlog 条目不能及时传播到从服务器的中继日志，或者根本无法传播。

可能性 #2：MySQL 数据包太小，错误被忽略。这种情况只可能发生在以下情况下：最大允许数据包数主服务器中的 max_allowed_pa​​cket 大于从服务器中的 max_allowed_pa​​cket。这通常会停止复制。如果您跳过所有从服务器错误（如果 /etc/my.cnf 中有 slave-skip-errors=all），那么在这种独特情况下可以忽略各种正常数据。

可能性 #3：配置跳过从属 SQL 线程中的任何重复键错误

[mysqld]
slave-skip-errors=1062 (skips duplicate key errors)

可能性 #4：配置跳过从属 SQL 线程中的任何 SQL 错误

[mysqld]
slave-skip-errors=all (skips every SQL error under the sun)

可能性 #5：让从属服务器的 I/O 线程直接终止，而不通知 mysqld。这种情况可能发生。简单的更正？执行以下操作以重新建立从属 I/O 线程：

STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;

可能性 #6：/etc/my.cnf 中的 replicate-do-db 和 replicate-ignore-db 组合错误（免责声明：这仅代表我的观点）

有些人在 /etc/my.cnf 中混合使用这两个选项，却不以为然。恕我直言，这些选项应该是互斥的。您可以遵循在从属服务器中过滤数据或过滤数据的逻辑。它们不应一起使用，因为您可能会从复制中获得虚假结果。数据要么存在，要么不存在，数据不应该存在，也不应该存在。

答案2

您正在使用的 mk-table-sync 版本可能未将 binlog 格式设置为 STATEMENT，因此实际上并未更改主服务器上的任何数据（按照设计），也就不会有任何内容进入二进制日志。

相关内容