性能文章>MySQL备份问题排查和思考>

MySQL备份问题排查和思考转载

2年前
345247

作者:roidba、流转的时光。

  • 1. 背景

  • 2. 疑点

  • 3. 问题分析

  • 4. 问题定位

  • 5. checking permissions的疑惑

  • 6. 探索优化思路

  • 7. 补充:关于几个timeout参数生效点

1. 背景

行内数据库备份在使用某备份软件,使用的数据库版本MySQL 8.0社区版,全备使用mysqldump进行,DBA早上巡检发现有一套数据库全备份失败,心里一疙瘩怎么回事呢?来看看如下报错

[mysqldump: Error: 'Lost connection to MySQL server during query' when trying to dump tablespaces mysqldump: couldn't execute 'SHOW VARIABLES LIKE 'ndbinfo'\_version' MySQL server has gone away (2006)]

肯定有同学有疑问?

  • 为什么mysqldump会出现丢失连接?
  • 为什么不使用xtrabackup呢?这需要另外章节来阐述了。

2. 疑点

为什么mysqldump会出现丢失连接?带着该问题进行以下分析:

  • 1.检查备份软件工具负载情况
  • 2.检查数据库中错误日志
  • 3.数据库的负载情况

3. 问题分析

3.1 备份软件是否存在高负载、排队或超时配置导致响应超时?

对整个备份系统进行排查,虽然备份系统任务多,但并没有出现性能瓶颈导致数据库备份时超时,备份软件也没有设置备份超时时间自动断开的相关配置

3.2 检查数据库错误日志
   2020-10-26T01:31:14.465387+08:00 149718 [Note] [MY-010914] [Server] Aborted connection 149718 to db: 'unconnected' user: 'root' host: 'localhost' (Got an error reading communication packets).

通过数据库错误日志发现同备份软件报错一样,对于这个错误,MOS上有一个比较好的解释如下:

不管怎么样我们后面先来看备份软件触发了些什么语句。

3.3 检查数据库负载情况,备份期间cpu、io均比较正常

4. 问题定位

从上述检查来看,报错处是Got an error reading而不是timeout,关于timeout的触发方式我们最后总结。首先从备份软件架构,备份软件在数据库中部署agent,所以连接属于交互式连接受到参数interactive_timeout的影响,那么为什么导致的超时丢失连接的呢?我们可以进行问题复现,使用备份软件对数据库发起重新备份,对数据库进行监控

4.1 通过备份软件发起备份,可以看到会发起4个本地备份连接,3个处于sleep状态,一个线程处于执行状态下,如下:

SQL语句:

  SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE, ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'UNDO LOG' AND FILE_NAME IS NOT NULL AND LOGFILE_GROUP_NAME IS NOT NULL AND LOGFILE_GROUP_NAME IN (SELECT DISTINCT LOGFILE_GROUP_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE' AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA IN ('xxx'))) GROUP BY LOGFILE_GROUP_NAME, FILE_NAME, ENGINE, TOTAL_EXTENTS, INITIAL_SIZE ORDER BY LOGFILE_GROUP_NAME;

注意这里的状态为checking permissions,并且这个语句长期处于这个状态。我们以前理解的这个就是在鉴权,我们一般的认知是下面一些顺序:

  • starting:lex+yacc 语法语**析,得到解析树
  • checking permissions:根据解析后的解析树,对需要访问的表进行鉴权
  • opening tables:打开访问的表,建立内部访问表的属性(表和字段信息),建立好和Innodb的关联,同时加上表锁(MDL LOCK)
  • optimizing/statistics/preparing:这3个状态处于语句的物理和逻辑优化阶段,之后建立好执行计划
  • Sending data( 8.0为executing):select语句MySQL层和Innodb层进行数据交互,遇到这个状态通常考虑语句是否足够优化
  • Update:同上insert语句,如果遇到行锁会处于这个状态下。
  • Updating:同上delete/update语句,如果遇到行锁会处于这个状态下。
  • query end(waiting for handler commit 8.0):语句的提交过程包含在这个状态下,遇到这个问题,主要考虑是否大事务的存在。
  • closing tables:和opening tables对应,释放表的内部访问版本放入缓存共下次使用,同时也包含语句的错误回滚也在这个状态下
  • freeing items:释放解析树

我们能够看到,鉴权实际上在比较靠前的位置,是不是说这里语句还没真正的开始执行呢?我们先放一放。

4.2 通过执行show processlist发现上述SQL一直处于运行状态,于是终止备份,手工运行该SQL

由此可以推测发现,备份软件在发起备份时会发起4个连接,而其中一个连接执行SQL比较久,而另外3个sleep连接在超过interactive_timeout后断开,导致agent整体退出关闭所有的数据库连接,执行的SQL也终止,所以报错Got an error reading。但是奇怪的是我们在日志并没有找到Got timeout reading communication packets的日志。

4.3 重点是该SQL为什么运行时间这么久呢?我们通过运行SQL获取执行计划和我们采用perf top+top -H的方式来看看内部的函数调用。发现如下:

  • 结合资源占用情况可以看到占用cpu资源最大的函数是:JOIN_CACHE::read_record_field
  • 结合执行计划看sub_part、tsf、cat使用了临时表和join_buffer,试图分析i_s.files无果,该试图中大多是数据字典,无法访问。
  • 这可能和我们系统中存在大量ibd文件有关。肯定很多同学会问,为什么会有这么多ibd,因为我们大量使用 分库、分表、分区

我们知道join cache 一般用在两表join连接,被驱动表没有索引的情况下,将驱动表的数据放到join cache中,当join cache满了以后驱动一次被驱动表,以此来减少被驱动表全表扫描的次数,进而提高性能。

其次我们需要知道的MySQL虽然某一个线程负载高但是,一个线程只能使用CPU核心,我们监控监控的是整体的CPU,因此虽然一个CPU已经达到99%的高负载,但是整体平均下来也不那么明显,这是我行以后监控需要持续改进的地方。

5. checking permissions的疑惑

很明显上面的分析我们发现语句实际已经执行了,但是为什么处于checking permissions状态呢?为了解开这个疑惑,我们需要将断点放到THD::enter_stage和JOIN_CACHE::read_record_field上,当然这部分我们没有深入的研究,只看debug状态,debug 什么呢,只要证明状态 executing 后进入了checking permissions状态且在checking permissions状态下执行了JOIN_CACHE::read_record_field即可如下:

这里证明了语句已经进入了执行阶段,但是每次读取一行join cache的记录转换一次状态为checking permissions,栈如下:

我们来看红色函数的注释如下:

INFORMATION_SCHEMA picks metadata from new DD using system views.

显然这里和访问information_schema中的数据有关,因为这里涉及到information_schema和数据字典的实现,过于庞大,我们不做研究了。

但是我们得出一个结论,对于访问字典视图,出现比较奇怪的状态,我们应该用perf top或者pstack获取信息,而不能停留在常规的认知上。

6. 探索优化思路

  • 肯定有同学想问mysqldump为什么要执行上面这个SQL呢?这个还需要备份厂商来解释了,该SQL在备份中还不能短时间改善,银行是非常注重备份,不可能等厂商改,所以我们放弃该思路
  • 既然厂商无法调整,那我们就从数据库本身着手,SQL属于内部试图,我等源码基础也不好,无奈啊!只能从执行计划和占用高资源得函数着手,既然join_cache这么高,且执行计划中提示使用了join_buffer和临时表,那么我们来试图调整join_buffer_size,当前默认是2M,将join_buffer_size调整后再次执行SQL,SQL运行1min7s,效果明显。

至此,我们已经找到优化思路,调整数据库join_buffer_size来解决,肯定有同学问,这个也不能随便调整啊,因为这是一个session级别的参数,可能导致MySQLD使用内存大幅增加。但是,我们架构中设计的这个库是专门用于全备的,没有任何应用连接,所以可以调整该参数。再次发起数据库备份,观察几天时间,该问题不再发现。透过事物看本质发现,mysql中在有大量的表或分区情况下,在通过内部试图、数据字典读取操作系统中文件时可能会存在有各种性能问题,对于某些查询操作我们可以在备库进行,尽量减少对主库的冲击。

7. 补充:关于几个timeout参数生效点

接下来我们也研究了几个timeout参数, 如果出现超时遇到了日志是Got timeout reading communication packets,而不是Got an error reading communication packets。实际上几个timeout 参数都是通过poll的timeout参数实现的,我们稍微总结了一下如下:

  1. 连接进行握手,连接时poll的timeout受到connect_timout影响
  2. loop 进入死循环
  3. wait_timeout/interactive_timeout 参数设置poll timeout参数
  4. 堵塞等待命令来到
  5. 命令来到退出堵塞。
  6. 命令执行期间读写更改poll的参数,受net_read_timout和net_write_timeout参数影响
  7. 命令执行
  8. 命令执行完成后,再次做wait_timeout/interactive_timeout参数检查并且恢复
  9. goto loop

因此总结一下:

  • Got timeout reading communication packets:可能和参数connect_timout,net_read_timout,wait_timeout/interactive_timeout 有关

  • Got timeout writing communication packets:可能和参数net_write_timeout有关

文章来源:微信公众号

原文链接:https://mp.weixin.qq.com/s/iOCjPF0XelG3VTiojW5gQA

点赞收藏
分类:标签:
大绿植
请先登录,查看4条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

日常Bug排查-偶发性读数据不一致

日常Bug排查-偶发性读数据不一致

7
4