内容列表
概述
数据库镜像介绍
数据库镜像动态
数据库镜像可用性场景
实现数据库镜像
数据库镜像和高可用性技术
结论

概述
数据库镜像是SQL SERVER 2005用于提高数据库可用性的新技术。数据库镜像将事务日志记录直接从一台服务器传输到另一台服务器，并且能够在出现故障时快速转移到备用服务器。可以编写客户端程序自动重定向连接信息，这样一旦出现故障转移就可以自动连接到备用服务器和数据库。

自动进行故障转移并且使数据损失最小化通常包括昂贵的硬件和复杂的软件。但是，数据库镜像可以在不丢失已提交数据的前提下进行快速故障转移，无须专门的硬件，并且易于配置和管理。

数据库镜像介绍
在数据库镜像中，一台SQL Server 2005实例连续不断的将数据库事务日志发送到另一台备用SQL Server实例的数据库副本中。发送方的数据库和服务器担当主角色，而接收方的数据库和服务器担当镜像角色。主服务器和镜像服务器必须是独立的SQL Server 2005实例。

在所有SQL Server数据库中，在对真正的数据页面进行修改之前，数据改变首先都记录在事务日志中。事务日志记录先被放置在内存中的数据库日志缓冲区中，然后尽快地输出到磁盘（或者被硬化）。在数据库镜像中，当主服务器将主数据库的日志缓冲区写入磁盘时，也同时将这些日志记录块发送到镜像实例。

当镜像服务器接收到日志记录块后，首先将日志记录放入镜像数据库的日志缓冲区，然后尽快地将它们硬化到磁盘。稍后镜像服务器会重新执行那些日志记录。由于镜像数据库重新应用了主数据库的事务日志记录，因此复制了发生在主数据库上的数据改变。

主服务器和镜像服务器将对方视为数据库镜像会话中的伙伴。数据库镜像会话包含了镜像伙伴服务器之间的关系。一台给定的伙伴服务器可以同时承担某个数据库的主角色和另一个数据库的镜像角色。

除了两台伙伴服务器（主服务器和镜像服务器），一个数据库会话中可能还包含第三台可选服务器，叫做见证服务器。见证服务器的角色就是启动自动故障转移。当数据库镜像用于高可用性时，如果主服务器突然失败了，如果镜像服务器通过见证服务器确认了主服务器的失败，那么它就自动承担主服务器角色，并且在几秒钟之内就可以向用户提供数据库服务。

数据库镜像中需要注意的一些重要事项：
•        主数据库必须为FULL还原模型。由于bulk-logged操作而导致的日志记录无法发送到镜像数据库。
•        初始化镜像数据库必须首先使用NORECOVERY还原主数据库，然后再按顺序还原著数据库事务日志备份。
•        镜像数据库和主数据库名称必须一致。
•        由于镜像数据库处于recovering状态，因此不能直接访问。通过在镜像数据库上创建数据库快照可以间接读取某一个时刻点的镜像数据库。（参阅该白皮书后面“数据库镜像和数据库快照”部分）

注意： 要想获取更多与数据库镜像术语有关的信息，请参阅SQL Server 2005 Books Online中关于“Overview of Database Mirroring”。

操作模式
数据库镜像会话有三种可能的操作模式。根据事务安全性的设置以及镜像会话中是否需要见证服务器来决定精确的操作模式。
表1.   数据库镜像操作模式



如果safety设置为FULL，那么通过同步方式传输数据，并且需要一台镜像服务器才能提供数据库服务。quorum投票表决要求至少两台服务器的参与才能够决定两个伙伴服务器各自承担什么角色，主角色还是镜像角色。
为了更深入研究这三种操作模式，首先来更进一步研究一下事务安全性和quorum的角色。

事务安全性
If 事务安全性（或者'safety'）设置为FULL，那么主服务器和镜像服务器工作在同步传输模式下。当主服务器硬化其主数据库日志记录到磁盘时，也同时将日志发送到镜像服务器。然后主服务器等待镜像服务器的回答。镜像服务器将那些相同的日志记录硬化到镜像日志所在磁盘后，对主服务器进行答复。当safety设置为OFF时，主服务器不会等待来自服务器的确认，因此主数据库和镜像数据库可能不是完全同步的（也就是，镜像可能滞后于主数据库）。

同步传输方式保证镜像数据库事务日志中所有事务与主数据库事务日志中的事务同步，因此可视为事务是安全传输的。要将safety设置为FULL，使用
ALTER DATABASE [<dbname>] SET SAFETY FULL;
当safety设置为OFF，主服务器和镜像服务器之间的通信是异步的。主服务器不会等待镜像服务器已将事务记录硬化的确认信息。镜像服务器通过尽快记录事务日志的来试图保持与主服务器同步，但是如果主服务器突然失败同时强制镜像服务器提供服务，那么某些事务还是有可能丢失（参阅SQL Server Books中的'Forced Service'）。
Quorum和见证服务器
当safety设置为FULL，数据库镜像需要quorum才能提供数据库服务。quorum是在同步数据库镜像会话中要求的所有连接起来的服务器之间的最小关系。由于一个quorum至少需要两台服务器，因此当safety为FULL时，主服务器必须和其他某至少一台服务器组成quorum才能够提供数据库服务。

见证服务器帮助主服务器或者镜像服务器组成quorum。如果存在见证服务器，那么主数据库或者镜像数据库失败时，其余两台服务器还可以组成quorum。如果主服务器无法看到镜像服务器，那么它可以和见证服务器组成quorum，并保持提供数据库服务。类似地，如果镜像服务器和见证服务器看不到主服务器，那么这两台服务器可以组成quorum，镜像服务器担当新主服务器的角色。

见证服务器失败不被视为数据库镜像绘画中的单点失败。因为如果见证服务器失败了，那么主服务器和镜像服务器还可以组成quorum（更多信息请参阅SQL Server Books Online中的“Quorum in Database Mirroring Sessions”主题）。

高可用操作模式
高可用操作模式支持最大程度的数据库可用性，如果主数据库失败将自动转移到经销数据库。它要求将safety设置为FULL并且定义一台见证服务器作为数据库镜像会话中的一员。

高可用操作模式最适合于那些服务器之间具有高速且可靠的通信线路，同时要求在单一数据库上实现自动故障转移的场景。当safety为FULL时，主服务器必须短暂等待来自镜像服务器的回答，主服务器性能也因此受到镜像服务器能力的影响。由于单数据库失败将导致自动故障转移，因此如果有多数据库应用程序，那么就应该考虑其他操作模式（参阅该白皮书中实现数据库镜像部分介绍的“多数据库问题”）

高可用模式中数据库镜像是自监视的。如果主数据库突然不可用，或者主服务器停机，那么见证服务器和镜像服务器将组成quorum，然后镜像的SQL Server将进行自动故障转移。此时，竞相服务器实例将其角色转换为新主服务器并恢复数据库。由于镜像数据库已经重新执行了主数据库的事务日志并且其事务日志也与主数据库同步，因此镜像服务器可以快速提供数据库服务。

此外，SQL Server 2005可以在数据库恢复前就向用户提供数据库服务。SQL Server数据库恢复包括三个阶段：分析阶段、redo阶段、以及最后的undo阶段。在SQL Server 2005中，只要redo阶段完成，新恢复的数据库就可以让用户访问。因此如果数据库镜像故障转移发生，新恢复的主数据库只要完成了redo阶段就可以向用户提供服务了。因为镜像数据库自始至终都在重新执行事务日志记录，因此所有镜像服务器只须完成redo过程就可以了，通常几秒钟就可以完成。

高保护操作模式
高保护操作模式中事务安全性设置为FULL，但是镜像会话中没有见证服务器。主服务器必须组成quorum，可是没有见证服务器，因此只能和镜像服务器配合在一起。这种模式下由于没有见证服务器来担当平局决胜的角色，因此只能手动完成故障转移。行自动故障转移是不可能的，因为如果主服务器失败，镜像服务器没有见证服务器来组成quorum。

safety设置为FULL，如果主服务器突然间失去了和镜像服务器的quorum，那么镜像服务器必须使其数据库停止服务。不推荐使用高保护模式的数据库镜像配置，除非在高可用模式下必须临时移除见证服务器时，可以使用该模式作为一种临时过渡。

高性能操作模式
在高性能操作模式下，事务安全性设置为OFF，以异步方式传输日志记录。主服务器无须等待镜像服务器所有日志记录已被硬化的确认信息。镜像服务器尽自己最大可能保持与主服务器数据的一致，但不能保证在任何时刻来自主数据库的所有最新事务日志记录都能够被硬化到镜像数据库的事务日志中。

在高性能模式下，见证服务器不承担任何角色，也不需要quorum。因此高性能模式无法启用自动和手动的故障转移。唯一允许的故障转移方式就是forced service ，它同样也是一种手工操作：
ALTER DATABASE <dbname> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
forced service故障转移导致立刻恢复镜像数据库。如果某些主数据库的事务日志记录还没有被镜像服务器接收，那么恢复镜像数据库将导致潜在的数据丢失。高性能模式特别适合于远距离的数据传输（换句话说，用于远程站点的灾难恢复），或者对那些活动频繁且可以容忍某种程度数据丢失的数据库进行镜像。

数据库快照和数据库镜像
由于镜像数据库处于recovering状态，因此不可访问也不可读。在SQL Server 2005企业版和开发人员版中可以创建数据库快照来读取某个时点的镜像数据库。数据库快照提供了一个只读的数据库视图，开放数据给用户访问。这些数据与创建快照时刻的数据库数据相一致。

对数据库快照的访问如同访问一个其他的数据库。查询数据库快照时，从数据库快照文件中读出那些自快照创建后被修改的数据，从原始数据库中读出未修改的数据。最终效果就是读取了在创建快照时刻数据库当时的数据。（更多信息请参阅SQL Server Books Online中"Using Database Snapshots with Database Mirroring"主题。）
由于数据库快照确实增加了镜像服务器的负担，因此需要当心它们对数据库镜像性能可能造成的影响。由于只能镜像到一个数据库，因此如果需要将数据扩充到多个只读的报表服务器上，那么事务复制是更好的选择。（更新信息请阅读后面实现数据库镜像部分的“数据库镜像和复制”）

客户端重定向
在SQL Server 2005中，如果使用ADO.NET或者SQL Native Client连接配置了镜像的数据库，那么应用程序就可以利用驱动程序的能力在发生数据库镜像故障转移时自动重定向数据库连接。必须在连接字符串中指定原始主服务器和数据库名称，以及可选的故障转移伙伴服务器名称。

连接字符串的写法有许多种，以下只给出一个例子，指定server A作为主服务器，server B作为镜像服务器，AdventureWorks作为数据库名称：
"Data Source=A;Failover Partner=B;Initial Catalog=AdventureWorks;Integrated Security=True;"
如果连接到原始主服务器失败，那么就使用连接字符串中的failover partner作为备用服务器名称。如果连接到原始主服务器成功，那么就不使用连接字符串中的failover partner名称，但是会从主服务器上查询其故障转移伙伴的名称并将结果存放在客户端缓存中。

假设客户端成功连接到主服务器，然后一个数据库镜像故障转移发生（自动地、手动的、forced）。当下一次应用程序尝试使用连接时，ADO.NET或者SQL Native Client驱动程序将会检测到与旧主服务器的连接已经失败，然后自动重新连接由failover partner名称指定的新主服务器。如果连接成功并且新的镜像服务器存在，那么驱动程序从新主服务器处获取新的故障转移伙伴名称并将其存放在客户端缓存中。如果无法连接到备用服务器，那么驱动程序将交替尝试与每个服务器的连接直道连接超时。

使用内置在ADO.NET和SQL Native Client驱动程序中的数据库镜像支持的最大优点就是无须重新编写应用程序，或者在应用程序中编写特殊代码来处理数据库镜像的故障转移。

如果不使用ADO.NET或者SQL Native Client自动进行重定向，那么也可以使用其他技术使应用程序进行故障转移。例如，如果客户端连接到一台虚拟服务器，可以使用Network Load Balancing手动重定向一台服务器到另一台服务器的连接。还可以编程实现自己的重定向代码和连接重试逻辑。

但是，所有这些用于协调客户端重定向和数据库镜像的技术都有一些重要限制。数据库镜像只能工作在数据库级别，而不是服务器级别。如果应用程序查询一台服务器上的多个数据库，或者使用完全限定对象名称进行跨数据库查询，那么就需要多加小心了。如果多个数据库位于一台服务器并且都配置了和备用服务器的镜像，就有可能出现其中一个数据库故障转移到备用服务器而其他数据库依然在原始服务器的情况。如果是那样的话，可能就要求每个数据库查询都使用一个单独的连接，这样将无法进行跨数据库查询，因为在镜像服务器上只有一个数据库是主数据库，其余都是镜像数据库。

数据库镜像与SQL SERVER 2005版本
下表显示各种版本的SQL SERVER 2005支持的数据库镜像功能。
表 2。   数据库镜像和SQL SERVER 2005版本



少数几个数据库镜像功能要求使用SQL SERVER 2005企业版或者开发人员版：
•        高性能模式下safety设置为OFF （异步数据传输）；
•        数据库快照；
•        使用多线程在镜像数据库上应用事务日志（并行REDO）。
SQL Express和工作组版本可以作为数据库镜像的见证服务器，但不能作为伙伴服务器。

数据库镜像动态
要深入理解SQL SERVER 2005 数据库镜像，了解数据库镜像会话如何变化将对您大有帮助。这一部分内容包括数据库镜像会话中不同的数据库状态、同步和异步的日志记录传输机制、以及故障转移次序。

配置和安全性
一旦确定了主服务器、镜像服务器、以及可选的见证服务器，设置数据库镜像主要包括三个步骤。
1.        必须备份数据库并使用norecovery在镜像数据库上还原该数据库。
注意：在备份数据库并还原到镜像数据库之前，主数据库必须设置为FULL还原模型。如果必须在事务日志中传输Bulk-logged记录，那么数据库镜像将无能为力。镜像服务器必须有足够的磁盘空间以允许和主数据库同样的文件增长。如果希望在镜像服务器中创建数据库快照，那么还必须为快照提供额外的磁盘空间。
如果备份、拷贝、以及还原数据库耗费了相当长的时间，那么可能需要现在原始数据库上进行一次事务日志备份来控制日志的大小。但是，如果通过日志到日志的备份清理了日志记录，数据库镜像将无法初始化。因此必须在初始化数据库镜像之前在镜像数据库上按顺序恢复那些事务日志记录备份。
2.        参与数据库镜像会话的服务器必须彼此信任。对于本地通信而言，例如一个域内的通信，信任意味着SQL Server实例登陆账号必须有权限连接到其他镜像服务器，也包括endpoints。首先在每个服务器上使用CREATE LOGIN命令，然后使用GRANT CONNECT ON ENDPOINT命令（参阅" in SQL Server Books Online中“Example of Setting Up Database Mirroring Using Windows Authentication”）
非信任域之间的通信必须使用证书。如果使用CREATE CERTIFICATE语句创建自签名的证书，基本上所有数据镜像证书的要求都可以满足。确认在CREATE CERTIFICATE语句中将证书标记为ACTIVE FOR BEGIN_DIALOG。
3.        下一步是创建数据库镜像的endpoints。创建endpoints要求您必须具有SQL Server instance的系统管理员权限。必须在每台服务器上创建专门用于数据库镜像的endpoints. 创建endpoints最简单的方式就是使用Configure Database Mirroring Security向导，可以在Database Properties对话框中Mirroring页面上单击Configure Security按钮启动该向导。Configure Security对话框会在构造和执行CREATE ENDPOINT命令之前，提示您输入正确的计算机名称和端口号，以及可选的登陆帐号。（参阅SQL Server Books Online中 “How to: Create a Mirroring Endpoint (Transact-SQL)”）  

如果在域中设置数据库镜像，并且所有的SQL Server实例使用相同的服务帐号和密码，那么就不需要在每个服务器上创建登陆帐号。类似的，如果在工作组中，并且所有的SQL Server实例使用相同的服务帐号和密码，也不需要在每个服务器上创建登陆帐号。设置endpoints时将Configure Database Mirroring Security向导中的登陆帐号保留为空就可以了。

每个数据库endpoint必须指定服务器上一个唯一的端口号。如果使用不同服务器上的SQL Server实例，那么这些端口号可以是相同的。Configure Database Mirroring Security向导会自动建议您使用5022作为端口号。如果任何SQL Server实例运行在同一台服务器上，那么每个实例的端口号必须唯一，所有的镜像端口号也必须唯一。
假设在高可用镜像会话中有三台服务器。Server A是主服务器，server B是镜像服务器，server W作为见证服务器。对于server A而言，下面的命令在5022端口创建endpoint：
CREATE ENDPOINT [Mirroring]
        AS TCP (LISTENER_PORT = 5022)
        FOR DATABASE_MIRRORING (ROLE = PARTNER, ENCRYPTION = ENABLED);
注意：角色被指定为PARTNER，这样该服务器可以担当数据库镜像的主服务器或者镜像服务器。在server B上执行相同的命令。因为server B是独立物理服务器上的SQL Server实例，因此可以使用相同的端口号。然后对于server W，使用
CREATE ENDPOINT [Mirroring]
        AS TCP (LISTENER_PORT = 5022)
        FOR DATABASE_MIRRORING (ROLE = WITNESS, ENCRYPTION = ENABLED);
注意：对于server W，角色被指定为WITNESS。
默认不启动endpoint。接下来在每个服务器上使用下面的命令来启动endpoint：
ALTER ENDPOINT [Mirroring] STATE = STARTED;
可以在CREATE ENDPOINT命令中插入可选的STATE选项。在每台服务器上反复执行该选项。
使用CREATE ENDPOINT创建endpoint时，可以通过协议特定的参数根据IP地址来限制对endpoint的访问。结合RESTRICT_IP with ALL选项和EXCEPT_IP加上那些允许访问的特殊IP地址可以对一组IP地址作限制。（参阅SQL Server Books Online中的See “CREATE ENDPOINT”） 。
查询每个服务器的sys.database_mirroring_endpoints目录视图来检查数据库镜像的endpoints：
SELECT *
FROM sys.database_mirroring_endpoints;
4. 要启动数据库镜像，接下来指定指定伙伴服务器和见证服务器。 必须具有数据库管理员权限才可以启动和管理一个给定的数据库镜像会话。在server A，即打算作主服务器的机器上设置主数据库角色以及伙伴（镜像）服务器：
-- Specify the partner from the principal server
ALTER DATABASE [AdventureWorks] SET PARTNER =
N'TCP://B.corp.mycompany.com:5022';
镜像伙伴的名称必须为完全限定计算机名。决定机器的完全限定名称可能有些难，不过Configure Database Mirroring Security向导会在建立endpoint时自动找出它们。

从命令行提示中运行下面的命令也可以找出一台机器的完全限定名称：
IPCONFIG /ALL
将"Host Name"和"Primary DNS Suffix"连接到一起。如果您看到的信息类似于：
Host Name . . . . . . . . . . . . : A
Primary Dns Suffix  . . . . . . . : corp.mycompany.com
那么计算机名就是A.corp.mycompany.com。加上'TCP://'前缀然后再附加':<端口号>' ，就是镜像伙伴名称。
在镜像服务器上重复相同的命令，但是要指定主服务器名称：
-- Specify the partner from the mirror server
ALTER DATABASE [AdventureWorks] SET PARTNER =
N'TCP://A.corp.mycompany.com:5022';
接下来在主服务器上指定见证服务器：
-- Specify the witness from the principal server
ALTER DATABASE [AdventureWorks] SET WITNESS =
        N'TCP://W.corp.mycompany.com:5026';
执行完CREATE ENDPOINT后见证服务器上就不需要执行其他命令了。

最后，在主服务器上指定会话的safety级别：
-- Set the safety level from the principal server
ALTER DATABASE [AdventureWorks] SET SAFETY FULL;
此时，镜像将自动启动，然后主服务器和镜像服务器将进行同步。

可以调整判定镜像伙伴是否故障的超时值，使用ALTER DATABASE命令的TIMEOUT参数。例如将TIMEOUT值改为20秒（默认是10），在主服务器上执行：
-- Issue from the principal server
ALTER DATABASE [AdventureWorks] SET PARTNER TIMEOUT 20;
最后，在主服务器上使用ALTER DATABASE和REDO_QUEUE选项可以镜像服务器上redo队列的大小。下面的查询将镜像服务器的redo队列设置为100兆：
-- Issue from the principal server
ALTER DATABASE [AdventureWorks] SET PARTNER REDO_QUEUE 100MB;
只要指定了镜像伙伴，镜像将立即启动。

数据库镜像目录视图
数据库镜像会话包括组成伙伴的服务器，可能还有见证服务器之间的关联。每台参与镜像的服务器都保存关于镜像会话和当前数据库状态的元数据。可以在主服务器和镜像服务器上通过查询sys.database_mirroring目录视图来检查会话状态。使用另一个视图sys.database_mirroring_witnesses可是返回见证服务器的信息（要想获得两个目录视图中所有列的更完整的描述，请参阅  SQL Server Books Online的“sys.database_mirroring" and "sys.database_mirrroing_witnesses”）。

了解数据库镜像会话如何工作以及数据库处于何种状态的一种不错的方法就是检查目录视图里的数据。我们从高可用配置开始（safety设置为FULL，有一台见证服务器）。下面的查询返回了主服务器或者见证服务器上数据库镜像会话的基本描述信息。
SELECT
      DB_NAME(database_id) AS 'DatabaseName'
    , mirroring_role_desc
    , mirroring_safety_level_desc
    , mirroring_state_desc
    , mirroring_safety_sequence
    , mirroring_role_sequence
    , mirroring_partner_instance
    , mirroring_witness_name
    , mirroring_witness_state_desc
    , mirroring_failover_lsn
FROM sys.database_mirroring
WHERE mirroring_guid IS NOT NULL;
在见证服务器上运行下面类似的查询，可以返回见证服务器的相关描述信息。
SELECT
      Database_name
    , safety_level_desc
    , safety_sequence_number
    , role_sequence_number
    , is_suspended
    , is_suspended_sequence_number
    , principal_server_name
    , mirror_server_name
FROM sys.database_mirroring_witnesses;
现在来比较在一个典型的数据库镜像会话中两个查询的输出结果。假设已经设置了server A到 server B的数据库镜像，使用safety为FULL。（设置以下配置的示例代码，请参阅后面的实现数据库镜像“配置和安全性”）见证服务器是server W，对AdventureWorks数据库做镜像。表3显示了两个查询的输出结果：
表3. 高可用镜像会话，两个伙伴服务器sys.database_mirroring输出结果。



注意数据库镜像会话中的每个伙伴保存的所有元数据从另一个伙伴的角度来看是完全相同的。每个伙伴保存其数据库名称、整个会话的safety设置、数据库的镜像状态、以及两个序列计数器。
•        mirroring_safety_sequence计数器保存在两个伙伴上，只要safety设置改变时将增加该计数器的值。
•        mirroring_role_sequence计数器保存在两个伙伴以及见证服务器上，只要发生故障转移就增加该计数器的值。
伙伴数据库的状态以及见证服务器的状态都保存在每个伙伴服务器上：
•        mirroring_state_desc显示了会话中伙伴数据库的状态。
•        mirroring_witness_state_desc显示了会话中见证服务器的状态。
最后，每个伙伴都包含一个mirroring_failover_lsn。LSN是一个日志序列号，用于唯一标识每条事务日志记录。 镜像伙伴将上次硬化的最后一组日志记录的最高LSN +1保存起来。在上表中，由于主数据库中只有为数不多的活动，因此 镜像转移故障的lsn和主服务器以及见证服务器的lsn相同。当传输大量数据时，可能就会发现主服务器的lsn值大于镜像服务器的值，因为镜像服务器的运行有些滞后。
现在比较一下在见证服务器上找到的元数据。下表显示了来自见证服务器元数据的一些可比较信息：
表 4. 见证服务器上sys.database_mirroring_witnesses的输出，关联了伙伴的元数据。


注意见证服务器的元数据包含了safety的描述、safety的序列号、以及角色序列号。见证服务器还保存了会话是否被挂起的信息，以及主服务器和镜像服务器的名称。注意见证服务器的目录视图并没有报告镜像故障转移的lsn，而且也不保存数据库状态。

数据库镜像所需的全部元数据（特别是故障转移lsn和伙伴服务器名称）都保存在镜像伙伴上。见证服务器只保存在高可用模式下作为见证者必须保存的那些数据，特别是用于跟踪会话中角色转换数目的角色序列号。该计数器用于帮助判定何时一台主服务器可以做角色转换。相关知识会在下一部分介绍的场景中进行阐述。

数据库镜像状态和状态转换
在数据库镜像会话过程中，每台伙伴服务器都对数据库状态作记录和保存，可以通过sys.database_mirroring目录视图来查看。mirroring_state列返回状态号，mirroring_state_desc列返回状态的描述性名称。（要想获取关于数据库状态号和描述性名称的完整列表，请看SQL Server Books Online中的“sys.database_mirroring”）。同样的目录视图还用于报告见证服务器的状态信息。
除了为每个数据库报告状态信息以外，还有三个重要术语用来对数据库镜像中的服务器和数据库进行描述。
1.        主服务器上的数据是exposed ，当它进行事务处理但是没有日志数据被发送到镜像服务器。
2.        不能提供数据库服务 – 当主服务器不允许任何用户连接到数据库，不允许任何事务处理。
3.        服务器被孤立 – 当它无法联系数据库镜像会话中任何其他服务器，同时别人也联系不上它。
当主数据库是exposed，它可以接收用户连接和进行事务处理，但是没有日志记录被发送到镜像数据库。因此如果主数据库失败了，那么镜像数据库不包含任何自主数据库进入exposed状态后主服务器上发生的事务。同样的，也不可以清理主数据库的事务日志，这导致日志文件的无限增长。

当safety设置为FULL时，如果主服务器无法和其他服务器组成quorum，它将停止提供数据库服务。主服务器将不允许主数据库上的用户连接和事务，并断开所有当前的用户。只要主服务器能再次组成quorum，就立刻重新提供数据库服务。

一台服务器可能运转正常但是它和数据库镜下会话中的其他服务器之间的通信连路中断了。如果那样的话，我们称服务器被孤立了。 当safety为FULL时，如果主服务器被孤立，那么它将无法提供数据库服务，因为会话中没有其他服务器可与之共同组成quorum。

现在来关注一下数据库镜像状态，从主服务器和数据库开始。

主服务器数据库状态
当safety设置为FULL，主数据库的正常操作状态时SYNCHRONIZED状态。当safety设置为OFF，主数据库的正常操作状态是SYNCHRONZING状态。
•        如果safety设置为FULL，主数据库的起始状态始终是SYNCHRONIZING，当主数据库和镜像数据库事务日志同步后，数据库状态就转换成SYNCHRONIZED，
•        如果safety设置为FULL并且主服务器断开了和见证服务器的连接但依然可以进行事务处理，那么数据库状态为exposed。
•        如果safety设置为FULL并且主服务器无法和其他服务器组成quorum，那么将无法提供数据库服务。不允许任何的用户连接和事务处理。
下表显示了主数据库可能的状态，以及导致状态转换的一些事件。
表 5. 主数据库状态，safety为FULL以及safety为OFF。



当safety设置为FULL，主数据库首先进入SYNCHRONIZING状态，只要和镜像数据库同步，两个伙伴都进入SYNCHRONIZED状态。当safety设置为OFF，伙伴数据库从SYNCHRONIZING状态开始并在整个镜像过程中保持该状态。

对于这两个safety设置，如果会话被挂起或者出现了镜像服务器的redo错误，那么主数据库进入SUSPENDED状态。如果镜像服务器不可用，那么主数据库进入DISCONNECTED状态。

在DISCONNECTED和SUSPENDED状态下：
•        当safety设置为FULL，如果主服务器无法和见证服务器或者镜像服务器自称quorum，那么主数据库被视为exposed。这意味着主数据库为活动状态，支持用户连接和事务处理。 但是没有日志记录被发送到镜像数据库。因此如果主数据库失败了，那么镜像数据库不包含任何自主数据库进入exposed状态后主服务器上发生的事务。同样的，也不可以清理主数据库的事务日志，这导致日志文件的无限增长。
•        当safety设置为FULL，如果主服务器无法和其他服务器组成quorum，它将不能提供数据库服务。所有用户将被断开连接，也不允许新的事务处理。
•        当safety设置为OFF，朱数据库被视为exposed，因为没有事务日志记录被发送到镜像。

注意：Management Studio's Object Explorer会在Server树图中数据库名称的旁边报告主数据库状态。将主数据库的SYNCHRONIZED状态报告为 'Principal, Synchronizing'，DISCONNECTED状态报告为'Principal, Disconnected.'

镜像数据库状态
镜像数据库具有和主数据库相同的状态，但是由于镜像数据库始终处于nonrecovered状态，因此在担当镜像角色的时候不能提供数据库服务。下表显示了可以导致镜像服务器和数据库状态改变的一些最常见事件。
表 6. 镜像服务器状态，safety为FULL以及safety为OFF.



和主数据库一样，Management Studio's Object Explorer在Server树的数据库名称旁边报告镜像数据库状态。镜像数据库的SYNCHRONIZED状态报告为'Mirror, Synchronizing'，DISCONNECTED状态报告为'Mirror, Disconnected.'

见证服务器状态
在sys.database_mirroring目录视图中有三种见证服务器状态，CONNECTED、 DISCONNECTED和UNKNOWN。
表 7. Witness服务器状态（记录在伙伴服务器上）



由于见证服务器状态真正记录在伙伴服务器而不是见证服务器上，因此这些状态是从有利于伙伴的角度来设置的，因此当您看到见证服务器为DISCONNECTED状态时，意味着伙伴和见证服务器断开了。数据库镜像启动后，如果镜像服务器无法与主服务器进行初始化，那么见证服务器进入UNKNOWN状态。

传输事务日志记录
SQL Server主服务器和镜像服务器传输消息和日志记录的次序根据事务安全性的设置而不同。我们先研究同步传输，然后再研究异步传输。

当SQL Server将事务事件记录在事务日志中时，日志记录被写入磁盘前暂时存放在日志缓冲区中。 数据库镜像时，每次日志缓冲区被输出到硬盘时（硬化），主服务器也将相同的日志记录块发送到镜像服务器。

1. 当safety设置为FULL，只要SQL Server主服务器硬化它的日志记录块，就同时将相同的日志记录块发送到镜像服务器，并认为本地的日志I/O和远程镜像服务器的日志I/O从本质上来说是一样 的。这种传输称为同步的，因为在一个事务提交之前，主服务器既要等待本地的I/O（硬化）还要等待等待镜像服务器有关完成I/O（硬化）的答复。

每次主服务器或者镜像服务器硬化日志缓冲区时，都会将缓冲区中最高的日志序列号（LSN）+ 1作为mirroring_failover_lsn记录在元数据中。mirroring_failover_lsn用于协商事务日志最后的保障点，这样两个伙伴数据库就可以在初始化时保持同步，在故障转移后也保持同步。

当主服务器发送日志记录给镜像服务器时，主服务器上的mirroring_failover_lsn通常会提前一些。镜像服务器硬化日志记录时会记录其mirroring_failover_lsn，然后回复主服务器。但是等主服务器接收到来自镜像的确认信息时，主服务器可能已经开始硬化新的一组日志记录了。

表 8显示了主服务器和镜像服务器safety为FULL时的一个事件序列示例。
表 8. Safety为FULL （同步传输）事件序列的示例。





以上事件序列中关键的一点就是：当 safety设置为FULL时，主服务器硬化日志缓冲区以及将日志缓冲区中日志记录的副本发送到镜像服务器，二者是同时进行的。然后主服务器开始等待自己的I/O以及镜像服务器的I/O，两个I/O都完成后才认为事务完成了。当主服务器接收到来自镜像的答复后，再开始处理下一次硬化。

当safety设置为FULL时，尽管主服务器和镜像服务器之间协调紧密，但是数据库镜像不是分布式事务，也不使用两阶段提交协议。
•        在数据库镜像中，两个事务分别在两台服务器上执行，并不是一个跨服务器的分布式事务。
•        数据库镜像不使用伙伴服务器作为分布式事务中的资源管理器。
•        数据库镜像事务不经历准备和提交阶段。
•        最重要的是，镜像服务器上事务提交失败不会导致主服务器上的事务会滚，这一点与分布式事务不同。
2. 当safety设置为OFF时，主服务器不等待来自镜像服务器的确认消息，因此主服务器上已提交事务数量可能多于镜像服务器，如图9所示：
表 9. Safety为OFF （异步传输）事件序列的示例。

数据库镜像角色转换
可以从数据库镜像服务器或者应用程序的角度来思考数据库镜像故障转移问题。从数据库镜像服务器角度，故障转移就是将镜像服务器转换为主服务器，以及使用新恢复的数据库作为主数据库。故障转移可以是自动的、手动的、或者forced service。
•        自动的 – 只有高可用模式下才会产生（safety设置为FULL以及见证服务器的参与）
•        手动的 -  只有高可用和高保护操作模式下才会产生（safety设置为FULL），两个伙伴数据库都是SYNCHRONIZED。
•        Forced service （允许数据丢失） - 主要是在高性能模式下（safety OFF）用于立刻和手动的恢复镜像数据库
当safety设置为FULL时，用于互换服务器角色的最好的方式是使用手动故障转移，而不是forced service。

自动故障转移
自动故障转移是高可用模式下（safety为FULL使用见证服务器）数据库镜像的功能。大多数情况下，SQL Server可以在几秒钟内完成自动故障转移。SQL Server可以进行局部自动故障转移，因为包含在数据库镜像会话中的SQL服务器会彼此测试对方的存在。该过程称为“ping”，但包含的操作远不止一个普通的 IP地址ping。镜像服务器和见证服务器联系主服务器以检查主物理服务器是否存在、SQL Server是否存在、以及主数据库是否可用。类似的， 主服务器和见证服务器ping镜像服务器以检查镜像物理服务器和SQL Server实例的可用性，以及镜像数据库的还原状态。

假设使用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的会话中。

高可用场景中服务器失败
高可用操作模式下的数据库镜像其目的就是尽可能增加数据库的可用性。在这种模式下，如果主数据库无法访问，那么数据库镜像将迅速使镜像数据库可以接受访问。在下面的一组场景中，我们的讨论将从高可用配置加上三台独立的服务器开始。
在下面的高可用场景中，Server A作为主服务器启动，Server B是镜像服务器，而Server W是见证服务器，如图1所示：



所有这三台服务器可以在同一个站点使用局域网连接，也可以在不同的站点使用WAN进行连接。Server A和Server B可以互换角色，但是Server W始终作为见证服务器。
现在来考虑如果其中一台服务器出现故障时产生的结果。

场景 HASL1.1： 主服务器失败
下面的场景分析了在高可用模式下主服务器失败时会发生什么。图 2显示了不同的角色，以及镜像伙伴之间如何做角色转换。



主服务器Server A失败后，镜像和见证服务器组成quorum，自动的故障转移产生。如果重新恢复了原始的主服务器，它将担当起镜像服务器的角色。

注意：要导致高可用模式下的故障转移，失败可以发生在不同的级别上：服务服务器可能停机、主服务器上的SQL SERVER实例可能停止或者失败、服务器上的主数据库可能不可用或状态可疑。在下面场景中，主服务器失败可能由这些事件中的任何一个引起。

因为Server B和W可以组成quorum，并且二者均无法联系Server A，那么Server B可以将自己提升为新的主服务器。但是如果没有镜像服务器，镜像会话就被认为是exposed。

Server A恢复后，它成为新的主服务器，镜像会话也不再是exposed
单服务器失败事件并不多见，两台服务器失败就更少见了，因此研究在这种情况下出现的结果十分有用。
两台服务器可以同时或者几乎同时失败，但从数据库镜像的角度来看，其结果被视为一台服务器失败紧接着另一台也失败了。因此这些场景只考虑当多台服务器顺序失败时的后果。
接下来的两个场景分析主服务器 Server A失败，紧接着其他两台服务器也失败时会产生的结果。
•        新的主服务器 Server B失败；
•        见证服务器 Server W失败；

场景 HASL1.2： 主服务器失败，随后新的主服务器失败
同前面的场景一样，在高可用操作模式下，如果主服务器首先失败，那么故障转移发生。图3显示了如果新的主服务器接下来也失败了，那么无论怎样恢复这些服务器，新的主服务器（Server B）始终保持其主服务器的角色。



Server A失败后，Server B成为新的主服务器，但是无法将数据发送给镜像服务器，因此主服务器处于exposed，即使它仍然提供数据库服务。当Server A失败紧接着Server B也失败，那么就不存在数据库镜像了，因为Server B已经停工了。

如果Server A首先恢复，它从见证服务器的mirroring_role_sequence号中检测到见证服务器已经组成了新的quorum。Server A接纳了镜像服务器的角色，然后等待Server B恢复。Server B一旦恢复，立刻开始了和Server A的数据库镜像过程。如果Server B先恢复，那么就重新回到了在HASL1。1中显示的初始场景。

注意： 如果Server W在Server A和Server B相继失败后也宣告失败，导致所有三台服务器均停工，那么无论以什么次序恢复见证服务器，已经转换完成的Server A和Server B的角色将保持不变。

场景 HASL1.3：主服务器失败，随后见证服务器失败
主服务器失败后发生故障转移。见证服务器可能接下来也失败，如图4所示：



当见证服务器 Server W主服务器 Server A失败后也出现失败，那么新主服务器 Server B依然为主服务器但被孤立，无法组成quorum，也不能提供数据库服务。
如果Server A首先恢复，Server B的mirroring_role_sequence号将比Server A的大1，因为产生了故障转移。这些信息指示Server A如今Server B在Server A只有担当了主服务器的角色。Server A和Server B组成quorum 并成为一对镜像，此后两台服务器保持同步。除非Server W恢复，否则不会产生自动故障转移。
注意： 如果Server W在Server A和Server B相继之后也宣告失败，那么无论以什么次序恢复见证服务器，已经转换完成的Server A和Server B的角色将保持不变。

场景 HASL2.1： 镜像服务器失败
如果镜像服务器首先失败，那么主服务器被视为exposed，因为它无法发送数据给镜像服务器。图 5显示了Server B，即镜像服务器失败时的行为。



没有自动故障转移发生，镜像伙伴也不会交换角色。当Server B恢复时，所有三台服务器还原到其初始角色和状态。

下表显示了镜像服务器Server B失败以及恢复时数据库状态。
由于没有镜像服务器，数据无法存放在冗余数据库中，因此会话处于exposed
Server B一旦恢复立刻重新担当起它的镜像服务器角色。只要两台服务器同步，镜像会话就不再被视为exposed。
接下来的两个场景考虑镜像服务器Server B失败，紧接着主服务器Server A或者见证服务器Server W失败时产生的结果。

场景 HASL2.2：镜像服务器失败，随后主服务器失败
紧随镜像服务器之后主服务器也失败了，镜像伙伴服务器的角色保持不变。图6显示了采用不同方式还原服务器时角色将如何转换。



在Server B和Server A都失败后，各服务器状态显示在图中的右上角处。
如果Server B首先恢复，它将从见证服务器Server W处检测到Server A依然为主服务器并且还没有产生故障转移，mirroring_failover_lsn也没有增加。其结果为，Server B依然为镜像服务器。Server W恢复后将会话还原到初始状态。
注意： 如果Server W在Server B和Server A相继失败之后也宣告失败了，那么以任何顺序还原这些服务器将导致相同结果。

场景 HASL2.3： 镜像服务器失败，随后见证服务器失败
镜像服务器失败，随后见证服务器也失败，那么主服务器被孤立并且无法和任何其他服务器组成quorum。因此它必须停止数据库的工作，如图7右上角所示。



由于镜像服务器故障以及随后的见证服务器失败，主服务器 Server A保持其主服务器角色，由于无法和任何其他服务器组成quorum，而safety又被设置成FULL，因此不再为数据库提供服务，并断开所有的用户连接。
如果Server B首先恢复，那么数据库镜像将重新开始工作，尽管由于缺失见证服务器而不会产生自动故障转移。
如果Server W首先恢复，那么情况与图5中显示的一样。
注意： 如果Server A在Server B和Server W相继失败之后也宣告失败，那么以任何次序还原这些服务器其最终结果保持不变。

场景 HASL3.1： 见证服务器失败
见证服务器失败时，数据库镜像继续进行但是不可能产生自动的故障转移。如果再有一台或多台服务器失败，就意味着没法组成quorum，那么主服务器上的数据库也不再服务于数据库用户。



Server W恢复后，两个伙伴服务器Server A和Server B维持它们的初始角色。
下表显示了见证服务器失败以及恢复后，数据库状态以及quorum的变化。
下面的两个场景考虑见证服务器Server W失败，紧接着主服务器 Server A或者镜像服务器Server B失败时产生的结果。

场景 HASL3.2： 见证服务器失败，随后主服务器失败
见证服务器首先失败，那么数据库镜像将继续进行，但是不可能产生自动的故障转移。其余两台服务器中任何一台失败将导致无法组成quorum，余下的那台服务器将被孤立。



如果Server W首先恢复，那么Server B将从见证服务器那里检测到最后的主服务器是Server A，同时Server B依然是镜像服务器。最终Server A恢复时，它将保持其主服务器角色。
注意： 如果Server B在Server W和Server A相继失败后也宣告失败了，那么以任意次序还原这些服务器都不会影响最终结果。

场景 HASL3.3： 见证服务器失败，随后镜像服务器失败
如果见证服务器失败，随后镜像服务器也失败，那么主服务器被孤立。由于safety设置为FULL并且主服务器无法组成quorum，它将不再提供数据库服务，如图10所示。



注意： 如果Server A在Server W和Server B相继失败之后也宣告失败， 那么以任意次序还原这些服务器都不会影响最终结果。
总结：高可用场景中服务器失败

从这些场景中可以得出几个结论。在高可用操作模式下：
1.        如果主服务器首先不可用，那么产生自动的故障转移，原先的镜像服务器将担当主服务器角色，并使其数据库服务于用户活动。后续的服务器失败和恢复不会影响使用新主服务器的数据库镜像的整体配置。数据库镜像将以相反的方向继续进行。
2.        如果镜像首先不可用，那么产生自动的故障转移 。后续的服务器失败以及恢复次序都不会影响镜像伙伴角色。
3.        如果见证服务器首先不可用，那么不可能产生自动的故障转移，镜像伙伴服务器将保持其初始角色。后续的服务器失败以及恢复都不会影响镜像伙伴角色。
下表总结了在高可用场景中出现一台或两台服务器失败时产生的结果。表中假设的条件是safety设置为FULL并且镜像会话中的服务器满足下列条件：
A： 主服务器， SYNCHRONIZED
B： 镜像服务器，SYNCHRONIZED
W： 见证服务器，CONNECTED
表中使用灰色加亮显示故障转移场景。
表10。 总结：单服务器或者双服务器失败，显示伙伴服务器角色和数据库状态。

高可用场景中通信失败
高可用操作模式需要三个SQL Sever实例。如果这些服务器位于两个或三个独立的物理站点并且相距很远，那么这些站点间的通信就很可能出现问题。换句话说，服务器依然运转但是彼此间的通信连路中断了。这种情况比前面的那些场景要复杂一些，但原理是一样的。

下面高可用操作场景中通信失败的研究将通过两组来完成。第一组是基于三个来自不同站点的SQL SERVER实例，因此有三条独立的通信连路。第二组是基于两个独立站点上的服务器，第一个站点上的一对服务器和第二个站点上的第三台服务器之间有一条通信连路。

先从第一组开始，假设一个数据库会话中所有三台服务器之间有三条独立的通信连路。例如，主服务器、镜像服务器和见证服务器位于三个独立的协作站点上（也有可能三台服务器位于同一个站点，但使用私有网络连接）
初始条件是Server A上运行主数据库并且与其镜像伙伴Server B保持同步。Server B上是镜像数据库Safety设置为FULL，见证服务器 (Server W)也包含在数据库镜像会话中。图11显示了初始配置。



注意： 要获得页面上图表的解释，请参阅前面介绍的“高可用场景中服务器失败”
根据图11，三条链路可能首先中断：A/B， A/W和B/W。注意当某条通信连路中断时，所有三台服务器依然运转正常。只有主服务器和镜像服务器之间的通信连路有一些影响，如表11所示。
表11。 总结：单条通信连路中断



只有主服务器/镜像服务器的连接中断会对镜像造成影响。其他的连路中断，例如主服务器/见证服务器或者镜像服务器/见证服务器之间的通信中断不会改变数据库镜像会话的行为。
总之，表HACL1显示出：
•        所有单条链路中断场景中只有主服务器/镜像服务器链路中断会影响数据库镜像，主服务器运行 状态为exposed，因为没有日志记录发送到镜像。
现在考虑如果第二条连路中断产生的结果。两条连路可以同时中断，也可以相继中断。
如果两条连路同时中断，其最终结果与两条连路相继中断是一样的。但是无法事先预料中断的先后顺序；只有知道了先后次序才能够据此分析链路同时中断的结果。
由于这个原因，我们只考虑链路顺序中断的情形。表12列出了高可用模式中通信链路中断的一些基本场景。
表12。 大部分双-通信链路中断的结果与服务器故障场景中单机故障是一样的。



表HACL2显示所有顺序的双-通信链路失败都等价于前一部分介绍的单服务器故障场景，因此我们不再这里对它们作重复分析了。
值得注意的一点是：
•        两条链路中断时只有一个场景会产生故障转移：主服务器/见证服务器链路中断，随后主服务器/镜像服务器链路中断。
如果主服务器/镜像服务器链路中断，随后主服务器/见证服务器也出现链路中断，那么不会产生故障转移，即使主服务器被孤立而且镜像服务器和见证服务器无法联系上它。
我们再仔细研究一下场景 HACL1.2。

场景 HACL1.2： 主服务器/镜像服务器连路中断，随后主服务器/见证服务器链路中段
如果主服务器/镜像服务器链路中段，随后主服务器和见证服务器之间的链路也中断了，那么主服务器被孤立。它看不到其他服务器并且失去了它的quorum。同时，镜像服务器和见证服务器无法知道主服务器是否依然健在，因此Server B担当起主服务器，然后自动的故障转移产生。图12显示了这些事件。



当主服务器/镜像服务器以及主服务器/见证服务器之间的通信链路相继中断有，Server A被孤立并使其数据库停止服务。Server B和W无法形成quorum，因为Server A可能执行了一些Server B上没有的工作。
如果主服务器/见证服务器 (A/W) 链路中断首先修复，那么Server A继续担当其主服务器角色，状态为  DISCONNECTED。但是不会进行数据库镜像，因为主服务器和镜像服务器之间的连接还没有修复。
如果主服务器/镜像服务器 (A/B) 链路中断首先修复，那么Server A将继续与Server B的数据库竞相，即使没有见证服务器，因此该会话是exposed。除非主服务器/见证服务器连接最终被修复，否则不会产生自动的故障转移。

总结：高可用场景中通信失败：三个站点
下表总结了使用三台独立物理服务器时单链路和双-链路中断的行为。
表中的初始条件是Safety设置为FULL，服务器分别是：
A： 主服务器， SYNCHRONIZED
B： 镜像服务器， SYNCHRONIZED
W： 见证服务器， CONNECTED
使用灰色加亮显示故障转移路径。

场景 HACL4： 两个站点，见证服务器位于镜像服务器站点
如果所有服务器之间仅有一条通信连路，那么必须选择见证服务器的位置。首先，假设见证服务器和镜像数据库服务器放置在一起。两组服务器之间仅有一条通信连路，该链路可能中断，如图13所示。



Server A看不到见证服务器Server W或者镜像数据库服务器Server B，因此无法组成quorum。 Server B和Server W可以组成quorum，但二者均无法看见主服务器Server A。链路中断的结果显示在图14。



因为Server A无法看见见证服务器Server W或者原先的镜像伙伴Server B，因此必须进入disconnected状态并使数据库不可用。
Server B和Server W可以组成quorum。Server B无法看见Server A，因此Server B试图成为主服务器并使其数据库联机。因为Server W也看不到Server A，因此同意了Server B。 Server B现在有了quorum，担当起会话的主服务器角色，然后还原其数据库。
如果恢复通信连路，Server A能够看到Server B如今成为主服务器，并检测到见证服务器Server W也认可Server B为主服务器。Server A将其角色转换为镜像服务器，然后尝试与新主服务器同步。同步之后的配置结果如图15所示。



总结：见证服务器位于镜像服务器的远程站点上，如果站点间的通信链路中断，自动的故障转移产生。
场景 HACL5： 两个站点，见证服务器位于主服务器站点
在这个高可用场景中，假设将见证服务器放置在主服务器所在的同一站点上，如图16所示，然后两个站点间的通信中断了。



在这种情况下，负责镜像数据库的Server B被主服务器和见证服务器孤立。Server A和Server W继续组成quorum，因此Server A保持其数据库为主数据库。但是，Server A同时将数据库设置成disconnected状态，因为它无法看到Server B也不可能进行数据传输。Server B也无法看到Server A，因此也进入disconnected状态。配置结果如图17所示。



Server A继续接受事务但无法截断事务日志记录。如果迅速恢复了链路，镜像会话还可以重新同步并返回到初始操作状态。
总结：见证服务器和主服务器位于同一站点，镜像服务器位于远程站点，站点之间的通信中断不会产生自动的故障转移。
总结： 高可用场景中通信连路中断
在使用三台独立服务器的高可用配置中，有三条独立的通信连路。
•        主服务器/镜像服务器出现通信失败，没有自动的故障转移会发生。
•        主服务器/见证服务器首先出现通信失败，随后主服务器/镜像服务器通信中断 ，自动的故障转移将发生。恢复链路将继续反方向的数据库镜像。
•        镜像服务器/见证服务器通信失败，没有自动的故障转移会发生。
在只有一条通信连路的高可用配置模式中，见证服务器驻留在主服务器或者镜像服务器所在站点上。
•        见证服务器驻留在镜像服务器的远程站点上，如果站点之间的通信链路中断，那么自动的故障转移将发生。
•        见证服务器和主服务器位于同一站点上，镜像服务器在远程站点，站点之间的通信中断不会导致自动的故障转移发生。

高保护方案
高保护模式配合safety FULL一起工作，但没有见证服务器。因为镜像配置中只包括主数据库服务器和镜像数据库服务器，因此只有一条通信连路。这使场景数量大大降低。
场景 1。 高保护操作模式只包括两个SERVER实例，主服务器和镜像服务器。由于没有见证服务器，自动的故障转移师不可能的。服务器之间仅有一条通信连路会中断，导致配置结果如图18所示。



因为safety设置为FULL，并且主服务器不再和镜像服务器组成quorum，主服务器必须使数据库成为disconnected而且无法服务于用户活动。
场景2。 高保护场景中如果镜像数据库不可用，那么主服务器不变，如图19所示。



场景3。 高保护场景中如果主数据库不可用，那么镜像数据库必须继续担任镜像，但进入disconnected状态，如图20所示。



因为高保护操作模式使用safety FULL，因此任何破坏都导致主数据库比可用，而镜像数据库继续维持recovering状态：没有数据库是联机的。其结果是：该模式对于高可用性需求而言不是一个好的解决方案，因此更适合作为一种临时方案，如必须将见证服务器移除一小段 时间。

高性能方案
高性能操作模式配合safety OFF一起工作。 没有见证服务器角色。因为镜像配置中只包括主数据库服务器和镜像数据库服务器，因此只有一条通信连路。尽管类似于高保护模式，但由于safety设置为OFF，因此其行为与高保护模式并不相同。
场景1。 在高性能操作模式中使用两个SQL SERVER实例。一个负责主数据库另一个负责镜像数据库。因此服务器之间只有一条通信连路并且可能中断，导致如图21所示的配置结果。