MySQL5.7:崩溃恢复“”优化“” 所带来的3例退化-阿里云开发者社区

开发者社区> zhaiwx_yinfeng> 正文

MySQL5.7:崩溃恢复“”优化“” 所带来的3例退化

简介:
+关注继续查看

背景

在MySQL5.7之前的版本中,每次崩溃恢复时都需要打开数据目录下所有的ibd文件,校验其有效性并内存中创建表空间链表。当表的数量特别多的时候, 会严重影响到崩溃恢复的性能。

为了解决这个问题,MySQL5.7版本中增加了新的日志类型MLOG_FILE_NAME及MLOG_CHECKPOINT。前者记录了被修改后的Ibd文件名,后者记录了最近一次checkpoint的LSN点。通过扫描Redo日志,InnoDB可以找到在最近一次checkpoint之后修改过的数据文件,这样在崩溃恢复时就无需打开所有的表空间。

但据我所知,这个特性至少引入了三个问题。以下简单为大家分享下

Log Parse Buffer溢出(bug#83245)

第一个问题是在做checkpoint时,会在一个mtr里将这期间修改的文件名记录到redo中,如果涉及的文件过多的话,就会导致一个mtr非常巨大,在崩溃恢复时,用于解析log的buffer(大小为2MB)会溢出。这个bug在MySQL5.7.18版本被修复。

为了避免这个问题,在做checkpoint写文件名时,如果已产生的log大小超过4个page size(LOG_CHECKPOINT_FREE_PER_THREAD), 就将当前日志提交掉并重新开启mtr(这中间不释放log_sys->mutex)

另一个修改是在崩溃恢复parse redo log的时候,如果一个log group中都是MLOG_FILE_NAME, 则直接推进recovered_offset/lsn,相当直接推进recover的点,这样在parse buffer里就无需存储整个mtr的日志。

详细修复补丁见这个commit

崩溃恢复的性能退化(bug#80788)

该特性带来的另外一个严重问题是崩溃恢复的性能退化,尤其是在表少,但需要恢复的日志量很大的时候。这是因为在崩溃恢复时最少扫描两次日志,最多要重复扫描三次,以下摘自commit log的解释

    First scan: Scan all the redo logs from checkpoint lsn and process
    only MLOG_FILE_* records during first scan. It scans till the
    last MLOG_CHECKPOINT.

    Second scan: Scan all redo logs from checkpoint lsn and add log
    records to hash table. It verifies whether space id is having
    corresponding MLOG_FILE_NAME record. If the hash table heap memory
    is reached the threshold then stop adding records to hash but it
    continues to scan till end of the redo log file.

    Third scan: Scan all redo logs from checkpoint lsn and add log records
    to hash table only if the tablespace exists. If the heap memory reached
    the threshold then simultaneous scan and apply will happen.

我在report了bug后,很快官方就确认了,但直到5.7.19版本才fix了这个问题,对崩溃恢复有要求的同学最好尽快升级到这个版本。

简单看了下官方的修复,思路也比较简单,将第一次和第二次扫描合并,这样最少一次,最多两次扫描(buffer pool不够大的时候)。

Patch链接如下:
COMMIT 1
COMMIT 2

更高的fil_system::mutex冲突(bug#85304)

由于需要在redo中记录修改的文件名,每次在做数据变更时,都会去调用函数mtr_t::set_named_space,对于用户表空间,会进一步的调用函数mtr_t::lookup_user_space-> fil_space_get 通过space id来获得表空间的fil_space_t对象,这需要fil_system::mutex的保护。在高并发下可能导致比较激烈的锁冲突。

目前MySQL5.7还没有修复计划(估计也不会去修了..),但8.0版本已经将 WL#7142的工作整体删除了,并实现了另外一套机制来加速崩溃恢复(后面单独介绍)。而针对fil_system::mutex的通用场景冲突也在优化过程中。我们可以期待下MySQL8.0版本 :)

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
管理系统中风险是系统可用性和可扩展性的关键(4)
管理系统中风险是系统可用性和可扩展性的关键(4)
6 0
阿里巴巴数据库分库分表的实践(5)
阿里巴巴数据库分库分表的实践(5)
4 0
从时延毛刺问题定位到 Netty 的性能统计设计(下)
从时延毛刺问题定位到 Netty 的性能统计设计(下)
4 0
用阿里云飞天计划提供的CES服务器为高中生活搭建“故事簿”网页
一名刚踏入大学的大一本科生利用阿里云提供的CES服务器为高中“故事簿”搭建网页
15 0
IT运维人员,把握现在展望未来
  近年来,互联网在中国的发展势头迅猛并呈现出广阔前景。根据中国互联网络信息中心报告显示,截至2020年3月,我国网民规模已经达到9.04亿,互联网普及率增至67.0%,超全球平均水平。   互联网强劲发展的背后是整个IT行业的蓬勃。国家统计局发布的2019平均工资数据表明,工资最高的行业是信息传输、软件和信息技术服务业,IT行业从业人员平均年薪已超16万元。
6 0
阿里巴巴数据库分库分表的实践(1)
阿里巴巴数据库分库分表的实践(1)
6 0
阿里巴巴数据库分库分表的实践(2)
阿里巴巴数据库分库分表的实践(2)
3 0
阿里巴巴数据库分库分表的实践(4)
阿里巴巴数据库分库分表的实践(4)
6 0
Keras之父写给年轻程序员的33条忠告
  代码是一种交流方式,Keras 之父 Fran?ois Chollet 在本文中为我们总结了在开发过程中、API 设计中及软件职业生涯中应该关注哪些要点。原则是形式化的直觉,比原始模式识别适用于更广泛的情况,Fran?ois Chollet 的这份原则清单将带你领略大师的品味。
6 0
+关注
zhaiwx_yinfeng
MySQL内核开发者, 《高性能MySQL 第三版》译者之一,活跃于MySQL社区,BugList,etc...
224
文章
5
问答
来源圈子
更多
阿里云数据库:帮用户承担一切数据库风险,给您何止是安心!支持关系型数据库:MySQL、SQL Server、PostgreSQL、PPAS(完美兼容Oracle)、自研PB级数据存储的分布式数据库Petadata、自研金融级云数据库OceanBase支持NoSQL数据库:MongoDB、Redis、Memcache更有褚霸、丁奇、德哥、彭立勋、玄惭、叶翔等顶尖数据库专家服务。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载