《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與你要回跳的那個事務號一致;
至此,我們目的達成,但這又有什么意義呢?當前時間點下的數據為什么要回跳到之前的某個事務呢?這就要說到前幾天我們處理的一個案例;
先說一下我們的復制環境,以下圖為例:
根節點為寫庫,承載主寫業務,為避免單點故障,增加一災備節點進行保護;
轉發節點作為根節點的訂閱以及末端節點的發布,只進行復制命令的轉發工作,雙轉發進行冗余,避免單鏈路故障影響末端訂閱;
末端訂閱承載各類讀業務,雙鏈路各取部分節點做負載均衡;
新聞熱點
疑難解答