环境
- oom异常关闭导致 MySQL5.7 启动失败。
同事导入数据时异常关闭，应该是数据量太大导致mysql崩溃，尝试重启失败了提示如下：
Database was not shutdown normally! 2021-02-26T21:33:29.691452+08:00 0 [Note] InnoDB: Starting crash recovery. 2021-02-26T21:33:30.287496+08:00 0 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 #进度到这里自动退出了
配置文件修改参数 innodb_force_recovery = 1 ---->将0 修改为1 ---->没有设置的可以在mysqld下添加参数
注解：
innodb_force_recovery可以是设置1-6，数字大的包含数字小的功能，所以我们要从1开始设置来尝试启动mysql innodb_force_recovery=0，关闭恢复功能 正常启动 innodb_force_recovery=1，即使发现了损坏页面也继续让服务器继续运行，这个选项对于备份或者转存当前数据尤为有用 innodb_force_recovery=2，阻止恢复主线程的运行，如果清除操作会导致服务器挂掉 innodb_force_recovery=3，恢复后不回滚事务 innodb_force_recovery=4，如果插入到缓冲区的合并操作会导致系统崩溃，将不会被执行 innodb_force_recovery=5，启动数据库时，忽略撤消日志 innodb_force_recovery=6，启动数据库时，忽略与恢复相关的前滚日志
配置恢复
配置完成后重洗启动数据库
#先打开日志 [root@db02 ~]# tail -f /mydata/3306/log/mysql-error.log #启动了很久显示失败 [root@db02 ~]# /etc/init.d/mysqld restart ERROR! MySQL server PID file could not be found! Starting MySQL.................................................................................................................................... ERROR! The server quit without updating PID file (/mydata/3306/data/db02.pid). #查看日志显示已经恢复到百分之百了 2021-02-26T21:40:27.983238+08:00 0 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 2021-02-26T21:41:26.220425+08:00 0 [ERROR] InnoDB: Waited for 10 seconds for 256 pending reads 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 #再往下翻翻发现错误点----->是因为启用了恢复时启用了 innodb_force_recovery 参数 2021-02-26T21:42:11.303902+08:00 0 [ERROR] InnoDB: innodb_force_recovery is on. We do not allow database modifications by the user. Shut down mysqld and edit my.cnf to set innodb_force_recovery=0 mysqld: Operation not allowed when innodb_forced_recovery > 0. 2021-02-26T21:42:11.306255+08:00 0 [ERROR] Aborting
关闭此参数
#关闭innodb_force_recovery 参数 [root@db02 ~]# vim /etc/my.cnf innodb_force_recovery = 0
启动数据库
[root@db02 ~]# /etc/init.d/mysqld start Starting MySQL.. SUCCESS!
注：
到这里数据库就起来了，如果配置为1无法启动数据库可以在往后注意尝试，直到可以启动为止。
检查是否有损坏的表
配置跳过表和网络启动
mysqld_safe --skip-grant-tables --skip-networking &
检查是否启动
ps -ef|grep mysql
打开日志观察是否有损坏的表
tail -f /mydata/3306/log/err.log
检查损坏的表并尝试修复
mysqlcheck -A --auto-repair -uroot -p -A
如损坏的表过多则重新初始化数据库，初始化前先备份
没有损坏的表可以继续使用当前实例运行。
坏表处理
备份数据库
mysqldump -uroot -p -A -R -E --triggers >/tmp/dump.sql
创建新的初始化目录
mkdir /mydata/3306/data_new
授权
chown -R mysql:mysql /mydata/3306/data_new
修改my.cnf
vim /etc/my.cnf datadir=/mydata/3306/data_new # 改为新的 # skip_grant_tables # 注释此选项 # innodb_force_recovery # 注释此选项
初始化mysql
mysqld --initialize-insecure --basedir=/mysql/mysql57 --datadir=/mydata/3306/data_new
关闭旧 mysql
pkill mysql
启动mysql
/etc/init.d/mysqld start # 这个文件里要改成新的数据目录名去启动
注：如果报socket错误可以做个软连接或者改配置文件即可。
连接mysql
mysql -uroot -p
将备份导入到新库
source /tmp/dump.sql 或者 mysql < /tmp/dump.sql
检查数据
此时已经恢复完成，可以将MySQL停止，将旧数据目录和新数据目录重命名回去，修改配置文件，以恢复原状。
优化系统和 MySQL 配置优化
系统配置优化
cat >/etc/sysctl.conf<<'EOF' vm.swappiness=0 # 减少 swap 分区使用 vm.overcommit_memory = 1 # 允许所有内存分配 EOF # 生效 sysctl -p
MySQL 配置优化
# 配置文件永久修改 vim /etc/my.cnf innodb_buffer_pool_size = 2G # 将缓冲池配置为系统当前可用内存的 3/4 # 命令行临时修改 set global innodb_buffer_pool_size=(select 2*1024*1024*1024);
innodb_force_recovery=6 无法启动 MySQL 的情况
请参见我的另一篇文章：
https://blog.csdn.net/weixin_45385457/article/details/141136121
