深入浅出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。
择项目(Articles)
在上面的向导中选择了Publication的类型之后,接下来就是要选择把那些对象作为Article发布出去。一般而言,一个Article就是指代数据库中的一个对象。在下图中,在Articles向导页中列出了可以发布的所有的对象:表,存储过程,视图,函数。
很多的时候,当我们的Articles都是选择表,因为我们要把表中的改变的数据发布出去。对于表,我们也有更多的选择,例如选择那些字段,因为可能在表中有些数据是不变的,此时我们只要选择那些数据常常改变的字段,减少不必要的数据传输。如图:
另外,我们还可以点击”Aritlces Properties”来设置更多有关Articles的选项,如图:
那么,这里需要注意的就是:我们可以同时为很多的Article设置选项,也可以为某一个Article设置。
如果我们的选择的Articles中包含表,那么我们可以在向导的下一步对表添加一些过滤条件,如图所示:
Snapshot快照
在上面选择和配置了Articles之后,下面就要思考一个“鸡生蛋,蛋生鸡”的问题:既然是把Publisher中的数据同步到Subscriber中,那么,在Subscriber上面首先一定要存在一个和Publisher一样的数据库,之后才能把Publisher中的改变同步过去。
在向导中的这个Snapshot步骤就是来在Subscriber中创建一个现有数据库的快照的,创建快照的过程可以在立刻进行,也可以在向导完成之后在某个时刻运行,如图:
在这里又有一些点需要注意。建立一个快照的时候,我们的Publication选择的那些表会被加上锁,如果那些表很大,那么这个加锁的过程会很长,导致对表的读写都延时,而且会进行大量的读写日志的操作,从而消耗大量的CPU,磁盘I/O等资源。另外,如果表过大,在传输的过程中会严重消耗网络资源,可能导致外部对数据库的访问被阻塞。
安全设置
设置了快照之后,下一步就要设置运行Publication的代理进程采用何种的身份进行运行。如图:
在事务复制的Publication中涉及到的两个代理分别是快照代理和日志读取代理。
快照代理的任务就是把Publication中的数据移动到之间在Distributor中设置的快照文件夹和distribution数据库中。为了实现这些操作,这里设置的用户在publication涉及到的数据库和distribution数据库中都必须在db_owner角色中。而起这个用户还必须对快照文件夹有写的权限。
日志读取代理主要用来把publication中的数据复制到distribution中,但是这个代理不需要访问快照文件夹。所以,日志读取代理的这个用户只要在distribution数据库中处于db_owner的角色就行了。
我们可以通过点击“Security Setting”进行更多的设置,如图:
设置完成之后,点击下一步,直到完成。
最后结果如图所示:
潜在问题分析
大家从上面的操作可以知道,建立一个Replication的应用需要花很多的步骤,步骤越多,可能出现的问题也就越多。其中最有可能出现问题的地方就是安全设置那一块。所以,在配置之前已经要把用户和对应的角色分配好,一般的建议是在采用SQL Server验证方式来连接。