MySQL服务器异常断电启动报错,启动提示“The server quit without updating PID file”问题解决

公司ERP使用本地服务器,机柜放在机房,包括MySQL数据库。今天下午,由于电缆问题异常断电,UPS冗余未能生效,使得MySQL数据库服务器异常断电。

当时就感觉不妙,等到来电开机后,验证了我的担忧。使用systemctl start mysql启动MySQL无法启动,报错如下:

Job for mysql.service failed because the control process exited with error code.
See “systemctl status mysql.service” and “journalctl -xe” for details.

使用“journalctl -xe”查看了详细的报错,得出如下结果:

Oct 14 14:46:52 Database mysql[1896]: ..The server quit without updating PID file (/home/DBs/MySQL/Database.pid). … failed!
Oct 14 14:46:52 Database systemd[1]: mysql.service: Control process exited, code=exited, status=1/FAILURE
— Subject: Unit process exited
— Defined-By: systemd
— Support: https://www.debian.org/support

— An ExecStart= process belonging to unit mysql.service has exited.

— The process’ exit code is ‘exited’ and its exit status is 1.
Oct 14 14:46:52 Database systemd[1]: mysql.service: Failed with result ‘exit-code’.
— Subject: Unit failed
— Defined-By: systemd
— Support: https://www.debian.org/support

— The unit mysql.service has entered the ‘failed’ state with result ‘exit-code’.
Oct 14 14:46:52 Database systemd[1]: Failed to start MySQL Community Server.
— Subject: A start job for unit mysql.service has failed
— Defined-By: systemd
— Support: https://www.debian.org/support

— A start job for unit mysql.service has finished with a failure.

— The job identifier is 486 and the job result is failed.

根据报错,先常规的修复下文件权限试试看。执行如下指令修复:

    chown -Rf mysql:mysql /home/DBs/MySQL

再次执行启动,然鹅貌似我应该是没什么面子,故障依旧。如此只能查询下日志,看看是什么情况了。
切换到数据库目录/home/DBs/MySQL,然后cat了一下err文件,我的服务器名字是“Database.err”(一般文件名是您服务器主机名加上.err),得出如下的错误信息:

2020-10-14T06:52:37.075938Z 0 [Note] –secure-file-priv is set to NULL. Operations related to importing and exporting data ar e disabled
2020-10-14T06:52:37.076059Z 0 [Note] /usr/local/mysql/bin/mysqld (mysqld 5.7.28-log) starting as process 3138 …
2020-10-14T06:52:37.089976Z 0 [Note] InnoDB: PUNCH HOLE support available
2020-10-14T06:52:37.090025Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-10-14T06:52:37.090032Z 0 [Note] InnoDB: Uses event mutexes
2020-10-14T06:52:37.090037Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2020-10-14T06:52:37.090042Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-10-14T06:52:37.090048Z 0 [Note] InnoDB: Using Linux native AIO
2020-10-14T06:52:37.090586Z 0 [Note] InnoDB: Number of pools: 1
2020-10-14T06:52:37.090740Z 0 [Note] InnoDB: Using CPU crc32 instructions
2020-10-14T06:52:37.093337Z 0 [Note] InnoDB: Initializing buffer pool, total size = 512M, instances = 1, chunk size = 128M
2020-10-14T06:52:37.134555Z 0 [Note] InnoDB: Completed initialization of buffer pool
2020-10-14T06:52:37.174234Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2020-10-14T06:52:37.213180Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2020-10-14T06:52:37.218275Z 0 [ERROR] InnoDB: Ignoring the redo log due to missing MLOG_CHECKPOINT between the checkpoint 255 12169130 and the end 25512169006.
2020-10-14T06:52:37.218319Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2020-10-14T06:52:37.828459Z 0 [ERROR] Plugin ‘InnoDB’ init function returned error.
2020-10-14T06:52:37.828514Z 0 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
2020-10-14T06:52:37.828529Z 0 [ERROR] Failed to initialize builtin plugins.
2020-10-14T06:52:37.828539Z 0 [ERROR] Aborting

2020-10-14T06:52:37.828554Z 0 [Note] Binlog end
2020-10-14T06:52:37.828698Z 0 [Note] Shutting down plugin ‘CSV’
2020-10-14T06:52:37.829505Z 0 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

啧啧,有点儿秀了。简单解释就是由于异常关机,导致Innodb引擎的完整性校验无法通过(简而言之就是可能有数据丢了)。
作为ERP系统,数据还是蛮重要的。所以我安安静静的先尝试修复。编辑/etc/my.cnf文件,在[mysqld]下面添加了“innodb_force_recovery”配置,从1尝试到6,都是给出了该提示。

innodb_force_recovery = 1

出师未捷身先死,无奈之下,只能把数据库目录下的ib_logfile*文件全部删掉了。说干就干:

mv ib_logfile* ../

我不敢删,先把它移到别的地方去吧。然后启动试试看

systemctl start mysql

启、启动成功了,貌似?也许?应该?好了?

你说啥?这样子会导致事务中的数据丢失?这问题没有吧,一个ERP系统,几秒钟的数据哪有那么重要?实在不行让业务部门再去做一下嘛…
好吧,这样子就处理好了MySQL服务器异常断电无法启动,报错“The server quit without updating PID file”的问题了。好像,so easy?

发表评论

电子邮件地址不会被公开。 必填项已用*标注