《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與你要回跳的那個事務號一致；

至此，我們目的達成，但這又有什么意義呢？當前時間點下的數據為什么要回跳到之前的某個事務呢？這就要說到前幾天我們處理的一個案例；

先說一下我們的復制環境，以下圖為例：

根節點為寫庫，承載主寫業務，為避免單點故障，增加一災備節點進行保護；

轉發節點作為根節點的訂閱以及末端節點的發布，只進行復制命令的轉發工作，雙轉發進行冗余，避免單鏈路故障影響末端訂閱；

末端訂閱承載各類讀業務，雙鏈路各取部分節點做負載均衡；