深入浅出SQL Server Replication第三篇：事物复制实战-建立Publisher

深入浅出SQL Server Replication第三篇：事物复制实战-建立Publisher

对于很多的SQL Server DBA而言，Replication不是什么新鲜的事物了，也是大家常常说的“复制”，很多的朋友已经在项目中使用。正如其他技术一样：有人可以使用的好，有人会抱怨技术不行。

我们AgileSharp团队也经过了不少高可用的案例， Replication还是非常有价值的。因此，我们整理了很多的资源，我们决定发布一系列的Replication文章，一是为了帮助大家了解Replication，另外也是为以后的讲述高可用做个铺垫。

在之前的文章中，我们已经对Replication做了总体的介绍，而且也讲述了如何配置Distributor。那么在本篇文章中，我们将会讲述如何配置Publisher。

Publisher可以看出是数据产生的源头，也是Replication的核心，因为只有Publisher产生了变化，其他的组件的运行才有意义。可以想象得到：一个Publisher可以有很多的Publication，也就是说，一个发布服务器可以有多个发布。其实这一点很好的理解。

这一点拿生活的图书订阅就很好解释了：我们不可能对出版社的所有书都感兴趣，我们只是订阅自己喜欢的书籍，而出版社同时又为很多的读者提供订阅服务器，即发布很多不同的书。

同理，因为一个Publisher发布服务器就是一个数据库实例，这个实例中有多的对象是变化的，如表。但是很多的订阅服务器并不是对所有的这些变化都感兴趣，只对部分感兴趣，所以，我们可以在这个发布服务器上面创建多个Publication发布，从而满足不同的订阅服务器。

在每一个Publication发布中有包含很多的Aritcle（项目），我们知道：项目用于标识发布中包含的数据库对象。一次发布可以包含不同类型的项目，包括表、视图、存储过程和其他对象。当把表作为项目发布时，可以用筛选器限制发送到订阅服务器的数据的列和行。

下面，就带领大家一起创建一个Publication。

 

 

建立Publication

想要创建一个Publication，必须首先要将一个Publisher和Distributor进行关联。我们在上一篇文章中已经讲述了如何创建和配置Distributor，这里就在赘述。

谁可以创建一个Publication发布

要清楚，不是谁都可以创建Publication的。只有具有db_owner的角色的用户才可以创建。

为了使得数据库可以在Replication中使用，我们必须要进行一定的配置。我们在Publisher（发布服务器）的对象管理器中进行如下操作，如图：

20121017144149.png(47.93 K)

10/17/2012 2:48:18 PM

 

在Replication节点上面点击右键，然后开始设置相关的内容，如下图：

2.png(49.20 K)

10/17/2012 2:48:18 PM

 

在弹出的窗口中包含了两个选项。在”General”选项卡中，我们可以设置连接到Distributor的用户的信息，因为Publisher连接到Distributor，肯定是通过某个用户才能连过去的，我们在这里就可以设置这个用户的密码等信息。

在”Publication Databases”选项卡中，我们可以选择哪个数据库将会作为发布源来对外发布数据。并且，还可以选择采用何种复制方式，如事务复制，合并复制。

 

 

 

创建新的Publication

配置好了Publisher之后，就可以创建一个Publication了，其实这个步骤，我们在第一篇文章中也做了简要的展示，如图：

 

4.png(37.73 K)

10/17/2012 3:08:37 PM

 

 

然后根据向导一步步的创建，这里就不在重复，下面直接给出图示：

 

5.png(31.15 K)

10/17/2012 3:08:37 PM

 

 

 

6.png(56.71 K)

10/17/2012 3:08:37 PM

 

 

我们这里演示的是事务复制的示例。

另外，在其中，还有一个另外的一个事务复制（Transaction publication with updatable subscriptions，事务复制的可更新订阅）。

事务复制支持在订阅服务器中通过可更新订阅和对等复制来进行更新。下面介绍两种可更新订阅：

·       立即更新。必须连接发布服务器和订阅服务器才能在订阅服务器中更新数据。

·       排队更新。不必连接发布服务器和订阅服务器即可在订阅服务器中更新数据。可以在订阅服务器或发布服务器脱机时进行更新。

在订阅服务器中更新数据时，首先将数据传播到发布服务器，然后再传播到其他订阅服务器。如果使用立即更新，将使用两阶段提交协议立即传播更改。如果使用排队更新，更改将存储在队列中；当网络连接可用时，再在发布服务器中异步应用排队事务。由于更新异步传播至发布服务器，所以发布服务器或另一台订阅服务器有可能更新同一数据，而在应用更新时会发生冲突。将根据创建发布时设置的冲突解决策略检测和解决冲突。

如果在新建发布向导中创建具有可更新订阅的事务发布，将同时启用立即更新和排队更新。如果使用存储过程创建发布，则可以启用一个或两个选项。创建发布的订阅时，可以指定要使用的更新模式。如有必要，以后可以在两种更新模式之间切换。

 

择项目(Articles)

在上面的向导中选择了Publication的类型之后，接下来就是要选择把那些对象作为Article发布出去。一般而言，一个Article就是指代数据库中的一个对象。在下图中，在Articles向导页中列出了可以发布的所有的对象：表，存储过程，视图，函数。

 

7.png(54.86 K)

10/17/2012 3:23:51 PM

 

 

很多的时候，当我们的Articles都是选择表，因为我们要把表中的改变的数据发布出去。对于表，我们也有更多的选择，例如选择那些字段，因为可能在表中有些数据是不变的，此时我们只要选择那些数据常常改变的字段，减少不必要的数据传输。如图：

 

8.png(12.12 K)

10/17/2012 3:23:51 PM

 

 

另外，我们还可以点击”Aritlces Properties”来设置更多有关Articles的选项，如图：

 

9.png(68.15 K)

10/17/2012 3:23:51 PM

 

 

那么，这里需要注意的就是：我们可以同时为很多的Article设置选项，也可以为某一个Article设置。

如果我们的选择的Articles中包含表，那么我们可以在向导的下一步对表添加一些过滤条件，如图所示:

 

 

Snapshot快照

在上面选择和配置了Articles之后，下面就要思考一个“鸡生蛋，蛋生鸡”的问题：既然是把Publisher中的数据同步到Subscriber中，那么，在Subscriber上面首先一定要存在一个和Publisher一样的数据库，之后才能把Publisher中的改变同步过去。

在向导中的这个Snapshot步骤就是来在Subscriber中创建一个现有数据库的快照的，创建快照的过程可以在立刻进行，也可以在向导完成之后在某个时刻运行，如图：

11.png(55.62 K)

10/17/2012 4:03:06 PM

 

在这里又有一些点需要注意。建立一个快照的时候，我们的Publication选择的那些表会被加上锁，如果那些表很大，那么这个加锁的过程会很长，导致对表的读写都延时，而且会进行大量的读写日志的操作，从而消耗大量的CPU，磁盘I/O等资源。另外，如果表过大，在传输的过程中会严重消耗网络资源，可能导致外部对数据库的访问被阻塞。

 

安全设置

设置了快照之后，下一步就要设置运行Publication的代理进程采用何种的身份进行运行。如图：

12.png(46.73 K)

10/17/2012 4:28:33 PM

 

在事务复制的Publication中涉及到的两个代理分别是快照代理和日志读取代理。

快照代理的任务就是把Publication中的数据移动到之间在Distributor中设置的快照文件夹和distribution数据库中。为了实现这些操作，这里设置的用户在publication涉及到的数据库和distribution数据库中都必须在db_owner角色中。而起这个用户还必须对快照文件夹有写的权限。

日志读取代理主要用来把publication中的数据复制到distribution中，但是这个代理不需要访问快照文件夹。所以，日志读取代理的这个用户只要在distribution数据库中处于db_owner的角色就行了。

我们可以通过点击“Security Setting”进行更多的设置，如图：

13.png(53.74 K)

10/17/2012 4:28:33 PM

 

设置完成之后，点击下一步，直到完成。

20121017162747.png(62.31 K)

10/17/2012 4:28:33 PM

 

最后结果如图所示：

20121017162755.png(27.77 K)

10/17/2012 4:28:33 PM

 

潜在问题分析

大家从上面的操作可以知道，建立一个Replication的应用需要花很多的步骤，步骤越多，可能出现的问题也就越多。其中最有可能出现问题的地方就是安全设置那一块。所以，在配置之前已经要把用户和对应的角色分配好，一般的建议是在采用SQL Server验证方式来连接。