一、背景
有一台物理机上一个版本为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，修改参数能规避这个问题，当然，更好的解决方式还是升级版本
