SQL SERVER 2005数据库镜像

通过第七期和第八期的文章，我们了解了SQL SERVER 2005数据库的原理、实现方式以及SQL SERVER 2005在高可用、高性能和高保护模式下会有不同的数据库镜像状态，而且了解了SQL SERVER 2005在不同应用模式下故障转移的方式。接下来，我们将根据以下两类事件对数据库镜像预期的可用性进行分析：
一个或多个服务器或者数据库失败
服务器之间一条或多条通信链路失败
一般来讲，服务器失败可能是由于某个镜像伙伴数据库或者某个SQL SERVER 2005实例不可用。此外，即使服务器本身可以继续运转，但是数据库镜像伙伴服务器之间的通信链路可能中断。以下场景中，两个组件的同时失败被视为一个组件紧接着另一个组件的顺序失败。例如，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），那么旧的主服务器将在此次会话中承担新镜像服务器角色。
5、 当safety设置为FULL，并且会话中没有见证服务器，或者见证不知何故退出了会话，镜像伙伴服务器的失败将导致无法组成quorum，主服务器也因此不再保持主数据库可以使用。
高可用场景中服务器失败
高可用操作模式下的数据库镜像其目的就是尽可能增加数据库的可用性，在这种模式下，如果主数据库无法访问，那么数据库镜像将迅速使镜像数据库可以接受访问。在下面的高可用场景中，Server A作为主服务器启动，Server B是镜像服务器，而Server W是见证服务器，如图所示：
所有这三台服务器可以在同一个站点使用局域网连接，也可以在不同的站点使用WAN进行连接。Server A和Server B可以互换角色，但是Server W始终作为见证服务器。
下面来看其中一台服务器出现故障产生的结果：
H1、主服务器失败：主服务器A失败后，镜像和见证服务器组成quorum，自动的故障转移产生，如果重新恢复了原始的主服务器，它将担当起镜像服务器的角色。
H2、主服务器失败，随后新的主服务器失败：同H1场景一样，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的数据库镜像过程。
H3、主服务器失败，随后见证服务器失败：当主服务器（Server A）失败，依照H1场景，镜像服务器（Server B）成为主服务器，这时如果紧接着见证服务器 （Server W）也出现失败，那么新的主服务器Server B依然为主服务器，但是被孤立，无法组成quorum，也不能提供数据库服务。
H4、镜像服务器失败：如果镜像服务器首先失败，那么主服务器被视为exposed，因为主服务器无法发送数据给镜像服务器，因此在高可用模式下，当镜像服务器Server B失败时，主服务器仍然能够提供数据库服务，但是不产生故障转移。
H5、镜像服务器失败，随后主服务器失败：当镜像服务器Server B失败后，主服务器Server A仍然能够提供数据库服务，但是不能够故障转移，这时如果主服务器Server A也发生失败，那么见证服务器被孤立。这时如果Serve B首先恢复，它将从见证服务器Server W处检测到Server A依然为主服务器并且还没有产生故障转移，Mirroring_failover_lsn也没有增加，其结果为，Server B依然为镜像服务器。Server W恢复后会话还原到初始状态。
H6、镜像服务器失败，随后见证服务器失败：镜像服务器失败，随后见证服务器也失败，那么主服务器被孤立，并且无法和任何其它服务器组成quorum，因此这时主服务器将断开所有的用户连接，停止提供数据库服务。如果镜像服务器Server B首先恢复，那么数据库镜像将重新开始提供服务，但不能够实现故障转移。如果Server W首先恢复，那么主服务器开始提供服务，也不能够实现故障转移。
H7、见证服务器失败：当见证服务器失败时，数据库镜像继续进行，但是不能产生自动的故障转移，如果再有一台或多台服务器失败，就意味着没法组成quorum，那么主服务器上的数据库也不在提供服务。
H8、见证服务器失败，随后主服务器失败：见证服务器首先失败，那么数据库镜像将继续进行，但是不可能产生自动的故障转移，其余两台服务器中任何一台失败将导致无法组成quorum，余下的那台服务器将被孤立。如果Server W首先恢复，那么Server B将从见证服务器中检测到最后的主服务器是Server A，同时Server B依然是镜像服务器，最终Server A恢复时，它将保持其主服务器角色。
通过上面的8个场景可以得出几个结论，再高可用操作模式下：
1、 如果主服务器首先不可用，那么产生自动的故障转移，原先的镜像服务器将担当主服务器角色，并使其数据库服务于用户活动。后续的服务器失败和恢复不会影响使用新主服务器的数据库镜像的整体配置。
2、 如果镜像首先不可用，那么产生自动的故障转移，后续的服务器失败以及恢复次序都不会影响镜像伙伴角色。
3、 如果见证服务器首先不可用，那么不可能产生自动的故障转移，镜像伙伴服务器将保持其初始角色。后续的服务器失败以及恢复都不会影响镜像伙伴角色。
此外在使用三台独立服务器的高可用配置中，有三条独立的通信链路，由于通信链路的失败和服务器失败的场景类似，在此仅总结链路失败后的结论：
1、 主服务器/镜像服务器出现通信失败，没有自动的故障转移发生。
2、 主服务器/见证服务器首先出现通信失败，随后主服务器/镜像服务器通信中断，自动的故障转移发生，恢复链路将继续反方向的数据库镜像。
3、 镜像服务器/见证服务器通信失败，没有自动的故障转移会发生。
在只有一条通信链路的高可用配置模式中，见证服务器驻留在主服务器或者镜像服务器所在站点上，链路失败后结论如下：
1、 见证服务器驻留在镜像服务器的远程站点上，如果站点之间的通信链路中断，那么自动的故障转移将发生。
2、 见证服务器和主服务器位于统一站点上，镜像服务器在远程站点，站点之间的通信中断不会导致自动的故障转移发生。
通过上述高可用场景的分析，我们对SQL SERVER 2005数据库镜像有了比较深刻的认识，SQL SERVER 2005现在至少支持四种高可用性技术，尽管不同技术相互之间有些功能重叠，但每种技术都有各自的优缺点。这些技术是：
◆数据库镜像 – 为了便于讨论，我们将考虑高可用操作模式。
◆故障转移群集 – 最典型的配置就是2节点的Windows故障转移群集配置一个SQL SERVER实例。
◆ 日志传送 – 采用SQL SERVER内置的日志传送和一个独立的监视服务器。
◆ 事务复制 – 一台分发服务器和一台订阅服务器，如果发行服务器失败，订阅服务器作为备用服务器。

数据库镜像和群集
数据库镜像和故障转移群集最主要的差异就是提供了不同级别的冗余，数据库镜像提供的保护是数据库级别的，而群集提供的保护是服务器实例级别的。另一个主要差别就是在数据库镜像中，主服务器和镜像服务器是独立的 SQL SERVER实例，两个实例有不同的名称；而群集中的 SQL SERVER实例则使用相同的虚拟服务器名称和IP地址，而且无论哪个节点主持群集实例，虚拟服务器名称和IP地址始终保持不变。
如果您的业务需要在服务器一级的数据库保护（例如，您的应用程序需要同时访问同一服务器上的多个数据库），故障转移群集将是更适合的选择。但是，如果每次只须为一个数据库提供可用性，那么数据库镜像具有更多优势。
数据库镜像不像群集那样需要专门的硬件，也没有共享存储介质失败的潜在危险。数据库镜像可以在最短时间内让备用数据库开始提供服务，其速度快于任何其它的高可用技术。
不能在群集中使用数据库镜像，但是可以考虑使用数据库镜像作为一种手段来创建群集数据库实例的一个热备用份。这样做需要特别小心，因为群集的故障转移时间长于数据库镜像的超时值，高可用模式下的镜像会话将对群集的故障转移做出反应，认为这是主服务器失败了，然后会将群集节点设置为镜像状态。
数据库镜像和事务复制
数据库镜像和事务复制都建立在读取原始服务器事务日志的基础上，事务复制多用于配置高可用性，因为它可以将发行数据库中的用户事务在几秒钟内递送到订阅数据库中。数据库镜像的优点是速度等于甚至快于复制，但需要递送所有的数据库事务，而不单单是与用户表相关的事务。
事务复制技术适合于将数据扩充到多个订阅者。事务复制的订阅数据库通常是只读的，如果需要近乎实时的数据访问，那么事务复制是理想的候选者。
数据库镜像与事务复制兼容，如果需要维持发行数据库的一个热备份，数据库镜像就是非常有用的一种方式。其它用于保护复制发行商的方式，事务复制将事务日志递送给订阅者的速度要快于事务日志备份。正是因为数据库镜像速度很快，因此特别适合用于维持发行数据库的热备份。
数据库镜像和日志传输
数据库镜像和日志传输都依赖SQL SERVER数据库提供的恢复和还原功能。在数据库镜像中，镜像数据库始终保持recovering状态，连续不断地还原来自主数据库的事务日志。而日志传输中的备用数据库则周期性地应用事务日志备份中的事务。因为bulk-logged数据被附加到事务日志备份中，因此日志传送可以工作在bulk-logged恢复模型下。数据库镜像则不同，它直接将日志记录从主数据库传送到镜像数据库中而且不能递送bulk-logged数据。
很多情况下数据库镜像可以提供与日志传送相同的数据冗余以及更高的可用性和自动故障转移。但是，如果应用程序依赖一台服务器上的多个数据库，那么日志传送是有效的方式。
结论
数据库镜像是SQL SERVER 2005中的新技术，可以实现高可用性和高性能的数据库冗余解决方案。在数据库镜像中，当主数据库的事务日志缓冲区被写入磁盘时（硬化的），事务日志记录就从主数据库直接发送到镜像数据库。这种技术可以使镜像数据库几乎和主数据库的数据保持同步，同时不会丢失提交的数据。在高可用性操作模式中，如果主服务器失败了，那么镜像服务器将自动成为新的主服务器并还原数据库。使用新的ADO.NET或者SQL Native Access Client驱动程序，应用程序还可以从自己的服务器上进行自动的故障转移，数据库镜像成为SQL SERVER 2005提供的高可用技术家族中的新成员，为成长型企业在各个发展时期提供一个灵活的业务连续性解决方案。