SQL Server 2005数据库镜像(8)

假设使用safety FULL和见证服务器配置了数据库镜像。镜像服务器即Server B通过ping发现主服务Server A不可用。Server B与见证服务器通信并收到见证服务器也看不到Server A的确认消息。那么Server B将和见证服务器组成quorum并将自己提升为主服务器角色。它将恢复它的数据库并且通知见证服务器如今自己担当了主服务器的角色（尽管数据库处于disconnected状态，新主数据库的事务日志也不能被截断）。

Server B的新主数据库继续重新执行事务日志中的活动，但是它将持续redo状态而且大多数情况下只有很少的工作需要完成。在所有SQL Server版本中，新主数据库只要完成redo过程就立刻可用了。当数据库进入undo状态时将可以接收用户连接了。完成redo通常只需几秒钟，尽管余下的undo阶段时间可能很长。在数据库镜像中，新的主数据库只要redo阶段完成就可以为用户连接提供服务。新主服务器B的数据库处于DISCONNECTED状态而且是exposed，但是只要redo过程完成就可以提供数据库服务。

通常将整个应用程序从主服务器重新定向到新主服务器花费的时间要多于数据库镜像的自动故障转移。应用程序必须检测和重试连接，这样也会增加该过程的整体时间。此外，如果将新的SQL Server验证登陆账号添加到服务器，还需要使用系统存储过程sp_change_users_login将这些登陆账户映射到新主数据库的用户账户。如果旧的主服务器上一些关键对象，如SQL Agent作业还没有拷贝到新主服务器上，也会耽误应用程序故障转移的完成。（更多信息请阅读该白皮书实现数据库镜像部分的“为故障转移准备镜像服务器”）

现在假设旧的主服务器联机了。如果是手动故障转移，或者旧的主服务器被快速修复的自动故障转移场景，两台服务器需要进行角色互换，那么就必须进行一个协商过程。在数据库镜像重新开始之前，两台伙伴服务器需要决定彼此怎样进行同步。镜像故障转移lsn这个过程中扮演了一个关键角色。

Server A （新镜像服务器）落后了，但它并不清楚自己落后了多少。Server A向server B（新主服务器）报告它从server B接收的最后的镜像故障转移lsn。另一方面，Server B由于某些提交的工作而导致它有最新的镜像故障转移lsn，server A必须要追赶上server B。Server B将足够数量的事务日志发送给server A，使server A通过重新这些执行事务并与Server B同步。

手动故障转移

手动故障转移就是依次交换两个伙伴服务器的角色。它要求safety设置为FULL，并且主服务器和镜像服务器处于SYNCHRONIZED状态。

在主服务器上使用下面的ALTER DATABASE命令进行手动故障转移：

ALTER DATABASE AdventureWorks SET PARTNER FAILOVER;

或者在Management Studio的Database Properties/Mirroring对话框中单击Failover按钮。手动故障转移在旧的主数据库上断开所有用户连接并回滚所有未完成的事务。通过完成所有redo队列中已提交的事务，回滚所有未完成的事务（在undo阶段）来恢复镜像数据库。旧的旧的镜像数据库被分配了主数据库角色，而旧的主数据库则担当新的镜像数据库角色。两台服务器根据它们的镜像故障转移lsn协商数据库镜像的新起点，然后处理角色互换。

可以使用手动故障转移作为实现操作系统或者SQL SERVER实例的‘滚动升级’的一种方式来，假如您在初始化镜像服务器之前首先升级镜像服务器。更多信息请参阅SQL Server Books Online中'Manual Failover' 主题。

Forced Service

在镜像服务器上使用ALTER DATABASE命令进行forced Service：　

ALTER DATABASE AdventureWorks SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS;

通常只有当safety为OFF并且主服务器再也无法运转时才使用这种方式。也可以在safety为FULL使使用该命令，但是如果恢复的镜像服务器无法组成quorum，它也不能提供数据库服务。因此最好在safety为OFF（高性能操作模式）是使用该命令。由于异步的数据传输无法保证镜像数据库包含所有主服务器上提交的最新事务，因此有些数据可能会丢失。

数据库镜像可用性场景

在这一部分，您将根据以下两类事件对数据库镜像预期的可用性结果进行研究：

◆一个或多个服务器或者数据库失败
◆服务器之间一条或多条通信连路失败

服务器失败可能是由于某个镜像伙伴数据库、或者某个SQL SERVER实例不可用。此外，即使服务器本身可以继续运转，但是数据库镜像伙伴服务器之间的通信连路可能中断。

以下场景中，两个组件的同时失败被视为一个组件紧接着另一个组件的顺序失败。例如，Server A和B出现了同时失败，镜像系统将该事件视为一个顺序事件：Server A失败然后Server B失败，或者反过来。

使用下面的规则来判定一个不可用事件的预期结果：

1.当safety设置为FULL时，主服务器需要至少一台其他服务器才能形成quorum来保持数据库可用。

如果主服务器无法组成quorum，也就无法再提供数据库服务了。

2.当safety设置为FULL，如果镜像服务器和见证服务器都无法联系到主服务器，那么镜像服务器可以和见证服务器组成quorum并且改变其角色，使之成为新的主服务器。

这就是自动的故障转移。

3.当safety设置为FULL，如果主服务器和见证服务器合作组成quorum，但是断开了和镜像服务器的连接，那么主服务器失败将不允许镜像服务器和见证服务器组成quorum，也不允许镜像服务器承担主服务器的角色。

这样可以防止所做的工作由于会话中断而丢失。

4.当safety设置为FULL，如果失败的主服务器在停机或者孤立后重新加入会话，同时旧的镜像服务器已经承担了主服务器的角色（和见证服务器组成quorum），那么旧的主服务器将在此次会话中承担新镜像服务器角色。

在故障转移过程中，镜像服务器和见证服务器会增加镜像角色顺序计数器。因为主服务器的镜像角色顺序计数器 小于另一个伙伴服务器和见证服务器的顺序计数器，因此那两台服务器会在旧的主服务器重新加入会话之前组成quorum并开始工作。旧的主服务器担当起镜像的角色。

5.当safety设置为FULL并且会话中没有见证服务器，或者见证不知何故退出了会话，镜像伙伴服务器的失败将导致无法组成quorum，主服务器也因此不再保持主数据库可以使用。

无法组成quorum，因此不可能进行自动的故障转移，如果见证服务器不包含在safety为FULL的会话中。