先来了解一下一个基本的关于复制的概念。
什么是复制?
复制就是把数据的多个拷贝(复制品)分发到公司中的各个服务器中,通过复制为多台服务器提供相同的数据。这样用户就可以在不同服务器中访问同样的信息。
对于一个拥有大量用户的企业,复制可以分散用户访问服务器的负载。
什么是复制模型?
定义了服务器和数据副本之间的关系。
在复制模型里有三种角色,他们的任务各不相同。
1、 发布服务器:提供数据以便复制到其他服务器。
2、 分发服务器:作为发布和订阅之间的存储区。
3、 订阅服务器:接收复制数据。
一个数据库服务器实例可以充当发布服务器和分发服务器两个角色。
什么是复制类型?
复制类型有以下三种:
1、 快照复制:由发布服务器进行数据的更新和修改,周期性地复制到其他服务器。缺点是可能引起流量的增加。
2、 事务性复制:由发布服务器进行数据的更新和修改,但是复制是实时性的,即当有数据的改变的时候才触发复制的行为,优点是可以减少数据复制的流量。
3、 合并复制:发布服务器和订阅服务器都可以对数据进行更新和修改。复制是实时性的。当数据同步同时发生时,那么发布服务器的修改和订阅服务器的修改被合并在一起。
下面通过一个案例来详解复制的实现方式,本次以合并复制为例。
需求:
需求:现在随着玩家数量剧增,“moshou1”有些不堪重负,于是增加了一个SQL Server2005服务器,默认实例“moshou2”。现在希望将moshou1中的“player”数据库中的“玩家信息表”同步到“moshou2”中的player数据库中的玩家信息表,并要实现玩家无论登录哪个服务器更改个人信息都会同步到另一台服务器。如何实现?
需求分析:使用SQLserver 2005的数据复制功能,实现负载均衡数据库之间的数据同步和更新。本例采用“合并复制”数据的修改由发布服务器和订阅服务器共同来完成。并且数据的修改是实时的。合并复制自动创建初始快照。
备注:本例为了演示的方便,就在同一个服务器两个不同的实例中做这个实验,跟实际情况没有太多的出入。注意截图中的默认实例模拟moshou1,命名实例cool模拟moshou2
(一)、首先要启动SQL server agent的代理服务,moshou1、moshou2这两个实例的服务都必须启动
登录到SQL server的SSMS界面
 启动管理工具
启用代理
启用代理2
(二)、定义“玩家信息表”的主键,如果不定义的话,那么在发布服务器的时候会出错
修改玩家信息表
设置主键
(三)、moshou1上新建发布
新建发布
打开新建发布向导
新建发布向导
选择自己作为分发服务器,即该服务器即是发布服务器也是分发服务器
新建发布向导2
将SQL server 代理配置为自动启动
新建发布向导3
设置快照文件夹的位置
新建发布向导4
选择要发布的数据库
新建发布向导5
选择发布类型为“合并发布”
新建发布向导6
订阅服务器类型保存默认
新建发布向导7
要发布的项目,选择玩家信息表
新建发布向导8
项目问题保持默认
新建发布向导9
新建发布向导10
快照代理,勾选“立即创建快照”
新建发布向导11
点击快照代理的安全设置按钮,设置快照代理的安全性
发布向导12
发布向导13
创建发布
发布向导14
给该发布起一个名字
发布向导15
发布向导16
下图是创建好的本地发布
发布向导17
(四)、moshou2上新建订阅
新建订阅1
新建订阅2
查找发布服务器
新建订阅3
选择发布服务器
新建订阅4
设置合并代理的位置
新建订阅5
在订阅服务器上新建订阅数据库
新建订阅6
新建订阅7
新建订阅8
点击右边的按钮,设置合并代理安全性
新建订阅9
新建订阅10
设置完成后,如图所示
新建订阅11
同步计划设置为连续运行
新建订阅12
立即初始化订阅
新建订阅14
订阅类型保持默认
新建订阅15
勾选在向导结束后,创建订阅
新建订阅16
新建订阅17
新建订阅18
(五)、验证一下
打开cool实例下的player数据库,展开表,可以看到同步过来的玩家信息表
验证1
在默认实例的player数据库中对玩家信息表进行修改,可以同步到cool的player数据库的玩家信息表中
我们在默认实例的玩家信息表中添加一个列eee,然后可以看到马上就同步到了cool实例的表中