记一次MySQL数据库损坏修复

概览

昨天晚上在本地的虚拟机中安装了 CentOS 8.3 Stream,觉得还挺好用的,据说包管理工具 dnf 要比 yum 更好用,其实我没什么感觉,遂想把阿里云的云服务器也升级成 CentOS 8.3(当前版本为CentOS Linux release 7.9.2009)。

于是为当前服务器创建了一份快照后就去执行升级命令了,升级过程中遇到了诸如Python2.7 UnicodeEncodeError、dnf 无法安装 rpm 包等问题,但是最终也通过 Google 解决了。
安装结束后,重新启动,一切正常,就在我准备睡觉时,Jetpack 给我发邮件说我的网站炸了,我一看果然上不去了。

好家伙,看了一眼Nginx好好的,但是MySQL挂了;

我仔细一看,好家伙整个 /var/lib/mysql文件夹都不见了,难怪启动不了。

考虑到我每四天就会通过 mysqldump 和 python 脚本自动备份数据库文件到阿里云 OSS,所以我选择了直接重装 MySQL(顺便更新了一下 MySQL 版本)然后导入 *.sql文件解决了数据库的问题,此时网站已经可以正常访问。

分析

解决问题之后,我们来复盘一下。
考虑到这个网站全都是由我一人在维护,加之最近在忙着 ICPC 的比赛,所以系统已经很久都没有维护了。昨天晚上登上 SSH 看了一下,顺便执行了 sudo yum upgrade 升级了一下 yum 的包,我不确定此时我的网站有没有挂,我在没有检查系统状态的情况下就直接创建快照了,那这样的快照无异于不照。

众所周知阿里云创建快照的时间不快,大概要个 5-10 分钟,而在创建的过程中我已经开始执行升级内核的命令了,虽然我不知道这是不是造成本次事故的主要原因,但是我强烈不推荐大家在创建系统快照的同时执行危险操作

其实我已经吃过数据丢失的亏了,在我刚接触云服务器的时候,尚不知道快照的重要性。当时也不是太懂 Linux 怎么用,一不小心就把写了两周的 Wordpress 博客搞炸了(好像是因为装了一个 AppNode 之后数据库被挤下去了),甚至还开了工单希望工程师帮我恢复成一小时之前的样子,现在看看当时的自己真的好可爱呀。

自那之后我就坚持备份,一个多月前我发现我旗下的某个网站被国外某博彩网站黑掉了(应该是我把后台密码设置的太简单了),访问主页会直接跳转到他们的网站,以至于我的那个域名直接被 Chrome 和 Safari 拉黑了。我到后台一看,缺德的黑客把我的网站数据全都改成了乱码,幸亏我还做了全站目录备份,几乎没什么损失。

备份常用操作备忘

mysqldump命令格式

mysqldump -h主机名 -P端口 -u用户名 -p密码 –database数据库名 > 文件名.sql

直接压缩

mysqldump -hhostname -uusername -ppassword -database databasename | gzip > backupfile.sql.gz

备份某些表

mysqldump -hhostname -uusername -ppassword databasename specific_table1 specific_table2 > backupfile.sql

还原数据库

mysql -hhostname -uusername -ppassword databasename < backupfile.sql

还原压缩的数据库

gunzip < backupfile.sql.gz | mysql -uusername -ppassword databasename

订阅评论
提醒
0 评论
内联反馈
查看所有评论