SQLSERVER 2012之AlwaysOn -- 一次硬件升级引发的问题

原文:SQLSERVER 2012之AlwaysOn -- 一次硬件升级引发的问题

这是上周遇到的一个案例:对已有的硬件进行升级而引发的问题,期间还触发了一个比较严重的BUG,可谓多灾多难;不过值得庆幸的是,在一连串连锁问题出现的时候,并没有出现人工操作失误(这往往是在处理故障中风险最高、影响最大的问题)而扩大故障影响范围;

 

==========================华丽丽的分割线==========================

    先说一下环境:

    我做的是跨机房3节点alwayson:

    部署方面:3个节点中,两个位于主机房,同步模式,另外一个位于异地机房,跨子网异步模式;

    软件方面:windows 2012+SQLSERVER 2012 SP2+CU3;

    硬件方面:由于该系统上线时间较早,除了本地硬盘(RAID 10)用于存放必要的安装程序包外,每个节点各配置了一块IO卡用于存放数据、日志文件以及备份

 

    此前该系统在使用时,应用侧经常出现提交事务抖动(本地机房两节点同步),改为异步模式后应用侧性能表现良好;我们知道,在同步模式下,由于应用端需要等待在同步secondary节点完成日志固化(harden)后才能收到提交或回滚信息,因此两节点间的网络环境,以及磁盘IO能力就成为上述影响的关键;

    而在此之前,我们已经对网络进行了优化(详见:《SQLServer 2012之AlwaysOn —— 指定数据同步链路,消除网络抖动导致的提交延迟问题》),因此可以排除网络影响;另外,我们通过对磁盘IO性能的监控(尤其是checkpoint时的影响),最终定位到磁盘IO确实存在压力,最后决定更换IO卡;

    在申请设备的时候,我们发现,由于此前的IO卡为第一代产品,与目前最新采购的第三代产品有兼容性问题(无法同时安装),因此需要先将secondary节点从alwayson环境中踢出,重新安装后重新初始化数据,并添加回alwayson环境;这一步按照标准步骤执行,十分顺利;

    其次,我们准备切换AG到已更新硬件的节点(此处我们叫他Node_B),结果发现切换过程很顺利(手动故障转移),但切换后不能进行备份(由于后续需要将另外一个节点进行同样的更新硬件操作,不能备份就意味着在重新加回alwayson环境时,不能初始化数据),随即又将服务切回Node_A上(最初的master节点);

    随后,我们检查了Node_B的errorlog,发现其中出现如下错误信息:

Information 29-Apr-2014 3:17:24 PM MSSQL$PRD 9012 Server There have been 25958400 misaligned log IOs which required falling back to synchronous IO. The current IO is on file W:\MOUNTLOG\PRDLOG\PRDLOG1.ldf. 
Information 29-Apr-2014 3:17:17 PM MSSQL$PRD 9012 Server There have been 25958144 misaligned log IOs which required falling back to synchronous IO. The current IO is on file W:\MOUNTLOG\PRDLOG\PRDLOG1.ldf.

    其实从Node_B更换完硬件,并添加回alwayson环境后,就一直再报类似的错误,只是切换比较顺利,我们都忽略了检查errorlog这一关键的步骤;

    继续来说上面的错误信息,misaligned是个针对于IO方向的报警,具体的原理可以参考以下文章

http://blogs.msdn.com/b/saponsqlserver/archive/2014/10/02/message-misaligned-log-ios-which-required-falling-back-to-synchronous-io-in-sql-server-error-log.aspx

    而导致misaligned的原因,是由于两个节点的IO卡,其物理扇区大小不一致(Node_A为512,Node_B为4096;此处的物理扇区是存储设备底层设置的,与操作系统中format 4K~64K不是一个概念,操作系统格式化的定义是分配单元大小,或称之为簇)。上述链接中对9012错误进行了详细的分析,再此不再赘述;

    另一方面,是由于misaligned而导致了切换节点后无法进行备份么?第二天,我又搭了一套类似的环境进行测试,但问题没有重现;于是我们准备用另一套方案进行升级:

    既然由于AG中两个节点的物理扇区大小不等导致misaligned,我们准备先在现有AG中再增加一个物理扇区大小为4096的节点(Node_C),然后再切换AG到Node_B后,踢掉Node_A。这样AG中有两个同步关系的节点(Node_A、Node_C,且物理扇区大小均为4096),或许可以实现备份。

 

==========================华丽丽的分割线==========================

    按照上述方案,我们又安排了一次停机。但这次在切换服务并踢掉Node_A后,不但备份问题没有解决,连AG组也变成正在解析的情况

技术分享

 

 

 

    从下图中,AG组中只能识别到当前节点;

技术分享

   

 

 

 

 

 

 

    但Node_B仍可以正常的访问(读写正常,listener IP也可以正常使用),而Node_C则无法访问;这种状态极为不合理;

    此外,在errorlog中,发现大量remote harden of transaction的报错

技术分享

   

 

 

 

 

 

 

      执行备份(spid=509)被checkpoint进程阻塞(spid=23),又被DB STARTUP进程阻塞(spid=35)技术分享

 

 

 

技术分享

 

 

 

 

 

 

 

技术分享

 

 

 

 

 

 

 

技术分享

 

 

 

 

 

 

 

    根据微软工程的分析“这是最近刚刚发现的一个SQL 的bug,只发生在SP2 CU3和CU4上面。即便不做BACKUP,也会发生这样的阻塞。”

    这可能是由于SQL Server内部发生了死锁,建议尽快再所有节点上安装以下这个补丁。

    http://support.microsoft.com/en-us/kb/3033492

    http://support.microsoft.com/en-us/kb/3034679

    您可以单独安装hotfix,或者安装SQL 2012 SP2CU5,我们建议您对于所有打过SP2 CU3(5556)和CU4(5569)并且配有AlwaysOn的环境,都尽快打上CU5

    http://support.microsoft.com/en-us/kb/3037255/en-us

 

    但目前的情况是需要先保证alwayson恢复正常,于是我们准备通过停机复制数据文件的方式将数据库迁移到其他alwayson环境下;但在停止sqlserver服务的时候hang住

技术分享

 

 

 

 

 

 

 

    无奈,只能重启服务器。但神奇的是,重启大法在这里居然是最完美的解决方案。重启后,各种服务均恢复正常;

技术分享

 

 

 

 

 

 

 

总结:这个案例比较特殊,在切换过程中遇到了另一个BUG,但好在BUG中出现的内部进程的死锁通过重启得到了释放。另外,对于第一部分提到的misaligned的问题,最好在安装硬件后,先检查一下物理扇区的大小是否一致,以免出现性能问题;

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。