隽永东方温馨提示：为了避免类似的数据库引擎再次莫名崩溃造成测试网站无法打开的不好体验，隽永东方已全面布局了远程云端高配阿里云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打开了数据库，惊人的发现问题解决了，久违的数据库一个一个美美的呈现了出来，当时真的感觉瞬间泪流满面，一个通宵的研究没有白费，此次的数据拯救完美收官。
记录以上心路历程，主要是分享创业路上的酸甜苦辣，创业不易，且创且珍惜！
事情起因
今天下午偶然发现美国cPanel服务器无法连接数据库，登录服务器发现以下错误：
INFO: rcu_sched self-detected stall on CPU
0: (288016 ticks this GP) idle=ba5/140000000000001/0 softirq=596083517/596083517
INFO: rcu_sched self-detected stall on CPU
2: (288017 ticks this GP) idle=e99/140000000000001/0 softirq=408174935/408174935
然后设法重启后，起初发现似乎一切正常，但是晚点就发现mysql无法启动，始终返回以下错误：
Starting MySQL. ERROR! The server quit without updating PID file
处理过程
至此感觉到了问题的严重性，尝试了各种修复方案，发现仍然无法再次启动mysql，于是紧急联系了cPanel官方的技术支持团队，通过提交 Request Emergency Assistance 与对方官方技术支持工程师直接取得了电话联系，对方工程师紧急介入技术协助，通过查看给出以下解决方案，顺利解决了此次的故障：
Hello,
We just spoke on the phone a moment ago. I am Melanie and I will be assisting you with your concerns with MySQL.
The concern appears to be due to InnoDB being unable to start:
150223 17:59:16 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
150223 17:59:16 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files…
InnoDB: Error: trying to add tablespace 210 of name ‘./munin_innodb/sample_table.ibd’
InnoDB: to the tablespace memory cache, but tablespace
InnoDB: 210 of name ‘./eaqlight_com/wp_itsec_log.ibd’ already exists in the tablespace
InnoDB: memory cache!
MySQL attempts to repair the issue automatically, however is unable to do so as the table space exists in the memory cache.
I have started the MySQL service by disabling InnoDB by adding the following to /etc/my.cnf:
skip-innodb
default_storage_engine=MYISAM
This will disable databases that use InnoDB such a Roundcube and Horde until the InnoDB table structure can be repaired. While cPanel does not preform database or InnoDB recovery services, we do have a detailed guide on the forums that may help you in addressing the concern:
I hope this information helps. Please do advise if you have any further questions or concerns.
Best Regards,
—
Melanie Littleton
cPanel, Inc.
Technical Analyst
通过cPanel官方工程师的回复可以看出来此次故障源于这台服务器上mysql服务里边的InnoDB引擎Corruption导致的，mysql服务有两种常见的引擎，一种是InnoDB，一般使用在较大型的网站数据库系统，比如magento之类的，另外一种最常见的引擎是MYISAM，这种引擎通用于其他所有轻型的数据库系统，比如我们最常用的WordPress等，至此问题已经找到了，此次的InnoDB引擎Corruption是由于这台服务器上的一个Magento的网站过大的资源消耗间接导致了InnoDB引擎的Corruption，我们彻底对该站点进行了迁移处理，确保该服务器只运行MYISAM引擎，同时紧急要求技术工程师对这台服务器网站进行排查，确保所有站点一律不会采用InnoDB引擎。
针对此次故障，我们技术工程师虽然第一时间进行了处理，但仍然导致网站中断访问了4个小时左右的时间，针对此次的中断我们向广大客户表示诚挚的歉意，并且会依据公司相关SLA和TOS等协议进行相应的补偿，同时我们郑重承诺，虽然无法确保服务器的可用性达到100%（就算世界排名第一的主机商承诺的uptime也只有99.9%也允许一年内有几十个小时的中断和维护的时间），但我们可以保证在出现任何一种问题的时候能够第一时间响应，第一时间进行处理，确保所有网站数据的安全性和稳定性。
隽永东方技术支持团队敬上
2015年2月13日晚19:23