一 现象
一套MySQL主-备-备-备数据库,其中的备库升级到主库之后,系统监控报警 Seconds_Behind_Master 瞬间为0,瞬间为数十万秒。第一感觉是遇到了复制风暴--不同于主备server_id 的log event在主备库之间无限循环复制。升级的逻辑图如下:
二 分析
在双主复制结构中,主库发生数据更新,会将更新记录为含有server_id_1 的log event事件发送到备库,然后备库更新数据,将含有server_id_1的log event 事件发送给主库,因此最初主库上的log event 更新事件又传了回来,这时候MySQL就要对复制事件的server_id进行判断,发现复制事件的server_id和自己的server_id相同时,放弃执行,如果不同 则执行该log event 并记录到binlog 里面继续发送给备库。 如果该event的server_id和主备的server_id都不相同,该log event 则在主备库中无限循环执行,也就是通常所说的复制风暴。
那为什么slave lag 为时大时小呢? 首先我们要了解MySQL 对于slave lag 的计算方式(sql/slave.cc )
解释如下:
long_time_diff就是seconds_behind_master
seconds_behind_master= slave系统时间 - master执行创建event的timestamp - ( slave系统时间 - master系统时间 )
(slave系统时间-master执行最新event的timestamp):得到最新event到slave执行还要多久。
(slave系统时间-master系统时间):可能存在主备系统时间差别,所以计算seconds_behind_master要减去,但实际情况,slave和master系统时间基本一致,得到结果应该接近0
所以seconds_behind_master的值是由于slave系统时间-master执行最新event的timestamp 决定的,当导致循环复制的log event创建时间越久远,slave lag 会越大,执行完 这个event,会执行真正主库执行的log event ,此时slave lag 就会变成0 。
三 解决
查看新主库的server_id
![](/attachment/201508/3/22664653_14386171788uZw.jpg)
查看新备库的server_id
![](/attachment/201508/3/22664653_1438617217nhIq.jpg)
主库上冲突的事务的server_id
![](/attachment/201508/3/22664653_1438617217vPVw.jpg)
备库上冲突事务的server_id
![](/attachment/201508/3/22664653_1438617218p1xy.jpg)
老的主库的server_id
![](/attachment/201508/3/22664653_1438617218WT59.jpg)
解决方法
在新的备库更改server_id为冲突数据的server_id,等数据耗完毕,server_id改为原库的server_id。 读者朋友可以思考一下为什么在备库上执行更改server_id的操作?
![](/attachment/201508/3/22664653_1438617218PEKP.png)
对于MySQL 本身,可以加上一层判断,在复制结构中检查 log envent的server_id是否属于 复制结构中数据库的server_id,如果不是,则判断该事物属于复制风暴事物,予以抛弃 。
一套MySQL主-备-备-备数据库,其中的备库升级到主库之后,系统监控报警 Seconds_Behind_Master 瞬间为0,瞬间为数十万秒。第一感觉是遇到了复制风暴--不同于主备server_id 的log event在主备库之间无限循环复制。升级的逻辑图如下:
![](/attachment/201508/3/22664653_143861665544X4.jpg)
二 分析
在双主复制结构中,主库发生数据更新,会将更新记录为含有server_id_1 的log event事件发送到备库,然后备库更新数据,将含有server_id_1的log event 事件发送给主库,因此最初主库上的log event 更新事件又传了回来,这时候MySQL就要对复制事件的server_id进行判断,发现复制事件的server_id和自己的server_id相同时,放弃执行,如果不同 则执行该log event 并记录到binlog 里面继续发送给备库。 如果该event的server_id和主备的server_id都不相同,该log event 则在主备库中无限循环执行,也就是通常所说的复制风暴。
那为什么slave lag 为时大时小呢? 首先我们要了解MySQL 对于slave lag 的计算方式(sql/slave.cc )
- bool show_master_info(THD* thd, Master_info* mi)
- {
- /*省略*/
- /*
- Seconds_Behind_Master: if SQL thread is running and I/O thread is
- connected, we can compute it otherwise show NULL (i.e. unknown).
- */
- if ((mi->slave_running == MYSQL_SLAVE_RUN_CONNECT) &&
- mi->rli.slave_running)
- {
- long time_diff= ((long)(time(0) - mi->rli.last_master_timestamp)
- - mi->clock_diff_with_master);
- /*
- Apparently on some systems time_diff can be <0. Here are possible
- reasons related to MySQL:
- - the master is itself a slave of another master whose time is ahead.
- - somebody used an explicit SET TIMESTAMP on the master.
- Possible reason related to granularity-to-second of time functions
- (nothing to do with MySQL), which can explain a value of -1:
- assume the master's and slave's time are perfectly synchronized, and
- that at slave's connection time, when the master's timestamp is read,
- it is at the very end of second 1, and (a very short time later) when
- the slave's timestamp is read it is at the very beginning of second
- 2. Then the recorded value for master is 1 and the recorded value for
- slave is 2. At SHOW SLAVE STATUS time, assume that the difference
- between timestamp of slave and rli->last_master_timestamp is 0
- (i.e. they are in the same second), then we get 0-(2-1)=-1 as a result.
- This confuses users, so we don't go below 0: hence the max().
- last_master_timestamp == 0 (an "impossible" timestamp 1970) is a
- special marker to say "consider we have caught up".
- */
- protocol->store((longlong)(mi->rli.last_master_timestamp ?
- max(0, time_diff) : 0));
- }
- else
- {
- protocol->store_null();
- }
- /*省略*/
- }
long_time_diff就是seconds_behind_master
seconds_behind_master= slave系统时间 - master执行创建event的timestamp - ( slave系统时间 - master系统时间 )
(slave系统时间-master执行最新event的timestamp):得到最新event到slave执行还要多久。
(slave系统时间-master系统时间):可能存在主备系统时间差别,所以计算seconds_behind_master要减去,但实际情况,slave和master系统时间基本一致,得到结果应该接近0
所以seconds_behind_master的值是由于slave系统时间-master执行最新event的timestamp 决定的,当导致循环复制的log event创建时间越久远,slave lag 会越大,执行完 这个event,会执行真正主库执行的log event ,此时slave lag 就会变成0 。
三 解决
查看新主库的server_id
![](/attachment/201508/3/22664653_14386171788uZw.jpg)
查看新备库的server_id
![](/attachment/201508/3/22664653_1438617217nhIq.jpg)
主库上冲突的事务的server_id
![](/attachment/201508/3/22664653_1438617217vPVw.jpg)
备库上冲突事务的server_id
![](/attachment/201508/3/22664653_1438617218p1xy.jpg)
老的主库的server_id
![](/attachment/201508/3/22664653_1438617218WT59.jpg)
解决方法
在新的备库更改server_id为冲突数据的server_id,等数据耗完毕,server_id改为原库的server_id。 读者朋友可以思考一下为什么在备库上执行更改server_id的操作?
![](/attachment/201508/3/22664653_1438617218PEKP.png)
对于MySQL 本身,可以加上一层判断,在复制结构中检查 log envent的server_id是否属于 复制结构中数据库的server_id,如果不是,则判断该事物属于复制风暴事物,予以抛弃 。
四 参考资料
[1] 通过源码解析MySQL Seconds_Behind_Master
[2] MySQL复制事件在主备之间来回传输检测
[3] 主备备的两个备机转为双master时出现的诡异slave lag问题
[1] 通过源码解析MySQL Seconds_Behind_Master
[2] MySQL复制事件在主备之间来回传输检测
[3] 主备备的两个备机转为双master时出现的诡异slave lag问题
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22664653/viewspace-1760960/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/22664653/viewspace-1760960/