sql server快照复制mysql_SQL Server复制方法：快照、合并或事务（二）

如何拓扑

在此，我们最主要的是要确定选择使用哪种复制拓扑。选择错误的拓扑将带来非常令人不满意的结果。

当需要一个临时的数据下发时，我们可以使用快照复制。因为每次快照下发时，所有的数据都是一次性移动的，但是它需要花费大量的带宽。只有在需要复制的数据变化远远超过了初始数据集的规模才在缓慢的WAN上使用快照复制。换言之，如果大部分的数据都在不断地更新，那么选择使用快照技术是非常正确的。如果并非如此，那么就不能选择它。

当需要在发行者和订阅者之间进行传输时，就应该选择合并复制。当有多个订阅者时，数据变化会及时地在网络上从发行者复制到所有的订阅者。

事务技术可能是复制最常见的形式。它是用来在几乎实时地(或按照调度)将数据变化传输到一个或多个订阅者。事务复制最常用于服务器之间的实时传输。

不管我们使用哪种SQL Server复制拓扑，订阅者之间都是完全独立的。订阅者可以因为多种原因而落后，包括网络拥挤、磁盘I/O拥挤以及用户进程锁定和阻塞。由于订阅者彼此都是独立的，因此，一个订阅者的速度下降并不影响其他的订阅者。

复制代理

数据是由复制代理传输的，其中每个发布都有几个复制代理需要创建。快照代理可以用在三种复制拓扑上。当复制创建后，就会得到物件快照并被上传到每个订阅者。当使用合并复制或事务复制时，将会有一个日志读取器代理在分发器上运行并捕捉事务日志的变化。然后这些变化会被记录到发行数据库上。

当使用事务复制时，数据变化将从发行数据库上读取并通过发行代理应用到订阅者上。当使用合并复制时，数据变化通过合并代理从发行数据库上读取。合并代理又将从订阅者上获取数据变化并上传到发行者以便分配到其他订阅者上。

当创建订阅时，我们有两个选项用于创建每个订阅者。我们可以使用发送订阅或请求订阅。当分配代理运行在发行数据库的服务器上工作时就是发送订阅。而当请求代理运行在订阅数据库的服务器上时就是请求订阅。

发送订阅的优点是分配代理集中在分发器上。这就能够限制管理开销同时保持订阅者的分配(或合并)代理低负载。请求订阅的优点是分配代理的工作量分散到所有订阅者上。当分配数据库位于同一台服务器或实例上作为发行者时，建议使用请求订阅。

复制获取

当建立分发器时，系统会提示选择一个文件夹来存储快照。当使用的都是发送订阅时，这可能是一个本地驱动器路径。当使用请求订阅或同时使用发送和请求订阅时，则必须指定一个网络共享路径。此网络共享不可以是一个管理共享，并且每个运行SQL Server代理的订阅者的域名帐号必须能读写网络共享。

如果运行的都是发送订阅而且有超过30个左右的订阅，那么在尝试启动订阅时将出现超时错误。最快速的补救方法就是编辑分发或合并代理的任务。编辑第二步并将任务类型修改为操作系统命令。接着将完整路径和可执行复制命令名称设置在现有参数的前面。SQL Server2008的默认路径是C:Program FilesMicrosoft SQL Server100COM(在SQL 2000中用80取代100，而在SQL 2005则是90取代)。当运行分发代理时，可以使用distrib.exe，而当运行合并代理时，则使用replmerg.exe。

修复SQL Server复制故障可能会非常棘手。默认情况下，代理并不提供大量错误数据。我们可以通过修改任务属性中的-OutputVerboseLevel开关来调整所接收到的错误数据总数。通过增加默认的数目，更多的错误数据将记录到任务步骤中。我们也可以终止运行代理的SQL代理任务，然后在DOS命令提示符中运行命令来轻松地看到更多错误数据。

当SQL Server复制有大量数据需要传输时，为了保持更新，需要一定数量的网络带宽。如果带宽无法满足，那么复制将越来越缓慢。如果在一个低带宽、低延迟的网络中，那么通过添加SubscriptionStreams开关(或者在已经存在开关的情况下，增加开关数目)将有助于增加线路数目。如果在一个高延迟网络，那么由于事务整合性是在流之间维护的，因此增加这些设置可能不会提高性能。