概述

数据库镜像是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 [] 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 DATABASESET 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 serverALTER 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 serverALTER DATABASE [AdventureWorks] SET PARTNER =N'TCP://A.corp.mycompany.com:5022';

接下来在主服务器上指定见证服务器：

-- Specify the witness from the principal serverALTER DATABASE [AdventureWorks] SET WITNESS = N'TCP://W.corp.mycompany.com:5026';

执行完CREATE ENDPOINT后见证服务器上就不需要执行其他命令了。

最后，在主服务器上指定会话的safety级别：

-- Set the safety level from the principal serverALTER DATABASE [AdventureWorks] SET SAFETY FULL;

此时，镜像将自动启动，然后主服务器和镜像服务器将进行同步。

可以调整判定镜像伙伴是否故障的超时值，使用ALTER DATABASE命令的TIMEOUT参数。例如将TIMEOUT值改为20秒（默认是10），在主服务器上执行：

-- Issue from the principal serverALTER DATABASE [AdventureWorks] SET PARTNER TIMEOUT 20;

最后，在主服务器上使用ALTER DATABASE和REDO_QUEUE选项可以镜像服务器上redo队列的大小。下面的查询将镜像服务器的redo队列设置为100兆：

-- Issue from the principal serverALTER 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_lsnFROM sys.database_mirroringWHERE 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_nameFROM 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所示：

图1：示例数据库镜像会话在高可用操作模式下启动

所有这三台服务器可以在同一个站点使用局域网连接，也可以在不同的站点使用WAN进行连接。Server A和Server B可以互换角色，但是Server W始终作为见证服务器。

现在来考虑如果其中一台服务器出现故障时产生的结果。

场景 HASL1.1：主服务器失败

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

图2：在高可用模式下，当主服务器Server A失败，故障转移发生

主服务器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）始终保持其主服务器的角色。

图3：由于主服务器失败，接着新主服务器也失败而导致角色转换

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所示：

图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，即镜像服务器失败时的行为。

图5：在高可用模式下，当镜像服务器Server B失败时不产生故障转移

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

下表显示了镜像服务器Server B失败以及恢复时数据库状态。

由于没有镜像服务器，数据无法存放在冗余数据库中，因此会话处于exposed。

Server B一旦恢复立刻重新担当起它的镜像服务器角色。只要两台服务器同步，镜像会话就不再被视为exposed。

接下来的两个场景考虑镜像服务器Server B失败，紧接着主服务器Server A或者见证服务器Server W失败时产生的结果。

场景 HASL2.2：镜像服务器失败，随后主服务器失败

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

图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右上角所示。

图7：A镜像服务器失败，随后见证服务器失败，导致主服务器无法提供数据库服务

由于镜像服务器故障以及随后的见证服务器失败，主服务器 Server A保持其主服务器角色，由于无法和任何其他服务器组成quorum，而safety又被设置成FULL，因此不再为数据库提供服务，并断开所有的用户连接。

如果Server B首先恢复，那么数据库镜像将重新开始工作，尽管由于缺失见证服务器而不会产生自动故障转移。

如果Server W首先恢复，那么情况与图5中显示的一样。

注意：如果Server A在Server B和Server W相继失败之后也宣告失败，那么以任何次序还原这些服务器其最终结果保持不变。

场景 HASL3.1：见证服务器失败

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

图8：在高可用模式下，见证服务器Server W首先失败，那么数据库镜像继续

Server W恢复后，两个伙伴服务器Server A和Server B维持它们的初始角色。

下表显示了见证服务器失败以及恢复后，数据库状态以及quorum的变化。

下面的两个场景考虑见证服务器Server W失败，紧接着主服务器 Server A或者镜像服务器Server B失败时产生的结果。

场景 HASL3.2：见证服务器失败，随后主服务器失败

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

图9：原始见证服务器失败，随后主服务器失败，镜像伙伴角色保持不变

如果Server W首先恢复，那么Server B将从见证服务器那里检测到最后的主服务器是Server A，同时Server B依然是镜像服务器。最终Server A恢复时，它将保持其主服务器角色。

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

场景 HASL3.3：见证服务器失败，随后镜像服务器失败

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

图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：高可用配置中三台独立服务器、三条独立通信连路的初始状态

注意：要获得页面上图表的解释，请参阅前面介绍的“高可用场景中服务器失败”

根据图11，三条链路可能首先中断：A/B， A/W和B/W。注意当某条通信连路中断时，所有三台服务器依然运转正常。只有主服务器和镜像服务器之间的通信连路有一些影响，如表11所示。

表11：总结：单条通信连路中断

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

由于这个原因，我们只考虑链路顺序中断的情形。表12列出了高可用模式中通信链路中断的一些基本场景。

表12：大部分双-通信链路中断的结果与服务器故障场景中单机故障是一样的 

 表HACL2显示所有顺序的双-通信链路失败都等价于前一部分介绍的单服务器故障场景，因此我们不再这里对它们作重复分析了。 

值得注意的一点是： ◆两条链路中断时只有一个场景会产生故障转移：主服务器/见证服务器链路中断，随后主服务器/镜像服务器链路中断。 如果主服务器/镜像服务器链路中断，随后主服务器/见证服务器也出现链路中断，那么不会产生故障转移，即使主服务器被孤立而且镜像服务器和见证服务器无法联系上它。 我们再仔细研究一下场景 HACL1.2。 

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

图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 使用灰色加亮显示故障转移路径。 

表13：总结：单条链路中断和双-链路中断，高可用模式，三台独立服务器，Safety设置为FULL

场景 HACL4：两个站点，见证服务器位于镜像服务器站点 

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

图13：主服务器和镜像服务器/见证服务器站点之间的通信连路中断了

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

图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所示。 

图15：该场景通信连路恢复后的版本，数据库镜像按反方向进行 

总结：见证服务器位于镜像服务器的远程站点上，如果站点间的通信链路中断，自动的故障转移产生。

场景 HACL5：两个站点，见证服务器位于主服务器站点 在这个高可用场景中，假设将见证服务器放置在主服务器所在的同一站点上，如图16所示，然后两个站点间的通信中断了。

 图16：主服务器/见证服务器和镜像服务器之间的通信中断 

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

图17：该场景中通信失败导致两个伙伴为disconnected状态

Server A继续接受事务但无法截断事务日志记录。如果迅速恢复了链路，镜像会话还可以重新同步并返回到初始操作状态。 总结：见证服务器和主服务器位于同一站点，镜像服务器位于远程站点，站点之间的通信中断不会产生自动的故障转移。

总结：高可用场景中通信连路中断 在使用三台独立服务器的高可用配置中，有三条独立的通信连路。 

◆主服务器/镜像服务器出现通信失败，没有自动的故障转移会发生。
◆主服务器/见证服务器首先出现通信失败，随后主服务器/镜像服务器通信中断 ，自动的故障转移将发生。恢复链路将继续反方向的数据库镜像。
◆镜像服务器/见证服务器通信失败，没有自动的故障转移会发生。
在只有一条通信连路的高可用配置模式中，见证服务器驻留在主服务器或者镜像服务器所在站点上。
◆见证服务器驻留在镜像服务器的远程站点上，如果站点之间的通信链路中断，那么自动的故障转移将发生。
◆见证服务器和主服务器位于同一站点上，镜像服务器在远程站点，站点之间的通信中断不会导致自动的故障转移发生。 高保护方案 高保护模式配合safety FULL一起工作，但没有见证服务器。因为镜像配置中只包括主数据库服务器和镜像数据库服务器，因此只有一条通信连路。这使场景数量大大降低。 场景1：高保护操作模式只包括两个SERVER实例，主服务器和镜像服务器。由于没有见证服务器，自动的故障转移师不可能的。服务器之间仅有一条通信连路会中断，导致配置结果如图18所示。 

图19：高保护场景中如果镜像服务器不可用 ，那么主数据库不受影响 

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

图20：高保护场景中如果主数据库不可用，那么镜像数据库进入disconnected状态 

因为高保护操作模式使用safety FULL，因此任何破坏都导致主数据库比可用，而镜像数据库继续维持recovering状态：没有数据库是联机的。其结果是：该模式对于高可用性需求而言不是一个好的解决方案，因此更适合作为一种临时方案，如必须将见证服务器移除一小段时间。 高性能方案 高性能操作模式配合safety OFF一起工作。没有见证服务器角色。因为镜像配置中只包括主数据库服务器和镜像数据库服务器，因此只有一条通信连路。尽管类似于高保护模式，但由于safety设置为OFF，因此其行为与高保护模式并不相同。 场景1：在高性能操作模式中使用两个SQL SERVER实例。一个负责主数据库另一个负责镜像数据库。因此服务器之间只有一条通信连路并且可能中断，导致如图21所示的配置结果。

图21：高性能场景中通信失败，两个伙伴均进入disconnected状态，但是主数据库依然可用 

由于safety设置为OFF， Server A不需要quorum就可以使数据库保持为可用状态。因此尽管已经进入disconnected状态，主服务器还可以继续接受用户活动。如果通信恢复，那么镜像数据库将尝试追赶主数据库但无法做到，或者出现redo错误，如果它不能找回所有丢失的事务。 场景2：在高性能场景中，如果镜像数据库不可用，那么主数据库结果显示在图22中。

图22：如果在高性能模式下镜像服务器不可用，主数据库不受影响

由于safety设置为OFF，因此主数据库依然可用。 场景 3：如果在高保护模式下主数据库不可用，那么镜像数据库依然作为镜像，但将被断开，如图23所示。 

图23：如果主服务器不可用，那么Server B不会受到影响，但是进入disconnected状态 高性能操作模式和高保护模式一样，没有自动的故障转移。由于safety设置为OFF，当镜像服务器不可用时，主服务器将保持其数据库为可用。同样由于safety设置为OFF，不保证事务一定到达镜像数据库。如果强制故障转移到镜像服务器，那么有些事务可能会因此丢失。 

实现数据库镜像 可以在SQL SERVER 2005 Books Online，数据库镜像主题的“How To”中找到实现数据库镜像的基本信息。在白皮书的这一部分，我们来研究实现数据库镜像的一个特殊示例以及最佳实践。 

监视数据库镜像 通过在SQL SERVER 2005 Management Studio的Object Explorer中检查主数据库和镜像数据库，可以查明每个数据库镜像伙伴的状态。如果主数据库和镜像数据库是同步的，那么Object Explorer就在主数据库名称的后面附加一个（Principal， Synchronized）消息，在镜像服务器名称的旁边附加一个（Mirror， Synchronized）。可以在主服务器上弹出的数据库 Properties对话框中观察Mirroring页面下方的状态框，从而检查数据库镜像会话的状态。（数据库 Properties对话框不会在镜像服务器上打开）。 还可以查询数据库镜像目录视图sys.database_mirroring和sys.database_mirroring_witnesses（更多关于使用目录视图检查镜像会话中数据库状态的信息，请参阅该白皮书前面数据库动态部分的“Database Mirroring Catalog View Metadata”。SQL SERVER Books Online中也包含了目录视图的完整文档。） 

数据库镜像性能计数器 可以使用性能计数器监视数据库镜像会话中镜像伙伴之间的网络流量。SQL Server Database Mirroring对象包含了大量有用的性能计数器来监视主服务器和见证服务器。（参阅SQL Server Books Online中的"Monitoring Database Mirroring"） 可以在每个数据库上设置Database Mirroring对象。如果需要在一台服务器上监视不止一个数据库，那么既可以单独监视某个数据库的活动，也可以监视所有数据库的全部活动。 对于主服务器，Log Bytes Sent/sec 计数器指示主服务器发送日志数据到镜像服务器的速率，而Log Send Queue指示在某个给定时间点事务日志缓冲区中有多少字节要发送到镜像服务器。随着事务日志记录从主服务器发送到镜像服务器，主服务器的发送队列将逐渐缩小，但也会随着新的日志记录进入日志缓冲区而增长。主服务器上的Transaction Delay 计数器指示主服务器由于等待镜像服务器关于日志接收的确认消息导致的延迟。主服务器上的Sent/sec计数器与主服务器给镜像服务器发送的数据页面有关。 在镜像服务器上，Log Bytes Received/sec指示镜像服务器和主服务器之间相差多少。（见上面Log Bytes Sent/sec 计数器）。Redo Queue 计数器指示redo队列的大小。镜像服务器在redo阶段使用redo队列重新执行来自主服务器的事务。Redo Bytes/sec指示镜像服务器执行redo队列中事务的速率。 对于每个伙伴服务器，Sends/sec和Receives/sec 计数器指示有多少个发送和接收动作Bytes Sent/sec和Bytes Received/sec 计数器指示在每个伙伴服务器上那些发送和接收动作包含的字节数。 

估计Redo和Catch-up时间 如果出现故障转移，可以使用Redo Queue和Redo Bytes/sec来估算镜像数据库完成redo并成为可用状态需要花费的时间。使用下面的简单公式进行计算： 估计的redo时间（秒） =
(Redo Queue)/(Redo Bytes/sec) 类似的，如果主服务器上的活动领先于镜像服务器，可以使用Log Send Queue和Log Bytes Received/sec 计数器估算镜像服务器追赶上主服务器需要花费的时间。下面给出了计算公式： 估计的catch up时间（秒） =
(Log Send Queue)/( Log Bytes Received /sec) 

Profiler事件 SQL Server 2005 Profiler包含了一个数据库镜像事件类。Database:Database Mirroring State Change事件将记录被监视服务器是否发生了状态改变。（参见SQL Server Books Online主题“Database Mirroring State Change Event Class”）。当使用这个事件类时包含Database Name和State来会对您大有帮助。可以使用该事件通知您数据库镜像会话中的任何状态改变。 

数据库镜像排错 数据库镜像最容易出错的地方就是配置过程和运行过程。 

排除设置错误 如果已经设置了数据库镜像但是无法启动，那么重新开始所有配置步骤。 

1.确认镜像服务器尽可能接近主数据库。如果尝试启动数据库镜像时收到了以下的错误消息： 远程“AdventureWorks”数据库没有前滚到本地数据库日志副本中包含的一个时间点。（Microsoft SQL SERVER， 错误：1412） 说明镜像数据库滞后于主数据库。需要将主数据库的事务日志备份应用到镜像数据库（使用NORECOVERY），从而使镜像数据库恢复到某个时间点，并可以从此时间点开始接收来自主数据库的日志记录。 

2.确认每个服务器的SQL SERVER Windows服务帐户彼此相互信任。如果服务器所在的域没有建立信任关系，那么确保证书是正确的。 

3.通过查询sys.database_mirroring_endpoints目录视图，确认不仅定义而且启动了endpoint： 

SELECT * FROM sys.database_mirroring_endpoints;

 确认使用了正确的完全限定计算机名称以及正确的端口号。如果在一台物理服务器的多个实例之间配置镜像，那么端口号就必须是唯一的。SQL SERVER服务登陆帐号需要CONNECT到endpoint的访问权限。 最后，确认为服务器定义了正确的endpoint角色。 

4.确认在ALTER DATABASE命令中指定了正确的镜像伙伴名称。可以在主服务器和镜像服务器的sys.database_mirroring目录视图中（以及高可用模式下的sys.database_mirroring_witnesses witnesses）检查镜像伙伴名称。 

排除运行时错误 如果数据库镜像设置正确，然后在运行过程中出现了错误，请检查会话的当前状态。如果由于错误而使镜像处于SUSPENDED状态，就可能在镜像服务器上产生redo错误。检查并确认镜像服务器上有足够的磁盘空间用于redo（数据文件所在分区的剩余空间）和日志hardening（日志文件所在分区的剩余空间）。当您准备重新启动会话时，使用ALTER DATABASE来重新开始会话。 如果无法连接到主数据库，最可能的原因就是safety设置为FULL并且主服务器无法组成quorum。这种情况能够发生，例如，如果系统在高保护模式下运行（safety为FULL但没有见证服务器），镜像服务器又断开了和旧的主服务器的联系。可以在镜像服务器上使用下面的命令强制镜像服务器进行恢复： 

ALTER DATABASE [AdventureWorks] SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

 问题就在于一旦恢复了镜像数据库，镜像服务器将成为主服务器但却无法形成quorum，因此无法服务于数据库。如果那样的话，只要把safety设置为OFF就可以允许它服务于数据库了。 

安全性与性能 数据库镜像的性能是关于活动类型和事务安全性的一个函数。 传输日志到镜像服务器会影响主服务器性能。数据库镜像给主服务器带来的开销是关于活动类型的一个函数。数据库镜像在多用户以及大量长事务的系统上操作性能最好，因为数据库服务器正常的事务活动会掩盖传输日志记录到镜像服务器的引起的开销。如果单个用户顺序执行大量短事务，那么数据库镜像给每个事务造成的开销将十分显著。 主服务器性能同样受Safety设置的影响。当safety设置为FULL时，主服务器必须等待镜像服务器表示已经收到日志记录的确认信息，才可以将事务提交消息返回给客户端。如果有大量的用户和大量的长事务，那么这种等待导致的开销并不明显。单线程系统和包含许多小事务的系统在safety OFF时可以运行的更好。 因为镜像服务器连续不断地重新执行从主服务器接收的数据更新事务，镜像服务器的数据缓存将变得'hot'。换句话说，就是使用那些和主服务器类型相同的数据更新操作所涉及的数据页面和索引页面来加工缓存。为了使镜像服务器的缓存更接近于主服务器缓存，数据库镜像将一个SELECT提示也传递给镜像服务器，从而可以在镜像服务器重新生成用于数据查询的缓存内容。这样可以帮助镜像服务器更接近于主服务器，同时减少故障转移时剩余的redo时间。很明显，镜像服务器上任何其他活动，包括对数据库快照的查询也会影响缓存的状态，并因此增加故障转移时完成日志redo的时间。 

测试数据库镜像 当设置自己的系统来测试数据库镜像时，有许多选项可用。所有数据库镜像都要求在数据库镜像会话中的服务器必须是不同的SQL SERVER实例。因此可以在一台物理服务器上配置和测试数据库镜像，如果您安装了多个SQL SERVER 2005关系数据库引擎。也可以在一台虚拟服务器上测试多个实例，但是在物理服务器上进行测试更加可信。 进行数据库镜像的负载和压力测试时需要不同的物理服务器。一台服务器上的两个或者三个实例可能会消耗不切实际的服务器资源。此外服务器之间的网络连接质量也同样重要。主服务器和镜像服务器之间的网络越好，日志记录和消息传送的速度就越快。 最逼真的测试就是在一台真正的目标服务器或者试验台上进行，并且和最终系统的物理属性完全相同。当您在一台服务器上测试多个实例时，只能通过停止实例或者关机的方式来模拟数据库镜像中服务器失败的效果。使用多台物理服务器时，就可以通过断开网线的方式来测试网络连接失败的效果。 

下面的实践能够帮助您创建测试环境： 

◆要测试服务器失败，关闭SQL SERVER实例，通过SQL Configuration Manager或者使用 SHUTDOWN WITH NOWAIT。
◆要测试通信失败，拔掉服务器上的网线。
◆要测试数据库失败，停止SQL SERVER服务，重新命名。mdf文件，然后再重启SQL SERVER。
◆要导致镜像数据库的redo错误， 为主数据库添加一个新文件，将文件存放在主服务器存在但镜像服务器中不存在的分区中。
◆另一种导致镜像服务器redo错误的方法就是强制镜像服务器的数据库文件空间不足。
◆要迫使主服务器的数据库停工，强制主数据库数据文件空间不足。
◆要导致主数据库或镜像数据库日志缓冲区hardening失败，强制日志文件空间不足。

为故障转移准备镜像服务器 数据库镜像其实就是数据库到数据库的联系。只有数据库中的数据会通过日志记录从主数据库发送到镜像数据库。就像日志传送和复制一样，必须准备备用服务器和镜像数据库，以便出现故障时可以完全接管主数据库的工作。当您准备镜像服务器时，应该从以下几个层面进行考虑。 在物理服务器层面，确保备用服务器和主服务器拥有相同的或者尽可能接近的物理CPU和内存配置，否则备用服务器在故障转移后将无法胜任工作。此外可能还有一些支持应用程序、监视器、以及支持程序运行的可执行文件等等，都需要在镜像服务器上进行配置。 在SQL SERVER层面，确保备用服务器和主服务器拥有相同的SQL SERVER配置（例如，AWE、最大并行化程度）。但最重要的就是登陆帐户和账户权限。主服务器上所有激活的SQL SERVER登陆帐户都必须同时存在镜像服务器上，否则一旦出现故障转移，那么应用程序将无法使用这些登陆帐户连接到新的主服务器上。可以使用SQL SERVER集成服务的Transfer Logins任务将登陆帐户和密码从一台服务器拷贝到另一台服务器，但您还必须为这些登陆帐户设置数据库权限。如果将登陆帐户传输到另一个不同的域，那么可能出现不匹配色的SID，需要您去匹配它们。SQL SERVER主服务器上可能还存在大量的支持对象需要被转移到备用服务器上：SQL Agent作业和警报、SQL SERVER集成服务包、支持数据库、连接服务器的定义、备份设备、维护计划、SQL Mail或者数据库设置、可能还有分布式事务协调器（MSDTC）设置，等等。 当SQL Agent作业被传输到备用服务器后，大部分将被迫设置为禁用。一旦出现故障转移，需要您启用这些作业。故障转移后，如果应用程序使用SQL SERVER验证，还需要将SQL SERVER新的主服务器上的登陆帐户解析成新的主服务器上的数据库用户。完成该任务最好的工具就是存储过程sp_change_users_login。 

多数据库的问题 许多应用程序使用一台服务器上的多个数据库。多个数据库可以被一个应用程序引用，也可能被多个应用程序引用。但是数据库镜像每次只能在一个数据库上工作。当您设计数据库镜像时需要考虑这一点。 如果您希望高可用模式，那么最适合的就是一个应用程序配合一个数据库。当自动的故障转移发生时应用程序不再需要主服务器上的任何数据库。考虑如果多个数据库在一台服务器上并且操作在高可用模式下，那么可能出现什么情况呢？如果一台物理服务器掉电了，或者一个SQL SERVER实例失败了，或者网络通信失败了，那么所有数据库将自动故障转移到备用服务器，而他们的镜像将成为新的主数据库。如果见证服务器可用，应用程序可以连接到新的主数据库。但是如果某个数据库由于磁盘失败而产生了分页，因此只有这个数据库被故障转移，那么会发生什么呢？如果那样的话，应用程序就有可能无法连接到所有正确的数据库。
因此依赖多数据库的应用程序不适合使用数据库镜像的高可用模式。您可以将safety设置成OFF，实际上就是不使用自动故障转移，但您必需使用某种高效的方式保持和其它数据库服务器的同步。 

数据库镜像和高可用性技术 SQL SERVER 2005现在至少支持四种高可用性技术，尽管不同技术相互之间有些功能重叠，但每种技术都有各自的优缺点。

这些技术是： 

◆数据库镜像 – 为了便于讨论，我们将考虑高可用操作模式以及FULL safety和见证服务器。
◆故障转移群集 – 最典型的配置就是2节点的Windows故障转移群集配置一个SQL SERVER实例。
◆日志传送 – 采用SQL SERVER内置的日志传送和一个独立的监视服务器。
◆事务复制 – 一台分发服务器和一台订阅服务器，如果发行服务器失败，订阅服务器作为备用服务器。 在这一部分我们将比较这四种技术的基本功能，然后深入探讨怎样对数据库镜像进行补充或者提供一个更好的解决方案。 下表显示了四种技术的几个高可用性功能。 

表14：比较SQL SERVER 2005高可用性技术 

数据库镜像和群集 数据库镜像和故障转移群集最主要的差异就是提供了不同级别的冗余。数据库镜像提供的保护是数据库级别的，而群集提供的保护是服务器实例级别的。另一个主要差别就是在数据库镜像中，主服务器和镜像服务器是独立的 SQL SERVER实例，两个实例有不同的名称；而群集中的 SQL SERVER实例则使用相同的虚拟服务器名称和IP地址，而且无论哪个节点主持群集实例，虚拟服务器名称和IP地址始终保持不变。 如果您需要在服务器一级的数据库保护（例如，您的应用程序需要同时访问统一服务器上的多个数据库），故障转移群集将是更适合的选择。但是，如果每次只须为一个数据库提供可用性，那么数据库镜像具有更多优势。 数据库镜像不像群集那样需要专门的硬件，也没有共享存储介质失败的潜在危险。数据库镜像可以在最短时间内让备用数据库开始提供服务，其速度快于任何其它的高可用技术。此外，数据库镜像能够与ADO。NET和SQL Native Access Client很好的配合在一起，从而实现客户端的故障转移。 不能在群集中使用数据库镜像，但是可以考虑使用数据库镜像作为一种手段来创建群集数据库实例的一个热备用份。这样做需要特别小心，因为群集的故障转移时间长于数据库镜像的超时值，高可用模式下的镜像会话将对群集的故障转移做出反应，认为这是主服务器失败了，然后会将群集节点设置为镜像状态。 

数据库镜像和事务复制 数据库镜像和事务复制都建立在读取原始服务器事务日志的基础上，但此后采用的技术就截然不同了。（更多关于事务复制的细节，请参阅SQL SERVER Books Online中的相关主题）。事务复制多用于配置高可用性，因为它可以将发行数据库中的用户事务在几秒钟内递送到订阅数据库中。数据库镜像的优点是速度对于甚至快于复制，但需要递送所有的数据库事务，而不单单是与用户表相关的事务。 事务复制技术适合于将数据扩充到多个订阅者。事务复制的订阅数据库通常是只读的，如果需要近乎实时的数据访问，那么事务复制是理想的候选者。 数据库镜像与事务复制兼容，如果需要维持发行数据库的一个热备份，数据库镜像就是非常有用的一种方式。其它用于保护复制发行商的方式，例如日志传送无法在发行商自己的订阅者之前维持发行商的备用服务器。换句话说，事务复制将事务日志递送给订阅者的速度要快于事务日志备份。正是因为数据库镜像速度很快，因此特别适合用于维持发行数据库的热备份。 但是如果发行服务器失败，就必须手动使用还原好的备用数据库重新建立发行商，然后重新连接到分发服务器，， 使用日志传输维护发行商服务器的备用服务器所必须做的工作与此相同。 

数据库镜像和日志传输 数据库镜像和日志传输都依赖SQL SERVER数据库提供的恢复和还原功能。在数据库镜像中，镜像数据库始终保持recovering状态，连续不断地还原来自主数据库的事务日志。而日志传输中的备用数据库则周期性地应用事务日志备份中的事务。因为bulk-logged数据被附加到事务日志备份中，因此日志传送可以工作在bulk-logged恢复模型下。数据库镜像则不同，它直接将日志记录从主数据库传送到镜像数据库中而且不能递送bulk-logged数据。 很多情况下数据库镜像可以提供与日志传送相同的数据冗余以及更高的可用性和自动故障转移。但是，如果应用程序依赖一台服务器上的多个数据库，那么日志传送是有效的方式（参阅前一部分介绍的“Multi-Database Considerations”）。 此外，某些数据库镜像场景中还可以通过日志传送作为补充。例如：您可以某处配置一个高可用数据库镜像，然后将主数据库日志传送到远程站点以提供灾难恢复。图24显示了如何进行这种配置。 

图24：将主数据库日志传送到远程服务器 

这种方式的优点就是：一旦整个站点失败了，第二个站点上的数据还继续可用。但是，如果数据库镜像失败了，从Server B到远程备用服务器的日志传送通常必须重新开始。 其它使用日志传送补充数据库镜像的场景就是作为主服务器的本地备用，主服务器的数据库镜像会话用于灾难恢复。此时，数据库镜像会话运行在高性能操作模式下，远程站点的镜像服务器作为远程备用服务器。 

 
图25：通过主数据库日志传送的方式来保留所有的事务 

在高性能模式中存在的数据丢失，如果主服务器失败并且使用强制恢复服务的方式恢复了镜像服务器。如果您正在对旧的主服务器进行日志传送，并且如果旧的主服务器事务日志文件没有损坏，那么可以对主数据库进行“结尾日志”备份来获得事务日志中最后一组记录。如果备用日志传输数据库已经应用了所有其它的事务日志备份，您就可以将结尾日志备份应用到备用服务器，这样不会丢失旧的主服务器上的任何数据。然后可以对日志传送备用服务器中的数据和远程数据库做个比较，在需要时将丢失的数据拷贝到远程服务器。 当您对比日志传输和数据库镜像功能时，需要明确的一点就是：对主数据库进行数据库和日志备份很重要。将这些日志备份应用到的日志传送服务器可以对数据库镜像配置起到补充作用。 

阅读原文：原文链接