*近2次遇到数据库崩溃.
第*次是因为ups到服务器之间的电源碰掉,造成mysql数据库*个表丢失1000行数据.
第二次是因为机箱散热风扇停转,造成系统死机, mysql丢失了*部分数据.

2次灾难恢复的问题不同, 恢复步骤也不同.

第*次:
  本来每天有数据库的dump备份的,但是由于服务器硬件升*.并没有恢复这个每日定时任务.
当灾难发生时,只能找到15天以前的数据.丢失了整整2个星期的数据. *后能够想到的办法,
只有通过apache 的http日志去提取同事们的真实的操作,然后现这些操作.好在程序也是我
编的,实现起来虽然相当费劲,但也是可行的.
早在开始建立应用系统的时候, 就定下了*个原则,所有的http操作都只使用GET方式,不使用
POST方式,因为POST方式,在http日志中是没法挽救数据的.这*编程原则,成了我*后的救命
稻草,*写程序,从http log中提取数据,提取出2000条对损坏表有影响的操作记录.然后分类
为20种操作. 对这20种操作单独编写模拟写库程序, 整个*个双修日的白天和晚上就这么搭上
了. 出问题的那天是周5下午, 当同事们周*来上班的时候, 没有发觉业务系统有什么问题.
完成修复后,恢复了每日定时备份,并且通过调整,让mysql服务输出binlog,并保留100天.这也为
以后部署数据库镜像做好准备.

第二次:从binlog
  还没有来得及进行数据库镜像部署,第二次故障发生了,哈哈.由于有了binlog以及每日备份,
恢复数据就简单多了.其实就是*个从数据库镜像的配置过程.
  mysqldump导出的备份数据在*后*行会有时间标志, 记下这个时间标志, "2007-05-14 18:39:06"
然后找到这个时间标志在binlog中的偏移值, binlog*般在/var/lib/mysql/mysql-binlog.0000xx
根据文件日期找包含这个时间段的文件. 记下这个文件*. 然后还要找到当时备份的时间在这个log
文件的偏移值. 要找到这个偏移值.