sql server主從方案介紹

　　sql server 做爲目前主流的數據庫，用戶遍及世界各地。sql server也有一些比較成熟的主備方案，目前主要有：複製模式(發佈-訂閱模式)、鏡像傳輸模式、日誌傳輸模式、故障轉移集羣。後面會一一介紹介紹各自的優缺點。

（一）複製模式

　　複製模式也被稱爲發佈-訂閱模式，是由主服務器進行發佈消息，備份服務器進行訂閱，當主服務器數據發生變動時，就會發布消息，備份服務器讀取消息進行同步更新，中間過程延遲比較短。

　　複製方式是之前很常見的一種主備，速度快，延遲小，能夠支持部分同步等優勢，可是也有一個很明顯的缺點，由於是部分同步，若是是表修改，能夠主動同步，可是若是是新增表、視圖等操做，必須在發佈屬性中，將新加的表或者視圖添加到同步配置中，不然對這個表作的任何操做都不會同步。

　　複製模式同步，要求數據庫名稱和主機名稱必須一致，不然查找不到數據庫主機；要求數據庫不能使用端口，必須是能夠經過ip直接訪問的；

　　主要分爲如下4種發佈方式：

　　1.快照發布

　　　　快照發布，就是將全部要發佈的內容，作成一個鏡像文件，而後一次性複製到訂閱服務器，兩次快照之間的更新不會實時同步。這種方式佔用帶寬較多，所以比較適用內容不是很大，或者更新不須要很頻繁的場景

　　2.事務發佈/具備可更新訂閱的事務發佈

　　　　事務發佈，是在第一次設置好事務複製以後，全部發布的內容都會進行鏡像快照，訂閱服務器收到已發佈數據的初始快照後，發佈服務器將事務流式傳輸到訂閱服務器。當主服務器數據發生變動時，會經過日誌傳遞同步給訂閱服務器，數據近似於同步更新。

　　　　此方式會對主服務器性能形成很大影響（實時同步每次變動，而不是最終變動），適用於對數據及時性要求比較嚴格主備方案，可是目前已被微軟提供的集羣Always On所取代。

 

　　3.合併發佈

　　　　合併發佈是至關於兩臺都是主服務器，均可以對數據進行更新修改等操做，而後定時將發佈服務器上的內容與訂閱服務器上的內容進行合併，並根據配置保留相應內容，此種不多用。

（二）鏡像傳輸模式

　　數據庫鏡像傳輸，嚴格來講不是主從架構，而是主備架構，將兩臺數據庫服務器經過一臺中間監控服務器關聯起來，兩臺服務器經過鏡像文件，實時同步數據（有延遲，延遲很短）。當主服務器宕機以後，監控服務器自動切換到備份服務器上。

　　此方案優勢是能夠快速的切換主備方案，相比較Always on集羣，能夠不用共享磁盤便可實現，避免了數據庫集羣存儲單點故障，致使整個集羣崩潰。

　　缺點也很明顯，不管是主備服務器，要實現同步操做，都是依賴於性能低的那一端，所以兩臺服務器都要是高性能的才能夠保證同步的及時性；同時備份服務器只是備份和故障轉移，不能提供從服務器的只讀訪問，所以才說是主備服務器，並且是一對一，只能有一臺備份服務器。

（三）日誌傳輸模式

　　與鏡像傳輸模式相似，是將主數據庫日誌備份，發送到從服務器上，而後從服務器還原日誌，更新數據。

　　此方式優勢在於從服務器能夠有多臺從服務器，並且當主服務器腳本操做異常後，只須要在日誌同步以前，及時攔截日誌傳輸，便可保留從服務器數據，減小災難損失；此方式相較於「複製發佈」模式，還有一個有點就是不管是新增表、視圖等等，都會經過日誌同步給從服務器，而複製模式不行

　　而相應的缺點就是經過日誌備份傳輸，在還原，會有較大的時間延遲。並且沒法自動轉移故障，只能手動轉移。

（四）故障轉移集羣

　　集羣技術是微軟提供的，可用性最高的主備方案。它是將多臺服務器經過一個共享的外部存儲區域（SAN），鏈接成一個資源共享的服務器羣體，數據庫文件和實例，都存放並運行在該共享區域節點上，每臺服務器至關於一個節點，共同訪問共享的節點實例。服務器只有一個節點處於活動狀態，當活動節點出現故障，會有其餘節點主動啓動，取代當前故障點，整個過程只須要幾秒鐘，用戶沒法感知。

　　集羣有不少優勢，是目前最高效的高可用技術，可是他也有很明顯的缺點，全部的節點，都依賴於共享節點實例，若是共享節點出現故障，將會致使整個集羣失去做用，且很難恢復。

文章借鑑

　　https://www.cnblogs.com/CareySon/archive/2012/06/20/IntroductToSQLServerReplicationPart1.html