SQLServer 发布订阅(Replication)造成的Memroy压力(cmemthread等待)

深入了解下发布订阅:

    数据复制:允许一个数据源向一个或多个目标数据库分发数据,只需要OLE DB 访问接口即可访问;

整个复制框架包含:复制组件,复制代理,复制类型;

复制组件:

发布服务器:发布服务器是使用数据复制到可用的其他数据库服务器;跟踪数据的更改和维护其他源数据库信息;

分发服务器: 分发复制数据库的服务器,存储分发数据库,元数据,历史数据(事务复制)事务;

订阅服务器:是复制的目标服务器,复制数据库的接收和更新,订阅服务器也能更改数据(合并复制),可以将数据发布到多个订阅服务器;

项目 是复制的基本单元

项目包含一下:

完整的表、表的某些列、表的某些行、表的子集、视图、索引视图、用户自定义函数、存储过程;

也包含是否复制架构对象:架构对象包含约束,索引,触发器,排序规则,扩展属性,

不能包含系统数据库(master,model,msdb,tempdb)

复制代理:

快照代理(snapshot.exe)创建数据库快照,包含架构和数据,这是为分发数据库而提供的,负责分发数据库的更新状态信息;每一个发布服务器都有一个连接分发服务器的快照代理,适用于各类型的复制;

分发代理(distrib.exe)将来自快照复制的数据库或来自事务复制的事物到订阅服务器如果代理运行到分发服务器上,则是推送订阅,代理运行到订阅服务器上,则用于请求订阅,当然合并代理除外;

合并复制(replmerg.exe)运行到发布和订阅服务器上,当同步数据更新时,发生冲突时,将使用冲突解决程序设置的规则来解决,仅用于合并复制;

日志代理读取(logread.exe)从发布服务器上事务日志将标记复制的事物移动到分发服务器,+

时间: 2024-08-10 00:05:13

SQLServer 发布订阅(Replication)造成的Memroy压力(cmemthread等待)的相关文章

SqlServer发布订阅错误收集

目录 1. SqlServer发布订阅错误收集 1.1. Message:脚本对于表"dbo.table"失败. 1.1.1. 错误消息 1.1.2. 处理方法 1.2. 由于出现操作系统错误 3,进程无法读取文件D:\\XXXX\\X.pre (源: MSSQL_REPL,错误号: MSSQL_REPL20024) 1.2.1. 错误消息 1.2.2. 解决方法 1.3. 应用复制的命令时在订阅服务器上找不到该行 1.3.1. 错误消息 1.3.2. 解决方法 1.4. 数据库 'd

SQLServer 2008 R2 发布订阅配置指南

原以为配置SQLServer 2008 R2的发布订阅很简单,实际配置后才发现过程中有问题地方一直都没搞明白,最后经过几天的查找问题和实践,终于搞定了.现将过程记录如下. 一.发布服务器配置第一步:设置SQLAgent服务登录帐户为Administrators用户,设置后重新启动服务 第二步:在配置管理器里设置订阅服务器别名,设置后重起服务 注意32位和64位两处都要设置 第三步:右键点击本地发布,进入发布流程(保证sql服务器名称和系统服务器名称相同) 为发布的表单独建一个帐号 二.订阅服务器

SQLServer数据库发布订阅简单配置一主多从

一.配置分发服务器 一直下一步该页到 设置快照文件夹共享 后面一直下一步完成即可 完成分发服务器配置 二.发布订阅 ************************************************************************************************************************************************* 如果是在服务器上配置,出现以下错误 可使用 服务器名称 登录 而不使用 IP *******

Kafka是分布式发布-订阅消息系统

https://www.biaodianfu.com/kafka.html Kafka是分布式发布-订阅消息系统.它最初由LinkedIn公司开发,之后成为Apache项目的一部分.Kafka是一个分布式的,可划分的,冗余备份的持久性的日志服务.它主要用于处理活跃的流式数据. 在大数据系统中,常常会碰到一个问题,整个大数据是由各个子系统组成,数据需要在各个子系统中高性能,低延迟的不停流转.传统的企业消息系统并不是非常适合大规模的数据处理.为了已在同时搞定在线应用(消息)和离线应用(数据文件,日志

Redis_发布订阅(基础)

目录 前言 生产者和消费者 发布和订阅 注意 前言 随着业务复杂, 业务的项目依赖关系增强, 使用消息队列帮助系统降低耦合度.发布订阅(pub/sub)是一种消息通信模式,主要目的是解除消息发布者.消息订阅者之间的耦合 订阅分布本身也是一种生产者消费者模式, 订阅者是消费者, 发布者是生产者. 订阅发布模式, 发布者发布消息后, 只要有订阅方, 则多个订阅方会收到同样的消息 生产者消费者模式, 生产者往队列里放入消息, 由多个消费者对一条消息进行抢占. 订阅分布模式可以将一些不着急完成的工作放到

MS SQL 2008 发布订阅配置错误总结

最近在配置SQL 2008的发布订阅功能时,遇到了几个小错误,顺便归纳总结一下(以后碰到各类关于发布订阅的错误都将收录.更新到这篇文章),方便自己在以后碰到这类问题时,能够迅速解决问题.毕竟人的记忆能力有时效性,时间久了,有可能有些东西就模糊了或忘了,好记性不如烂笔头. 错误1:在数据库服务器上新建本地发布服务时报错. (图1) 报错的具体细节如下所示:   查看具体原因,是因为安装数据库实例时,没有选择安装Replication components,需要添加Replication compo

分享一个分布式消息总线,基于.NET Socket Tcp的发布-订阅框架,附代码下载

一.分布式消息总线 在很多MIS项目之中都有这样的需求,需要一个及时.高效的的通知机制,即比如当使用者A完成了任务X,就需要立即告知使用者B任务X已经完成,在通常的情况下,开发人中都是在使用者B所使用的程序之中写数据库轮循代码,这样就会产品一个很严重的两个问题,第一个问题是延迟,轮循机制要定时执行,必须会引起延迟,第二个问题是数据库压力过大,当进行高频度的轮循会生产大量的数据库查询,并且如果有大量的使用者进行轮循,那数据库的压力就更大了. 那么在这个时间,就需要一套能支持发布-订阅模式的分布式消

利用zookeeper的发布/订阅模式实现配置动态变更

??ZooKeeper的Watcher事件机制可以说分布式场景下的观察者模式的实现.基于这个watcher事件机制,配合注册到特定的ZNode节点,可以实现java应用的配置运行时的变更.在学习zookeeper之前,听同事说配置可以在运行时动态变更,觉得不可思议.研习了zookeeper之后,实现这个功能是很easy的. ??发布/订阅系统设计起来无非两种模式,推和拉. 1. 推模式,服务端负责把变更的数据推给订阅的客户端.Web即时通信里的Comet技术便可以实现这种功能. 2. 拉模式,也

SQLServer2008r2 复制(发布-订阅)总结

首先需求:我需要把205SERVER的数据同步到三个数据库中,2个本地,1个是在局域网(其实是vpn). 操作步骤:1首先,把发布.订阅服务器的sqlserver agent服务都打开. 2 创建一个发布服务,选择要复制的表,生成快照,启动. 3 建立本地订阅2个,这些都一切顺利. 4 在创建局域网订阅时,发现订阅失败,主要有几个地方出现问题. a创建订阅的时候,服务要求用实例名,不能用ip,所以必须在系统目录system32/drivers/etc下把host文件添加一条域名指向记录:192.