Replication的犄角旮旯（九）-- sp_setsubscriptionxactseqno，赋予订阅活力的工具

《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与你要回跳的那个事务号一致；

至此，我们目的达成，但这又有什么意义呢？当前时间点下的数据为什么要回跳到之前的某个事务呢？这就要说到前几天我们处理的一个案例；

先说一下我们的复制环境，以下图为例：

根节点为写库，承载主写业务，为避免单点故障，增加一灾备节点进行保护；

转发节点作为根节点的订阅以及末端节点的发布，只进行复制命令的转发工作，双转发进行冗余，避免单链路故障影响末端订阅；

末端订阅承载各类读业务，双链路各取部分节点做负载均衡；