《Replication的犄角旮旯》系列导读
Replication的犄角旮旯(一)--变更订阅端表名的应用场景
Replication的犄角旮旯(二)--寻找订阅端丢失的记录
Replication的犄角旮旯(三)--聊聊@bitmap
Replication的犄角旮旯(四)--关于事务复制的监控
Replication的犄角旮旯(五)--关于复制identity列
Replication的犄角旮旯(六)-- 一个DDL引发的血案(上)(如何近似估算DDL操作进度)
Replication的犄角旮旯(七)-- 一个DDL引发的血案(下)(聊聊logreader的延迟)
Replication的犄角旮旯(八)-- 订阅与发布异构的问题
Replication的犄角旮旯(九)-- sp_setsubscriptionxactseqno,赋予订阅活力的工具
---------------------------------------华丽丽的分割线--------------------------------------------
前言:有人总是拿MySQL的Master/Slave和SQL Server的replication比较,说Mysql的复制有多么强大、多么灵活。作为SQLServer的死忠,也曾被replication各种 的黑盒搞得体无完肤。不过还好,我们还是能从MS流露出来的各种存储过程中,发现蛛丝马迹,结合我们的头脑风暴,来一场真真正正的革命……
sp_setsubscriptionxactseqno,第一次了解是在拜读前任DBR的blog《在SQLServer2005/2008事务复制中如何跳过一个事务》时,而近期在处理一个复制异常事件时,忽然灵光闪现,既然可以向后跳过某些事务,是否可以前滚到之前的某个时间点再继续复制呢?本文将通过实际测试,继续玩复制
闲话少叙,书归正传……
关于跳过某些复制事务,在此不再赘述,详见《在SQLServer2005/2008事务复制中如何跳过一个事务》;这里只说如何追溯到之前某个时间点;
关于sp_setsubscriptionxactseqno这个存储过程,详见MSDN:https://msdn.microsoft.com/zh-cn/library/ms188764.aspx
具体用法如下:
sp_setsubscriptionxactseqno [ @publisher= ] 'publisher' , [ @publisher_db= ] 'publisher_db' , [ @publication= ] 'publication' , [ @xact_seqno= ] xact_seqno
其中@xact_seqno这个参数,如果指定当前事务(起始点)之后的某个事务(截止点),就可以跳过两个时间点之间的事务;但如果需要跳到当前事务之前的某个事务时,除了sp_setsubscriptionxactseqno这个存储过程外,还需要一个系统表来配合才能实现——MSsubscriptions,位于分发库(默认为distribution)中;
MSsubscriptions记录了每个订阅与发布项目的关系,详见MSDN:https://msdn.microsoft.com/zh-cn/library/ms188368.aspx
其中publisher_seqno表示该订阅创建时在发布服务器上的事务序列号,subscription_seqno为快照事务序列号(非初始化订阅则与publisher_seqno一致);
在事务复制中,订阅端应用事务时,需要检测当前事务是否小于这两个参数,如果当前事务号小于上述两个列的值,则逻辑上判为不成立(当前执行的事务早于创建订阅时的事务,理论上不成立)。
因此,要想回跳到之前某个时间点的事务,需要手动更新相应的记录,至少保证publisher_seqno和subscription_seqno与你要回跳的那个事务号一致;
至此,我们目的达成,但这又有什么意义呢?当前时间点下的数据为什么要回跳到之前的某个事务呢?这就要说到前几天我们处理的一个案例;
先说一下我们的复制环境,以下图为例:
根节点为写库,承载主写业务,为避免单点故障,增加一灾备节点进行保护;
转发节点作为根节点的订阅以及末端节点的发布,只进行复制命令的转发工作,双转发进行冗余,避免单链路故障影响末端订阅;
末端订阅承载各类读业务,双链路各取部分节点做负载均衡;
新闻热点
疑难解答