利用SQL server 的复制功能分散用户访问服务器的负载

先来了解一下一个基本的关于复制的概念。

什么是复制？

复制就是把数据的多个拷贝（复制品）分发到公司中的各个服务器中，通过复制为多台服务器提供相同的数据。这样用户就可以在不同服务器中访问同样的信息。

对于一个拥有大量用户的企业，复制可以分散用户访问服务器的负载。

什么是复制模型？

定义了服务器和数据副本之间的关系。

在复制模型里有三种角色，他们的任务各不相同。

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界面

（二）、定义“玩家信息表”的主键，如果不定义的话，那么在发布服务器的时候会出错

（三）、在moshou1上新建发布

打开新建发布向导

选择自己作为分发服务器，即该服务器即是发布服务器也是分发服务器

将SQL server 代理配置为自动启动

设置快照文件夹的位置

选择要发布的数据库

选择发布类型为“合并发布”

订阅服务器类型保存默认

要发布的项目，选择玩家信息表

项目问题保持默认

快照代理，勾选“立即创建快照”

点击快照代理的安全设置按钮，设置快照代理的安全性

创建发布

给该发布起一个名字

下图是创建好的本地发布

（四）、在moshou2上新建订阅

查找发布服务器

选择发布服务器

设置合并代理的位置

在订阅服务器上新建订阅数据库

点击右边的按钮，设置合并代理安全性

设置完成后，如图所示

同步计划设置为连续运行

立即初始化订阅

订阅类型保持默认

勾选在向导结束后，创建订阅

（五）、验证一下

打开cool实例下的player数据库，展开表，可以看到同步过来的玩家信息表

在默认实例的player数据库中对玩家信息表进行修改，可以同步到cool的player数据库的玩家信息表中

我们在默认实例的玩家信息表中添加一个列eee，然后可以看到马上就同步到了cool实例的表中