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

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云数据库 RDS SQL Server,基础系列 2核4GB
RDS SQL Server Serverless,2-4RCU 50GB 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版本 :)

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
21天前
|
SQL 关系型数据库 MySQL
MySQL慢查询优化、索引优化、以及表等优化详解
本文详细介绍了MySQL优化方案,包括索引优化、SQL慢查询优化和数据库表优化,帮助提升数据库性能。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
MySQL慢查询优化、索引优化、以及表等优化详解
|
25天前
|
缓存 监控 关系型数据库
如何优化MySQL查询速度?
如何优化MySQL查询速度?【10月更文挑战第31天】
56 3
|
28天前
|
缓存 关系型数据库 MySQL
如何优化 MySQL 数据库的性能?
【10月更文挑战第28天】
53 1
|
2月前
|
NoSQL 关系型数据库 MySQL
MySQL与Redis协同作战:百万级数据统计优化实践
【10月更文挑战第21天】 在处理大规模数据集时,传统的单体数据库解决方案往往力不从心。MySQL和Redis的组合提供了一种高效的解决方案,通过将数据库操作与高速缓存相结合,可以显著提升数据处理的性能。本文将分享一次实际的优化案例,探讨如何利用MySQL和Redis共同实现百万级数据统计的优化。
81 9
|
29天前
|
监控 关系型数据库 MySQL
数据库优化:MySQL索引策略与查询性能调优实战
【10月更文挑战第27天】本文深入探讨了MySQL的索引策略和查询性能调优技巧。通过介绍B-Tree索引、哈希索引和全文索引等不同类型,以及如何创建和维护索引,结合实战案例分析查询执行计划,帮助读者掌握提升查询性能的方法。定期优化索引和调整查询语句是提高数据库性能的关键。
166 1
|
2月前
|
NoSQL 关系型数据库 MySQL
MySQL与Redis协同作战:优化百万数据查询的实战经验
【10月更文挑战第13天】 在处理大规模数据集时,传统的关系型数据库如MySQL可能会遇到性能瓶颈。为了提升数据处理的效率,我们可以结合使用MySQL和Redis,利用两者的优势来优化数据查询。本文将分享一次实战经验,探讨如何通过MySQL与Redis的协同工作来优化百万级数据统计。
63 5
|
2月前
|
存储 关系型数据库 MySQL
优化 MySQL 的锁机制以提高并发性能
【10月更文挑战第16天】优化 MySQL 锁机制需要综合考虑多个因素,根据具体的应用场景和需求进行针对性的调整。通过不断地优化和改进,可以提高数据库的并发性能,提升系统的整体效率。
86 1
|
2月前
|
缓存 关系型数据库 MySQL
一文彻底弄懂MySQL优化之深度分页
【10月更文挑战第24天】本文深入探讨了 MySQL 深度分页的原理、常见问题及优化策略。首先解释了深度分页的概念及其带来的性能和资源问题。接着介绍了基于偏移量(OFFSET)和限制(LIMIT)以及基于游标的分页方法,并分析了它们的优缺点。最后,提出了多种优化策略,包括合理创建索引、优化查询语句和使用数据缓存,帮助提升分页查询的性能和系统稳定性。
135 1
|
2月前
|
NoSQL 关系型数据库 MySQL
MySQL与Redis协同作战:百万数据量的优化实录
【10月更文挑战第6天】 在现代互联网应用中,随着用户量的增加和业务逻辑的复杂化,数据量级迅速增长,这对后端数据库系统提出了严峻的挑战。尤其是当数据量达到百万级别时,传统的数据库解决方案往往会遇到性能瓶颈。本文将分享一次使用MySQL与Redis协同优化大规模数据统计的实战经验。
135 3
|
2月前
|
NoSQL 关系型数据库 BI
记录一次MySQL+Redis实现优化百万数据统计的方式
【10月更文挑战第13天】 在处理百万级数据的统计时,传统的单体数据库往往力不从心,这时结合使用MySQL和Redis可以显著提升性能。以下是一次实际优化案例的详细记录。
137 1

相关产品

  • 云数据库 RDS MySQL 版