disconnected

SQLServerAlwaysOn可用性及故障转移

2014-03-2701:55:04

标签：高可用数据库日志记录

原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明。

否则将追究法律责任。/382644/1384835

SQLServerAlwaysOn可用性及故障转移

杜飞

在AlwaysOn可用性组中，“可用性模式”是一个副本属性，该属性确定某一给定可用性

副本是否可在同步提交模式下运行。AlwaysOn的可用性模式决定了各副本之间是否允许存

在数据差异，SQLServer2012的可用性组使用异步提交模式和同步提交模式来决定主副本在

提交事务之前是否等待辅助副本将事务日志记录固化到磁盘。如果主副本配置为“异步提交

模式”，则它不会等待任何辅助副本将传入的事务日志记录写入磁盘（以便“强制写入日志”）。

如果某一给定的辅助副本配置为异步提交模式，则主副本不会等待该辅助副本强制写入日志。

如果主副本和某一给定辅助副本都配置为“同步提交模式”，则主副本将等待辅助副本，以

便确认它已强制写入日志（除非辅助副本在主副本的“会话超时期限”内未能使用ping命

令联系上主副本）。

同步提交模式

在同步提交模式下，主数据库在提交事务之前，主副本要等待同步提交辅助副本确认它已

将日志固化到磁盘上。只要辅助副本还没有告诉主副本日志固化完成，主副本上的事务就不

能提交。这样就保证两边的数据始终是同步的。只要一直在进行数据同步，辅助数据库就会

保持“已同步”(SYNCHRONIZED)的状态。同步提交模式能够保证给定的辅助数据库与主数据

库上的数据保持完全的同步。但是代价是主数据库上的事务提交会有滞后时间。可以说，同

步提交模式相对于性能而言更强调高可用性。

辅助副本的同步工作原理：

在同步提交模式下，在辅助副本联接可用性组并与主副本建立会话之后，辅助副本会将传

入日志记录写入到磁盘（“固化日志”）并向主副本发送确认消息。一旦辅助数据库上已经

硬化的日志赶上主数据库的日志末尾，辅助数据库的状态就会设置为SYNCHRONIZED。同

步所需的时间实质上取决于会话开始时辅助数据库滞后于主数据库的程度（按最初从主副本

收到的日志记录数计量）、主数据库的工作负荷和承载辅助副本的服务器实例的计算机的速

度。在同步给定辅助副本上的每个辅助数据库之后，辅助副本的同步运行状态总体上将为

HEALTHY。

同步操作按下列方式维护：

1.一旦从客户端收到事务时，主副本会将事务的日志写入事务日志，同时将该日志记录发

送到辅助副本。

2.一旦将日志记录写入主数据库的事务日志，只有此时故障转移到未收到该日志的辅助副

本，才能撤销该事务。主副本将等待来自同步提交辅助副本的确认。

3.辅助副本将硬化日志，并将确认消息返回给主副本。

4.收到来自辅助副本的确认后，主副本将完成提交处理并向客户端发送一条确认消息。

如果同步提交辅助副本未能确认其已固化日志，即超时，则主副本会将该辅助副本标记为

失败。辅助副本的连接状态更改为DISCONNECTED，主副本停止等待辅助副本的确认。此

行为确保失败的同步提交辅助副本不会阻止在主副本上固化事务日志。

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

AlwaysOn可用性组有一个会话超时机制。所有的主副本和辅助副本之间，会按固定间隔

互相发送ping。在会话超时期限内，如果收到ping命令，就说明副本之间的连接正常。收

到ping后，副本将重置此连接上的超时计数器。主副本和辅助副本之间就通过ping来判断

彼此是否依旧处于活动状态。

一旦某个副本因为网络故障、操作系统、SQLServer宕机等原因失去响应，它将不能按时

把ping命令发给它的伙伴。如果主副本和某个辅助副本间的会话发生超时（没有收到辅助

副本的ping），主副本和这个辅助副本之间的连接就会进入DISCONNECTED状态。进入

DISCONNECTED状态后，即使可用性副本处于同步提交模式，事务也不需要等待该副本的响

应就可以在主副本上提交。

会话超时限制是一个可用性组级别的设置，你可以通过在SQLServerManagementStudio

中打开可用组的属性来修改它的值，默认值为10秒，允许的最小值为5秒。通常建议你将

超时期限设置为10秒或更长。因为如果低于10秒，可能会使那些非常繁忙的系统错误地

进入DISCONNECTED状态。

辅助数据库的“NOTSYNCHRONIZING”状态：

无论使用什么可用性模式，如果一个事务在辅助数据库上重做失败，就会导致辅助数据库

进入“NOTSYNCHRONIZING”状态。和DISCONNECTED状态类似，此时即使可用性副本设置

为同步提交模式，事务也可以在主副本上之间直接提交而无需等待辅助副本响应。

如果你想中断某个数据库的数据同步，而不想影响可用性

组中的其它数据库，可以通过在SSMS中选择Suspenddatamovement来手动挂起挂起之后，

该数据库在各个可用性副本（无论是什么可用性模式）上的状态都会变成

“NOTSYNCHRONIZING”。

异步提交模式

在“异步提交模式”下，辅助副本永远不会与主副本同步。虽然给定的辅助数据库可能

会与对应的主数据库保持一致，但任何辅助数据库在任何时点都会落后。对于主副本和辅

助副本相隔很远而且您不希望小错误影响主副本的灾难恢复方案的情况，或性能比同步数据

保护更重要的情况，异步提交模式将会很有用。而且，由于主副本不会等待来自辅助副本

的确认，因而辅助副本上的问题从不会影响主副本。

异步提交辅助副本会尝试与接收自主副本的日志记录保持一致。但异步提交辅助数据库

往往会保持未同步状态，并且可能稍微滞后于相应的主数据库。通常，异步提交辅助数据

库和相应的主数据库之间的这个时间差会很小。但是，如果承载辅助副本的服务器的工作

负荷过高或网络速度很慢，则这个时间差会变得较大。

对于主副本和辅助副本相隔很远而不希望小错误影响主副本性能的灾难恢复方案，则可以

考虑使用异步提交模式。而且，由于主副本不会等待来自辅助副本的确认，因而辅助副本上

的问题从不会影响主副本。

AlwaysOn故障转移

部署AlwaysOn可用性组需要一个WindowsServer故障转移群集(WSFC)。若要启用

AlwaysOn可用性组，一个SQLServer实例必须驻留在某一WSFC节点上，并且该WSFC群

集和节点必须处于联机状态。此外，给定可用性组的每个可用性副本必须位于相同WSFC

群集的不同节点上。和SQLServer群集类似的，AlwaysOn可用性组也需要一个群集

resourceDLL来连接Windows群集和SQLServer实例。由于可用性组是一个群集资源，Windows

群集需要使用AlwaysOn的resourceDLL来控制资源的上线/离线，检查资源是否失败，更改

资源的状态和属性，以及发生各种命令给可用性副本实例。用户可以通过过故障转移群集管

理器查看可用性组资源的各种属性。

AlwaysOn可用性组的资源类型是“SQLServerAvailabilityGroup”，该资源类型使用的

resourceDLL的叫做，在中定义了如何对AlwaysOn可用性组进行Isalive

检查的方法。和SQLServer群集的resourceDLL（）一样，也是由群集

的进程加载的。由于AlwaysOn可用性组使用的是非Windows群集自带的资源类型

和resourceDLL，默认情况下Windows群集单独产生一个来专门加载。这

样即使该由于异常而崩溃，整个群集的其他资源也不会受到影响。

Always使用sp_rver_diagnostics来检查可用性组的健康状况。会建立并保持

一个连接到SQLServer，并通过这个连接运行sp_rver_diagnostics，然后不断的获得诊断信

息。sp_rver_diagnostics的评估结果会被用来和AlwaysOn可用组的FailureConditionLevel

设置向比较，来约定是够符合发生故障转移的条件。一旦条件满足，则可用性组就被切换到

新的可用性副本上。

有几点需要注意的是：

1.可用性组也是一种群集资源，但是它的HealthCheckTimeout属性默认是30000毫秒，

而不像群集资源那样是60000毫秒。所以可用性组的获取诊断信息并记录到扩展事件日志的

频率更高。

2.无论你在一个实例上配置多少个可用性组，该实例上只会运行一条

sp_rver_diagnostics语句来诊断所有的可用性组。如果每个可用性组的HealthCheckTimeout

设置不同，会挑选最小的那个值并除以3来作为sp_revr_diagnostics返回诊断信

息的间隔（max(5,min(HealthCheckTimeout/3))）。这个最小的HealthCheckTimeout值被称为

“有效HealthCheckTimeout”。

_rver_diagnostics只是检测实例的健康状态，而不是检测每个数据库的状态。所以如

果当前SQLServer实例还能正常工作，但可用性组所包含的数据库发生诸如数据文件损坏、

置疑等问题而不能被正常使用，sp_rver_diagnostics是无法发现问题的。就算你为当前的

可用性副本配置了自动故障转移，这种情况下也是不会触发故障转移的。

AlwaysOn发现故障之后，是否会立刻触发故障转移呢？这取决于可用性副本的可用性模

式和故障转移模式。根据副本间数据同步的模式，可用性模式有两种：同步提交和异步提交。

根据故障转移的方式，可用性副本也有两种故障转移模式：自动故障转移和手动故障转移。

自动故障转移模式只有当副本的可用性模式为“同步提交”时才可以选择。可用性模式和故

障转移模式的组合形成了可用组的三种故障转移形式：自动故障转移、计划的手动故障转移

（通称为“手动故障转移）、强制手动故障转移（通称为“强制故障转移”）。

如果发生故障，是否会立刻触发故障转移需要取决于可用性副本的可用性模式和故障转移

模式。如前所述，副本间数据同步模式有同步提交和异步提交两种。而可用性副本之间的转

移模式分为自动故障转移和手动故障转移两种。当副本的可用性模式为同步提交时才可以使

用自动故障转移模式。也就是说主副本和故障转移目标共同决定了故障转移模式，即如果二

者都配置为同步提交模式和自动故障转移模式则能发生自动故障转移；若两者中的一个配置

了手动故障转移，则只支持计划的手动故障转移；二者中的一个配置了异步提交模式，则只

能发生强制故障转移。其中只有强制故障转移可能会丢失数据。自动和手动故障转移会保证

数据的安全。

下图显示的是具有五个可用性副本的可用性组。主副本和一个辅助副本配置为使用同步

提交模式以及自动故障转移。另一个辅助副本配置为使用同步提交模式且仅限计划的手动

故障转移，两个辅助副本配置为使用异步提交模式，其仅支持强制手动故障转移（一般称为

“强制故障转移”）。

两个可用性副本之间的同步和故障转移行为取决于这两个副本的可用性模式。例如，对

于要发生的同步提交，涉及的当前主副本和辅助副本必须配置为同步提交。同样，对于要

发生的自动故障转移，需要将这两个副本配置为自动故障转移。因此，上述部署方案的行

为可用下表概括，它揭示了每个潜在主副本的行为：

通常，节点04在灾难恢复站点中作为异步提交副本部署。事实上，由于两个节点之间

的高网络延迟，在故障转移到节点04后节点01、02和03仍处于异步提交模式，这帮

助防止潜在的性能下降。

自动故障转移

在主副本变得不可用之后，自动故障转移将导致合格的辅助副本自动转换为主角色。当

承载主副本的WSFC节点对于承载辅助副本的节点而言为本地节点时，自动故障转移最适

合。这是因为数据同步最适合于计算机之间的低消息延迟时间情况以及因为客户端连接可

以保持为本地。

仅在以下条件下才发生自动故障转移：

?存在自动故障转移集。此自动故障转移集由主副本和辅助副本（“自动故障转移目标”）

构成，主副本和辅助副本都配置为同步提交模式并且设置为自动故障转移。如果主副本设

置为手动故障转移，则自动故障切换将无法发生，即使某一辅助副本设置为自动故障转移时

也是如此。

?自动故障转移目标具有正常运行的同步状态（这指示故障转移目标上的每个辅助数据库都

与其相应的主数据库同步）。

?WindowsServer故障转移群集(WSFC)群集具有仲裁。

?主副本已变得不可用，并且由灵活的故障转移策略定义的故障转移条件级别已得到满

足。

自动故障转移的原理，自动故障转移将启动以下操作序列：

1.如果承载当前主副本的服务器实例仍在运行，则它会将主数据库的状态更改为“已断开

连接”并断开所有客户端的连接。

2.如果在目标辅助副本上有任何日志记录正在恢复队列中处于等待状态，则辅助副本会应

用剩下的日志记录，以完成对辅助数据库的前滚操作。

3.先前的辅助副本转换到主角色。其数据库成为主数据库。新的主副本将尽快回滚任何

未提交的事务（恢复的撤消阶段）。锁定会分离这些未提交的事务，允许当客户端使用数据

库时在后台进行回滚。此过程不会回滚任何已提交的事务。

直到连接给定的辅助数据库后，才将其简要标记为NOT_SYNCHRONIZED。在回滚恢复开始

前，辅助数据库可以连接到新的主数据库并快速转换为同步状态。最佳事例是通常用于第

三个同步提交的副本，该副本在故障转移之后仍然为辅助角色。

4.然后，当承载先前主副本的服务器实例重新启动时，它将识别出其他可用性副本现在拥

有主角色。以前的主副本将转换为辅助角色，并且其数据库将成为辅助数据库。新的辅

助副本连接到当前主副本，并尽快将其数据库更新为当前主数据库。只要新的辅助副本重

新同步了其数据库，就可以再次执行故障转移，但按反向执行。

计划的手动故障转移（无数据丢失）

在数据库管理员针对承载目标辅助副本的服务器实例发出手动故障转移命令后，手动故障

转移将导致已同步的辅助副本转换为主角色。为了支持手动故障转移，辅助副本和当前主

副本必须同时配置为同步提交模式（如果有）。可用性副本上的每个辅助数据库都必须加入

到可用性组中，并与其对应的主数据库同步（也即，必须同步辅助副本）。这可确保对先前

主数据库提交的每个事务也对新的主数据库提交。因此，新的主数据库与旧的主数据库完

全相同。

下图说明计划的故障转移的各个阶段：

1.在故障转移之前，主副本位于Node01的服务器实例上。

2.数据库管理员启动计划的故障转移。故障转移目标为位于Node02的服务器实例上的

可用性副本。

3.故障转移目标（位于Node02上）将成为新的主副本。因为这是计划的故障转移，以

前的主副本在故障转移期间切换为辅助角色，并且使其数据库立即联机作为辅助数据库。

手动故障转移所需条件

为了支持手动故障转移，当前主副本必须设置为同步提交模式，而辅助副本必须：

配置为同步提交模式。

当前已与主副本同步。

若要手动对可用性组执行故障转移，您必须连接到将成为新的主副本的辅助副本。

计划的手动故障转移的工作方式

计划的手动故障转移（必须在目标辅助副本上启动）将启动以下操作序列：

1.为了确保在原始主数据库上不发生任何新的用户事务，WSFC群集向主副本发送要

求脱机的请求。

2.如果任何辅助数据库的恢复队列中有任何日志处于等待状态，则辅助副本将完成对

辅助数据库进行前滚的操作。所需时间取决于系统速度、最新工作负荷以及恢复队

列中的日志量。若要了解恢复队列的当前大小，请使用数据库镜像性能对象中

的RecoveryQueue性能计数器。

注意

可通过限制恢复队列的大小调整故障转移时间。不过，这会导致主副本的速度下降，以允

许辅助副本与其同步。

3.辅助副本成为新的主副本，先前的主副本成为新的辅助副本。

4.新的主副本回滚所有未提交的事务，并使其数据库作为主数据库联机。所有辅助数

据库都被简要地标记为NOTSYNCHRONIZED，直至它们连接到新的主数据库并重新

进行同步为止。此过程不会回滚任何已提交的事务。

5.当以前的主副本重新联机后，它将承担辅助角色，而以前的主数据库将成为辅助数

据库。新的辅助副本快速将新的辅助数据库与对应的主数据库重新同步。

注意

只要新的辅助副本重新同步了数据库，就可以再次执行故障转移，但按反向执行。

强制故障转移（可能丢失数据）

对可用性组强制进行故障转移（可能丢失数据）是一种灾难恢复方法，使您能够将辅助副

本用作温备用服务器。因为强制故障转移存在数据丢失的风险，所以应该谨慎使用。建

议仅当您必须立即将服务还原到可用性数据库并愿意承担数据丢失的风险时，才执行强制故

障转移。

强制故障转移的原理：

强制故障转移会启动一个将主角色转换为角色处于辅助或正在解析状态的目标副本的过

程。故障转移目标成为新的主副本，并立即将其数据库副本提供给客户端。当以前的主

副本变得可用时，它将转换为辅助角色，并且其数据库将成为辅助数据库。

所有辅助数据库（包括现在变得可用的以前的主数据库）将挂起。根据挂起的辅助数据

库以前的数据同步状态，它可能适合于补救该主数据库的未能提交的数据。在配置为只读

访问的辅助副本上，您可以查询辅助数据库以手动发现丢失的数据。然后，您可以对新的

主数据库发出Transact-SQL语句来进行必要的更改。

强制故障转移的风险：

一定要注意，强制故障转移可能会造成数据丢失。这是因为目标副本无法与主副本进行

通信，从而不能保证两个数据库同步。强制故障转移启动新的恢复分叉。因为原始主数据

库和辅助数据库位于不同的恢复分叉上，所以每个数据库现在包含另一个数据库不包含的数

据：每个原始主数据库包含任何尚未从其发送队列发送到以前的辅助数据库的更改（未发送

的日志）；以前的辅助数据库包含任何强制故障转移之后发生的更改。

如果因为主副本出现故障而强制进行故障转移，则潜在的数据丢失取决于是否在出现故障

之前已将所有事务日志发送到辅助副本。在异步提交模式下，可能会始终存在累积的未发

送日志。在同步提交模式下，可能仅在辅助数据库同步之前会出现这种情况。

本文出自“杜飞”博客，请务必保留此出处/382644/1384835