【MYSQL异常处理】记录一次MYSQL数据库断电无法启动异常，错误提示为 ERROR! The server quit without updating pID file (/usr/local/m

某xx项目，系统一直用着好好的，虽然无客户真实数据，但包含许多现场定制配置数据，结果客户突然把服务器给断电关机了，服务器环境大致如下

1 服务器环境描述：
2 centos7三台
3 其中，一台centos部署mysql，其他两台部署nacos,基础服务，及其他业务微服务应用

因为那会快下班了，客户都走了，想着第二天让客户给开下服务器，我们重启下相关服务应该没啥，事实证明我真是大意了

到了第二天，和同事一块开始恢复，然后傻眼了，半小时过去，MYSQL还没启起来，启动一直报错如下

 去mysql/data目录下查看，业务库的数据库文件都在，但看不出有木有损坏，也没有找到后缀pid的文件

pid文件的作用就是当mysql服务启动好之后，记录它当前的进程id,打开正常运行的mysql环境，pid文件中其实就只有一个码

继续使用命令查看MYSQL状态，提示锁文件

 尝试删除锁定的这个文件，启动依旧报图一的错误，去查了mysql的日志文件，看到其中包含[ERROR] [MY-013183] [InnoDB] Assertion failure:..之类的描述

于是去万能的网上找资料，但看到多数的说法是出现这个错就是表示数据库崩溃，会有数据丢失，根据不同的情况，有的能恢复，有的恢复不了

罗列几种网上的处理
1）手动创建pid文件再启动；
2）修改配置配置#innodb_force_recovery=6，强制启动mysql ，逻辑导出导入
3）如果data目录中的业务库文件还在，尝试迁移的方式恢复
4）找专业的数据恢复公司人员（这个就不考虑了）

然后一一尝试，最终都不行，原因为

1）使用touch命令确实可以手动创建，然但启动服务时，pid文件就会被自动删除
2）修改配置后启动，还是启动不起来，错误依旧
3）迁移这种，前提时两套一模一样版本的mysql环境，且都是正常的（这点不满足），第一台服务器data目录中的文件全部复制到第二台服务器data目录，第二台启动时可以直接识别到所有的库

真的是好气馁，很不幸，折腾两天，一无所获

肯定有人说，谁让你不做好备份，数据没了活该

确实是没做备份，确实是活该，但还是想说，一部分原因是服务器资源不是很足，本身就处于那种能用但很卡的情况

其实老早就装了SQLBackupAndFTPSetup，也配置了定时备份任务，但只要一启动备份任务，服务器会直接卡住，也是没招

最后的结果，只能联系公司开发人员，重新给提供一份库

数据无价，请大家引以为戒，做好日常数据备份工作！