数据库服务器事故总结。
宕机时间：20140107-20140111
事故起因：开发人员报告数据库服务器只能可读状态。登录服务器后发现只能可读。运行dmesg | grep error，发现有坏道，以为是系统问题，于是让IDC重启，这里操作不严谨，因为当时的主硬盘上是可读的并且备份硬盘上是可写的，安全的做法应该是把数据库本机备份一次，异地备份一次，然后再重启，下次应该注意。
重启后IDC回报系统卡在报错中断界面（无法加载/dev/root,/dev等）。IDC说他们无法解决，这是台数据库服务器，我决定开车到机房取回广州公司处理。我相信能从网络上找到参考资料去解决这个问题，因此我让小汪事先准备：1、网上资料；2、centos 5.5x32安装U盘。
取回机器后，从上面卸下备份硬盘插上外置硬盘盒，发现可读，心中稍感安慰，这也反映出备份的重要性。主硬盘是两块146Gsas硬盘做raid1，理论上单独一块坏了，另外一块可以独立接管工作的，奇怪的是：两块硬盘单独工作时，HDD0这块提示没有操作系统，HH1这块就是卡在报错中断界面。
经过资料搜集后，处理过程如下：
原理：Linux下普遍采用的是ext3文件系统，ext3是一个具有日志记录功能的日志文件系统，可以进行简单的容错和恢复，但是在一个高负荷读写的ext3文件系统下，如果突然发生掉电，就很有可能发生文件系统内部结构不一致，导致文件系统破坏。Linux在启动时，会自动去分析和检查系统分区，如果发现文件系统有简单的错误，会自动修复，如果文件系统破坏比较严重，系统无法完成修复时，系统就会自动进入单用户模式下或者出现一个交互界面，提示用户介入手动修复。
处理：从U盘启动centos 5.5x32，输入:linux resuce，进入修复模式。
1：查看是否检查到旧的硬盘 fdisk -l
2：扫描所有的卷组 vgscan
3：激活此卷 vgchange -ay /dev/卷名
4：挂载该卷。
5：mkfs.ext3 -n /dev/卷名 打印出超级块的位置，注意,一定要使用‘-n‘作为参数模拟 ext3 文件系统的创建而不是真的创建 ext3 文件系统。
6：fsck.ext3 -b -y 32768 /dev/卷名 使用备份的超级块来修复 ext3 文件系统。备注：如果这个超级块也有问题，那么可以尝试后面的几个超级块来修复。
7：重启后，会提示文件系统错误，这是只需要ctrl+D，进入单用户模式，卸载了出问题的那个卷，运行：fsck.ext3 -y /dev/卷名，则可解决问题。