转载时请务必以超链接形式标明文章 原始出处和作者信息及本版权声明。
链接：http://www.dbasky.net/archives/2009/02/mysql3.html
常在河边走，哪有不湿鞋。当服务器运行时间为无限时，挂机也将会成为常态。所以宕机后的灾后处理也成为运维人员的必修课。为了纪念此次宕机事件，以切身的经验与来分享如何简单的做数据库恢复。
众所周知，机器因故断电重启对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).
到此，理论上数据库恢复完毕。
发表评论