第28节 从库Seconds_Behind_Master延迟总结

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,高可用系列 2核4GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 从库Seconds_Behind_Master延迟总结到这里本系列已经接近尾声了,是时候对常见引起主从延迟的情形进行一个总结了。我想如果我一开始就把这些情形拿出来也许大家对具体的原因不是那么清楚,但是经过本系列的学习,我相信当我说起这些情形的时候大家都很清楚它的原因了。

从库Seconds_Behind_Master延迟总结


到这里本系列已经接近尾声了,是时候对常见引起主从延迟的情形进行一个总结了。我想如果我一开始就把这些情形拿出来也许大家对具体的原因不是那么清楚,但是经过本系列的学习,我相信当我说起这些情形的时候大家都很清楚它的原因了。当然如果还有其他造成延迟的情形也欢迎大家一起讨论。

欢迎关注我的《深入理解MySQL主从原理 32讲 》,如下:

image.png

一、总结

有了前面的知识我们就能够从本质上了解造成延迟的可能有哪些,我先来总结一下这些可能,我将其分为两类:

(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线程修改的数据相同即可以出现,大概测试如下:

从库:

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)

这个时候你会观察到延迟如下:

image.png

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

image.png

当然如果查看INNODB_TRX也可以观察到事务的存在,这里就不截图了,大家可以自己试试。

(2)MySQL层的MDL LOCK造成的延迟

这种情况也非常容易测试,我们只需要开启一个事务做一个select,然后主库对同样的表做DDL就可以出现如下:

从库:
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

这个时候你将会看到如下的信息:

image.png

我们可以通过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线程负载高的截图如下:

image.png

这个截图我们发现虽然整体负载不高在1多一点,但是Lwp号20092的线程已经跑满了,这个线程就是我们的sql线程,这个时候出现延迟是很可能的,这个截图正是来自一个没有合理使用主键或者唯一键造成的延迟的案例,案例如下:

https://www.jianshu.com/p/56e8ca2223a0

我们查看CPU负载应该使用top -H去查看,查看io负载可以使用iotop,iostat等工具。我需要强调一下看MySQL负载的时候我们必须用线程的眼光去看,第29节将让你获得这种能力。

到这里整个系列接近尾声,大家会发现主从的原理的还是比较复杂的,这可能颠覆了以前我们的认知,以前我们认为主从无非就是搭建起来能跑同时知道有io/sql线程就可以了(这确实很简单)。整个系列结论很简单,我们无非就是想配置出安全高效的从库同时知道延迟是怎么导致的,出现延迟后我们如何处理,我自认为本系列还是将这些问题讲解得很清楚了。当然如果本系列的原理部分都能够理解得很好,那么工作中解决主从问题一定会更加得心应手。


第28节结束

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
开发框架 前端开发 Android开发
跨平台应用程序开发如何选择框架
跨平台应用程序开发如何选择框架
|
11月前
|
缓存 移动开发 JavaScript
《vue2进阶篇:路由》第10章:vue-router,包括基础路由、嵌套路由、路由的query参数和params参数、命名路由、router-link的replace属性、编程式路由、缓存路由组件
《vue2进阶篇:路由》第10章:vue-router,包括基础路由、嵌套路由、路由的query参数和params参数、命名路由、router-link的replace属性、编程式路由、缓存路由组件
556 2
|
存储 人工智能 物联网
|
Java Spring 监控
Spring Boot Actuator:守护你的应用心跳,让监控变得触手可及!
【8月更文挑战第31天】Spring Boot Actuator 是 Spring Boot 框架的核心模块之一,提供了生产就绪的特性,用于监控和管理 Spring Boot 应用程序。通过 Actuator,开发者可以轻松访问应用内部状态、执行健康检查、收集度量指标等。启用 Actuator 需在 `pom.xml` 中添加 `spring-boot-starter-actuator` 依赖,并通过配置文件调整端点暴露和安全性。Actuator 还支持与外部监控工具(如 Prometheus)集成,实现全面的应用性能监控。正确配置 Actuator 可显著提升应用的稳定性和安全性。
516 0
|
SQL 运维 DataWorks
Flink CDC在阿里云DataWorks数据集成应用实践
本文整理自阿里云 DataWorks 数据集成团队的高级技术专家 王明亚(云时)老师在 Flink Forward Asia 2023 中数据集成专场的分享。
1678 2
Flink CDC在阿里云DataWorks数据集成应用实践
|
监控 应用服务中间件 nginx
使用 Docker Compose V2 快速搭建日志分析平台 ELK (Elasticsearch、Logstash 和 Kibana)
ELK的架构有多种,本篇分享使用的架构如图所示: Beats(Filebeat) -> -> Elasticsearch -> Kibana,目前生产环境一天几千万的日志,内存占用大概 10G
972 4
|
机器学习/深度学习 编解码 并行计算
深度学习的图像超分技术综述-输入单张图像(SISR)和输入多张图像的基于参考的图像(RefSR)
深度学习的图像超分技术综述-输入单张图像(SISR)和输入多张图像的基于参考的图像(RefSR)
677 0
|
监控 数据可视化 Go
实战 | Telegraf+ InfluxDB+Grafana 搭建服务器性能监控平台
在之前的文章《移动端UI自动化过程中的难点及应对策略》中我们讨论了影响移动端自动化稳定性的一些因素,其中宿主机环境是一个不可忽视的问题,大家都知道移动端的自动化一般都需要将设备挂载到实体服务器上运行,如果服务器宿主机出现断网或者磁盘空间不足等情况,都会在一定程度上影响自动化任务的执行,因此今天跟大家分享一下如何做服务器宿主机的监控。
619 0
实战 | Telegraf+ InfluxDB+Grafana 搭建服务器性能监控平台
|
算法 Java BI
Sentinel为什么这么强,我忍不住扒了扒背后的实现原理
大家好,我是三友~~ 最近我在整理代码仓库的时候突然发现了被尘封了接近两年之久的Sentinel源码库 两年前我出于好奇心扒了一下Sentinel的源码,但是由于Sentinel本身源码并不复杂,在简单扒了扒之后几乎就再没扒过了 那么既然现在又让我看到了,所以我准备再来好好地扒一扒,然后顺带写篇文章来总结一下。
Sentinel为什么这么强,我忍不住扒了扒背后的实现原理

热门文章

最新文章