CentOS7宕机后mysql服务无法启动

CentOS7宕机后mysql服务无法启动

1.尝试重启mysqld服务

systemctl restart mysqld

重启后卡死在执行命令中,长时间不退出,放弃

尝试手动启动

/usr/sbin/mysqld start

也不好使放弃

2.先尝试修改innodb_force_recovery参数

innodb_force_recovery 配置1-6选项：

1 (SRV_FORCE_IGNORE_CORRUPT): 忽略检查到的 corrupt 页。尽管检测到了损坏的 page 仍强制服务运行。一般设置为该值即可，然后 dump 出库表进行重建。
2 (SRV_FORCE_NO_BACKGROUND): 阻止主线程的运行，如主线程需要执行 full purge 操作，会导致 crash。 阻止 master thread 和任何 purge thread 运行。若 crash 发生在 purge 环节则使用该值。
3 (SRV_FORCE_NO_TRX_UNDO): 不执行事务回滚操作。
4 (SRV_FORCE_NO_IBUF_MERGE): 不执行插入缓冲的合并操作。如果可能导致崩溃则不要做这些操作。不要进行统计操作。该值可能永久损坏数据文件。若使用了该值，则将来要删除和重建辅助索引。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN): 不查看重做日志，InnoDB 存储引擎会将未提交的事务视为已提交。此时 InnoDB 甚至把未完成的事务按照提交处理。该值可能永久性的损坏数据文件。
6 (SRV_FORCE_NO_LOG_REDO): 不执行前滚的操作。恢复时不做 redo log roll-forward。使数据库页处于废止状态，继而可能引起 B 树或者其他数据库结构更多的损坏

innodb_force_recovery建议：

1、如果MySQL服务故障重启后，因为事务回滚导致异常，可以将参数innodb_force_recovery设置为3跳过回滚阶段
2、如果因为MySQL数据页损坏导致异常，可以使用SELECT+WHERE查找出未损坏数据并将其通过mysqldump导出。
3、将innodb_force_recovery参数设置大于0启动服务后，应通过修改端口或域名(VIP)指向来屏蔽应用访问。
4、将innodb_force_recovery参数设置大于0启动服务后，可以通过mysqlcheck命令来对表进行检查/分析/优化/修复。
5、使用force_recovery重启服务前，建议对数据库所有文件进行备份，避免修复过程中对数据进行二次损害。

在日常运维中，应将使用innodb_force_recovery参数进行数据恢复作为最后手段，做好完善的备份恢复机制，避免对数据库做高危操作。

vi /etc/my.cnf
# 添加
innodb_force_recovery = 3

若成功启动后注释掉此参数 重启mysqld服务

但我的问题未解决

2.查看/usr/sbin/mysqld status

[root@master3 ~]# /usr/sbin/mysqld  status
2022-07-11T02:24:32.318716Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.16) starting as process 16939
2022-07-11T02:24:32.320750Z 0 [ERROR] [MY-010123] [Server] Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root!
2022-07-11T02:24:32.320815Z 0 [ERROR] [MY-010119] [Server] Aborting
2022-07-11T02:24:32.321037Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.16)  MySQL Community Server - GPL.

百度后修改user参数无果后放弃

3.查看msyql的binlog文件

mysqlbinlog --start-datetime="2022-06-29 16:00:00" --stop-datetime="2022-07-11 09:00:00"  --base64-output=decode-rows -v binlog.000025

未见到异常信息

4.尝试mysqld --daemonize 方式启动

mysqld --daemonize
# 开启新的窗口查看日志
tail -1000f /var/log/mysqld.log

运行后看到/var/log/mysqld.log日志内报错
经验证排除了内存，句柄数等问题. 并且切换至root用户打开大量线程时没有问题。试着调整ulimit各项参数,最后发现是"max user processes "参数有问题，通过root用户调整大小至 12000,线程数也随着增大.

2022-07-11T02:39:22.810927Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.16) starting as process 1984
2022-07-11T02:39:22.871940Z 1 [ERROR] [MY-012574] [InnoDB] Unable to lock ./ibdata1 error: 11
2022-07-11T02:40:59.893262Z 1 [ERROR] [MY-012574] [InnoDB] Unable to lock ./ibdata1 error: 11
2022-07-11T02:41:00.893393Z 1 [ERROR] [MY-012574] [InnoDB] Unable to lock ./ibdata1 error: 11
2022-07-11T02:41:01.893623Z 1 [ERROR] [MY-012574] [InnoDB] Unable to lock ./ibdata1 error: 11
2022-07-11T02:41:02.893861Z 1 [ERROR] [MY-012574] [InnoDB] Unable to lock ./ibdata1 error: 11
2022-07-11T02:41:02.894715Z 1 [ERROR] [MY-012592] [InnoDB] Operating system error number 11 in a file operation.
2022-07-11T02:41:02.894745Z 1 [ERROR] [MY-012596] [InnoDB] Error number 11 means 'Resource temporarily unavailable'
2022-07-11T02:41:02.894773Z 1 [ERROR] [MY-012215] [InnoDB] Cannot open datafile './ibdata1'
2022-07-11T02:41:02.894839Z 1 [ERROR] [MY-012959] [InnoDB] Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data!
2022-07-11T02:41:02.894868Z 1 [ERROR] [MY-012930] [InnoDB] Plugin initialization aborted with error Cannot open a file.
2022-07-11T02:41:03.496799Z 1 [ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine
2022-07-11T02:41:03.497069Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2022-07-11T02:41:03.497874Z 0 [ERROR] [MY-010119] [Server] Aborting
2022-07-11T02:41:03.498844Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.16)  MySQL Community Server - GPL.

终于发现报错

问题解决方案

vi /etc/security/limits.conf
# 添加下列2参数 

* soft nproc 12000
* hard nproc 12000

nproc就是"max user processes"，完整描述是: nproc - max number of processes
参数含义:

单个用户可以启动的线程数，因为进程也会启动一个线程，所以也间接对进程数有限制。

注意：

该参数只对普通用户有用，root用户不在此限制。 所以用root用户可以启动几万个线程，无法重现这个问题.

重新加载系统参数

sysctl -p

重启mysqld服务

systemctl restart mysqld
# 服务启动成功

最后注释掉/etc/my.cnf中的innodb_force_recovery参数
未添加则无需注释

innodb_force_recovery = 3

在重启mysqld服务

systemctl restart mysqld