记一次Mysql数据库Innodb故障--误删除idb文件

       某天中午，午休快要结束的时候，勤奋、努力、敬业的小编巡检服务器，发现有一台服务器的/home分区空间不足。因为历史原因，这是一个旧的平台，新平台已经建成，也已经投入生产。可是旧平台上依然还有很多的业务。因为马上就要端午了，假期没人管，另外，这几台服务器也没有接入监控。如果不是今天巡检，客户不投诉，服务器跑死了，也没人知道。今天，老夫高兴，这个活儿，我来干了……
       于是，小编就开始排查服务器上的大文件。一通操作下来，锁定需要清理的大文件是Mysql数据库。这个数据库里面还存有2016年的数据。按照之前的经验，这些数据，已经没用了，是完全可以删的。
       作为一名专业的运维工程师，删除数据一定要小心小心再小心。

登录数据库                           OK
切换到指定的数据库                    OK
再确认一下要删除的表                  OK
确认一下命令“drop table ****”        OK
停下来再确认一下，少了个“;”，补上“;”   OK
回车                                 OK
一转眼有个报错，说“无法连接数据库”     NOOK
……顿时手脚冰凉！                      ……

       来不及多想，再登录一下数据库，说是找不到“找不到mysql.sock文件”。赶紧‘ss -ntl’，我去，找不到数据库的端口。‘ss -ntl|grep 3306’，命令输出结果为空。“ps aux|grep mysql”，没有和mysql相关的进程。赶紧“service mysqld start”，重启失败，提示说“mysql的pid文件怎么怎么样‘Starting MySQL..The server quit without updating PID file ([失败]mysql/data/###.pid).’”。……
       赶紧将所有的业务切换到备机上。切换操作正常，没有报错。查看业务日志，正常。松了一口气……幸好这个服务器还有一个备机。现在的当务之急是将出了故障的Mysql重新启动。
       可是一重启数据库，就提示“Starting MySQL..The server quit without updating PID file ([失败]mysql/data/###.pid).”。百度一下报错，看到各路大神们给的故障解决方案。
       1、查看数据库目录的权限，没有问题；
              重启失败
       2、查看数据库相关的进程，刚刚已经看过了，没有问题；
              重启失败
       3、my.cnf配置文件，一直都没动；
              重启失败
       4、将mysql-bin.index文件移走，死马当活马医吧；
              重启没让咱失望，依然失败
       5、selinux？我去，这是那个大神装的服务器，依然是“enforcing”，赶紧改了。前辈，请收下我的刀片，不用客气！哎，斯人已去！
              满怀信心的重启，还是失败，报错跟之前一样；
       看了一下刚刚执行删除操作的那张表，.frm文件16K，.idb文件0个字节。文件中的数据已经被删了。删的表太大了吗？看了一下服务器的内存，一共62G，还有56G的free。好吧，怪不得这两天眼皮老跳，倒霉啊！
       又百度了几篇文章，试了一下，结果还是失败。这可如何是好？
       ……“黔驴技穷”……好吧，因为当时是在中午午休期间，业务量相对比较小，现在业务正常，也没有收到投诉。有的话，就由网络部的大侠们，来背吧。手头还有一堆其他的事情，一直在催。这件事先放一下，待会儿忙完了再说。
       忙完其他事情，已经快要下班了。
       已经过去几个小时了，此刻心情已经平静下来。想起来看一下数据库的错误日志。打开一看：

180615 15:57:27 mysqld_safe Starting mysqld daemon with databases from /home/mysql/data
2018-06-15 15:57:28 0 [Warning] 'THREAD_CONCURRENCY' is deprecated and will be removed in a future release.
2018-06-15 15:57:28 0 [Note] /home/mysql/bin/mysqld (mysqld 5.6.24-log) starting as process 207209 ...
2018-06-15 15:57:28 207209 [Note] Plugin 'FEDERATED' is disabled.
2018-06-15 15:57:28 207209 [Note] InnoDB: Using atomics to ref count buffer pool pages
2018-06-15 15:57:28 207209 [Note] InnoDB: The InnoDB memory heap is disabled
2018-06-15 15:57:28 207209 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-06-15 15:57:28 207209 [Note] InnoDB: Memory barrier is not used
2018-06-15 15:57:28 207209 [Note] InnoDB: Compressed tables use zlib 1.2.3
2018-06-15 15:57:28 207209 [Note] InnoDB: Using CPU crc32 instructions
2018-06-15 15:57:28 207209 [Note] InnoDB: Initializing buffer pool, size = 2.0G
2018-06-15 15:57:28 207209 [Note] InnoDB: Completed initialization of buffer pool
2018-06-15 15:57:28 207209 [Note] InnoDB: Highest supported file format is Barracuda.
2018-06-15 15:57:28 207209 [Note] InnoDB: Log scan progressed past the checkpoint lsn 10797428236
2018-06-15 15:57:28 207209 [Note] InnoDB: Database was not shutdown normally!
2018-06-15 15:57:28 207209 [Note] InnoDB: Starting crash recovery.
2018-06-15 15:57:28 207209 [Note] InnoDB: Reading tablespace information from the .ibd files...
2018-06-15 15:57:28 207209 [ERROR] InnoDB: Tried to read 16384 bytes at offset 0. Was only able to read 0.
2018-06-15 15:57:28 7f348c930720  InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
2018-06-15 15:57:28 207209 [ERROR] InnoDB: File (unknown): 'read' returned OS error 71. Cannot continue operation
180615 15:57:28 mysqld_safe mysqld from pid file /home/mysql/data/###.pid ended

       每次重启数据库，都是上面类似的日志。似乎是Innodb引擎的问题。莫非是执行drop的时候，Mysql宕机，重启的时候数据库执行回滚操作，可是会滚失败，造成服务器无法启动。造成提示“Starting MySQL..The server quit without updating PID file ([失败]mysql/data/###.pid).”。似乎就是这个原因。原因虽然找到了，可是该如何拯救的。
       既然是回滚操作失败，那重启的时候，跳过回滚，是不是可以解决故障。
       编辑my.cnf配置文件，将“innodb_force_recovery”的值设置成“6”。重启数据库成功。虽然数据库重启成功了，但是现在高兴还太早。因为此时，数据库只能进行查询操作，不能执行增删改的操作。
       将数据库备份下来，重建数据库？可是硬盘的空间的不够！现在只是数据库宕机，如果在备份期间，空间不足，引起服务器宕机，这可就是雪上加霜了。先将“innodb_force_recovery”的值重新设置成“0”，重启失败。
       不过幸亏刚刚的操作，已经可以锁定，Mysql无法重启，是由回滚失败引起的。
       将Mysql的回滚重做日志“ib_logfile*”给他移走，强制他取消回滚，重启后“ib_logfile*”会重新生成，结果还是失败。我真的是无语了，想着放弃了。删库、跑路……
不行，自己手里出现的故障，这个故障必须由我自己解决，解决不了，这个锅，也得我自己来背。Google了一下，还有一个“ibdata1”文件，将这个文件，连同“ib_logfile*”统统移走。重启数据库，成功！此刻，小编真是感动的快要哭了……
       可是，做数据库做主从同步的时候，失败了。报错显示，说某张表不存在，可是通过数据库明明可以看到。莫非是表内容不完整。drop这张表，有报错。算了，反正这个表中的数据也不重要，简单暴力一点，直接将.frm和.idb文件移走，重新create一张表。再做主从同步，成功了……此时，已经晚上八点半了，晚饭还没吃。又观察了一会儿，发现主从同步没有问题。看了看镜子里，已经通红的眼睛，好了，今天就到这里吧！
       ……
       第二天（今天是假期啊），过来一看，发现数据库，主从同步出了故障，说某张表找不到。drop表，依然有报错。老办法，mv表的.frm和.idb文件，重新create表。重新做主从同步，可是依然有报错，说某张表找不到，不过这次是报的另一张表。好吧，按照刚刚的办法处理。接着又报了几次类似的错误，都是这么处理的。最后，主从终于没问题了……
       可是又有一个问题，重启后的数据库，看不到从主机上同步过来的新数据。可是Mysql的slave是OK的。不管了，太累了，请给我一个电影的时间……
       电影看完之后，再确认，已经有新的数据了。虚惊一场……
       这就是这次故障的始末！不过，安全起见，后期还要持续观察一段时间。
       运维工程师的路，注定是坑坑洼洼、坎坎坷坷。一名伟大的运维工程师的路，注定是填坑的路，抱着遇坑我幸，填坑我命的态度继续走下去，不能轻言放弃。
       等下，要给领导发个邮件吗？！？

       经过和同事沟通，确定引起这个故障的原因是，那个表的.idb文件，被同事给删了，这个坑被我踩到了！！！