MsSqlServer 复制分发概述

Replication方案可以分为Snapshot Replication, Transactional Replication, Peer-2-Peer Replication, Merge Replication。
Snapshot Replication:一般用于对于数据库的一次性的完全复制。
Transactional Replication:用于主数据库向从数据库的单向复制。
具有可更新订阅的事务性发布: 发布服务器与订阅服务器可以独立修改,会定时合并
Merge Replication:可以把多个数据库中的数据进行合并后,复制到目标数据库。

注:发布服务器上需要建立一个windows账号,用来对分布产生的文件进行读取与写入,同时为了利用此账号访问发布数据库,所以需要在
SqlServer上创建此账号,具体是选择浏览,选择windows账号。同时为了使sql
server服务可以读写分布产生的文件,要将agent服务设置为此系统账号。
而订阅服务器上也要建立一windows账号,是为了增大agent服务的权限,及对订阅数据的写操作。
一、准备工作:
1.在分发与发发数据库上建立一个 WINDOWS 用户,设置为管理员权限,并设置密码,作为发布快照文件的有效访问用户。
2.在SQL SERVER下实现发布服务器和订阅服务器的通信正常(即可以互访)。打开1433端口,在防火墙中设特例
3.在发布服务器上建立一个共享目录,作为发布快照文件的存放目录。例如:在D盘根目录下建文件夹名为SqlCopy
4.设置SQL 代理(发布服务器和订阅服务器均设置) 打开服务(控制面板—管理工具—服务) —右击SQLSERVER AGENT—属性—登录—选择“此帐户“ —输入或选择第一步中创建的WINDOWS 用户 —“密码“中输入该用户密码
5.设置SQL SERVER 身份验证,解决连接时的权限问题(发布、订阅服务器均设置)
步骤为:对象资源管理器—-右击SQL实例—–属性—-安全性—-服务器身份验证——选“SQL Server和WINDOWS“,然后点确定
6.开启SQL Server 2005的网络协议TCP/IP和管道命名协议并重启网络服务。
7.在SQL Server中创建步骤1中对应的系统用户登陆名,作为发布数据库的拥有者(设置为dbo_owner和public)。

二、开始:
在分发服务器上建共享文件夹
1,分发服务器上,右击复制,建立分发,注意在指定快照路径时需是网络路径,如:\\192.168.16.204\sqlCopy
204为分发服务器。 若出现运行复制分发时 “由于出现操作系统错误 3,进程无法读…”
则要查看分发服务器属性中的快照与订阅服务器的快照是否指向了网络连接。
2,发布服务器上,右击复制-本地发布,建立发布
2,订阅服务器上,右击复制-本地订阅,建立发布,分发代理安全性中
在以下Windows账号下运行,此账号指订阅服务器的账号,或者选择代理
连接到分发服务器: 选择使用以下SQL Server登陆名 分发服务器所要发布的数据库拥有者的账号

发布服务器配置(在发布服务器上配置发布和订阅)
1. 选择 复制 节点
2. 右键本地发布 —-下一步———系统弹出对话框看提示—-直到“指定快照文件夹“
—-在“快照文件夹“中输入准备工作中创建的目录(指向步骤3所建的共享文件夹)——选择发布数据库——-选择发布类型——-选择订阅服务器类型——-选择要发布的对象——设置快照代理——-填写发布名称。
3. 右键本地订阅——–选择发布服务器——-选择订阅方式(如果是在服务器方订阅的话选择推送订阅反之选择请求订阅)——-填加订阅服务器——–选择代理计划(一般选择连续运行)———其余选择默认项。

注:1)
原先数据库的Release一般会分为三部分:1.表结构的变化(包括加/删表,加/删列);2.配置数据的装载(如添加新功能的配置数据);3.刷函数与存储过程脚本。
对于本项目中的Replication数据库,在Release过程中需注意以下几点:1.若新加的表需要进行Replication,除了在主数据库创
建表之外,还需配置此表进行Replicate,并进行初始化。2.若要删除某处于Replication的表,需先取消此表的Replication,
再在主、从库中drop此表。3.若需要加/删Replication表的列(此列不能为主键列)时,可以直接在主数据库上执行脚本,变化会自动
Replicate到从数据库。4.配置数据的装载也只需要在主数据库完成。5.函数与存储过程需要在主、从库上都进行刷新。
2)增加列、删除列不能直接在manage studio上面操作,否则出现无法对 表’frmUser’ 执行 删除,因为它正用于复制。 (.Net
SqlClient Data Provider,此时要用sql语句。sql server的说明是:对表进行架构更改时必须使用
Transact-SQL ,在 SQL Server Management Studio 中进行架构更改时,Management Studio
将尝试删除并重新创建表。因为无法删除已发布的对象,所以架构更改失败。

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-08-04 00:56:02

MsSqlServer 复制分发概述的相关文章

SQL Server 事务复制分发到订阅同步慢

原文:SQL Server 事务复制分发到订阅同步慢 最近发现有一个发布经常出现问题,每几天就出错不同步,提示要求初始化.重新调整同步后,复制还是很慢!每天白天未分发的命令就达五六百万条!要解决慢的问题,需要了解从发布数据库到订阅数据库中,有哪些操作,才知道哪个步骤同步缓慢. 这是很久之前自己做的一张图,主要描述发布到分发.分发到订阅中,复制使用了哪些操作,如下图: 发布到分发: 在发布中,复制是使用日志读取器读(sp_replcmds)取发布数据库中的事务日志的,日志读取器是按事务顺序读取的,

SQL SERVER2005 的三种复制类型概述

一.事务复制 事务性复制通常从发布数据库对象和数据的快照开始.创建了初始快照后,接着在发布服务器上所做的数据更改和架构修改通常在修改发生时(几乎实时)便传递给订阅服务器.数据更改将按照其在发布服务器上发生的顺序和事务边界,应用于订阅服务器,因此,在发布内部可以保证事务的一致性. 事务性复制通常用于服务器到服务器环境中,在以下各种情况下适合采用事务性复制: 希望发生增量更改时将其传播到订阅服务器. 从发布服务器上发生更改,至更改到达订阅服务器,应用程序需要这两者之间的滞后时间较短. 应用程序需要访

mysql之 MySQL 主从基于 GTID 复制原理概述

一. 什么是GTID ( Global transaction identifiers ):MySQL-5.6.2开始支持,MySQL-5.6.10后完善,GTID 分成两部分,一部分是服务的UUid,UUID保存在mysql数据目录的auto.cnf文件中,这是一个非常重要的文件,不能删除,这一部分是不会变的.另外一部分就是事务ID了,随着事务的增加,值一次递增,如下图+---------------+----------+--------------+------------------+-

Windows活动目录系列---ADDS复制的概述(2)

AD DS是如何处理复制冲突的? 因为AD DS支持多主机复制模式,所以有可能会出现复制冲突的情况,一般会有三种可能的冲突: 在两台不同的DC上同时修改同一个对象的相同属性的值 在一台DC上新增或者修改一个对象,而同一时间在另外一台DC上这个对象所在的容器被删除了 在不同的DC上向同一个容器中新增了一个有相同的相关可分辨名的对象,比如在DC1和DC2上同时新增了一个账号,DC1上新增的是张珊,DC2上新增的是张山,但是他们的可分辨名称DN都是CN=zhangshan,CN=Users,DC=co

Windows活动目录系列---ADDS复制的概述(1)

AD DS分区介绍: 活动目录数据存储中所包含的信息会被ADDS发布到林中的所有DC上.数据存储中包含的大部分信息会在单域中发布,但是还有部分相关信息会不受域的复制边界限制,将信息发布到整个林中. 为了提升DC之间的复制效率和扩展性,活动目录的数据被逻辑的划分成几个分区,每个分区作为一个复制单元,并且每个分区都有自身的复制拓扑,ADDS有以下默认的分区: 配置分区.配置分区是在林中第一台DC被创建的时候自动生成的,配置分区中包含了林范围的ADDS结构信息,包括林中有哪些域或站点,每个域中有哪些D

LMAX Disrutpor—多生产者多消费者中,消息复制分发的高性能实现

解决的问题 当我们有多个消息的生产者线程,一个消费者线程时,他们之间如何进行高并发.线程安全的协调? 很简单,用一个队列. 当我们有多个消息的生产者线程,多个消费者线程,并且每一条消息需要被所有的消费者都消费一次(这就不是一般队列,只消费一次的语义了),该怎么做? 这时仍然需要一个队列.但是: 1. 每个消费者需要自己维护一个指针,知道自己消费了队列中多少数据.这样同一条消息,可以被多个人独立消费. 2. 队列需要一个全局指针,指向最后一条被所有生产者加入的消息.消费者在消费数据时,不能消费到这

mongodb复制+分片集原理

----------------------------------------复制集---------------------------------------- 一.复制集概述: 组成: Mongodb复制集(副本集replica set)由一组Mongod实例(进程)组成,包含一个Primary节点和多个Secondary节点,Mongodb Driver(客户端)的所有数据都写入Primary,Secondary通过oplog来同步Primary的数据,保证主节点和从节点数据的一致性,

MongoDB实战指南(七):MongoDB复制集之复制集工作机制

http://www.cnblogs.com/longshiyVip/p/5097336.html 概述了复制集,整体上对复制集有了个概念,但是复制集最重要的功能之——自动故障转移是怎么实现的呢?数据同步又是如何实现的?带着这两个问题,下面展开分析. 一. 数据同步 先利用mongo客户端登录到复制集的primary节点上. >mongo --port 40000 查看实例上所有数据库 rs0:PRIMARY> show dbs local 0.09375GB 可以看到只有一个local数据库

SQL Server 复制优化

曾搭建了一个复制系统,用于搜索业务,在业务上增加某些特别的功能后,读库压力增加,导致复制延时.通过多种方式进行优化,其中一个是修改复制代理的参数. 写库和分发库之间无复制延时,复制延迟出现在分发库和读库之间. 在SQL Server复制参数方面,主要调整了PacketSize,PacketSize 默认值是4096. ------------------------------------------------------------------------------------------