【问题标题】:mysql replication - master to slavemysql 复制 - 主从
【发布时间】:2011-09-07 09:44:08
【问题描述】:

我已经成功设置了一个主从环境,它肯定工作正常。

我唯一的问题是从表中选择计数,它们不一样,但在从主站 5 分钟后选择,在从站上创建了 50 行,也创建了 50 行(这就是我说我的原因我确定它工作正常)

大师:

+----------+
| COUNT(*) |
+----------+
|    77634 |
+----------+
1 row in set (0.00 sec)

从机:

+----------+
| COUNT(*) |
+----------+
|    76932 |
+----------+
1 row in set (0.00 sec)

知道为什么会这样吗?是否有可能当我使用'CHANGE MASTER TO'命令将slave更改为指向master时,二进制日志文件@master的位置已经移动了?

【问题讨论】:

  • 您的从站不包含复制运行前的最新快照
  • 你的意思是我拿的sqldump没有使用二进制日志文件的正确位置吗?
  • 很可能,您在创建转储时没有锁定 master 以防止写入。

标签: mysql replication database-replication master-slave


【解决方案1】:

在从属设备上尝试“SHOW SLAVE STATUS”以查看是否发生任何错误。

您也可以尝试从 master 加载数据以重新建立同步。

【讨论】:

    【解决方案2】:

    MySQL 复制不是“可靠的”,如果出错也不能自动重新同步。即使没有计划外的重启等,也有很多方法会出错。

    您需要积极监控它,以防止它在任何时间段内工作。

    你至少需要做两件事:

    1. 检查 SHOW SLAVE STATUS 的输出(在每个从站上),确保线程正在运行,没有报告错误并且 seconds_behind_master 不会太多。
    2. 定期对每个从机/主机运行某种一致性检查 - 我建议使用 --replication 选项的 mk-table-checksum

    并将这些检查的输出连接到您的监控系统,以便您的操作人员收到警报。

    您的运营人员还需要知道如何修复它(转储/恢复或其他修复)。您肯定需要为 Ops 编写某种知识库文章。

    我以前做过 - 这不是微不足道的,你很容易弄错。

    【讨论】:

      猜你喜欢
      • 2014-07-07
      • 2012-09-14
      • 2012-10-16
      • 2012-08-25
      • 2011-11-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-01-09
      相关资源
      最近更新 更多