关于SQL Server 群集的几个关键技巧

核心提示： 数据库镜像可能是最适合替代群集的一种方法，镜像涉及到三个元素：存储镜像数据库的实例称为主体；备份服务器称为镜像；如果要实现自动故障转移，关于SQL Server 群集的几个关键技巧(6)，还需要第三台服务器，称为见证方，您可以在运行于某群集中的 Microsoft Virtual Serv

数据库镜像可能是最适合替代群集的一种方法。镜像涉及到三个元素：存储镜像数据库的实例称为主体；备份服务器称为镜像；如果要实现自动故障转移，还需要第三台服务器，称为见证方。简而言之，主体上的数据库中的事务会在镜像中再次运行。当主体出现故障时，如果有见证方，数据库会自动故障转移到镜像。您必须为每个应用程序数据库设置镜像，但不能镜像系统数据库。

镜像是单独的 SQL Server 实例，与群集不同的是，镜像可以位于几千英里以外。其高速缓存中填充的是由于从主体中复制事务而发生的更新活动。当然，还可以假设，除了从主体接收镜像事务之外，镜像上没有其他活动。既然 SQL Server 已经在镜像中运行，所以，故障转移的速度通常要比在群集中快。由于至少有部分高速缓存已准备好，所以，初始性能并不像在群集方案中那样低。另请注意，当镜像数据库发生故障转移时，主体和镜像会互换角色。

数据库镜像的不足之处是，需要的总磁盘容量是群集的两倍。如果您想在同步模式下运行且不想丢失任何数据，那么您还会需要更多的 CPU 处理能力。正如我所说的，要想实现高可用性，需要花费很高的成本。

组合方法

由于镜像与主体之间的距离可以相当遥远，所以对于灾难恢复 (DR) 计划来说，选择镜像是非常明智的。群集是您的第一道防线。但是，如果您要同时利用群集和镜像，那会出现什么情况呢？在群集故障转移中，如果您的镜像配置中有见证方，则当群集 SQL Server 转入在线状态时，镜像会成为主体。但是，请注意，从新主体回到（群集的）新镜像的故障转移不是自动进行的。因此，当与群集结合使用时，最好不要对您的镜像数据库启用自动故障转移。

灾难恢复并不是您使用镜像的唯一原因；当您必须向主体应用服务包或修补程序时，镜像也是非常有用的。在这种情况下，您可以手动故障转移到镜像。在应用服务包或修补程序时，旧的主体服务器暂时处于离线状态，在新主体上发生的已提交事务会排队等候，等待被发送回新镜像（旧主体）。在完成服务包或修补程序的安装之后将会进行同步。最终，这两台服务器将完全处于同步状态。现在您便可以在主体和镜像之间转换角色了。故障转移与恢复只需要几秒钟的停机时间。您可以使用这种方法将 SQL Server 迁移到另一台计算机。只是不能实现故障恢复。

虚拟服务器添加灵活性

虚拟化允许您在一台物理服务器上并行运行一个或多个操作系统。虚拟化软件为群集概念添加了另外一层功能，因为您可以将软件加入群集。因此，如果主机正在其上运行的服务器出现故障，则主机及其来宾 OS 会故障转移到备份节点。这可能是迁移来宾服务器的最简便方法。补充一点，来宾 OS 不必具有群集功能。因此，您可以在运行于某群集中的 Microsoft Virtual Server 2005 之上的来宾 Windows Server 2003 内部运行 SQL Server Workgroup Edition。实质上，您会间接拥有群集 Workgroup Edition（请参见图 2）。

Figure 2 Using a virtual server (单击该图像获得较大视图)