暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

磁盘写满之后,数据库show status受到阻塞的原因

刘伟 2019-07-18
1101

注意:

1..以下所有讨论都基于mysql 5.5.37版本及官方文档,不保证适用于其他版本。

2.下文中提到的磁盘满,指的是数据文件(数据文件,日志文件,配置文件)所在磁盘分区。

3.由于篇幅问题,最后面的代码部分,只有关键的函数及逻辑判断部分。


前两天同事讨论到一个问题,当mysql从库磁盘满之后,show status及show slave status会被卡住,但其他select操作不受影响,但如果数据库是主库,磁盘满了之后,只有dml会被阻塞,select及show是不会受影响的。于是一群人讨论了一会,最后决定,SMC,以下就是我的结论。

直接查官文档的话,官方作如下表示:

https://dev.mysql.com/doc/refman/5.5/en/full-disk.html

1.实例每分钟检查是否有足够的空间写入。如果已经有空间了,继续执行操作。

2.每十分钟给日志文件写入一条记录,报告磁盘已经写满。

但就我的实验来说,上面的说法存在不少问题。

下面是我对官方文档的测试结果:

1.如果主库上打开binlog,那么当磁盘满之后,每10分钟,数据库会报告一条Disk is full writing './mysql-bin.000001' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space),也就是说bin log写满了,等待磁盘空间,这与文档描述相同。

2,如果在主库上关闭binlog,当磁盘满了之后,任何插入行为都会失败,报错为[ERROR] ./mysqld: The table 'x' is full,官方文档没有提到这个情况,此处的表x是innodb表。

上面是对主库所在磁盘写满之后,数据库实例的反应,下面讲讲我们遇到的情况:从库磁盘写满之后,show status及show slave status会被卡住,但其他select操作不受影响。

首先,以下是结论:

整个流程涉及3把锁:

1.mi->data_lock

2.LOCK_active_mi

3.LOCK_status

说明如下(以下操作安编号顺序执行):

1.当一个新操作被接收到slave io线程后,如果这时候磁盘写满了,这个写入操作就会被阻塞,然后等待,直到磁盘有空间之后继续写入,这个操作中,会持有mi->data_lock锁,只有操作完成或者操作失败后,这个锁才会被释放,恰好,磁盘满不属于错误,于是操作阻塞,该线程会一直持有mi->data_lock锁。

2.当发起一个show slave status请求的时候,执行的时候,会首先锁住LOCK_active_mi锁,然后锁定mi->data_lock锁,当然,现在的情况下,mi->data_lock不会得到,于是LOCK_active_mi锁就会被该线程持续持有。

3.另外其一个会话发起show global status,执行的时候首先锁定LOCK_status锁,由于show status包括,Slave_heartbeat_period,Slave_open_temp_tables,Slave_received_heartbeats               ,Slave_retried_transactions这些状态,于是还需要LOCK_active_mi锁,于是,这个会话也会被阻塞掉。

4.之后如果再另外发起请求,由于LOCK_status已经被锁定,于是所有涉及show status的请求,都会被阻塞到这里。

5.之后所有show slave status请求也都会被阻塞在LOCK_active_mi锁处。

看了以上的结论,是否会想到另外一个操作顺序:磁盘写满-》show status,这种操作的结果是:show status不会被阻塞的。

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论