MySQL异常宕机无法启动的处理过程_数据库_开发者

环境

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_jsnew

关闭旧 mysql

pkill mysql

启动mysql

/etc/init.d/mysqld start  # 这个文件里要改成新的数据目录名去启动

注：如果报socket错误可以做www.devze.com个软连接或者改配置文件即可。

连接mysql

mysql -uroot -p

将备份导入到新库

source /tmp/dump.sql
或者
mysql < /tmp/dump.sql

检查数据

此时已经恢复完成，可以将MySQL停止，将旧数据目录和新数据目录重命名回去，修改配置文件，以恢复原状。

优化系统和 MySQL 配置优化

系统配置优化

cat >/etc/sysctl.conf<<'EOF'
vmandroid.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);

以上就是MySQL异常宕机无法启动的处理过程的详细内容，更多关于MySQL宕机无法启动的资料请关注编程客栈(www.devze.com)其它相关文章！