AI 助理
备案控制台
开发者社区 数据库 文章 正文

MySQL · BUG分析 · Rename table 死锁分析

2016-03-27 3273
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
RDS MySQL Serverless 基础系列，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
云数据库 RDS PostgreSQL，高可用系列 2核4GB
RDS MySQL Serverless 高可用系列，价值2615元额度，1个月
简介：

背景

InnoDB buffer pool中的page管理牵涉到两个链表，一个是lru链表，一个是flush 脏块链表，由于数据库的特性：

  1. 脏块的刷新，是异步操作；
  2. page存在两个版本，一个是ibd文件的持久化版本，和buffer pool内存中的当前版本。

所以在对table对象进行ddl变更的时候，要维护两个版本之间的一致性，有一些操作需要同步进行page缓存的管理。例如以下三种ddl操作：

1. flush table t for export

这是MySQL 5.6提供的InnoDB transportable tablespace功能，用于在不同实例之间进行表传输。由于需要透明的在物理层面迁移ibd文件，所以需要保证buffer pool中的page和ibd文件中的page的一致性。其操作步骤如下：

  1. 持有t表的MDL锁，保证在t表上没有活跃事务，即buffer pool中的脏page都是已提交事务；
  2. 扫描buffer pool中的flush list，同步刷下脏块；
  3. 记录数据字典信息到cfg文件，用于目标端的表结构匹配和验证，最后在目标端import的时候，变更page的space，max_lsn等。

2. drop table t
在对表进行删除的时候，需要清理掉buffer pool中的page，但如果表比较大，占用过多的buffer pool，清理的动作会影响到在线的业务，所以MySQL提供了lazy drop table的方式。

  1. 同步方式: 扫描lru链表，如果page属于t表，就从lru链表，hash表， flush list中删除，回收block到free list中。

  2. lazy方式: 扫描lru链表，如果page属于t表，就给page设置一个space_was_being_deleted属性，等lru置换或者checkpoint flush dirty block的时候进行清理。

3. alter table t rename to t1
rename table name操作，虽然是DDL，但rename操作只是变更了数据字典中的table name和文件系统的ibd文件名称，所以，在rename的过程中，不存在对buffer pool中属于t表的page的同步操作，但由于要变更表名，即需要同步对文件的IO操作。

而今天要讲的主题，就发生在这里，由于rename table进行IO操作同步的过程中，产生的死锁。

问题现象

在MySQL 5.5版本上，error日志大量报出以下的错误信息:

InnoDB: fil_sys open file LRU len 0
InnoDB: Warning: too many (300) files stay open while the maximum
InnoDB: allowed value would be 300.
InnoDB: You may need to raise the value of innodb_open_files in my.cnf.
...
InnoDB: Warning: problems renaming 'db_1/#sql-xxx_xxx' to 'db_1/xxx', 1000 iterations
InnoDB: Warning: tablespace './db_1/#sql-xxx_xxx.ibd' has i/o ops stopped for a long time 1000

查看操作日志，是一个普通的rename语句操作，但持续很久，因为rename只是数据字典的变更，除了MDL锁阻塞以外
不应该持续这么长时间，pstack查看线程栈信息：

Thread 5 (Thread 0x50ad7940 (LWP 25047)):
#0  0x000000364aacced2 in select () from /lib64/libc.so.6
#1  0x00002aaab2e595fb in os_thread_sleep ()
#2  0x00002aaab2e1a3e2 in fil_rename_tablespace ()
#3  0x00002aaab2e0672b in dict_table_rename_in_cache ()
#4  0x00002aaab2e86af5 in row_rename_table_for_mysql ()
#5  0x00002aaab2e316db in ha_innodb::rename_table ()
#6  0x00000000006bea6c in mysql_rename_table ()
#7  0x00000000006c77ff in mysql_alter_table ()
#8  0x00000000005c6a8e in mysql_execute_command ()
#9  0x00000000005cd371 in mysql_parse ()
#10 0x00000000005cd773 in dispatch_command ()
#11 0x00000000005cea04 in do_command ()
#12 0x00000000005bf0d7 in handle_one_connection ()
#13 0x000000364b6064a7 in start_thread () from /lib64/libpthread.so.0
#14 0x000000364aad3c2d in clone () from /lib64/libc.so.6

Thread 100 (Thread 0x42945940 (LWP 3870)):
#0  0x000000364b60ab99 in pthread_cond_wait@@GLIBC_2.3.2 ()
#1  0x00002aaab2e589a5 in os_event_wait_low ()
#2  0x00002aaab2e57dd4 in os_aio_simulated_handle ()
#3  0x00002aaab2e14ccc in fil_aio_wait ()
#4  0x00002aaab2ea2418 in io_handler_thread ()
#5  0x000000364b6064a7 in start_thread () from /lib64/libpthread.so.0
#6  0x000000364aad3c2d in clone () from /lib64/libc.so.6

Thread 120 (Thread 0x40da6940 (LWP 3882)):
#0  0x000000364aacced2 in select () from /lib64/libc.so.6
#1  0x00002aaab2e595fb in os_thread_sleep ()
#2  0x00002aaab2e18838 in fil_mutex_enter_and_prepare_for_io ()
#3  0x00002aaab2e18aa5 in fil_io ()
#4  0x00002aaab2df5b63 in buf_flush_buffered_writes ()
#5  0x00002aaab2df6048 in buf_flush_batch ()
#6  0x00002aaab2ea13d8 in srv_master_thread ()
#7  0x000000364b6064a7 in start_thread () from /lib64/libpthread.so.0
#8  0x000000364aad3c2d in clone () from /lib64/libc.so.6

这里我只列了有意义的三个线程：

  1. 用户线程Thread 5
    用户线程确实在进行rename操作，但阻塞在fil_rename_tablespace函数中。
  2. master线程Thread 120
    InnoDB的master线程阻塞在fil_mutex_enter_and_prepare_for_io函数中。
  3. IO线程Thread 100
    InnoDB的IO线程一共有8个，4个读，4个写线程，发现都在os_event_wait_low中，也就是都空闲着等待condition中。

从上面的调用栈来看，线程之间长时间维持在这种状态下，明显发生了死锁，在我们解这个死锁之前，我们先来回顾一点背景知识，然后再说明死锁的真正原因。

InnoDB背景

checkpoint

由于对数据库的数据操作也遵循read-update-write的方式，所以数据的更新，会把buffer pool中的page变成脏块，由于write-ahead logs机制保证事务的完整性，脏块的write可以变成异步的，但又由于buffer pool的大小终究有限，而且对于recovery的时间的要求，又要求脏块的flush又要持续保证。

MySQL 5.5的版本由master thread来承担dirty flush的角色， dirty flush的过程就称为making checkpoint，lsn的推进保证了recovery的时间不被持续的变长。刷新的策略，受到当前IO pending的情况，double write-buffer是否打开，buffer pool中dirty page所占的比例，以及innodb_max_dirty_pages_pct参数的设置，进行灵活刷新，具体的代码细节，这里就不展开了。

异步IO

由于dirty flush是异步的，所以，master thread只负责提交IO请求，真正的IO操作是由IO helper thread来完成的。InnoDB使用的simulate AIO和native AIO会有一些差别，我们这里以simulate AIO为例进行说明。假设double write-buffer是打开的：

  1. 首先master thread搜集dirty pages，同步写入double write-buffer；
  2. 由于double write-buffer的方式是buffered write，所以等double write-buffer写满了之后；
  3. 同步把double write-buffer的page顺序写入到ibdata系统表空间中，如果完成之后系统crash，可以使用持久化的double write-buffer进行page恢复；
  4. 开始把 double write-buffer中的page，写入真正的ibd文件中。依次提交异步IO操作，提交IO操作的步骤分为：
    • 持有fil_system mutex，判断当前tablespace是否可用，
    • 判断当前fil_space的stop_io标示，如果设置就循环等待
    • 如果stop_io没有标示，就打开fil_space对应的ibd文件句柄，然后递增 fil_space->n_pending
    • 提交IO请求
  5. 等double write-buffer中的pages提交完所有的IO请求，使用os_aio_simulated_wake_handler_threads来唤醒IO helper thread来完成IO操作。

Rename 操作

接下来我们来看下rename操作的步骤：

  1. 首先在server层hold MDL锁；
  2. 进入InnoDB层，首先使用自治事务变更数据字典，包括SYS_TABLES，SYS_FOREIGN；
  3. 变更数据字典的内存对象，包括table, index, foreign list等；
  4. 变更fil_space对象以及对应的ibd数据文件名称，其中变更文件系统名称的时候：
    • 设置当前的fil_space的stop_io，阻止再进行IO操作
    • 判断当前是否有IO pending，如果有，就等IO pending结束
    • 如果没有IO pending，就关闭opened的句柄，并rename文件名称
    • 恢复stop_io标示
  5. 提交自治事务。

有了这些操作的具体步骤，我们就可以清晰的分析出死锁的原因。

死锁原因

两个线程，一个是master thread，需要提交flush dirty block的异步IO请求；一个是user thread，需要进行rename操作。

Rename操作，只变更数据字典和ibd文件名，并不需要同步buffer pool中的page，唯一需要同步的就是IO操作，通俗一点说，也就是在user thread进行rename table需要变更ibd文件名的时候，其它线程暂时不要对这个文件进行IO操作，等rename完成后，可以重新打开这个ibd文件，接着进行IO操作。

InnoDB使用两个标识来进行IO同步操作，即stop_io，n_pending。
stop_io：user thread要进行rename操作，提前设置这个标识，表示IO操作可以先hold暂停。
n_pending：master thread要进行flush操作，我已经提交了IO请求，user thread要进行rename可以先hold，等IO完成。

假设下面的时序：

  1. master thread提交了1个IO请求，设置了n_pending；
  2. rename操作设置stop_io，判断n_pending>0 就等待；
  3. master thread需要提交剩下的几个IO，发现stop_io已设置，就等待；
  4. 由于master thread没有提交完这批IO，没有唤醒IO helper thread，导致第1个IO请求无法完成，n_pending一直等于1；
  5. rename操作因为n_pending一直等于1，陷入了死等；
  6. master thread发现stop_io等于true，陷入了死等。

具体的代码可以参考：

1. master thread
fil0fil.cc: fil_mutex_enter_and_prepare_for_io

space = fil_space_get_by_id(space_id);
if (space != NULL && space->stop_ios) {
        /* We are going to do a rename file and want to stop new i/o's for a while */
        if (count2 > 20000) {
                fputs("InnoDB: Warning: tablespace ", stderr);
                ut_print_filename(stderr, space->name);
                fprintf(stderr,
                        " has i/o ops stopped for a long time %lu\n",
                        (ulong) count2);
        }
        mutex_exit(&fil_system->mutex);
        os_thread_sleep(20000);
        count2++;
        goto retry;
}

2. user thread
fil0fil.cc: fil_rename_tablespace

/* We temporarily close the .ibd file because we do not trust that
operating systems can rename an open file. For the closing we have to
wait until there are no pending i/o's or flushes on the file. */

space->stop_ios = TRUE;
ut_a(UT_LIST_GET_LEN(space->chain) == 1);
node = UT_LIST_GET_FIRST(space->chain);
if (node->n_pending > 0 || node->n_pending_flushes > 0) {
        /* There are pending i/o's or flushes, sleep for a while and retry */
        mutex_exit(&fil_system->mutex);
        os_thread_sleep(20000);
        goto retry;

修复方法

修复的方法也比较简单，在fil_rename_tablespace的时候，如果发现node->n_pending > 0的时候，在sleep之前，发起一次唤醒动作，即os_aio_simulated_wake_handler_threads，IO helper thread去完成master thread已经提交的IO请求，这样n_pending就会降到0，死锁就解开了。

文章标签：
云数据库 RDS MySQL 版
关系型数据库
MySQL
iOS开发
SQL
数据库
缓存
关键词：
云数据库 RDS MySQL 版bug分析
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发，帮助IT从业者们通过“阿里云Web应用上云解决方案”，了解一个企业级Web应用上云的常见架构，了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品：云数据库RDS MySQL 版 阿里云关系型数据库RDS（Relational Database Service）是一种稳定可靠、可弹性伸缩的在线数据库服务，提供容灾、备份、恢复、迁移等方面的全套解决方案，彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
db匠
目录
相关文章
蒋星熠Jaxonic
|
1月前
|
存储 消息中间件 监控
MySQL 到 ClickHouse 明细分析链路改造：数据校验、补偿与延迟治理
蒋星熠Jaxonic，数据领域技术深耕者。擅长MySQL到ClickHouse链路改造，精通实时同步、数据校验与延迟治理，致力于构建高性能、高一致性的数据架构体系。
蒋星熠Jaxonic
91 2
MySQL 到 ClickHouse 明细分析链路改造：数据校验、补偿与延迟治理
顾翔
|
2月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能（下）
使用MYSQL Report分析数据库性能
顾翔
90 3
凉凉心.
|
23天前
|
NoSQL 算法 Redis
【Docker】（3）学习Docker中 镜像与容器数据卷、映射关系！手把手带你安装 MySql主从同步 和 Redis三主三从集群！并且进行主从切换与扩容操作，还有分析 哈希分区 等知识点！
Union文件系统（UnionFS）是一种**分层、轻量级并且高性能的文件系统**，它支持对文件系统的修改作为一次提交来一层层的叠加，同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem) Union 文件系统是 Docker 镜像的基础。 镜像可以通过分层来进行继承，基于基础镜像（没有父镜像），可以制作各种具体的应用镜像。
凉凉心.
209 5
顾翔
|
2月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能（上）
最终建议：当前系统是完美的读密集型负载模型，优化重点应放在减少行读取量和提高数据定位效率。通过索引优化、分区策略和内存缓存，预期可降低30%的CPU负载，同时保持100%的缓冲池命中率。建议每百万次查询后刷新统计信息以持续优化
顾翔
153 6
顾翔
|
2月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能（中）
使用MYSQL Report分析数据库性能
顾翔
110 1
蓝易云
|
3月前
|
存储 关系型数据库 MySQL
深入理解MySQL索引类型及其应用场景分析。
通过以上介绍可以看出各类MySQL指标各自拥有明显利弊与最佳实践情墁，在实际业务处理过程中选择正确型号极其重要以确保系统运作流畅而稳健。
蓝易云
170 12
蓝易云
|
4月前
|
存储 SQL 关系型数据库
MySQL的Redo Log与Binlog机制对照分析
通过合理的配置和细致的管理，这两种日志机制相互配合，能够有效地提升MySQL数据库的可靠性和稳定性。
蓝易云
156 10
技术自由圈/原疯狂创客圈
|
4月前
|
SQL 关系型数据库 MySQL
MySQL group by 底层原理详解。group by 执行 慢 原因深度分析。（图解+秒懂+史上最全）
MySQL group by 底层原理详解。group by 执行 慢 原因深度分析。（图解+秒懂+史上最全）
技术自由圈/原疯狂创客圈
625 0
MySQL group by 底层原理详解。group by 执行 慢 原因深度分析。（图解+秒懂+史上最全）
蓝易云
|
7月前
|
SQL 关系型数据库 MySQL
【MySQL】SQL分析的几种方法
以上就是SQL分析的几种方法。需要注意的是，这些方法并不是孤立的，而是相互关联的。在实际的SQL分析中，我们通常需要结合使用这些方法，才能找出最佳的优化策略。同时，SQL分析也需要对数据库管理系统，数据，业务需求有深入的理解，这需要时间和经验的积累。
蓝易云
227 12
数据库知识学习者
|
6月前
|
缓存 JSON 关系型数据库
MySQL 查询优化分析 - 常用分析方法
本文介绍了MySQL查询优化分析的常用方法EXPLAIN、Optimizer Trace、Profiling和常用监控指标。
数据库知识学习者
386 0

热门文章

最新文章

  • 1
    MySQL包安装 -- RHEL系列（离线RPM包安装MySQL）
  • 2
    MySQL介绍和MySQL包安装 -- RHEL系列（Yum资源库安装MySQL）
  • 3
    MySQL包安装 -- Debian系列（Apt资源库安装MySQL）
  • 4
    MySQL包安装 -- SUSE系列（离线RPM包安装MySQL）
  • 5
    MySQL包安装 -- Debian系列（离线DEB包安装MySQL）
  • 6
    MySQL Docker 容器化部署全指南
  • 7
    【Docker】（3）学习Docker中 镜像与容器数据卷、映射关系！手把手带你安装 MySql主从同步 和 Redis三主三从集群！并且进行主从切换与扩容操作，还有分析 哈希分区 等知识点！
  • 8
    【赵渝强老师】MySQL的事务隔离级别
  • 9
    MySQL 与 Redis 如何保证双写一致性？
  • 10
    MySQL二进制包安装
  • 1
    【赵渝强老师】使用mydumper备份MySQL
    171
  • 2
    【赵渝强老师】使用select...into outfile语句备份MySQL
    337
  • 3
    【赵渝强老师】使用mysqldump备份MySQL
    199
  • 4
    MySQL数据库上云迁移
    122
  • 5
    数据库运维：mysql 数据库迁移方法-mysqldump
    871
  • 6
    Super MySQL｜揭秘PolarDB全异步执行架构，高并发场景性能利器
    387
  • 7
    MySQL报错：未知系统变量'tx_isolation'及隔离级别查询
    247
  • 8
    MySQL 常用函数
    379
  • 9
    MySQL 5.6/5.7 DDL 失败残留文件清理指南
    278
  • 10
    MySQL字符串拼接方法全解析
    523

    • 相关课程

    更多
  • MySQL企业常见架构与调优经验分享
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 阿里云数据库产品家族及特性
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • MySQL 技术大全：开发、优化与运维实战
  • 阿里云数据库运维实战手册
  • 搭建电商项目架构连接MySQL

    • 推荐镜像

    更多
  • mysql
    • 下一篇
    开通oss服务