一、事故现象
1、收到数据库prometheus监控告警 Exporter状态 == 0(down)
2、登录数据库服务器,并登录数据库,发现hung住,无法登录
3、为业务不可用,重启数据库服务器后,可登录使用mysql
二、事故原因分析
1、数据库与服务器关键指标探查
1.1、error 日志报错
mysql error日志中报出大量的Too many open files 错误
1)打开的都是frm文件
2)链接报错的用户只有dts:Got an error reading communication packets
3)其他用户都是:Got timeout reading communication packets
1.2、prometheus监控
1.3、服务器参数与数据库参数
1)服务器参数
服务器ulimit -a查看文件系统打开文件限制:100001
2)数据库参数
数据库参数限制都为:65535
show global variables like '%file%';
| innodb_open_files | 65535 |
| open_files_limit | 65535 |
2、事故分析
1)还原事故前后业务操作,只有DTS数据迁移是新增业务
2)数据库表的个数为75000多张
3)根据报错与表的个数,并且DTS在数据迁移前需要对整个DB下表的校验,猜测是DTS在一个事务中打开了DB下面所有的表的frm,用于校验,
由于表的个数为72000张,超过了mysql系统参数innodb_open_files、open_files_limit 的限制。
但是还未超过Linux 系统参数 open files的限制。
三、事故解决方案
1、调整服务器参数
open files 调整为 655350
/etc/security/limits.conf
2、调整mysql参数
innodb_open_files、open_files_limit 的限制也调整为655350
四、调整参数据后验证
通过监控可以看到,Innodb OPen Files 已经超过了原来的65535的限制,达到了75240,error 日志中也不在报错