SQL Server複製、鏡像、日誌傳輸及容錯移轉叢集區別

 

一, 資料庫複寫

　　SQL Server 2008資料庫複寫是通過發布/訂閱的機制進行多台伺服器之間的資料同步，我們把它用於資料庫的同步備份。這裡的同步備份指的是備份伺服器與主伺服器進行 即時資料同步，正常情況下只使用主要資料庫伺服器，備份伺服器只在主伺服器出現故障時投入使用。它是一種優於檔案備份的Database Backup解決方案。

　　SQL Server的複製分為以下幾種：

1. 快照發布:

　　發行伺服器按預定的時間間隔向訂閱伺服器發送已發佈資料的快照。每隔一段時間將訂閱資料庫中的相應表中的資料全部刪除，然後將自己相應表中的全部插到訂閱資料庫中

　　使用快照式複寫本身是最合適的：

　　1）很少更改資料。

　　2）在一段時間內允許具有相對發行伺服器已淘汰的資料副本。
　　3）複製少量資料。
　　4）在短期內出現大量更改。

　　在資料更改量很大，但很少發生更改時，快照式複寫是最合適的。 例如，如果某銷售組織維護一個產品價格列表且這些價格每年要在固定時間進行一兩次完全更新，那麼建議在資料更改後複製完整的資料快照。 對於給定的某些類型的資料，更頻繁的快照可能也比較適合。 例如，如果一天中在發行伺服器上更新相對小的表，但可以接受一定的延隔時間，則可以在夜間以快照形式傳遞更改。  

　　發行伺服器上快照式複寫的連續開銷低於事務複製的開銷，因為不用跟蹤增量更改。 但是，如果要複製的資料集非常大，那麼若要產生和應用快照，將需要使用大量資源。 評估是否使用快照式複寫時，需要考慮整個資料集的大小以及資料的更改頻率。

2. 事務發布:

　　在訂閱伺服器收到已發佈資料的初始快照集後，發行伺服器將事務串流到訂閱伺服器。

     事務複製通常從發行集資料庫對象和資料的快照開始。 建立了初始快照集後，接著在發行伺服器上所做的資料更改和架構修改通常在修改發生時（幾乎即時）便傳遞給訂閱伺服器。 資料更改將按照其在發行伺服器上發生的順序和事務邊界應用於訂閱伺服器，因此，在發布內部可以保證事務的一致性。

    以下各種情況下適合採用事務複製：

　　1). 希望發生增量更改時將其傳播到訂閱伺服器。

　　2). 從發行伺服器上發生更改，至更改到達訂閱伺服器，應用程式需要這兩者之間的延隔時間較短。
　　3). 應用程式需要訪問中間資料狀態。 例如，如果某一行更改了五次，事務複製將允許應用程式響應每次更改（例如，激發觸發器），而不只是響應該行最終的資料更改。
　　4).發行伺服器有大量的插入、更新和刪除活動。
　　5).發行伺服器或訂閱伺服器不是 SQL Server 資料庫（例如，Oracle）。

　　預設情況下，事務發布的訂閱伺服器應視為唯讀，因為更改將不會傳播回傳布伺服器。 但是，事務複製確實提供了允許在訂閱伺服器上進行更新的選項

3.  具有可更新訂閱的事務發布:

　　在 SQL Server 訂閱伺服器收到已發佈資料的初始快照集後，發行伺服器將事務串流到訂閱伺服器。來自訂閱伺服器的事務被應用於發行伺服器。

4.  合并發布:

　　在訂閱伺服器收到已發佈資料的初始快照集後，發行伺服器和訂閱伺服器可以獨立更新已發佈資料。更改會定期合并。Microsoft SQL Server Compact Edition 只能訂閱合并發布。

　　與事務複製相同，合併式複寫通常也是從發行集資料庫對象和資料的快照開始， 並且用觸發器跟蹤在發行伺服器和訂閱伺服器上所做的後續資料更改和架構修改。 訂閱伺服器在串連到網路時將與發行伺服器進行同步，並交換自上次同步以來發行伺服器和訂閱伺服器之間發生更改的所有行。

　　合併式複寫通常用於伺服器到用戶端的環境中。 合併式複寫適用於下列各種情況：

　　1).  多個訂閱伺服器可能會在不同時間更新同一資料，並將其更改傳播到發行伺服器和其他訂閱伺服器。
　　2). 訂閱伺服器需要接收資料，離線更改資料，並在以後與發行伺服器和其他訂閱伺服器同步更改。
　　3). 每個訂閱伺服器都需要不同的資料分區。
　　4). 可能會發生衝突，並且在衝突發生時，您需要具有檢測和解決衝突的能力。
　　5). 應用程式需要最終的資料更改結果，而不是訪問中間資料狀態。 例如，如果在訂閱伺服器與發行伺服器進行同步之前，訂閱伺服器上的行更改了五次，則該行在發行伺服器上僅更改一次來反映最終資料更改（也就是第五次更改的值）。

　　合併式複寫允許不同網站自主工作，並在以後將更新合并成一個統一的結果。 由於更新是在多個節點上進行的，同一資料可能由發行伺服器和多個訂閱伺服器進行了更新。 因此，在合并更新時可能會產生衝突，合併式複寫提供了多種處理衝突的方法    

      複製的缺點： 表有主鍵，而且表結構日後不能更改，如果架構穩定也是不錯的，如果有很多張表那就比較麻煩了

 　　複製方法及過程：

　　http://www.cnblogs.com/dudu/archive/2010/08/26/1808540.html

　　http://www.cnblogs.com/killkill/archive/2009/07/17/1525733.html

 　　http://dufei.blog.51cto.com/382644/84645

　　http://www.cnblogs.com/wangdong/archive/2008/10/24/1318740.html

 二，資料庫鏡像：

　　資料庫鏡像：

　　優點是系統能自動探索主伺服器故障，並且自動切換至鏡像伺服器。

　　缺點是配置複雜，鏡像資料庫中的資料不可見（在SQL Server Management Studio中，只能看到鏡像資料庫處於鏡像狀態，無法進行任何資料庫操作，最簡單的查詢也不行。想眼見為實，看看鏡像資料庫中的資料是否正確都不行。只 有將鏡像資料庫切換主要資料庫才可見）

　　相對於記錄傳送，資料庫鏡像顯然更高一級。在最簡單的形式下，它其實與記錄傳送的工作原理相似，但是生產伺服器發送事務到鏡像伺服器的頻率要高得多，這意味著更新速度也要快很多。

　　對於資料庫鏡像來說，容錯移轉功能也是需要手動完成。但是你可以添加第三個SQL Server，稱為witness。Witness可以作為一個普通的SQL Server，但是一直留意著其它兩個鏡像伺服器。當主鏡像發生故障，witness可以讓第二個鏡像接管操作，類似一種自動的容錯移轉。

　　在容錯移轉時，任何進行中的用戶端事務都將重新啟動，而由於在這一過程中仍然存在著延遲，鏡像伺服器也不能保證百分之百不遺失資料。

 

三，資料庫日誌傳輸：

 

　　作為高可用性的最低級形式，記錄傳送(log shipping)本質上是SQL Server複製功能的一種延伸

　　允許方案提供者建立多個資料庫副本。日誌傳輸能夠將次資料庫日誌副本同步發送到SQL Server執行個體上。然後這些日誌會在次伺服器上重放，從而保持資料庫副本是最新的。

　　有一些方案提供者使用日誌傳輸作為克服資料庫鏡像缺點的方法。資料庫鏡像是很好的技術，但是它只允許我們實現一個資料庫副本。鏡像可以接近即時的方式進行，所以資料庫修改可以快速地寫到次資料庫上。如果客戶資料庫損壞或資料庫記錄意外刪除，那麼這可能會造成問題。

　　日誌傳輸有兩個主要的優點。首先，方案提供者能夠實現一種延遲，這樣日誌就不會即時重放。這是很重要的，因為如果主(或鏡像)資料庫出現問題，日誌可以在重放之前攔截，因此可以防止問題擴散。

　　日誌傳輸第二個主要的優點是它支援實現多個資料庫副本。有一些單位使用日誌傳輸作為在備份資料中心維護資料庫副本的方法，這能夠防止主要資料中心出現問題時發生資料丟失。

　　雖然日誌傳輸通過是作為資料庫鏡像的補充措施，但是它是一種獨立的技術，它可以不依賴於鏡像技術而獨立使用。

　　http://www.searchdatabase.com.cn/showcontent_11708.htm

 

四，容錯移轉叢集

　　叢集技術是微軟可用性的最進階形式，它需要你設定一個Windows叢集。

　　在叢集中並不會涉及傳輸以及鏡像，取而代之，兩台或更多的電腦將會彼此串連在一個共用的外部儲存空間中，通常是存放區域網路(SAN)。資料庫檔案就存放在這個共用儲存空間上，同樣設定的SQL Server執行個體都運行在叢集節點上。

　　叢集中的所有節點中，實際上只有一個節點是一直處在活動狀態的，如果這個節點發生故障，其它的節點將啟動相應的SQL Server執行個體，並串連共用儲存空間的資料檔案。而整個容錯移轉過程往往只有幾秒鐘時間，對於任何給定的SQL Server執行個體，Windows叢集技術都可以確保用戶端始終注視活動的節點。

　　叢集技術非常複雜，但它是實現高可用的最高效技術。與前面介紹的兩個功能相比，叢集依賴於一個單一的資料庫檔案集。如果這些檔案損壞了，容錯移轉也不能起作用了，因為容錯移轉的執行個體同損壞的檔案是一樣的。而使用鏡像與記錄傳送，你可以對檔案進行即時拷貝，因此不必擔心檔案損壞的問題。SQL Server中，檔案遭到損壞的情況很少發生，因此我認為叢集應該還是一個不錯的選擇。

 　　缺點的。其中一個重要的問題是故障恢複的實現是非常昂貴的。Microsoft只在那些通過Windows Server認證的硬體上才支援故障恢複。  另一個問題是它要求使用共用儲存。

一, 資料庫複寫

　　SQL Server 2008資料庫複寫是通過發布/訂閱的機制進行多台伺服器之間的資料同步，我們把它用於資料庫的同步備份。這裡的同步備份指的是備份伺服器與主伺服器進行 即時資料同步，正常情況下只使用主要資料庫伺服器，備份伺服器只在主伺服器出現故障時投入使用。它是一種優於檔案備份的Database Backup解決方案。

　　SQL Server的複製分為以下幾種：

1. 快照發布:

　　發行伺服器按預定的時間間隔向訂閱伺服器發送已發佈資料的快照。每隔一段時間將訂閱資料庫中的相應表中的資料全部刪除，然後將自己相應表中的全部插到訂閱資料庫中

　　使用快照式複寫本身是最合適的：

　　1）很少更改資料。

　　2）在一段時間內允許具有相對發行伺服器已淘汰的資料副本。
　　3）複製少量資料。
　　4）在短期內出現大量更改。

　　在資料更改量很大，但很少發生更改時，快照式複寫是最合適的。 例如，如果某銷售組織維護一個產品價格列表且這些價格每年要在固定時間進行一兩次完全更新，那麼建議在資料更改後複製完整的資料快照。 對於給定的某些類型的資料，更頻繁的快照可能也比較適合。 例如，如果一天中在發行伺服器上更新相對小的表，但可以接受一定的延隔時間，則可以在夜間以快照形式傳遞更改。  

　　發行伺服器上快照式複寫的連續開銷低於事務複製的開銷，因為不用跟蹤增量更改。 但是，如果要複製的資料集非常大，那麼若要產生和應用快照，將需要使用大量資源。 評估是否使用快照式複寫時，需要考慮整個資料集的大小以及資料的更改頻率。

2. 事務發布:

　　在訂閱伺服器收到已發佈資料的初始快照集後，發行伺服器將事務串流到訂閱伺服器。

     事務複製通常從發行集資料庫對象和資料的快照開始。 建立了初始快照集後，接著在發行伺服器上所做的資料更改和架構修改通常在修改發生時（幾乎即時）便傳遞給訂閱伺服器。 資料更改將按照其在發行伺服器上發生的順序和事務邊界應用於訂閱伺服器，因此，在發布內部可以保證事務的一致性。

    以下各種情況下適合採用事務複製：

　　1). 希望發生增量更改時將其傳播到訂閱伺服器。

　　2). 從發行伺服器上發生更改，至更改到達訂閱伺服器，應用程式需要這兩者之間的延隔時間較短。
　　3). 應用程式需要訪問中間資料狀態。 例如，如果某一行更改了五次，事務複製將允許應用程式響應每次更改（例如，激發觸發器），而不只是響應該行最終的資料更改。
　　4).發行伺服器有大量的插入、更新和刪除活動。
　　5).發行伺服器或訂閱伺服器不是 SQL Server 資料庫（例如，Oracle）。

　　預設情況下，事務發布的訂閱伺服器應視為唯讀，因為更改將不會傳播回傳布伺服器。 但是，事務複製確實提供了允許在訂閱伺服器上進行更新的選項

3.  具有可更新訂閱的事務發布:

　　在 SQL Server 訂閱伺服器收到已發佈資料的初始快照集後，發行伺服器將事務串流到訂閱伺服器。來自訂閱伺服器的事務被應用於發行伺服器。

4.  合并發布:

　　在訂閱伺服器收到已發佈資料的初始快照集後，發行伺服器和訂閱伺服器可以獨立更新已發佈資料。更改會定期合并。Microsoft SQL Server Compact Edition 只能訂閱合并發布。

　　與事務複製相同，合併式複寫通常也是從發行集資料庫對象和資料的快照開始， 並且用觸發器跟蹤在發行伺服器和訂閱伺服器上所做的後續資料更改和架構修改。 訂閱伺服器在串連到網路時將與發行伺服器進行同步，並交換自上次同步以來發行伺服器和訂閱伺服器之間發生更改的所有行。

　　合併式複寫通常用於伺服器到用戶端的環境中。 合併式複寫適用於下列各種情況：

　　1).  多個訂閱伺服器可能會在不同時間更新同一資料，並將其更改傳播到發行伺服器和其他訂閱伺服器。
　　2). 訂閱伺服器需要接收資料，離線更改資料，並在以後與發行伺服器和其他訂閱伺服器同步更改。
　　3). 每個訂閱伺服器都需要不同的資料分區。
　　4). 可能會發生衝突，並且在衝突發生時，您需要具有檢測和解決衝突的能力。
　　5). 應用程式需要最終的資料更改結果，而不是訪問中間資料狀態。 例如，如果在訂閱伺服器與發行伺服器進行同步之前，訂閱伺服器上的行更改了五次，則該行在發行伺服器上僅更改一次來反映最終資料更改（也就是第五次更改的值）。

　　合併式複寫允許不同網站自主工作，並在以後將更新合并成一個統一的結果。 由於更新是在多個節點上進行的，同一資料可能由發行伺服器和多個訂閱伺服器進行了更新。 因此，在合并更新時可能會產生衝突，合併式複寫提供了多種處理衝突的方法    

      複製的缺點： 表有主鍵，而且表結構日後不能更改，如果架構穩定也是不錯的，如果有很多張表那就比較麻煩了

 　　複製方法及過程：

　　http://www.cnblogs.com/dudu/archive/2010/08/26/1808540.html

　　http://www.cnblogs.com/killkill/archive/2009/07/17/1525733.html

 　　http://dufei.blog.51cto.com/382644/84645

　　http://www.cnblogs.com/wangdong/archive/2008/10/24/1318740.html

 二，資料庫鏡像：

　　資料庫鏡像：

　　優點是系統能自動探索主伺服器故障，並且自動切換至鏡像伺服器。

　　缺點是配置複雜，鏡像資料庫中的資料不可見（在SQL Server Management Studio中，只能看到鏡像資料庫處於鏡像狀態，無法進行任何資料庫操作，最簡單的查詢也不行。想眼見為實，看看鏡像資料庫中的資料是否正確都不行。只 有將鏡像資料庫切換主要資料庫才可見）

　　相對於記錄傳送，資料庫鏡像顯然更高一級。在最簡單的形式下，它其實與記錄傳送的工作原理相似，但是生產伺服器發送事務到鏡像伺服器的頻率要高得多，這意味著更新速度也要快很多。

　　對於資料庫鏡像來說，容錯移轉功能也是需要手動完成。但是你可以添加第三個SQL Server，稱為witness。Witness可以作為一個普通的SQL Server，但是一直留意著其它兩個鏡像伺服器。當主鏡像發生故障，witness可以讓第二個鏡像接管操作，類似一種自動的容錯移轉。

　　在容錯移轉時，任何進行中的用戶端事務都將重新啟動，而由於在這一過程中仍然存在著延遲，鏡像伺服器也不能保證百分之百不遺失資料。

 

三，資料庫日誌傳輸：

 

　　作為高可用性的最低級形式，記錄傳送(log shipping)本質上是SQL Server複製功能的一種延伸

　　允許方案提供者建立多個資料庫副本。日誌傳輸能夠將次資料庫日誌副本同步發送到SQL Server執行個體上。然後這些日誌會在次伺服器上重放，從而保持資料庫副本是最新的。

　　有一些方案提供者使用日誌傳輸作為克服資料庫鏡像缺點的方法。資料庫鏡像是很好的技術，但是它只允許我們實現一個資料庫副本。鏡像可以接近即時的方式進行，所以資料庫修改可以快速地寫到次資料庫上。如果客戶資料庫損壞或資料庫記錄意外刪除，那麼這可能會造成問題。

　　日誌傳輸有兩個主要的優點。首先，方案提供者能夠實現一種延遲，這樣日誌就不會即時重放。這是很重要的，因為如果主(或鏡像)資料庫出現問題，日誌可以在重放之前攔截，因此可以防止問題擴散。

　　日誌傳輸第二個主要的優點是它支援實現多個資料庫副本。有一些單位使用日誌傳輸作為在備份資料中心維護資料庫副本的方法，這能夠防止主要資料中心出現問題時發生資料丟失。

　　雖然日誌傳輸通過是作為資料庫鏡像的補充措施，但是它是一種獨立的技術，它可以不依賴於鏡像技術而獨立使用。

　　http://www.searchdatabase.com.cn/showcontent_11708.htm

 

四，容錯移轉叢集

　　叢集技術是微軟可用性的最進階形式，它需要你設定一個Windows叢集。

　　在叢集中並不會涉及傳輸以及鏡像，取而代之，兩台或更多的電腦將會彼此串連在一個共用的外部儲存空間中，通常是存放區域網路(SAN)。資料庫檔案就存放在這個共用儲存空間上，同樣設定的SQL Server執行個體都運行在叢集節點上。

　　叢集中的所有節點中，實際上只有一個節點是一直處在活動狀態的，如果這個節點發生故障，其它的節點將啟動相應的SQL Server執行個體，並串連共用儲存空間的資料檔案。而整個容錯移轉過程往往只有幾秒鐘時間，對於任何給定的SQL Server執行個體，Windows叢集技術都可以確保用戶端始終注視活動的節點。

　　叢集技術非常複雜，但它是實現高可用的最高效技術。與前面介紹的兩個功能相比，叢集依賴於一個單一的資料庫檔案集。如果這些檔案損壞了，容錯移轉也不能起作用了，因為容錯移轉的執行個體同損壞的檔案是一樣的。而使用鏡像與記錄傳送，你可以對檔案進行即時拷貝，因此不必擔心檔案損壞的問題。SQL Server中，檔案遭到損壞的情況很少發生，因此我認為叢集應該還是一個不錯的選擇。

 　　缺點的。其中一個重要的問題是故障恢複的實現是非常昂貴的。Microsoft只在那些通過Windows Server認證的硬體上才支援故障恢複。  另一個問題是它要求使用共用儲存。