记一次生产数据库意外重启的经历

最终配置如下： 

#thread pool  
   thread_handling=pool-of-threads  
   #Group的数量，默认为系统CPU的个数，充分利用CPU资源  
   thread_pool_size=24  
   #每个group的最大线程数为thread_pool_oversubscribe+1  
   thread_pool_oversubscribe=3  
   performance_schema=off  
   #extra connection，防止线程池满的情况下无法登录MySQL  
   extra_max_connections = 8  
   extra_port = 33333 

备注：线程池在Percona,MariaDB,Oracle MySQL企业版中提供，Oracle MySQL社区版并不提供。

线程池貌似并不会直接导致内存不回收，网上有说同时开启Thread pool和PS会出现内存泄露，但是 目前Percona server 5.7.21-20+版本已经修复了这个问题，显然是不存在的。

慢查询

由于是生产环境，这个问题拖得时间有点长，，那么慢查询会不会影响内存使用问题呢？带着这个问题，查看了慢查询后台列表，在数据库奔溃的前一个时间段，的确有不少慢查询语句。但是这并不能在一定程度上说明问题，由于服务器的 MySql 服务在杀死之前，内存已经见底，此时连接数并不多，也就三四十来个左右，大多处于休眠状态，并且此时已经占用了大部分的Swap空间。也就是说，在资源有限的情况下必定会出现不少慢查询语句。

小结

其实这个"意外"一点也不意外，其实已经发生了多次了。但是还是做个小结吧，因为最终没有确认问题出现在哪里，所以还是发布了吧，万一有专业的DBA遇到类似的问题还可以小小的解惑一下。

【编辑推荐】

1. 亚马逊将在2019年底之前弃用所有Oracle数据库
2. 数据库运维的那些难题，我们用机器学习解决了
3. 12月数据库榜单，整体排名稳定如昨，Oracle 分数接连下降
4. 黑客攻击数据库的六大手段
5. 2018年12月全球数据库排行榜：Oracle惨不忍睹！

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!