我了解的数据库事务复制

事务复制

事务复制的基本机制,在联机文档上也有介绍。

基本原理


如图,主要依靠2个代理,1.日志读取代理(log reader agent),2.分发代理(distribution agent)。

其中log reader agent,负责从发布数据库上读取日志并且写入到分发数据库(distribution)中。然后distribution agent负责从distribution读取数据并且写入到订阅中。

Log Reader Agent


开profiler,使用tsql模板即可。在已经有复制环境的状态下,对发布项目执行:

BEGIN TRAN

go

INSERT INTO dbo.rename_sc DEFAULT VALUES

GO 10

COMMIT

最主要的部分:

如图,Log Reader Agent使用会话55去发布库的日志上读取事务,如果发现有需要分发的,那么会调用sp_MSadd_replcmds,这个存储过程会把抓到的指令存放到dbo.MSrepl_commands和MSrepl_transactions2个表中。然后就会使用过程sp_repldone标记事务已经被复制。

SELECT spid,program_name FROM sys.sysprocesses WHERE spid IN( 57,55)

在sql server中查询sys.sysprocesses 这2个spid 会发现program_name=‘Repl-LogReader-0-p1-9

也就是log reader agent在sql server 上有2个会话一个负责读,一个负责写。这样Log Reader Agent的一次读取完成。

Distribution Agent


Log Reader Agent写入完之后就是有Distribution Agent 把事务应用到订阅库。

获取事务

在存储过程sys.sp_MSget_repl_commands对表dbo.MSrepl_commands读取,之后就是在订阅服务器上面运行sp_MSins命令。

仔细观察其实不难发现msrepl_command表中存的是明码,通过和sp_browsereplcmds对比就能发现,那么也就是说其实在插入MSrepl_commands的时候就已经知道了。

但是这里有个问题Agent是怎么知道要调用这个存储过程的。

在这里会注意到有2个不同的会话在处理,一个负责读,一个负责写入,其中65负责从分发库中读取,51负责应用到订阅库

SELECT spid,program_name FROM sys.sysprocesses WHERE spid IN( 65 ,51)

修改订阅

最后会修改订阅服务器中的MSreplication_subscriptions中的一些字段,其中最终要的是timestamp,这个字段表示现在订阅已经应用到了那个事务。奇特的事情又出现,会发现有2个update语句。不知道是不是为了版本兼容。

UPDATE  MSreplication_subscriptions

SET     transaction_timestamp = CAST(@P1 AS BINARY(15))

+ CAST(SUBSTRING(transaction_timestamp, 16, 1) AS BINARY(1)) ,

"time" = @P2

WHERE   UPPER(publisher) = UPPER(@P3)

AND publisher_db = @P4

AND publication = @P5

AND subscription_type = 1

AND( SUBSTRING(transaction_timestamp, 16, 1) = 0

OR DATALENGTH(transaction_timestamp) < 16

)

UPDATE  MSreplication_subscriptions

SET     transaction_timestamp = CAST(@P1 AS BINARY(15))

+ CAST(CASE DATALENGTH(transaction_timestamp)

WHEN 16

THEN ISNULL(SUBSTRING(transaction_timestamp, 16, 1), 0)

ELSE 0

END AS BINARY(1)) ,

"time" = @P2

WHERE   UPPER(publisher) = UPPER(@P3)

AND publisher_db = @P4

AND publication = @P5

AND subscription_type = 1

Distribution Agent完成一次分发。

时间: 2024-11-07 08:19:51

我了解的数据库事务复制的相关文章

MySQL 数据库事务与复制

好久没有写技术文章了,因为一直在思考 「后端分布式」这个系列到底怎么写才合适. 最近基本想清楚了,「后端分布式」包括「分布式存储」和 「分布式计算」两大类. 结合实际工作中碰到的问题,以寻找答案的方式来剖解技术,很多时候我们都不是在创造新技术,而是在应用技术. 为了更有效率与效果的用好技术,我们需要了解一些技术的原理与工作方式. 带着问题从使用者的角度去剖析技术原理,并将开源技术产品和框架作为一类技术的参考实现来讲解. 以讲清原理为主要目的,对于具体实现的技术细节若无特别之处则尽可能点到即止.

监控SQL Server事务复制

通常,我们可以使用SSMS的复制监视器来监控复制.但我们不能24小时盯着看,得使用自动化的方式来监控它.微软在distribution数据库提供了系统存储过程dbo.sp_replmonitorsubscriptionpendingcmds,用于返回订阅上等待的命令数,以及需要投递所有这些命令到订阅者的时间的预估.我创建了一个每10分钟运行的作业,保存状态的历史记录数据到一个表,数据保留14天. 这个表在订阅者服务器的DBA数据库创建,代码如下: CREATE TABLE dbo.Replica

SQLServer 数据库镜像+复制方案

目标: 主机做了Mirror和Replication,当主机出现问题时,Replication和Mirror实现自动的故障转移(Mirror 和Replication都切换到备机,而当主机 重新启动后,自动充当备机的角色). 环境: 五台虚拟机,配置均为Windows2008 Enterprise + SQLServer2008R2 Enterprise 08R201:Mirror 见证机(WITNESS)           IP:192.168.56.101 08R202:主机(Rep+Mi

事务复制

本文截取自MSDN https://msdn.microsoft.com/zh-cn/library/ms151176(v=sql.120).aspx 事务复制通常从发布数据库对象和数据的快照开始.创建了初始快照后,接着在发布服务器上所做的数据更改和架构修改通常在修改发生时(几乎实时)便传递给订阅服务器.数据更改将按照其在发布服务器上发生的顺序和事务边界应用于订阅服务器,因此,在发布内部可以保证事务的一致性. 事务复制通常用于服务器到服务器环境中,在以下各种情况下适合采用事务复制: 希望发生增量

SQLServer 数据库镜像+复制切换方案

目标: 主机做了Mirror和Replication,当主机出现问题时,Replication和Mirror实现自动的故障转移(Mirror 和Replication都切换到备机,而当主机 重新启动后,自动充当备机的角色). 环境: 五台虚拟机,配置均为Windows2008 Enterprise + SQLServer2008R2 Enterprise 08R201:Mirror 见证机(WITNESS)           IP:192.168.56.101 08R202:主机(Rep+Mi

SqlServer 使用脚本创建分发服务及事务复制的可更新订阅

[创建使用本地分发服务器] /************************[使用本地分发服务器配置发布]***********************/ -- SqlServer 2008 R2 -- https://technet.microsoft.com/zh-cn/library/ms151860(v=sql.105).aspx use master go -- 服务器上是否已安装分发服务器 -- https://msdn.microsoft.com/zh-cn/library/ms

在Sql2000 sql2005 sql2008 下已能实现事务复制的强制订阅,但请求订阅始终不能实现总有下列错误提示

硬件环境 : 一台服务器 安装了 sqlserver2008 数据库 局域网还有一台机器 安装了 sqlserver2000数据库 两台server 通信 共享均没有问题 同步过程中遇到的问题  : 在Sql2000下已能实现事务复制的强制订阅,但请求订阅始终不能实现总有下列错误提示: 进程未能读取文件 "\\快照路径" 由于发生操作系统错误 5.. 步骤失败. 数据库的 [订阅] .[公布] 设置步骤 : 做了 从sql2008 到sql2000的数据同步 ,在sql2008数据库

如何处理SQL Server事务复制中的大事务操作

如何处理SQL Server事务复制中的大事务操作 事务复制的工作机制 事务复制是由 SQL Server 快照代理.日志读取器代理和分发代理实现的.快照代理准备快照文件(其中包含了已发布表和数据库对象的架构和数据),然后将这些文件存储在快照文件夹中,并在分发服务器中的分发数据库中记录同步作业. 日志读取器代理监视为事务复制配置的每个数据库的事务日志,并将标记为要复制的事务从事务日志复制到分发数据库中,分发数据库的作用相当于一个可靠的存储-转发队列. 分发代理将快照文件夹中的初始快照文件和分发数

Replication的犄角旮旯(四)--关于事务复制的监控

原文:Replication的犄角旮旯(四)--关于事务复制的监控 <Replication的犄角旮旯>系列导读 Replication的犄角旮旯(一)--变更订阅端表名的应用场景 Replication的犄角旮旯(二)--寻找订阅端丢失的记录 Replication的犄角旮旯(三)--聊聊@bitmap Replication的犄角旮旯(四)--关于事务复制的监控 Replication的犄角旮旯(五)--关于复制identity列 Replication的犄角旮旯(六)-- 一个DDL引发