mysql 复制 - 主从
我已经成功设置了主从环境,并且它绝对工作正常。
我遇到的唯一问题是从表中选择计数,它们不一样,但是在从主服务器上选择 5 分钟后,在从服务器上创建了 50 行,也创建了 50 行(这就是为什么我说我确信工作正常)
主人:
+----------+
| COUNT(*) |
+----------+
| 77634 |
+----------+
1 row in set (0.00 sec)
奴隶:
+----------+
| COUNT(*) |
+----------+
| 76932 |
+----------+
1 row in set (0.00 sec)
知道为什么会发生这种情况吗?当我使用“CHANGE MASTER TO”命令将从站更改为指向主站时,是否有可能,二进制日志文件@主站的位置已经移动了?
I have successfully set up a master to slave environment and it is definitely working fine.
The only problem I have is that selecting count from a table, they are not the same BUT selecting after 5 mins from master, 50 rows are created while on the slave, also 50 rows are created (that's why I said i'm sure that is working fine)
Master:
+----------+
| COUNT(*) |
+----------+
| 77634 |
+----------+
1 row in set (0.00 sec)
Slave:
+----------+
| COUNT(*) |
+----------+
| 76932 |
+----------+
1 row in set (0.00 sec)
Any idea why this happened? is it possible that when I changed the slave to point to the master using the 'CHANGE MASTER TO' command, the position of binary log file @ the Master moved already?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在从站上尝试“显示从站状态”以查看是否发生任何错误。
您还可以尝试从主服务器加载数据以重新建立同步。
Try 'SHOW SLAVE STATUS' on the slave to see if any errors have occured.
You can also try load data from master in order to re-establish the synchronization.
MySQL 复制并不“可靠”,如果出现问题也无法自动重新同步。即使没有计划外的重新启动等,它也有很多可能会出错的方式。
您需要积极监控它,以保证它在任何时间内都能正常工作。
您至少需要做两件事:
并将这些检查的输出挂接到您的监控系统,以便您的操作人员收到警报。
您的运维人员还需要知道如何修复它(转储/恢复,或其他一些修复)。您肯定需要为运维编写某种知识库文章。
我以前这样做过——这并不是一件小事,你很容易出错。
MySQL replication is not "reliable", nor is it able to automatically re-sync if it goes wrong. There are lots of ways it can go wrong even without unplanned reboots etc.
You need to ACTIVELY monitor it, to stand any chance of it working for any length of time.
You need, at the very least, to do two things:
And hook the output of those checks up to your monitoring system so that your operations staff get alerted.
Your Ops staff also need to know how to fix it (dump / restore, or some other fix). You will definitely need to write some kind of knowledge-base article for Ops.
I did this before - it is not trivial and you can get it wrong easily.