主页 / dba / 问题 / 20509
Accepted
atxdba
Asked: 2012-07-07 09:01:34 +0800 CST

通过共享服务器 ID 搞砸了复制

  • 772

所以我今天搞砸了一周。我正在添加另一对从站，并在新从站上设置与旧从站相同的服务器 ID。

布局有点像

Master
|     |
\/    |
oldS  |
      \/
      newS1
      |
      |
      \/
      newS2

所以要清楚旧的从站（oldS）和第一个新的从站（newS1）共享相同的服务器ID。

这不是循环复制，所以我希望一切都会好起来的。我不会预料到后果。

警报开始响起 b/c oldS1 开始越来越落后。查看日志目录，它正在制作成千上万的空中继日志。

我停止在 newS1 上工作，这似乎让事情变得清晰，因为 oldS1 停止制作空的中继日志并恢复。

直到我停止在 newS1 上工作时，两个奴隶似乎都处于一致的状态。

  • 修复所有问题是否会像使用新的、唯一的 ID 弹回 newS1 一样简单，尤其是考虑到 newS1 本身是从属于 newS2 的？
  • 还有什么需要注意的吗？
  • 为什么这会导致 oldS 在清空中继日志后生成空中继日志？我本来希望 oldS 和 newS1 不知道其他人的存在。
  • 我认为中继日志滚动只是由奴隶自己决定的。主人是否发送了一些信号，表明它应该产生一个新的中继日志？
mysql replication

1 个回答

  1. Best Answer

    从我的角度来看，您可能已经将数据漂移引入了复制。

    Baron Schwartz 在他的博客中将此描述为一个谜题。

    您可能需要重新加载oldS新newS1数据。

    至少，你应该使用pt-table-checksum来查看是否

    • Master 上的数据与 oldS 不同
    • Master 上的数据与 newS1 不同

    如果差异不相同，您可以

    在你接触任何东西之前，请修复server-id 的情况

    中继日志的产生是意料之中的，因为同级从属轮流从主服务器获取 SQL 条目。他们根本无法共享相同的服务器 ID。Master 会以某种方式提醒后续的 slaves 我已经给 server-id 一个 SQL 语句。因此，后续从站上的 I/O 线程将断开连接并重试。因此，空中继日志增加。（相信我，几年前我就用这个搬起石头砸自己的脚）。

    Master 与 Slaves 就此信息交谈的这种方法允许 MySQL（呃，Oracle）提出半同步复制。这也会破坏半同步复制。尽管 MySQL 5.6 将很快引入全局事务 ID，但server-id仍将用于其在 Master 上的检查和平衡方法。毕竟，如果一只老鹰有两只小鹰，那么没有一只老鹰会同时向两只嘴里吐口水来喂养它们。

    • 3

相关问题