none
新年第一天上班就碰到的重大故障--存储故障,导致数据库不可用,欢迎大家一起讨论,指出在故障处理过程中的不足之处 RRS feed

  • 常规讨论

  • 2011-2-09早上,带着新年的喜悦,我去上班。

    由于在过年期间放假,没有按之前的日常检查方式对所有服务器做日常检查,而是每天有选择的挑其中的一部分加以检查,因此上班第一天,上午我把手头负责管理的所有DB服务器统统查了遍,检查结果,没有发现什么异常,因此愉快的度过了第一个工作日。

     

     

    10点左右,突然接到公司监控的电话,称大量应用报错,网站无法下单,我心里咯噔一下,不会是数据库有啥大问题了吧,这个数据库服务器的硬件是年前1.23将数据库从原来的sql server 2000升级到sql  server 2008时刚新上的,服务器配置如下:

     

    硬件

    主机型号:Dell R910

       CPU : 46 Intel(R) Xeon(R) CPU E7540  2.00GHZ

    内存:64GB

    存储:Equallogic ps 6000,一个柜子,14块盘满,2块做hot spare,其余12块做成RAID1+0

    软件:

      OS : windows 2003 64位中文企业版+sp2

      DBMS: ms sql server 2008 64位中文企业版+sp2

     

     

    系统在正常运行时压力极小,服务器各项资源使用指标都很低,服务器硬件在性能上完全没有压力。

     

     

    MS Sql server 2008实例配置如下:

         Ms sql server 2008登录windows的帐号具有 lock page in memory权限

      Sql实例勾选了AWE选项

      分配给sql server的内存范围为15GB~58GB.

      Tempdb分配了300GB空间,存在一个单独的逻辑分区,包含24个文件,各文件的Size相同。基本是用户数据库size2倍。

     

     

    故障现场看到的现象及问题定位:

       在接到监控电话后,登录到服务器并用SSMS连接上了实例,使用sp_who2查看连接,

    发现来自所有web server的连接状态均为suspend,第一反应:存储出现了故障。

    于是查看windows错误日志,发现大量如下错误信息:

    The initiator could not send an iSCSI PDU.Error status is given in the dump data.

    并且在查看sql server错误日志后发现如下错误:

    The log for database XXXX is not available. Check the event log for related error messages. Resolve any errors and restart the database.

    看到此错误信息,可以基本断定问题就是出在存储上。

     

    但正当我准备登录存储的管理界面时,领导电话来了,讯问问题的情况,我如实做了回答。

    领导要求尽快解决故障,恢复业务。我们对此数据库做了镜像,但是这个数据库还扮演了发布的角色,如果此时就切换到镜像,后面将会有由此造成大量后续工作(后面其实还是被迫切换到了镜像,因此也由此造成后面我们花了2天才完成所有的善后工作)。

     

    采取的措施:

    在征得领导的同意后,决定重起服务器,希望借此可以解决故障。但是当重起后,我们才发现,服务器在我下了重起命令后5分钟后,依然可以ping到,这就意味着服务器并没有真正重起,或者说重起被卡住了。于是决定通过远程管理口重起,这会倒是在重起后ping不到了服务器,但是在重新可以ping通服务器后,我们发现不能通过远程桌面连接服务器,因此也就没有办法确认服务器的状况,但是有一点可以肯定,sql 服务不能连上了,也就是sql server服务没有起来,情况到了这个地步,不切镜像是不可能的了。 2235,使用

    Alter database set partner force_allow_data_loss强行切换了镜像,数据库在上述命令下达20秒后,状态变为可用,与是通知web服务器管理员切换DNS DNS切换1分钟后,故障解除,业务恢复。

     

     

    故障之后我总结了几点:

    1,  在没有通过存储管理界面查看存储本身给出的日志后就贸然重起服务器,实际上对问题的处理显得过于仓促与武断。正确的做法也许是,如果判定是存储的问题,应该是需要先解决存储的问题,再决定是否可以重起服务器。事后调查的原因(稍后我再向大家说明)表明,也许直接把服务器关机,然后再把存储关机,然后再开启存储,然后再启动服务器,故障也许就解决了,因为后面通过这种方式就成功启动了服务器;

    2,  在发现第一次重起服务器5分钟后依然可以ping通的时候,应该果断切换到镜像数据库,这样可以大大减少业务停机时间,算下来只需要10分钟就可以恢复业务。

    3,  是不是有比用Alter database set partner force_allow_data_loss强行切换镜像更好的启用镜像的方法。

     

     

     

    事故原因(dell给出的):

        由于ps6000的一个控制器的风扇出现3秒停转,导至该控制器失去功能,而且进一步导致存储的OS挂死,不能failover到另外一个控制器,也就是我们用2个控制器作成的HA在这个事故中并没有起到作用,在一个控制器出现故障后,另一个控制并没有接管工作,由此导致此次的事故。

      


    phil_he
    2011年2月17日 4:03

全部回复

  •    既然oracle的大牛DBA们可以组织人手编写一本专门讲述故障处理的书籍,那么做MS SQL server的大牛们是不是也可以这样做呢.
    phil_he
    2011年2月17日 4:06
  • You started it.
    2011年2月17日 4:13
  • 可惜我不是牛人呀
    phil_he
    2011年2月17日 4:17
  • 你好,

    欢迎共享你的解决方案!

    谢谢,
    邱爱华


    Ai-hua Qiu[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    2011年2月17日 8:23
  • 徐海蔚写了一本书,对故障处理有些介绍.

    另外,mirror是可以和replication共存的,你仔细看看文档。


    想不想时已是想,不如不想都不想。
    2011年2月17日 12:58
    版主
  •   是的,mirror是可以和replication共存的,但如果在主体出现故障后,被迫切换到镜像,这时候replication还能正常工作吗? 我们之前做过实验,表明在主体不能正常工作的情况下,即便是切换到了镜像,replication是会被挂住不能正常工作的,必须等主题起来并正常运行后才能开始replication.  在正常情况下,通过手动切换镜像,replication可以正常切换到新的主体上,但是出现

    主体故障后再被迫切换到镜像,似乎replication不能正常工作. 是否我们的测试结果或是方法不对呢.


    phil_he
    2011年2月18日 4:32
  •   是的,mirror是可以和replication共存的,但如果在主体出现故障后,被迫切换到镜像,这时候replication还能正常工作吗? 我们之前做过实验,表明在主体不能正常工作的情况下,即便是切换到了镜像,replication是会被挂住不能正常工作的,必须等主题起来并正常运行后才能开始replication.  在正常情况下,通过手动切换镜像,replication可以正常切换到新的主体上,但是出现

    主体故障后再被迫切换到镜像,似乎replication不能正常工作. 是否我们的测试结果或是方法不对呢.


    phil_he

    mirror+replicaiton是可以正常工作的,即使切换后(需要设置failoverpartner)

    但如果担当镜像的服务器出现故障,replicaiton就无法正常工作了。 因为在镜像+replicaiton的场景下,principal的日志会首先传送到mirror端,然后由mirror端传到distirbutor....这是默认的情况,可以通过其他的设置进行更改,不过可能会导致lsn不一致的问题,详见:

    http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/replicationanddbm.docx

     

     


     

    有dba的职位吗(北京的),请联系我 stswordman#hotmail.com

    2011年2月18日 16:00
    版主
  • 谢谢stswordman,看来我们的实验结果是正确的,因为在老的principal出现故障后,通过手工切换镜像后,老的principal就变成了mirror,而老的mirror就变成了principal,这正好应对上了stswordman说的现象.


    phil_he
    2011年2月18日 23:44
  • 非常支持写书的想法, 多多交流
    2011年3月1日 5:47
  • 徐海蔚写了一本书,对故障处理有些介绍.

    另外,mirror是可以和replication共存的,你仔细看看文档。


    想不想时已是想,不如不想都不想。


    《Microsoft SQL Server企业级平台管理实践》,ISBN:9787121102448

    2011年3月1日 8:30