技术分享 | MySQL中MGR中SECONDARY节点磁盘满，导致mysqld进程被OOM Killed

在对MySQL 8.0.26 vs GreatSQL 8.0.25的对比测试过程中，有一个环节是人为制造磁盘满的场景，看看MGR是否还能正常响应请求。

在实测过程中，最后发现磁盘满的那个节点，持续时间足够久后，会因为内存消耗过大而最终被OS给OOM Kill。

这个问题我已报告BUG（#104979），下面是该过程的详细记录。

首先，直接利用dd复制空文件填满磁盘。

disk full报告过程及何时被oom killed

来看下MySQL 8.0.26遇到disk full时日志都输出哪些内容：

从disk full时刻开始，大约过了2.5小时，mysqld进程内存消耗持续上升，最终引发oom kill

在这期间某个时刻抓到的待认证事务堆积，在被oom kill前实际不止这么多：

关注mysqld进程内存消耗变化

下面是mysqld进程内存消耗变化情况

OS层oom-killer相关日志：

GreatSQL 8.0.25测试过程

作为对比，我用GreatSQL 8.0.25也做了同样的测试。

从日志详情中可以看到，当磁盘空间满了之后，GreatSQL会将那个节点主动退出集群，对整个集群的影响非常小。

此外，从集群退出后，也不会再接收认证事务了，所以也没发生内存持续暴涨最终被oom killed的情况，实际观察过程中发现内存反倒还下降了

这样对比来看，GreatSQL的可靠性还真是可以的，官方的MySQL MGR的可靠性还有待进一步加强呀。

Enjoy GreatSQL :)

当磁盘空间写满了之后，MySQL是无法再写入任何数据的，包括对表数据的写入，以及binlog、binlog-index等文件。

当然了，因为InnoDB是可以把脏数据先放在内存里，所以不会立刻表现出来无法写入，除非开启了binlog，写入请求才会被阻塞。

当MySQL检测到磁盘空间满了，它会：

每分钟：检查空间是否得到释放，以便写入新数据。当发现有剩余空间了，就会继续写入数据，一切照旧。

每十分钟：如果还是发现没剩余空间，则会在日志中写入一条记录，报告磁盘空间满(这时候只写入几个字节还是够的)。

应该怎么办

那么，当发现磁盘空间满了之后，我们应该怎么处理呢，建议：

提高监控系统检测频率，预防再次发生；

及时删除不用的文件，释放空间；

若有线程因磁盘满的问题被阻塞了，可先杀掉，等到下一分钟重新检测时它可能又可以正常工作了；

可能因磁盘满导致某些线程被阻塞，引发其他线程也被阻塞，可把导致阻塞的线程杀掉，其他被阻塞的线程也就能继续工作了。

例外

有个例外的情况是：

当执行 REPAIR TABLE 或者 OPTIMIZE TABLE *** 作时，或者执行完 LOAD DATA INFILE 或 ALTER TABLE 之后批量更新索引时，这些 *** 作会创建临时文件，当执行这些 *** 作过程中mysqld发现磁盘空间满了，就会把这个涉及到的表标记为crashed，删掉临时文件(除了 ALTER TABLE *** 作，MySQL会放弃正在执行的 *** 作，删除临时文件，释放磁盘空间)。

备注：当执行这些命令过程中mysqld进程被意外被杀掉的话，其所生成临时文件不会自动删除，需要手工删掉才能释放磁盘空间。

---