latch mysql_Latch导致MySQL Crash
问题概述
最近我们遇到一个MySQL的问题,分析后很有代表意义,特地写出来供大家参考。
出现问题是,数据库先是被置为只读,然后过了一段时间,MySQL直接Crash掉了
发生Crash时MySQL的error日志中打印了以下内容:
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 1246555
--Thread 140363572082432 has waited at row0upd.cc line 2354 for 253.00 seconds the semaphore:
X-lock (wait_ex) on RW-latch at 0x7fa949340740 created in file buf0buf.cc line 1069
a writer (thread id 140363572082432) has reserved it in mode wait exclusive
number of readers 1, waiters flag 1, lock_word: ffffffffffffffff
Last time read locked in file btr0sea.cc line 931
Last time write locked in file/export/home/pb2/build/sb_0-17068951-1447697721.44/mysql-5.6.28/storage/innobase/row/row0upd.cc line 2354
根据日志中我们可以看到,线程140363572082432要对记录上一个X锁,但是等待0x7fa949340740线程的RW-latch的释放
我们再向下看查询到如下信息(涉及到用户信息 谓词就用xxx代替):
173 lock struct(s), heap size 30248, 7925 row lock(s), undo log entries 7924
MySQL thread id 5709783, OS thread handle 0x7fa8f0da7700, query id 92213034 10.23.163.54 citicqyh updating
update TB_DEPARTMENT_INFO set TOTAL_USER=1 where ID='ac84f17e-82d3-4519-a1da-0d5a5a835d44'
---TRANSACTION 53065242, ACTIVE 313 sec fetching rows, thread declared inside InnoDB 2081
mysql tables in use 2, locked 0
MySQL thread id 5428690, OS thread handle 0x7fa8f0136700, query id 92213061 10.23.163.55 citicqyh Sending data
SELECT COUNT(DISTINCT r.user_id) FROM TB_DEPARTMENT_INFO d left join tb_qy_user_department_ref r on r.department_id = d.id WHERE d.org_id = 'xxx' AND (d.dept_full_name LIKE 'xxx%' or d.dept_full_name = 'xxx
Trx read view will not see trx with id >= xxx, sees < xxx
......还有很多select语句省略
根据上面信息我们去数据库中查看了这些select语句,发现执行计划都是全表扫描。
首先数据库变成了只读,最后数据库crash了,crash输出的信息如下:
----------------------------
END OF INNODB MONITOR OUTPUT
============================
InnoDB: ###### Diagnostic info printed to the standard error stream
InnoDB: Error: semaphore wait has lasted > 600 seconds
InnoDB: We intentionally crash the server, because it appears to be hung.
7fa8f9580700 InnoDB: Assertion failure in thread 140363714529024 in file srv0srv.cc line 1754
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Error: semaphore wait has lasted > 600 seconds 提示600秒没有响应 数据库选择了Crash 强制重启
从报错信息来看:
update语句需要在记录上面加X锁,但是必须等待RW-Latch的释放
由于有大量的select语句是全表扫描,一直占用latch没有释放,update迟迟竞争不到RW-latch
Innodb 的Diagnostic线程检查到RW-Latch等待超过了600秒还没有返回,认为系统出现了严重问题,于是触发了MySQL服务的Crash。
进一步分析
这里首先需要补充一下Latch的概念:Latch在MySQL中是用于保护高速缓冲区中共享数据的,举个例子:
当我们执行select时,数据是缓存在buffer pool中的,多个线程并发访问或者修改这个数据必然需要一个并发控制机制,这个就是Latch
大家知道,数据库要访问的数据都必须先存在缓存中,而缓存一般比磁盘空间要小,数据缓存使用hash表来记录数据页是否在内存中。在Oracle中的并发控制比较精细:首先会对hash桶加latch,并根据hash桶查找对应的数据并加上pin,然后释放Latch。而MySQL相对没有控制得这么精细,对应的RW-Latch在errlog中说的很清楚,该RW-Latch是在buf0buf.cc的1069行创建的
RW-latch at 0x7fa949340740 created in file buf0buf.cc line 1069
对应的代码摘录如下:
rw_lock_create(PFS_NOT_INSTRUMENTED,&block->lock,SYNC_LEVEL_VARYING);
跟踪源码,知道这个Latch是MySQL在数据库启动,初始化 innodb_buffer_pool时,将Latch创建好的。对应的函数调用过程:
buf_pool_init_instance()->buf_chunk_init()->buf_block_init()
正是由于这个RW-Latch被长时间占用了,其他的线程一直竞争不到,才导致了这个问题
修复建议
这类问题的发生多数都是因为SQL写的不好,在表上面进行了大量的全表扫描占用了大量的Latch,解决方案就是避免SQL长时间占用latch:
修改select查询避免全表扫描,避免latch长期被占用
适当的加索引,让select执行更快,也避免一个select锁的数据更少
适当加大buffer pool instance,每个buffer pool都有自己独立的Latch,避免latch竞争。
本文来自云栖社区合作伙伴“DBGEEK”
latch mysql_Latch导致MySQL Crash相关推荐
- mysql批量insert bug_MySQL Bug insert into on duplicate key update 语法更新 text blob 大字段导致 MySQL crash...
1. 背景 业务执行 SQL 导致 MySQL 进程 Crash,做故障切换后,新的主库又 Crash 了.查看 MySQL 错误日志,发现多次 Crash 时的堆栈相同,如下: Thread poi ...
- 导入失败 mysql_服务器宕机导致mysql出问题的处理方法
点上方蓝字"工控先生"免费快速关注 本文由"135编辑器 在工作中,我们会遇到由于服务器突然断电,导致mysql数据库启动失败,这个启动失败大部分都是由于数据库本身的文件 ...
- mysql同步出错后重启_服务器重启导致mysql同步出错
服务器重启导致mysql同步出错 151119 11:05:04 mysqld_safe Starting mysqld daemon with databases from /data/mysql ...
- 怎么操作会导致MySQL锁表
怎么操作会导致MySQL锁表 转载于:https://www.cnblogs.com/luao/p/10867785.html
- mysql索引失效_导致MySQL索引失效的几种常见写法
最近一直忙着处理原来老项目遗留的一些SQL优化问题,由于当初表的设计以及字段设计的问题,随着业务的增长,出现了大量的慢SQL,导致MySQL的CPU资源飙升,基于此,给大家简单分享下这些比较使用的易于 ...
- 360安全卫士 导致MySQL 5.0.24 自动关闭
1/17/2009 9:47:00 PM 360安全卫士 导致MySQL 5.0.24 自动关闭 360安全卫士版本 5.0.0.1020 今天升级安全卫士到5.0.0.1022 ,已经解决了这个问题
- 压测导致mysql数据库CPU很高_排查压测问题引发的系统性能调优过程
前言:今天测试部门的小梦找到我,委屈巴巴的说我写的接口有问题,因为她对这个接口进行压力测试时,发现系统的吞吐量一直上不去,并且 应用服务器 (部署接口项目的服务器) 的CPU.内存等资源的使用率也一直 ...
- like左匹配索引失效_导致MySQL索引失效的一些常见写法总结
前言 最近一直忙着处理原来老项目遗留的一些SQL优化问题,由于当初表的设计以及字段设计的问题,随着业务的增长,出现了大量的慢SQL,导致MySQL的CPU资源飙升,基于此,给大家简单分享下这些比较使用 ...
- 反汇编程序导致程序crash的解决思路
曾经发现win7下程序基地址不停地变动,又发现下移代码会导致程序crash,一度怀疑win7系统或者vs编译器是不是做了什么校验机制,专门针对数据逆向者,限制反汇编修改代码,打断了我学习外挂编写的信心 ...
- 闰秒导致MySQL服务器的CPU sys过高
今天,有个哥们碰到一个问题,他有一个从库,只要是启动MySQL,CPU使用率就非常高,其中sys占比也比较高,具体可见下图. 注意:他的生产环境是物理机,单个CPU,4个Core. 于是,他抓取了CP ...
最新文章
- 算法训练 区间k大数查询
- 是否可能有一台算力无穷大的计算机?
- python优秀库_2017年度15个优秀的数据科学领域Python库
- Spring Cloud Gateway不能使用外置tomcat部署的问题
- [z]IE6各种不兼容问题
- IDEA 快捷键终极大全
- 微软发布了开发社区采用.NET Standard的最新信息
- webRTC实战总结
- arm中断保护和恢复_浅谈ARM处理器的七种异常处理
- 前端特效demo | 值得收藏的6个 HTML5 Canvas 实用案例
- python编程高手之路——函数调用
- 6410的系统时钟设置(上)---6410时钟控制逻辑框架分析
- 谁适合做Scrum Master?
- Linux -单用户模式(忘记Linux的root密码)
- 贪吃蛇c语言代码高难,100多行代码的《贪吃蛇》
- 数据-第14课-栈的定义及实现
- Toad:基于 Python 的标准化评分卡模型
- Qt5.12.6 + VS2019添加图片资源文件
- X86加装PCIE网卡无法访问ESXi的问题
- python查找第k大的数_寻找数组中第K大的数
热门文章
- 养老保险和住房公积金如何转移
- SpringBoot掌握的差不多了,就剩下一个Actuator没搞定了,本文详细来介绍!!!
- Java集合原理分析
- Linux 内核 regulator 机制
- 纯CSS实现四种方式文本反差色效果
- Ubuntu安装微信,三步到位
- c语言编程绘制空间螺旋线,在UG中绘制变螺距螺旋线的方法
- 【Python数据分析学习实例】篮球运动位置分析
- IT行业都有哪些职位?工作内容及升职路线
- 设计adm和CPU计算机组装方案,成熟的解决方案:CPU风扇(AMD和INTEL)的详细拆卸和安装方法(图形教程)...