mysql笔记(3)–数据库恢复

常在河边走，哪有不湿鞋。当服务器运行时间为无限时，挂机也将会成为常态。所以宕机后的灾后处理也成为运维人员的必修课。为了纪念此次宕机事件，以切身的经验与来分享如何简单的做数据库恢复。
    众所周知，机器因故断电重启对web  server的影响是很少的，但是对data server的危害却巨大的。这些倒来个彻底，由于机房原因所有的服务器全部重启了。不出所料，所有的服务重新开启后网站正常工作，很高兴数据库还能跑起来，看来伤害还不是特别大，不过还是很小心确认一下数据库的运转情况，首先进入一台mysql,从服务器
1.show processlist  查看了一下当前运行进程

功能: 显示mysql当前运行的进程.
目的: 因为数据库做了主从，所以我想看看主从的工作正常与否.
扩展: show full processlist显示完整的当前运行进程.
数据显示:
*************************** 2. row ***************************
     Id: 919176
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 25507
  State: Waiting for master to send event
   Info: NULL
*************************** 3. row ***************************

好家伙，time怎么达到2W多秒呢。可能从服务器备份出问题了，先看状态再说:
注:time显示主从机器的备份时间差
2. show slave status

功能:查看当前从服务器的运行情况:
目的:查看slave是否没有开同步进程。
扩展： 还有show master status:使用对像是master服务器
显示数据片断:
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
               ……………………
                Master_User: root
                Master_Port: 3306
           Slave_IO_Running: Yes
          Slave_SQL_Running: No
                Last_Errno: 126
                 Last_Error: ………………………
       …………………………..

晕，Slave_SQL_Running: No,看来执行同步sql进程挂了，原因是Last_Error，查看了last error的内容原来是表坏了，嗨还是看看mysql的日志吧，看看是否其它表挂掉。

3.查看mysql的错误日志;

位置: mysql数据库表的路径MYSQL_PATH/data/下面
名称; 本机名称.err
目的：查看是否有更多坏表

grep了一下，果然有不少表出现问题，看来还是把库中的表都check一下，再repair吧.

4.check table [table_name,...] option

功能：检查当前的表的情况
目的:查看表是否坏掉
数据输出：
mysql> check table host;
+————+——-+———-+———-+
| Table      | Op    | Msg_type | Msg_text |
+————+——-+———-+———-+
| mysql.host | check | status   | OK       |
+————+——-+———-+———-+
1 row in set (0.00 sec)

5.repair table [table_name,...]

功能: 修改出错的表
目的：修表

经过上面两个步骤，终于把当前slave的表都修好了，并且监视了.err一会儿。看来表是没问题了。重启一下slave看看正常否。重启slave比较简单,先停，再开.

6.stop slave 关闭slave
7.start slave 再次打开slave 注意：没用start master这一说

经过了上面两个步骤再show slave status\G
显示数据片断:
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
               ……………………
                Master_User: root
                Master_Port: 3306
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
                Last_Errno: 0
                 Last_Error:
       …………………………..

哈哈双yes,并且errno为0哈哈，问题解决。先前time值也下去了。

问题还没结束，接查他其它机器，同样我查看了另一组的主从按以上相同的步骤，先
show processlist\G 发现slave与主机的时间差也很高，再用
show slave status\G
显示数据片断:

*************************** 1. row ***************************

             Slave_IO_State: Waiting for master to send event

               ……………………

                Master_User: root

                Master_Port: 3306
          Master_Log_File: mysql-bin.001194
        Read_Master_Log_Pos: 38828750
           Slave_IO_Running: No

          Slave_SQL_Running: Yes
                Last_Errno: 0

                 Last_Error:

       …………………………..

这回倒好，和上面那台slave服务器正好相反了，这台服务器是IO同步进程没有正常运行。但是errno却为0,真是怪了，于重启了一下slave（上面介绍过的）,再看slave status问题依然存在。嗨，既然没有正常启动IO同步进程那么一定在err日志里面有所体现，看了一下日志果然有问题，大概的意思就是当从服务器向主服务器同步数据的时候，位置查找有误。嗨，通过当前slave 的status看出当前同步到了Master_Log_File: mysql-bin.001194       Read_Master_Log_Pos: 38828750。怎么会位置不存在呢，还是看看主服务器的壮态吧。

8.show master status\G

功能：显示主服务器的信息
目的：看一下，日志保存到什么地方了
数据显示:
mysql> show master status\G
*************************** 1. row ***************************
            File: mysql-bin.001198
        Position: 61499218
    Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)

主服务器都保存到001198号日志文件了，那么从服务器的号比它小应该能找到位置呀。这是怎么回事呢？还是看看主服务的001194号日志文件吧.

9.日志文件一般保存在MYSQL_PATH/LOGS下面，呵呵，当然可以自己设置.

ls -al一下，不出所料001194号日志文件出问题了，大小才28023460 b,当然从服务器找不到001194号日志文件的Read_Master_Log_Pos: 38828750  这个位置了.看来机器断电的瞬间，磁盘的cache没来得及把内容写入到磁盘块中。然后开机后又重新开始写新的文件，而从服务器可能恰好再那个时刻把数据记下去了，不知道分析的有没有道理。问题摆再眼前：有数据丢失怎么办，能找回来吗？可以，重做slave就行了。但是由于其它原因放弃了重做slave.直接把从服务器的备份到出错文件的下一个位置。001195号文件的开头开始备份。

10. change master to master_log_file=’mysql-bin.001195′,master_log_pos=0;

功能：修改备份对像(master)的参数.
目的：把备份位置改到正常 的位置上去。
扩展:
mysql > change master to
 ->master_host=’host’,
 ->master_user=’user’,
 ->master_password=’pass’,
 ->master_log_file=’filename’,
 ->master_log_pos=’position’,

修改完从服务器的备份位置后，重启动slave.好了(双YES,并 errorno=0).

到此，理论上数据库恢复完毕，可以回家吃晚饭了。注意：数据库的错误千奇百怪，以上方案做为入门可以解决简单问题。

路过的高手请补充.谢谢