SQL SERVER複寫拓撲結構中，訂閱端宕機後的處理…..（一）

前提:本次描述的是SQL SERVER 2008R2版本，其它版本沒有測試，複製類型主要是Transaction Replication和P2P複製

 

無論是高可用，高可擴充，還是高效能，SQLSERVER的複製分發都是一個不錯的選項，配置相對容易，對前景程式的改動也少，因此使用很廣泛，但是後期的日常維護，故障排錯就麻煩了，

需要對複製分發的原理，中繼資料表等相當的瞭解之後才有可為，否知的話一遇到問題，不知所措，萬能的解決方案便是重新初始化。本文測試的是當訂閱端突然宕機，或者是人為關機，但是

發布端資料庫還在不停地Insert/Update,導致鏈路掛起，而一旦訂閱端重連上後的處理方法。本次測試分訂閱端短期中斷和長期中斷。

 

publication database : mysales_normal

publication                : pub_mysales_normal

publication type        : transaction replication/peer-to-peer replication

subscription database    : mysales_normal

一個是預設執行個體，一個是命令執行個體，參與複製分發的表為vendor.具體如所示：

 

 

 

 

 

 

 

 

 

 

首先我把命令執行個體服務和Agent關閉，然後往發布端vendor表插入兩條記錄

 

USE mysales_normalGOINSERT INTO [mysales_normal].[myinventory].[Vendor]VALUES(1,'peter','beishangguang','shanghai','40034','13458294')INSERT INTO [mysales_normal].[myinventory].[Vendor]VALUES(2,'top','yyyyyyyy','guangzhou','40034','13458294')GO

此時，logreader agent 從mysales_normal裡讀取兩條記錄檔，然後把它寫入到distribution..msrepl_commands中，distribution agent 從該表中讀取命令

後寫入訂閱端相應的vendor表中，但此時串連已中止，我們可以從replication monitor中看到相應的錯誤資訊。

 

 

我們可以通過sp_browereplcmds來讀取msrepl_commands表中的命令：

SELECT mt.publisher_db,id,article,article_id FROM distribution.dbo.MSpublisher_databases md INNER JOIN distribution.dbo.msarticles mtON mt.publisher_db=md.publisher_dbWHERE mt.publisher_db='mysales_normal'exec distribution..sp_browsereplcmds@publisher_database_id=7, @article_id=8

可以看到這兩條命令已經在msrepl_commands表中了。在replication monitor中也可看到有兩條命令沒有傳送到distributior 中：

 

這時候我們重啟具名執行個體服務，看看這兩條命令能不能傳到訂閱端：

發現兩條命令已經發送到訂閱端，在來看看訂閱表中的資料：

USE mysales_normalGOSELECT *  FROM [mysales_normal].[myinventory].[Vendor]

已經有資料了，說明資料寫入了訂閱表，但當查看replication monitor中未發送命令時，發現undistributed commands還為2 ，：

根據 BOL上的解釋：undistributed commands 是：還沒有沒有發送到訂閱伺服器的命令數。

The number of commands in the distribution database that have not been delivered to the selected Subscriber.

A command consists of one Transact-SQL data manipulation language (DML) statement or one data definition language (DDL) statement.

此時在replication monitor中insert tracer,發現鏈路是通的，而msrepl_commands中還有兩條命令。

exec distribution..sp_browsereplcmds@publisher_database_id=7, @article_id=8 

 

這些無用的命令什麼時候，被誰清理掉了？這就輪到 Distribution clean up:distribution這個job,每隔10分鐘運行一次，把那些已寫入到訂閱端的命令清理掉.

手動運行一次，在看看結果，發現sp_browereplcmds返回空結果集了。但是通常為replication monitor這個工具監視的需要，msrepl_commands至少要保留一條記錄，：

exec distribution..sp_browsereplcmds  @publisher_database_id=7

可以手工刪除msrepl_commands中，這個命令的一行資料，

DELETE  FROM distribution.dbo.msrepl_commands WHERE publisher_database_id=7

總結：1：replication monitor 中 undistributed commands 並不能即時的反應未發送的命令，它只是顯示發布項在msrepl_commands中對應的記錄有多少條，Distribution clean up:distribution

這個job每隔10分鐘跑一次，故 undistributed commands 有10分鐘的滯後，我們只能通過Insert tracer來即時監控當前鏈路是否暢通，如果不暢通，可以大致判斷有多少條命令掛起！

2：當訂閱端重新連上後，發行伺服器會自動的把掛起的命令傳送到訂閱端，不需要人工幹預！