客户系统数据库意外关闭了,查看数据库故障时间的警告日志:
发现在故障时间,数据库的警告日志中出现了大量的IO错误,最终导致数据库的核心进程出现错误,导致数据库意外关闭。
既然出现了IO错误,我们肯定需要关注下操作系统的日志:
这里截取其中的几行我们分析下:
Jan 8 14:29:55 zrdb-1 kernel: qla2xxx 0000:18:00.0: LOOP DOWN detected (2).
Jan 8 14:29:55 zrdb-1 kernel: qla2xxx 0000:18:00.0: LOOP DOWN detected (2 5 0).
Jan 8 14:29:56 zrdb-1 kernel: bnx2: eth0 NIC Copper Link is Down
Jan 8 14:29:56 zrdb-1 kernel: eth2: Link is Down
Jan 8 14:29:56 zrdb-1 kernel: bonding: bond1: link status definitely down for interface eth2, disabling it
Jan 8 14:29:56 zrdb-1 kernel: bonding: bond1: making interface eth3 the new active one.
Jan 8 14:29:56 zrdb-1 kernel: bonding: bond0: link status definitely down for interface eth0, disabling it
Jan 8 14:29:56 zrdb-1 kernel: bonding: bond0: making interface eth1 the new active one.
Jan 8 14:30:25 zrdb-1 kernel: port-3:0-1: blocked FC remote port time out: saving binding
Jan 8 14:30:25 zrdb-1 kernel: sd 3:0:0:0: SCSI error: return code = 0x00010000
Jan 8 14:30:25 zrdb-1 kernel: end_request: I/O error, dev sdb, sector 1662453767
Jan 8 14:30:25 zrdb-1 kernel: Buffer I/O error on device sdb1, logical block 207806713
Jan 8 14:30:25 zrdb-1 kernel: lost page write due to I/O error on sdb1
Jan 8 14:30:25 zrdb-1 kernel: Buffer I/O error on device sdb1, logical block 207806714
Jan 8 14:30:25 zrdb-1 kernel: lost page write due to I/O error on sdb1
。。。
Jan 8 14:30:28 zrdb-1 kernel: Aborting journal on device sdb1.
Jan 8 14:30:28 zrdb-1 kernel: sd 3:0:0:0: SCSI error: return code = 0x00010000
Jan 8 14:30:29 zrdb-1 kernel: end_request: I/O error, dev sdb, sector 1981510079
Jan 8 14:30:30 zrdb-1 kernel: ext3_abort called.
Jan 8 14:30:31 zrdb-1 kernel: EXT3-fs error (device sdb1): ext3_journal_start_sb: Detected aborted journal
Jan 8 14:30:34 zrdb-1 kernel: Remounting filesystem read-only --这里文件置为了只读状态
。。。
同样在数据库故障时间段内,操作系统的日志中也报出了大量的IO 错误,然后文件系统出于对磁盘数据的保护,把所在的分区置为只读状态了,从而导致了数据库意外关闭。
不过需要注意的是在报出IO错误之前,网卡down掉了,而且fc的连接也断开过一次,而查看fc存储的日志,发现这个时间段也存在一次意外的中断。
所以推断这一故障的原因很可能是因为网络和fc中断后,导致了fc存储对应的文件系统读取出现了较多的IO错误,而操作系统处于安全考虑将该分区重新置为只读状态,而数据库的核心进程dbwn和lgwr进程由于无法完成写入动作,最终强制将数据库关闭。
此时的解决办法其实很简单的,需要重新把上述所在的磁盘分区重新挂载为可读写状态,然后重新启动数据库。
关于文件系统只读,小鱼以前也遇到了很多次,只是每次小鱼都是直接重新挂载就好了,没去过多分析为什么出现文件系统只读,今天借助这个故障的分析,让我们维护人员应该更多的去了解操作系统、存储和网络,这个虽然不一定是我们所擅长,但是一些基本的我们还是必须去掌握,当然这跟实际的工作环境相关。
Good luck!