技术分享 | 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 :)

(+)是外连接，表示当前条件等号左侧的表为主表，如果等号条件成立，查询中如果有等号右侧表中的字段，按照关联条件查询出数据，如果右侧没有条件符合，那么查询中补空。

举个例子，假设emp和dept表数据如下：

emp: emp_id, emp_name, dept_id

001 张三10

002 李四10

003 王五20

004 赵六30

dept: dept_id dept_name

10 部门1

20 部门2

查询语句：select emp_id, emp_name, dept_name

from emp, dept

where emp.dept_id = dept.dept_id(+)

从上面两表能看出来，emp表中的最后一行数据，dept_id为30，在dept表没有对应的数据，使用直连（即不带加号）只能查询到前三行数据，可是使用外连，以emp为主表，那么emp表的数据就都可以查到。结果如下：

emp_id emp_namedept_name

001张三 部门1

002 李四 部门1

003王五 部门2

004 赵六 NULL(空，没有数据)

---