请选择 进入手机版 | 继续访问电脑版

从库Seconds_Behind_Master延迟总结

[复制链接]
苍野狼步 发表于 2020-12-31 19:01:03 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
导读:
  
  本文节选自八怪专栏《深入理解MySQL主从原理32讲》第28节

想阅读更多内容请点击订阅专栏

注意:如果正文有图片不清晰可以将图片生存到本地查看(本文发起横屏观看效果更佳)
  
到这里本系列已经接近尾声了,是时候对常见引起主从延迟的情形举行一个总结了。我想如果我一开始就把这些情形拿出来也许各人对具体的原因不是那么清楚,但是颠末本系列的学习,我相信当我说起这些情形的时候各人都很清楚它的原因了。当然如果尚有其他造成延迟的情形也欢迎各人一起讨论。
一、总结

有了前面的知识我们就可以或许从本质上相识造成延迟的大概有哪些,我先来总结一下这些大概,我将其分为两类:
(1)第一类:

这一类延迟情况大概造成服务器有较高的负载,大概是CPU/IO的负载。因为从库在实际执行Event,如果我们服务器的负载比力高应该思量这几种情况,关于如何查看线程的负载可以参考29节。


  • 大事务造成的延迟,其延迟不会从0开始增加,而是直接从主库执行了多久开始。比如主库执行这个事务花费的20秒,那么延迟就会从20开始,可以自己细心观察一下很容易看到。这是因为Query Event中没有准确的执行时间,这个在上一节的盘算公式中详细形貌过了 ,可以参考第8节和第27节。
  • 大表DDL造成的延迟,其延迟会从0开始增加,因为Query Event记载了准确的执行时间。这个在上一节的盘算公式中也详细形貌过了,可以参考第8节和第27节。
  • 表没有公道的使用主键大概唯一键造成的延迟。这种情况不要以为设置slave_rows_search_algorithms参数为 INDEX_SCAN,HASH_SCAN就可以完全解决问题,原因我们在第24节举行了形貌。
  • 由于参数sync_relay_log,sync_master_info,sync_relay_log_info不公道导致,特别是sync_relay_log会极大的影响从库的性能。原因我们在第26节举行过形貌,因为sync_relay_log设置为1会导致大量relay log刷盘操作。
  • 是否从库开启了记载binary log功能即log_slave_updates参数开启,如果不是须要可以关闭掉。这种情况我遇到很多次了。
(2)第二类:

这一类延迟情况往往不会造成服务器有较高的负载。它们要么没有实际的执行Event,要么就是做了特殊的操作造成的。


  • 长期未提交的事务大概造成延迟瞬间增加,因为GTID_EVENT和XID_EVENT是提交时间其他Event是下令发起的时间。这个我们在第27节中举例形貌过了。
  • Innodb层的行锁造成的延迟,这种是在从库有修改操作而且和SQL线程修改的数据有辩论的情况下造成的,因为我们前面23节说过SQL线程执行Event也会开启事务和获取行锁,下面我们举行测试。
  • MySQL层的MDL LOCK造成的延迟,这种情况大概是由于SQL线程执行某些DDL操作但是从库上做了锁表操作造成,原因我们已经在23节形貌过了,下面我们举行测试。
  • MTS中不公道的设置参数slave_checkpoint_period参数导致,这个在第27节已经测试过了。
  • 在从库运行期间手动改大了从库服务器时间,这个也在第27节已经测试过了。
二、相关测试

因为上面的延迟情形很多我们都已经测试和报告过了。下面我们测试锁造成的延迟情形。
(1)Innodb层的行锁造成的延迟

这个很容测试,我只要先在从库做一个事务和SQL线程修改的数据相同即可以出现,大概测试如下:
  1. 从库:mysql> begin;Query OK, 0 rows affected (0.00 sec)mysql> delete from tmpk;Query OK, 4 rows affected (0.00 sec)不要提交主库执行同样的语句mysql> delete from tmpk;Query OK, 4 rows affected (0.30 sec)
复制代码
这个时候你会观察到延迟如下:

如果查看sys.innodb_lock_waits能看到如下的效果:

当然如果查看INNODB_TRX也可以观察到事务的存在,这里就不截图了,各人可以自己试试。
(2)MySQL层的MDL LOCK造成的延迟

这种情况也非常容易测试,我们只需要开启一个事务做一个select,然后主库对同样的表做DDL就可以出现如下:
  1. 从库:mysql> begin;Query OK, 0 rows affected (0.00 sec)mysql>mysql>mysql> select * from tkkk limit 1;+------+------+------+| a    | b    | c    |+------+------+------+|    3 |    3 |  100 |+------+------+------+1 row in set (0.00 sec)不要提交,表上MDL LOCK就不会释放主库执行语句:mysql> alter table tmpk add testc int ;Query OK, 0 rows affected (1.14 sec)Records: 0  Duplicates: 0  Warnings: 0
复制代码
这个时候你将会看到如下的信息:

我们可以通过state看到这是等待MDL lock获取而导致的延迟,关于MDL lock的详情可以参考我的文章:
http://blog.itpub.net/7728585/viewspace-2143093/
三、总结

通过整个系列,我们应该清楚了Seconds_Behind_Master盘算的方法,同时如果出现了延迟,我们首先查看从库是否有负载,根据是否有负载举行区别对待,注意这里的负载一定要使用top -H查看io/sql/worker线程的负载。我曾不止一次的遇到朋友问我延迟问题,当我问他负载如何的时候他告诉我负载不高啊整体负载也就不到2,这里我们应该注意的是对于一个线程只能使用到一个CPU核,虽然整体负载不到2但是大概io/sql/worker线程已经跑满了,实际上负载已经很高了,我们来看下面的这个截图就是sql线程负载高的截图如下:

这个截图我们发现虽然整体负载不高在1多一点,但是Lwp号20092的线程已经跑满了,这个线程就是我们的sql线程,这个时候出现延迟是很大概的,这个截图正是来自一个没有公道使用主键大概唯一键造成的延迟的案例,案例如下:
https://www.jianshu.com/p/56e8ca2223a0
我们查看CPU负载应该使用top -H去查看,查看io负载可以使用iotop,iostat等工具。我需要强调一下看MySQL负载的时候我们必须用线程的眼光去看,第29节将让你得到这种本领。
到这里整个系列接近尾声,各人会发现主从的原理的照旧比力复杂的,这大概颠覆了以前我们的认知,以前我们认为主从无非就是搭建起来能跑同时知道有io/sql线程就可以了(这确实很简单)。整个系列结论很简单,我们无非就是想设置出安全高效的从库同时知道延迟是怎么导致的,出现延迟后我们如那边置惩罚,我自认为本系列照旧将这些问题解说得很清楚了。当然如果本系列的原理部分都可以或许理解得很好,那么工作中解决主从问题一定会更加得心应手。
识别下方二维码添加作者为挚友

END
  
点击下图小程序订阅
《深入理解MySQL主从原理32讲》专栏
可相识更多八怪技能文章











扫码参加MySQL技能Q群



(群号:793818397)
   






来源:https://blog.csdn.net/n88Lpo/article/details/100549898
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则


专注素材教程免费分享
全国免费热线电话

18768367769

周一至周日9:00-23:00

反馈建议

27428564@qq.com 在线QQ咨询

扫描二维码关注我们

Powered by Discuz! X3.4© 2001-2013 Comsenz Inc.( 蜀ICP备2021001884号-1 )