/ postgresql

worst day

21:40 - 服务不可用

监控宝提示Homepage无法访问,以为有人在部署,后来其他服务也不可用,登录到服务器上看发现top都不能执行了,报过Bus errorSegment fault等,看/var/log/syslog发现是RAID卡出错,从iDRAC上看没有错误,RAID卡和电池状态正常。

目前已经无法提供服务了,重启试一下。

RAID卡无法被识别到,系统进不去。

强制刷一下RAID卡固件,失败,都无法识别,也没法刷固件了。

关机,等第二天去机房把磁盘换到另一台机器上,另一台机器有型号一样的RAID卡。

7:00 - 能进系统了

第二天早晨开机后发现可以进系统,但数据库启动不了,可能数据库的某些文件被破坏。

再次重启机器,系统无法启动,需要fsck

8:10 - 进入机房

去机房把服务器电源拔掉,长按开机键让电量耗光,如果这种reset还是没能解决问题,就只能更换到另一台服务器了。

hardware reset不管用,把磁盘放入另一台服务器。

启动时提醒需要import raid配置,import进入系统提示需要fsck

手工执行fsck,出现很多错误,一一确认后让fsck修复,可以进入系统。

备份系统到别的服务器

14:30 - 修复数据库

数据库(PostgreSQL 9.6)和一些静态文件有损坏

备份了数据库的data目录后,开始试着恢复数据库

reset了xlog,用dd创建了一个全0的clog,数据库可以启动,但有些奇怪的数据,dump出所有数据重建databaserestore,因为我们比较在意database的建模,很多有关系的表之间都有外键约束,restore的时候能帮我们发现很多不一致的数据,只好fix-dump-restore测试,一直到所有数据都正常后,vacuum, rebuild index

21:00 - 结束

真是worst day,现在看来数据库方面有更好的修复方法,起码可以做到只丢失最近的一部分数据,然而我们没有realtime的数据库备份也是个大问题,准备使用Barman来解决这些问题,另外服务器硬件也有一些东西需要重新考虑