这是上周遇到的一个案例：对已有的硬件进行升级而引发的问题，期间还触发了一个比较严重的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的问题，最好在安装硬件后，先检查一下物理扇区的大小是否一致，以免出现性能问题；