Shell's Home

Sep 22, 2008 - 1 minute read - Comments

紧急修复

贝壳周四的时候收到消息,烟台的系统崩溃,于是在24小时之内走了一趟天堂和地狱间的旅行。

开始的时候,贝壳在查一些业务有关的资料。期间和一个同事开了几句玩笑,但是发现他一脸便秘的样子,和我说没空。贝壳很郁闷,怎么这么没面子?过了几分钟,事情就发展成贝壳也一脸便秘的没胆子了,原因是烟台的系统崩溃。由于远程无法连接,只能让客户去机房重起整个系统。可重起后也没有反应。于是贝壳怕了,马上通知了老板。老板马上做了决定,要我们当时飞去烟台,并且在几分钟内给我们搞定了机票。于是在贝壳头处理紧急问题的时候,就受到了”飞机-出租- 零反应”的待遇。

中间首先要感谢一下给我们做Oracle技术支持的纪锋老师,这次如果不是他的大力协助,恐怕问题不会这么快解决。我们在零时间往烟台赶的时候,纪老师也马上打车往机场走。我们是五点接到的问题通告,五点半就联络好了各种问题,乘公司的车子往机场走(主要怕下班高峰不好打车)。六点多点的时候,我们拿到了登机牌,去做安检,然后顺便讨论起问题原因。当时认为基本不可能是软件问题,因为软件问题重起后基本都可以解决,也不会弄的机器停机(这个最终被检验是正确的)。可能是维护问题或者硬件问题。按照机器安装时间来计算,硬件问题的可能居多(系统才刚刚交付几个月)。

飞机是8点50在烟台落的地,落地后我们心急火燎地坐出租往报社赶。车刚出机场,收到一个消息,问题消失了。我们顿时安心很多,要是问题继续出现导致更严重问题,怕我们全都吃不了兜着走。现在,虽然我们还要去找出根本原因,可总比被客户拷问着检查系统来的好的多。到了报业后,我们先检查了系统。第一个被发现的问题是备份机已经满了,怎么会这样?系统的设计容量是三年500G,按照现在的数据量估计,最高不会超过30G,可备份机上足足有100G的空间!我们倒推了数据,发现备份要用140G以上的空间。怎么会这样呢?

原因我们没有找到,不过按照纪老师给出的原因,是备份的时候大量的归档日志造成了数据量暴增。但是备份暴增怎么会造成系统不能访问呢?贝壳陷入了奇怪的感觉中。虽然直觉上觉得就是这个理由,但是实际上却无法确定。按照我和同事说的话,如果用这个理由来说服我,是无法说服的。但是如果在目前让我给出一个理由,恐怕只有这个了。当天比较晚了,因此没有进一步分析,只是让纪老师调整了备份策略就去睡觉了。

第二天,贝壳仔细检查了所有的系统日志,找到了真正引发错误的理由。Linux9号错误,原因是因为文件无法访问。可是,究竟为什么造成9号错误呢?又是为什么导致重起后错误不消失,过后错误又莫名消失呢?进一步分析日志找到了这后两个问题的理由,客户重起节点1未完成时,直接重起了节点2。RAC似乎在所有节点同时失效后无法自动重连,即使重起也不行,必须重起客户端。最后按照数据倒推,认定问题在本地磁盘耗尽上。只是开始为了检测数据库备份,执行了 crosscheck,释放了部分磁盘空间,因此查不出来。

从这次事故恢复来说,最大的问题在于客户那里没有人及时进行系统维护,最终导致了磁盘耗尽。因此说做一个系统简单,然而要长期维护系统,恐怕就没这么简单了。