记一次mysql无法启动故障恢复和备份规划 _备份

一次深刻的教训（阿里云自建mysql，.9，.6），没有对数据库备份足够的重视，升级服务没有做应急预案，导致线上环境停机4小时维护。
一、事情经过：
1、应用需要升级，
2、阿里云提示系统有漏洞需要打补丁，需要重启服务器
3、停了应用服务，没有手工停mysql服务，重启服务器
4、部署好应用，发现mysql连接异常，一脸懵逼。
提示：to local MYSQL'/var/lib/mysql/mysql.sock'
找不到mysql.sock，通过网上搜索也没找到原因，
执行;提示stop成功，start。
执行，提示mysql dead but

文章插图
一时间定位不到问题，查看错误日志。
二、通过请教高人，解决问题的步骤：
1、应该是表中有错误的数据导致启动失败，此时mysql -uroot -P已经连接不到mysql，通过修改/ect/f 增加一行y=2,强制启动mysql，完成数据备份。
2、此时该出错的表还是操作不了，通过导出除此表之外的其他数据，庆幸这张表还只是暂时的日志文件，还没太大的意义。
3、到错误表处就结束了。
4、新建一个数据库实例，数据导入，新建出错的表，启动服务恢复生产应用。
到此，离停服务器已经过去4个小时，仿佛经历了一场大劫难，以长时间停止线上服务和丢失数据的风险为代价，这个教训实在太大了。
接下来付出了代价总要成长，反思为什么会出现这些问题，以后该怎么避免此类问题：
三、为什么会出现本次问题？
1、对服务器没有完全把控，重启服务器前没有停止mysql服务，导致mysql被强制关闭可能出现预知不到的异常或错误
2、mysql备份策略不齐，以及部署应用前没有全量备份，导致数据有丢失的风险
3、服务升级前没有做应急预案，即在通知的升级时间范围内如果出现不可预知的问题导致该时间段内不能完成正常的升级，应该立即启动应急预案恢复生产的使用，以免造成不良的影响和损失。
四、以后做哪些策略来避免此类的问题发生？(大佬的建议：先备份，至少有两个机器有存档，还要验证备份恢复，别备份的数据有问题或恢复不了，回头写个应急预案，应对各种问题的，高可靠性，安全性问题也考虑下，随着业务发展，不同阶段梯队和技术建设也要跟上。这次问题，也是找上面要资源的机会，直接买mysql服务考虑下，省运维，数据备份问题应该也给你解决了)
1、专业的人做专业的事情，条件允许的情况下招一个专业的运维来负责服务器的升级维护。
2、条件允许的情况下使用阿里原生的mysql，减少数据库的维护和风险。
根据目前情况自己操作的时候需要做的工作：
1、mysql升级到5.7，完整的数据库备份策略，每周全量备份，每天增量备份。备份文件在两台服务器上存档，以防出现灾难性丢失数据的情况。
2、轻易不要重启服务器，必要时，一定要把该关闭的应用手动关掉，比如mysql，redis
3、做好应急预案，如果中途出现问题，先恢复线上运行
【记一次mysql无法启动故障恢复和备份规划】4、必要时增加服务器，做服务集群，避免停机维护造成的不良影响。