vps做网站教程沧州网站建设开发服务

一、背景

有一台物理机上一个版本为5.6.16的从库出现了内存的增高，观测其日志可以发现，这台数据库已经oom很多次了，并且stop slave的时候会卡住非常长的时间才能停止

二、根本原因

上述的现象可以看到是一个明显的内存泄漏现象，那么这种就是bug了，可以到mysql的bug网站进行搜索，可以明确的看到这个bug很符合我们当前的现象，这个bug实在5.6.25修复的，当然也可以结合其他一些bug1,bug2,bug3来分析原因

三、现状分析及规避

根据bug的描述，我们先分析下实例本身的问题

1.参数现状

# 可以看到我们的master_info_repository，relay_log_info_repository比较符合bug中的描述
show variables like '%master_info_repository%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| master_info_repository | TABLE |
+------------------------+-------+
1 row in set (0.00 sec)show variables like '%relay_log_info_repository%';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| relay_log_info_repository | TABLE |
+---------------------------+-------+
1 row in set (0.00 sec)show variables like '%parallel_workers%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| slave_parallel_workers | 0     |
+------------------------+-------+
1 row in set (0.00 sec)

2.内存现状

每天的内存都会增加1-2G

3.调整参数

stop slave;
set global master_info_repository="FILE";
set global relay_log_info_repository="FILE";
# 如果是0则不用处理
set global slave_parallel_workers=0;
start slave;

4.结果

观测了两天，从目前结果来看，修改完参数之后内存没有增长,已经确定是命中了bug，修改参数能规避这个问题，当然，更好的解决方式还是升级版本