一、事故现象

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 日志中也不在报错

 

 posted on 2023-09-08 17:58  xibuhaohao  阅读(869)  评论(0)    收藏  举报