隽永东方温馨提示:为了避免类似的数据库引擎再次莫名崩溃造成测试网站无法打开的不好体验,隽永东方已全面布局了远程云端高配阿里云RDS,确保数据库的稳定和安全。

事情的起因源于这次香港测试服务器的数据库迁移,本来这种迁移通过服务器SCP、WGET等方式驾轻就熟,并没有太大难度,只不过冥冥之中上天和我们开了一个小小的玩笑,差点造成一次数十个站点数据库丢失无法恢复的惨剧,幸好及时处理好,避免了一场血光之灾,废话少说,言归正传。

由于这两台香港服务器采用了大陆目前最好的LINUX主机控制面板WDCP3.0,WDCP用过2.5版本的人都应该会赞不绝口,不仅好用还稳定,最重要的是免费,当初我就说过,如果这个软件商业化,价格合适的话,我会毫不犹豫的选择支持购买,只不过3.0以后问题BUG层出不穷,这半年多来频繁的忙活于处理服务器的各种问题,事后想想毕竟免费的是最贵的,没有足够的资金支持,再好的软件也没法一直坚持下去。

此次的迁移一开始波澜不惊,一切似乎很顺利,平稳迁移好以后,有一天突然发现前面这台老的服务器上的某些站点数据库里边一些表点不开了,始终提示表不存在,当时还没太在意,感觉小问题,repair 一下就肯定能好,但是逐步深入查看以后,发现了问题的严重性,这种表在phpmyadmin底下压根就无法点击查看,更不用说去repair了,当然因为新服务器上一会之间没发现这个问题,于是又疏忽大意了,就这样安稳的过了两天以后,同事突然和我说发现很奇怪的问题,新服务器上搭建WordPress新站,竟然提示一堆的数据库错误,当时第一反应就是,是不是WordPress的debug打开了,小事情,然后挨个排除以后,还是发觉始终无法安装上,于是进入新服务器的phpmyadmin一看,顿时吓出一身冷汗,发现前两天老服务器上的问题竟然像瘟疫一样的蔓延到了新服务器上,而且影响范围甚至扩大化了,好多数据库从左侧看表都存在,但是点击的时候就是提示:

到这个时候凭借我丰富的LINUX运维经验,还是没感觉事情有多大,心想既然表都还在,只是phpmyadmin里边无法识别而已,多大点事情,到另外一台服务器上新创建一个空白数据库,直接把.frm .MYD.MYI等文件拷贝过去,更改一下属组为mysql:mysql,重启一下mysql不就手到擒来吗,但是当信心满满的去操作了一遍以后,发觉在新服务器上的空白数据库底下,右侧显示了表格,但是所有表格都显示in use:

当全选这些表格,点击下拉的repair table以后,显示了大量的错误:

尤其是其中的 Unknown table engine ‘InnoDB’ 印象很深刻,记得前几年美国cPanel出现过类似的问题,还是紧急花钱请老外来协助处理的,而且最终也并不算完美处理,只是临时把INNODB引擎关闭,在不启动INNODB的情况下,才重新让MYSQL活过来,具体查看此篇文章:有关2015年2月23日美国cPanel服务器mysql无法连接的公告 当时连夜付费给老外,打英文电话给老外的情景现在还记忆犹新,至此我才真的感到了恐慌,因为我心理很清楚,涉及到了INNODB引擎的崩溃,就不是小问题,处理起来很棘手,而且几乎网络上没有完整的方案可用,全靠自己摸索,于是我从同事诚惶诚恐的眼光中接手了这件事情的处理,因为凭他的经验这个问题一定处理不好,于是开始了漫长的寻找问题,解决问题的过程,这期间我整整熬了一个通宵,到凌晨时分,还没解决问题的时候,我近乎绝望,难道今年的本命年是我的灾难年,新年的第一个月就给我了一个如此大的下马威,期间我简单记录一下都采取过了哪些手段。

随着深入研究MYSQL的错误日志,距离真相也越来越近,我知道彻底解决这个问题不是梦想,但是临门一脚何其艰难,期间采用过给my.cnf里边加入:

[mysqld]
innodb_force_recovery = 6
innodb_purge_threads=0

重启MYSQL以后,再次发现脆弱的MYSQL再次死去,于是重启服务器,重新更改配置文件,查看错误日志,反复数遍,终于MYSQL再次启动起来,希望再次降临,但是然并卵,凡是INNODB的数据库表依旧无法点击查看,无法导出,至此有点心灰意冷,甚至想过干脆放弃好了,这几个站点从零开始重新搭建吧,虽然苦点,但是至少能挽回点损失,顿时从心底涌起一股悲凉,想着好几个项目历经千辛万苦好不容易要结束了,结果临门一脚却踢了个乌龙,有点欲哭无泪的感觉,创业这么多年,孤独了这么多年,不被理解了这么多年,贫穷了这么多年,我的2017年不应该这样开头的,不应该,于是我不死心,尝试洗了把冷水,让头脑清醒一下,然后在深夜接近12点的时候,开车回到了家,继续挑灯夜战,妻子心疼给煮了美味可口的饭菜,但是有心事的时候,再美味的饭菜也嚼之无味,于是又想到了会不会是MYSQL版本太低的问题,是不是升级一下MYSQL到5.6说不定就所有问题全部迎刃而解了,事后想想,自己也未免太理想化了,于是接下来又陷入了升级MYSQL的死循环,一遍一遍的升级,一遍一遍的纠错,一遍一遍的重启MYSQL,然后悲凉的看着MYSQL提示错误无法启动,最后一次当再次重启成功MYSQL的时候,感觉世界末日并没有如期而至,但是命运依旧多舛,MYSQL升级到5.6以后并没有丝毫解决问题,问题涛声依旧。

于是疲劳和绝望缠绕着自己昏昏欲睡的度过了几个小时,临近凌晨时分,咪了不足两个小时的我又清醒的醒过来,立马继续进入战斗状态,尝试以新思路和角度进行纠错,当然至少到这个时候,新服务器上MYSQL启动成功了,几十个站点挽救回来了,只剩余将近10个采用了INNODB的数据库依旧在ICU里边抢救中,随时面临阵亡,这个时候随着研究的逐步深入,真相其实已经很近了,问题的根源基本找到了,就是我同事在迁移数据库的时候,只迁移了VAR底下的数据库文件,对应的INNODB所依赖的ibdata1并没有迁移过去,而经过查询发现,INNODB并不能只迁移数据库文件,否则就会出现类似的表被锁定无法识别的悲剧,到这个时候其实我已经坚信问题解决已经在咫尺之间,但是距离真正完美解决总还是差那么一小步,于是熬了将近一个通宵以后,带着仍旧的遗憾,囫囵吞枣的刷牙洗脸吃个早餐,送儿子上学后,就又再次奔赴前线战斗了,这次我选择了从缺失的ibdata1入手,为了不影响正在运行中的服务器的MYSQL数据库,于是相当了让同事在本地安装一个XAMPP套件,正是这个天才的想法最终挽救了这十来个数据库的生命,XAMPP套件顺利下载安装,MYSQL服务成功启动,APACHE无法启动,凭经验轻松判断出是SKYPE占据了80端口,关闭SKYPE以后,APACHE成功启动,然后把事先备份好的数据连通备份的ibdata1一起拷贝过去,然后不报太大希望的尝试通过phpmyadmin打开了数据库,惊人的发现问题解决了,久违的数据库一个一个美美的呈现了出来,当时真的感觉瞬间泪流满面,一个通宵的研究没有白费,此次的数据拯救完美收官。

记录以上心路历程,主要是分享创业路上的酸甜苦辣,创业不易,且创且珍惜!

最近一台阿里云服务器当初安装WDCP的时候没有考虑数据盘加载的问题,发现直接挂载的系统分区一共才18G,而站点数据所在的分区/www加上系统本身一共占用了将近一半的容量,这样长期运营,很快就会磁盘空间不够导致很大的隐患,于是决定把阿里云默认的数据盘充分利用起来。

默认阿里云自带的数据盘是未格式化,未挂载的一块数据盘,这点对于Linux的新手来说足够坑爹,同样国外的linode就做得比这个要好,直接就挂载上去了,降低了使用门槛,当然话说回来,想自己折腾centos系统,提高水平,不会操作分区挂载分区就算没有入门,好了闲话少说言归正传:

阿里云主机数据盘未做分区和格式化,可以根据以下步骤进行分区以及格式化操作。下面的操作将会把数据盘划分为一个分区来使用。

1、查看数据盘

在没有分区和格式化数据盘之前,使用 “df –h”命令,是无法看到数据盘的,可以使用“fdisk -l”命令查看。

得到信息如下:

Disk /dev/hda: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1        2432    19535008+  83  Linux
/dev/hda2            2433        2610     1429785   82  Linux swap / Solaris

Disk /dev/xvdb: 85.8 GB, 85899345920 bytes
255 heads, 63 sectors/track, 10443 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/xvdb doesn't contain a valid partition table

2、 对数据盘进行分区

执行“fdisk /dev/xvdb”命令,对数据盘进行分区;

根据提示,依次输入“n”,“p”“1”,两次回车,“wq”,分区就开始了,很快就会完成。

3、 查看新的分区

使用“fdisk -l”命令可以看到,新的分区xvdb1已经建立完成了。

4、格式化新分区

使用“mkfs.ext3 /dev/xvdb1”命令对新分区进行格式化,格式化的时间根据硬盘大小有所不同。

5、接下来的步骤是关键,因为我这台云主机是正在运行wdcp的,因此/www里边的数据一定要转移出来,否则,贸然挂载很可能造成这个分区数据全部丢失的噩梦,先创建一个临时目录
mkdir /mnt/data
挂截
mount /dev/xvdb1 /mnt/data

6、移动数据
先停上相关的服务,如
service mysqld stop
service httpd stop
service nginxd stop
service pureftpd stop
service wdapache stop
移动数据
mv /www/* /mnt/data

7、修改启动选项
vim /etc/fstab
增加一行,如下
/dev/xvdb1 /www ext3 defaults 1 2
保存退出,然后reboot一下,就顺利完成,是不是很简单,你也试试看吧。