登录
首页 >  数据库 >  MySQL

MySQL主从同步机制和同步延时问题追查

来源:SegmentFault

时间:2023-02-16 15:23:33 337浏览 收藏

在IT行业这个发展更新速度很快的行业,只有不停止的学习,才不会被行业所淘汰。如果你是数据库学习者,那么本文《MySQL主从同步机制和同步延时问题追查》就很适合你!本篇内容主要包括MySQL主从同步机制和同步延时问题追查,希望对大家的知识积累有所帮助,助力实战开发!

今天遇到一个问题,

mysql> show slave status\G;
    // 状态一
    Seconds_Behind_Master: NULL
    // 状态二
    Seconds_Behind_Master: 0
    // 状态三
    Seconds_Behind_Master: 79

连续查询,大部分时间该属性值

mysql> show slave status\G;
#状态一:
    Slave_IO_State: Reconnecting after a failed master event read
    Slave_IO_Running: No
    Slave_SQL_Running: Yes
    Seconds_Behind_Master: NULL
#状态二:
    Slave_IO_State: Waiting for master to send event
    Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
    Seconds_Behind_Master: 0
#状态三:
    Slave_IO_State: Queueing master event to the relay log
    Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
    Seconds_Behind_Master: 636

通过MySQL主从复制线程状态转变,我们可以看到三种状态的不同含义:

# 状态一
# 线程正尝试重新连接主服务器,当连接重新建立后,状态变为Waiting for master to send event。
Reconnecting after a failed master event read
# 状态二
# 线程已经连接上主服务器,正等待二进制日志事件到达。如果主服务器正空闲,会持续较长的时间。如果等待持续slave_read_timeout秒,则发生超时。此时,线程认为连接被中断并企图重新连接。
Waiting for master to send event

# 状态三
# 线程已经读取一个事件,正将它复制到中继日志供SQL线程来处理。
Queueing master event to the relay log

在这里,我们可以猜测,由于某些原因,从服务器不断的和主服务器进行断开并尝试重连,重连成功后又再次断开。

我们再看看主机的运行情况:

图片描述

发现问题出在

10.144.63.*
10.144.68.*
两台机器上,我们查看其中一台的错误日志:

190214 11:33:20 [Note] Slave: received end packet from server, apparent master shutdown: 
190214 11:33:20 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.005682' at postion 13628070

拿到关键字

Slave: received end packet from server, apparent master shutdown:
Google
搜索一下,在文章Confusing MySQL Replication Error Message中可以看到原因为两台备机的
server-id
重复。
One day it happen to me, and took me almost an hour to find that out.
Moving foward I always use a base my.cnf to I copy to any other server and the first thing is to increase the server-id.
Could MySQL just use the servername intead of a numeric value?

问题修复

定位了问题,我们确认下是否重复,发现两台备机的该字段确实相同:

vim my.cnf

#replication
log-bin=mysql-bin
# 这个随机数字相同导致的
server-id=177230069
sync_binlog=1

更改一个其他不同的数字,保存,重启

MySQL
进程,报警恢复。

总结

最终来看,这个问题的解决非常简单,但从刚开始的迷茫到最后的思路清晰,都是我们排查问题所常见的,这篇文章的主要收获是让你明白主从同步的机制和追查问题的思路,希望下次我们都能很快的解决主从同步带给我们的问题。

参考资料

  1. 《MySQL基础内幕 InnoDB存储引擎 第2版》P8.7 复制
  2. MySQL主从复制线程状态转变: http://www.ywnds.com/?p=3821
  3. Confusing MySQL Replication Error Message: https://www.percona.com/blog/...

理论要掌握,实操不能落!以上关于《MySQL主从同步机制和同步延时问题追查》的详细介绍,大家都掌握了吧!如果想要继续提升自己的能力,那么就来关注golang学习网公众号吧!

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表