服务器 Gind.cn
  1. 服务器 Gind.cn
  3. mk-table-sync在主从scheme中：更改不复制到从站
Intereting Posts
pipe理组织内的笔记本电脑和台式机，并向他们推送Windows更新 真正的虚拟硬盘（使用驱动程序） 有没有办法使用Windows 2008备份到FTP 使用单链光纤用于全双工链路有什么优点/缺点？ 我的Postfix安装路由通过Amazon / SES出了什么问题？ （smtp_sender_dependent_authentication） //，如何在Linux上将访问令牌保护到远程自动化秘密存储（如Hashicorp Vault）？ 如何为CentOS安装第3章的联机帮助页 重新启动后，vSphere ESXi 5.5 Windows访客网卡不活动 如何使64位Apache的行为为32位？ Linux上的持久ip规则（Redhat） redirect循环 – AWS ELB SSL Nginx Linux ifconfig命令的ip地址，子网掩码永久 访问ip_conntrack导致yum更新后的并发问题 通过使用realm，sssd和adcli的Active DirectoryjoinUbuntu 14.04 LTS 谷歌地图在防火墙后面

mk-table-sync在主从scheme中：更改不复制到从站

我正在使用mk-table-sync在MySQL 5.1上同步主表到从表的表。 不幸的是，虽然差异被正确地检测到，但是在主设备（DELETE，REPLACE，ecc。）上完成的修改似乎不会传播到从设备。 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

反复给出总是相同的结果，没有实际的变化的奴隶。

login从站：

http://pastebin.com/kxuxks1P

login主设备：

http://pastebin.com/kVjEWEdL

在主服务器和复制数据库中的其他每个表上执行DELETE操作也是一样的。

有任何想法吗？

提前致谢

诚实地说，我从不信任mk-table-sync的–execute参数。 我总是使用 – 打印。

replace这个 

 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

或者如果从机没有二进制日志logging 

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

这样，你可以看到实际的SQL在从机上安全运行。

UPDATE 2011-05-31 12:57

“有趣的，纠正我，如果我错了，但不应该通过复制传播给奴隶的查询运行？我不明白为什么这不会发生”

这是一个公平的问题。 然而，想一想MySQL复制的工作方式。 在主服务器上完成SQL语句时，会将其logging在主服务器的二进制日志中。 从站的I / O线程读取主站二进制日志中的任何新条目，并将其附加到从站的最后一个中继日志中。 从属的SQL线程将中继日志条目作为FIFO队列读取，并按照其logging顺序处理SQL语句。 如果从站在其configuration中具有日志 – 从站更新和日志bin，则完成时的SQL状态将logging在从站的二进制日志中。

有关MySQL复制的小问题。

现在，为什么主人不复制到奴隶？

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

可能性＃1 ：networking延迟导致主站的binlog条目不能及时传播到从站的中继日志，或根本没有传播到从站的中继日志。

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

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

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

可能性＃4 ：configuration跳过从属SQL线程中的任何SQL错误 

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

可能性＃5 ： 奴隶的I / O线程简单地死亡，而不告诉mysqld 。 这可能发生。 简单的更正？ 执行以下操作重新build立从I / O线程： 

 STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;

可能性＃6 ： 在/etc/my.cnf中有错误的replicate-do-db和replicate-ignore-db组合 （声明：这是我的看法）

有些在/etc/my.cnf中混合了这两个选项，并没有考虑到这一点。 恕我直言，这些选项应该是相互排斥的。 您遵循过滤数据或过滤从属数据的逻辑。 他们不应该一起使用，因为你可以从复制得到虚假的结果。 数据应该存在或不存在，NOT数据应该存在而不存在 。

您可能正在使用mk-table-sync的版本，它不会将binlog格式设置为STATEMENT，因此不会真正更改master上的任何数据（按devise），因此没有任何内容进入二进制日志。