SQL Server 2012 新一代的高可用技术AlwaysOn 之四 AlwaysOn的可用性模式

可用性模式是每个可用性副本的一个属性。可用性模式决定了主副本在提交事务之前是否需要等待某个辅助副本将事务日志记录固化到磁盘。AlwaysOn可用性组支持两种可用性模式：“异步提交模式”和“同步提交模式”。如果你曾经使用过数据库镜像，你会发现可用性模式的概念和镜像的概念（异步操作模式和同步操作模式）非常相似。

异步提交模式

使用此可用性模式的可用性副本称为“异步提交副本”。当辅助副本处于异步提交模式下时，主副本无需确认该辅助副本已经完成日志固化，就可以提交事务。因此，主数据库事务提交不会受到辅助数据库的影响而产生等待。但是，辅助数据库的更新可能会滞后于主数据库，如果发生故障转移，可能会导致某些数据丢失。如果为当前主副本配置了异步提交可用性模式，则它将通过异步方式为所有辅助副本提交事务，而不管这些副本各自的可用性模式设置如何。

对于主副本和辅助副本相隔很远而且您不希望小错误影响主副本性能的灾难恢复方案，异步提交模式将会很有用。而且，由于主副本不会等待来自辅助副本的确认，因而辅助副本上的问题从不会影响主副本。

在异步提交模式下，辅助副本会尽量与自主副本的日志记录保持一致。不过，即使辅助数据库和主数据库上的数据事实上是同步的，可用性组也始终认为辅助数据库处于“SYNCHRONIZING”状态（即“未同步”状态），因为理论上在异步模式下，辅助数据库在任何时点都可能会落后。

同步提交模式

使用此可用性模式的可用性副本称为“同步提交副本”。在同步提交模式下，主数据库在提交事务之前，主副本要等待同步提交辅助副本确认它已将日志固化到磁盘上。只要辅助副本还没有告诉主副本日志固化完成，主副本上的事务就不能提交。这样就保证两边的数据始终是同步的。只要一直在进行数据同步，辅助数据库就会保持“已同步”(SYNCHRONIZED)的状态。

同步提交模式能够保障给定的辅助数据库与主数据库上的数据保持完全的同步。但是这种保障的代价是主数据库上的事务提交会有滞后时间。可以说，同步提交模式相对于性能而言更强调高可用性。

为了优化AlwaysOn可用组在同步提交模式下的性能，SQLServer在AlwaysOn的工作线程和消息传递上动了很多脑筋。首先来看看，在辅助副本联接可用性组并与主副本建立会话之后，两者是如何同步日志的。

步骤	行为
1.连接	辅助副本通过主副本的镜像端点建立两者之间的连接
2.请求数据	辅助副本发出一个请求到主副本，要求主副本发送日志块。辅助副本和主副本会协商出一个日志块的LSN初始位置以及一些其他的信息。
3.运行Log Scanner	在主副本上，log Scanner的工作线程开始工作。Log Scanner负责将日志块传送到辅助副本。
4. 固化和重做日志	辅助副本会使用固化(harden)线程和重做(redo)线程的工作线程来处理Log Scanner发送过来的日志块，固化线程将日志块固化到辅助副本的磁盘上，而重做线程负责将日志中记录的事务在辅助副本上重新演绎。
5.反馈进度	每当辅助副本收到3条来自主副本的消息的时候，就把固化和重做的进度作为一个消息返回给主副本。如果超过1秒钟还没收到3条消息的话，进度消息也会被返回。反馈到主副本的消息里包含了哪些LSN已经在辅助副本上被重做和固化。

 

通过上述的过程，最终辅助数据库上已经固化的日志会赶上主数据库的日志末尾。此时辅助数据库的状态就会设置为SYNCHRONIZED。这个同步阶段所需的时间主要取决于会话开始时辅助数据库滞后于主数据库的程度。另外，你需要明确重做线程和固化线程的区别，这点对理解事务提交的工作机制很重要。固化线程是将日志写入到日志文件，而重做线程是负责将日志中包含的数据更新真是的反映到数据文件上，这两个线程在AlwaysOn中是完全独立工作的。

接下里来看看在主副本上提交一个事务会发生些什么。

步骤	行为
1. 提交事务	在主副本上运行COMMIT TRAN命令来提交事务。
2. 写入到本地日志记录	在主副本上，COMMIT TRAN命令会被写成一条日志记录（此时记录还在主数据库的日志缓存中）。然后主副本上的log writer工作线程会把直到COMMIT命令为止的所有日志记录组成一个日志块从缓存写入到磁盘上的LDF文件中去。当日志被写入到磁盘之后，主数据库就开始等待来自辅助副本的消息来确认日志在辅助数据库上被成功写入磁盘。在这之前，该事务提交操作会保持等待。
3. 扫描日志	当日志块开始被从缓存写入到磁盘上时，它也会发信号给Log Scanner工作线程，告诉Log Scanner“日志已经准备好了，可以被发送到辅助副本上去了”。 Log  Scanner从缓存中取出日志块，把它发送给AlwaysOn的日志块解码器(Log Block Cracker)。解码器会搜索日志中那些需要特别处理的操作，比如file stream操作，文件增长等。解码器会把这些操作作为一个消息发送给辅助副本。一旦日志块被解码完毕，整个日志块也会被作为消息发送给辅助副本。
4. 处理日志块消息	日志块消息在辅助副本上得到处理。固化线程负责将日志固化到磁盘上。然后日志被保存到辅助数据库的日志缓存中，重做线程从缓存中获得日志块并开始执行重做操作。
5. 反馈进度	每当辅助副本收到3条来自主副本的消息的时候，就把固化和重做的进度作为一个消息返回给主副本。如果超过1秒钟还没收到3条消息的话，进度消息也会被返回。进度信息中包含当前哪些LSN被固化了，哪些LSN已经被重做了。由于重做线程晚于固化操作启动，被固化的LSN可能会多于被重做的LSN。
6. 完成提交	主数据库受到了辅助副本来的确认消息，完成事务提交处理并向客户端发送一条确认消息。

 

在同步提交模式下，日志块必须在主副本和辅助副本上都被固化到磁盘上，事务才能真正在主数据上提交。但是它并不要求日志在辅助副本上完成重做，这样可以减轻对主副本的性能影响。

另外，AlwaysOn会定期检查各个副本，以及副本上的各个数据库的健康情况。如果某个副本不能正常通信，那这个主副本和辅助副本间的连接进入DISCONNECTED状态。如果某个数据库不能正常进行数据同步，则这个数据库会进入“NOTSYNCHRONIZING”状态。

可用性副本之间的“DISCONNECTED”连接状态

AlwaysOn 可用性组有一个会话超时机制。所有的主副本和辅助副本之间，会按固定间隔互相发送ping。在会话超时期限内，如果收到ping命令，就说明副本之间的连接正常。收到ping 后，副本将重置此连接上的超时计数器。主副本和辅助副本之间就通过ping来判断彼此是否依旧处于活动状态。

一旦某个副本因为网络故障、操作系统、SQLServer宕机等原因失去响应，它将不能按时把ping命令发给它的伙伴。如果主副本和某个辅助副本间的会话发生超时（没有收到辅助副本的ping），主副本和这个辅助副本之间的连接就会进入DISCONNECTED状态。进入DISCONNECTED状态后，即使可用性副本处于同步提交模式，事务也不需要等待该副本的响应就可以在主副本上提交。

会话超时限制是一个可用性组级别的设置，你可以通过在SQLServer Management  Studio中打开可用组的属性来修改它的值，默认值为10 秒，允许的最小值为5秒。通常建议你将超时期限设置为10 秒或更长。因为如果低于10 秒，可能会使那些非常繁忙的系统错误地进入DISCONNECTED状态。

辅助数据库的“NOT SYNCHRONIZING”状态

无论使用什么可用性模式，如果一个事务在辅助数据库上重做失败，就会导致辅助数据库进入“NOTSYNCHRONIZING”状态。和DISCONNECTED状态类似，此时即使可用性副本设置为同步提交模式，事务也可以在主副本上之间直接提交而无需等待辅助副本响应。

如果你想中断某个数据库的数据同步，而不想影响可用性组中的其它数据库，可以通过在ManagementStudio中选择Suspenddata movement来手动挂起（图3-5）。挂起之后，该数据库在各个可用性副本（无论是什么可用性模式）上的状态都会变成“NOTSYNCHRONIZING”。

                             

图3-5挂起可用性数据库

本节的最后，要提一下可用性模式对事物复制的影响。如果你把主数据库作为复制的发布数据库，事务复制的LogReader代理程序不会去处理那些尚未在辅助副本上固化的日志。因此，一旦辅助副本和主副本断开连接，那么复制就会停止工作。只有当辅助副本恢复和主副本的对话后，复制才能继续。此时主副本的日志可能会由于复制停止工作而变的很大。这种设计的主要目的是确保复制的数据发送速度，要慢于AlwaysOn的发送速度。因为辅助副本可能会通过故障转移成为新的主副本，从而变成新的发布服务器。如果复制跑得比AlwaysOn快，可能会发生订阅服务器比发布服务器数据更加新的情况。