深入淺出SQL Server Replication第三篇：事物複製實戰-建立Publisher

深入淺出SQL Server Replication第三篇：事物複製實戰-建立Publisher

對於很多的SQL Server DBA而言，Replication不是什麼新鮮的事物了，也是大家常常說的“複製”，很多的朋友已經在項目中使用。正如其他技術一樣：有人可以使用的好，有人會抱怨技術不行。

我們AgileSharp團隊也經過了不少高可用的案例， Replication還是非常有價值的。因此，我們整理了很多的資源，我們決定發布一系列的Replication文章，一是為了協助大家瞭解Replication，另外也是為以後的講述高可用做個鋪墊。

在之前的文章中，我們已經對Replication做了總體的介紹，而且也講述了如何配置Distributor。那麼在本篇文章中，我們將會講述如何配置Publisher。

Publisher可以看出是資料產生的源頭，也是Replication的核心，因為只有Publisher產生了變化，其他的組件的運行才有意義。可以想象得到：一個Publisher可以有很多的Publication，也就是說，一個發行伺服器可以有多個發布。其實這一點很好的理解。

這一點拿生活的圖書訂閱就很好解釋了：我們不可能對出版社的所有書都感興趣，我們只是訂閱自己喜歡的書籍，而出版社同時又為很多的讀者提供訂閱伺服器，即發布很多不同的書。

同理，因為一個Publisher發行伺服器就是一個資料庫執行個體，這個執行個體中有多的對象是變化的，如表。但是很多的訂閱伺服器並不是對所有的這些變化都感興趣，只對部分感興趣，所以，我們可以在這個發行伺服器上面建立多個Publication發布，從而滿足不同的訂閱伺服器。

在每一個Publication發布中有包含很多的Aritcle（項目），我們知道：項目用於標識發布中自主資料庫對象。一次發布可以包含不同類型的項目，包括表、視圖、預存程序和其他對象。當把表作為項目發布時，可以用篩選器限制發送到訂閱伺服器的資料的列和行。

下面，就帶領大家一起建立一個Publication。

 

 

建立Publication

想要建立一個Publication，必須首先要將一個Publisher和Distributor進行關聯。我們在上一篇文章中已經講述了如何建立和配置Distributor，這裡就在贅述。

誰可以建立一個Publication發布

要清楚，不是誰都可以建立Publication的。只有具有db_owner的角色的使用者才可以建立。

為了使得資料庫可以在Replication中使用，我們必須要進行一定的配置。我們在Publisher（發行伺服器）的對象管理器中進行如下操作，

20121017144149.png(47.93 K)10/17/2012 2:48:18 PM

 

在Replication節點上面點擊右鍵，然後開始設定相關的內容，如：

2.png(49.20 K)10/17/2012 2:48:18 PM

 

在彈出的視窗中包含了兩個選項。在”General”選項卡中，我們可以設定串連到Distributor的使用者的資訊，因為Publisher串連到Distributor，肯定是通過某個使用者才能連過去的，我們在這裡就可以設定這個使用者的密碼等資訊。

在”Publication Databases”選項卡中，我們可以選擇哪個資料庫將會作為發布源來對外發布資料。並且，還可以選擇採用何種複製方式，如事務複製，合併式複寫。

 

 

 

建立新的Publication

配置好了Publisher之後，就可以建立一個Publication了，其實這個步驟，我們在第一篇文章中也做了簡要的展示，

 

4.png(37.73 K)10/17/2012 3:08:37 PM

 

 

然後根據嚮導一步步的建立，這裡就不在重複，下面直接給出圖示：

 

5.png(31.15 K)10/17/2012 3:08:37 PM

 

 

 

6.png(56.71 K)10/17/2012 3:08:37 PM

 

 

我們這裡示範的是事務複製的樣本。

另外，在其中，還有一個另外的一個事務複製（Transaction publication with updatable subscriptions，事務複製的可更新訂閱）。

事務複製支援在訂閱伺服器中通過可更新訂閱和點對點複寫來進行更新。下面介紹兩種可更新訂閱：

·       立即更新。必須串連發行伺服器和訂閱伺服器才能在訂閱伺服器中更新資料。

·       排隊更新。不必串連發行伺服器和訂閱伺服器即可在訂閱伺服器中更新資料。可以在訂閱伺服器或發行伺服器離線時進行更新。

在訂閱伺服器中更新資料時，首先將資料傳播到發行伺服器，然後再傳播到其他訂閱伺服器。如果使用立即更新，將使用兩階段交易認可協議立即傳播更改。如果使用排隊更新，更改將儲存在隊列中；當網路連接可用時，再在發行伺服器中非同步應用排隊事務。由於更新非同步傳播至發行伺服器，所以發行伺服器或另一台訂閱伺服器有可能更新同一資料，而在應用程式更新時會發生衝突。將根據建立發布時設定的衝突解決方案策略檢測和解決衝突。

如果在建立發布嚮導中建立具有可更新訂閱的事務發布，將同時啟用立即更新和排隊更新。如果使用預存程序建立發布，則可以啟用一個或兩個選項。建立發布的訂閱時，可以指定要使用的更新模式。如有必要，以後可以在兩種更新模式之間切換。

 

擇項目(Articles)

在上面的嚮導中選擇了Publication的類型之後，接下來就是要選擇把那些對象作為Article發布出去。一般而言，一個Article就是指代資料庫中的一個對象。在中，在Articles嚮導頁中列出了發行就緒的所有的對象：表，預存程序，視圖，函數。

 

7.png(54.86 K)10/17/2012 3:23:51 PM

 

 

很多的時候，當我們的Articles都是選擇表，因為我們要把表中的改變的資料發布出去。對於表，我們也有更多的選擇，例如選擇那些欄位，因為可能在表中有些資料是不變的，此時我們只要選擇那些資料常常改變的欄位，減少不必要的資料轉送。

 

8.png(12.12 K)10/17/2012 3:23:51 PM

 

 

另外，我們還可以點擊”Aritlces Properties”來設定更多有關Articles的選項，

 

9.png(68.15 K)10/17/2012 3:23:51 PM

 

 

那麼，這裡需要注意的就是：我們可以同時為很多的Article設定選項，也可以為某一個Article設定。

如果我們的選擇的Articles中包含表，那麼我們可以在嚮導的下一步對錶添加一些過濾條件，:

 

 

Snapshot快照

在上面選擇和配置了Articles之後，下面就要思考一個“雞生蛋，蛋生雞”的問題：既然是把Publisher中的資料同步到Subscriber中，那麼，在Subscriber上面首先一定要存在一個和Publisher一樣的資料庫，之後才能把Publisher中的改變同步過去。

在嚮導中的這個Snapshot步驟就是來在Subscriber中建立一個現有資料庫的快照的，建立快照的過程可以在立刻進行，也可以在嚮導完成之後在某個時刻運行，

11.png(55.62 K)10/17/2012 4:03:06 PM

 

在這裡又有一些點需要注意。建立一個快照的時候，我們的Publication選擇的那些表會被加上鎖，如果那些表很大，那麼這個加鎖的過程會很長，導致對錶的讀寫都延時，而且會進行大量的讀寫日誌的操作，從而消耗大量的CPU，磁碟I/O等資源。另外，如果表過大，在傳輸的過程中會嚴重消耗網路資源，可能導致外部對資料庫的訪問被阻塞。

 

安全設定

設定了快照之後，下一步就要設定運行Publication的代理進程採用何種的身份進行運行。

12.png(46.73 K)10/17/2012 4:28:33 PM

 

在事務複製的Publication中涉及到的兩個代理分別是快照代理和日誌讀取代理。

快照代理的任務就是把Publication中的資料移動到之間在Distributor中設定的快照檔案夾和distribution資料庫中。為了實現這些操作，這裡設定的使用者在publication涉及到的資料庫和distribution資料庫中都必須在db_owner角色中。而起這個使用者還必須對快照檔案夾有寫的許可權。

日誌讀取代理主要用來把publication中的資料複製到distribution中，但是這個代理不需要訪問快照檔案夾。所以，日誌讀取代理的這個使用者只要在distribution資料庫中處於db_owner的角色就行了。

我們可以通過點擊“Security Setting”進行更多的設定，

13.png(53.74 K)10/17/2012 4:28:33 PM

 

設定完成之後，點擊下一步，直到完成。

20121017162747.png(62.31 K)10/17/2012 4:28:33 PM

 

最後結果：

20121017162755.png(27.77 K)10/17/2012 4:28:33 PM

 

潛在問題分析

大家從上面的操作可以知道，建立一個Replication的應用需要花很多的步驟，步驟越多，可能出現的問題也就越多。其中最有可能出現問題的地方就是安全設定那一塊。所以，在配置之前已經要把使用者和對應的角色指派好，一般的建議是在採用SQL Server驗證方式來串連。