场景

　　公司最近的sharepoint的数据库服务器老是出问题，并且在一旦出现问题，就导致无法正常工作。最主要的是我们要加班还原以前的数据库，这是最头疼的。于是在网上查找资料，实现主备机的同步，对于sharepoint而言我们只需做到sharepoint的内容数据库同步即可。这种技术有个专业名词叫做双机热备。

双机热备原理

双机热备特指基于高可用系统中的两台服务器的热备（或高可用），因两机高可用在国内使用较多，故得名双机热备，双机高可用按工作中的切换方式分为：主-备方式（Active-Standby方式）和双主机方式（Active-Active方式），主-备方式即指的是一台服务器处于某种业务的激活状态（即Active状态），另一台服务器处于该业务的备用状态（即Standby状态)。而双主机方式即指两种不同业务分别在两台服务器上互为主备状态（即Active-Standby和Standby-Active状态）。

我们主要是通过SQL Server 2005 订阅复制功能来实现双机热备，如下图所示：

SQL Server 2005 订阅复制原理

下面的概述来自微软官方的MSDN

SQL Server 2005 复制种类

事务复制概述：

　　　　　　　　　　事务性复制通常从发布数据库对象和数据的快照开始。拍摄初始快照后，随后在发布服务器中所做的数据更改和架构修改通常在修改发生时便传递给订阅服务器。数据更改在订阅服务器中应用的更改顺序以及更改所处的事务边界与在发布服务器中相同。

事务性复制通常用于服务器到服务器环境中，在以下各种情况下适合采用事务性复制：

希望发生增量更改时将其传播到订阅服务器。
从发布服务器中发生更改，到更改到达订阅服务器，应用程序需要这两者之间具有较低的滞后时间。
应用程序需要访问中间数据状态。例如，如果某一行更改了五次，事务复制允许应用程序对每次更改做出响应，而不只是对该行的最终数据更改做出响应。
发布服务器有大量的插入、更新和删除活动。
发布服务器或订阅服务器不是 SQL Server 数据库（例如，Oracle）。

合并复制概述

　　　　　　　　　　与事务复制相同，合并复制通常也是从发布数据库对象和数据的报表快照开始。并用触发器跟踪在发布服务器和订阅服务器中所做的后续数据更改和架构修改。订阅服务器与发布服务器在连接到网络时进行同步，并交换自上次同步以来发布服务器和订阅服务器间发生变化的所有行。

合并复制通常用于服务器到客户端的环境中。合并复制适用于下列各种情况：

多个订阅服务器可能会在不同时间更新同一数据，并将这些更改传播到发布服务器和其他订阅服务器。
订阅服务器需要接收数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改。
每个订阅服务器都需要不同的数据分区。
可能会发生冲突。如果发生冲突，则需要具备检测和解决冲突的功能。
应用程序需要最终的数据更改结果，而不是访问中间数据状态。例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器中的行更改了五次，则该行在发布服务器中仅更改一次，并更改为第五个值以反映最终数据更改。

合并复制允许不同站点自主工作，然后在以后将更新合并成一个统一的结果。由于更新是在多个服务器中进行，因此，同一数据可能由发布服务器和多个订阅服务器进行了更新。于是，合并更新时就可能出现冲突。合并复制提供有数种处理冲突的方法。