专栏首页idba主从替换之后的复制风暴

主从替换之后的复制风暴

一 现象

一套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 )

  1. bool show_master_info(THD* thd, Master_info* mi)
  2. {
  3. /*省略*/
  4. /*
  5. Seconds_Behind_Master: if SQL thread is running and I/O thread is
  6. connected, we can compute it otherwise show NULL (i.e. unknown).
  7. */
  8. if ((mi->slave_running == MYSQL_SLAVE_RUN_CONNECT) &&
  9. mi->rli.slave_running)
  10. {
  11. long time_diff= ((long)(time(0) - mi->rli.last_master_timestamp)
  12. - mi->clock_diff_with_master);
  13. /*
  14. Apparently on some systems time_diff can be <0. Here are possible
  15. reasons related to MySQL:
  16. - the master is itself a slave of another master whose time is ahead.
  17. - somebody used an explicit SET TIMESTAMP on the master.
  18. Possible reason related to granularity-to-second of time functions
  19. (nothing to do with MySQL), which can explain a value of -1:
  20. assume the master's and slave's time are perfectly synchronized, and
  21. that at slave's connection time, when the master's timestamp is read,
  22. it is at the very end of second 1, and (a very short time later) when
  23. the slave's timestamp is read it is at the very beginning of second
  24. 2. Then the recorded value for master is 1 and the recorded value for
  25. slave is 2. At SHOW SLAVE STATUS time, assume that the difference
  26. between timestamp of slave and rli->last_master_timestamp is 0
  27. (i.e. they are in the same second), then we get 0-(2-1)=-1 as a result.
  28. This confuses users, so we don't go below 0: hence the max().
  29. last_master_timestamp == 0 (an "impossible" timestamp 1970) is a
  30. special marker to say "consider we have caught up".
  31. */
  32. protocol->store((longlong)(mi->rli.last_master_timestamp ?
  33. max(0, time_diff) : 0));
  34. }
  35. else
  36. {
  37. protocol->store_null();
  38. }
  39. /*省略*/
  40. }

解释如下: 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

查看新备库的server_id

主库上冲突的事务的server_id

备库上冲突事务的server_id

老的主库的server_id

解决方法 在新的备库更改server_id为冲突数据的server_id,等数据耗完毕,server_id改为原库的server_id。 读者朋友可以思考一下为什么在备库上执行更改server_id的操作?

对于MySQL 本身,可以加上一层判断,在复制结构中检查 log envent的server_id是否属于 复制结构中数据库的server_id,如果不是,则判断该事物属于复制风暴事物,予以抛弃 。

四 参考资料 [1] 通过源码解析MySQL Seconds_Behind_Master [2] MySQL复制事件在主备之间来回传输检测 [3] 主备备的两个备机转为双master时出现的诡异slave lag问题

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-02-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 死锁案例之二

    一 前言 死锁,其实是一个很有意思也很有挑战的技术问题,大概每个DBA都会在工作过程中遇见。关于死锁我会持续写一个系列的案例分析,希望能够对想了解死锁的朋友有...

    用户1278550
  • 面试题|无索引如何删除亿级数据?

    存在索引的情况下就比较简单,直接利用索引进行删除,写一个for 循环语句 每次删除500行,每次判断delete 影响的行数可以累加计算删除了多少行,直到删除结...

    用户1278550
  • order by 主键id导致全表扫描的问题

    一 简介 在检查某业务数据库的slowlog 时发现一个慢查询,查询时间 1.57s ,检查表结构 where条件字段存在正确的组合索引,正确的情况下优化器应...

    用户1278550
  • 【MyBatis-4】MyBatis批量insert、update、delete数据

    在日常开发中,批量操作数据库数据是常见场景,比如批量插入、批量修改、批量删除数据。MyBatis为批量操作数据提供了非常便利的方案。

    云深i不知处
  • 【玩转腾讯云】比快更快,Github Action + 云开发部署静态网站

    云开发静态托管是云开发提供的静态网站托管的能力,静态资源(HTML、CSS、JavaScript、字体等)的分发由腾讯云对象存储 COS 和拥有多个边缘网点的腾...

    Booker Zhao
  • 微信“搜一搜”接入京东商品的背后说明了什么?

    孟永辉
  • SVN chechout failed: xxx is not valid as filename in directory svn检出错误

    https://blog.csdn.net/luckysiesteven/article/details/80492196

    拓荒者
  • 移动安全加固基础版操作指引

    乐固加固提供了专业版加固服务,相比普通版本整体保护强度更高,主要包括SO加壳保护、APK 防二次打包保护、资源防篡改、内存防dump等服务,目前服务于公司内百万...

    腾讯云@移动安全
  • MyBatis 多参数综合查询的动态 SQL 实现示例

    一个会写诗的程序员
  • 澳政府网站遭黑客袭击,60万份个人资料遭泄露

    据报道,一名16岁的澳大利亚青年日前轻易地潜入澳大利亚维多利亚州大众交通(5.76, -0.06,-1.03%)运输网站,并获得了60万份网站用户的个人机密数据...

    安恒信息

扫码关注云+社区

领取腾讯云代金券