qileilove

          blog已經轉移至github,大家請訪問 http://qaseven.github.io/

          SQL Server復制入門----復制的幾種模式

            發布-訂閱的復制模式

            這種模式使得發布服務器也是訂閱服務器,如圖3所示。

          圖3.發布-訂閱復制模式

            這種模式適用于服務器A和服務器B的網絡非常昂貴但服務器B和各個訂閱服務器的網絡成本很低的情況。比如,公司的總部在北京,服務器A在北京,服務器B是上海分公司的,各個訂閱服務器通過局域網和服務器B進行連接。在這個例子中,服務器A和服務器B通過VPN進行連接,這個費用是相當昂貴的,而服務器B和各個訂閱服務器通過局域網連接的成本可以忽略。

            以訂閱服務器為中心的復制模式

            這種模式以訂閱服務器為中心,如圖4所示。

          圖4.以訂閱服務器為中心復制模式

            這種模式適用的場景比如:各個區域將各自的業務數據匯總到總部這種類型的業務場景。

            多個發布服務器和多個訂閱服務器的復制模式

            這種模式適用于數據對等的環境,一個簡化的版本如圖5所示。

          圖5.多個發布服務器和多個訂閱服務器  簡介

            本篇文章根據發布服務器,分發服務器和訂閱服務器的組織方式和復制類型來講述常用復制的幾種模式。

            模式的選擇

            選擇復制的模式取決于多個方面。首先需要考慮具體的業務需求,在此之后還需要考慮硬件和網絡的限制。對于業務需求來說考慮的角度可以分為兩個部分:自治和延時。自治是指”數據不被影響的程度”,比如說一個業務場景:公司的總部在北京,發布服務器和分發服務器全在總部,各個地區的分部有訂閱服務器,使用快照復制來接收推送訂閱總部每個月一次的公司員工通訊錄。在這個業務場景中,訂閱服務器僅僅是接收發布服務器發布的通訊錄信息,對于這些信息的修改是不會回傳給總部服務器的,這個業務場景的自治程度就是非常低的。而對于延時來說,就是”在發布服務器上的數據修改應用到訂閱服務器上的時間”,比如還是上面那個例子,每次訂閱服務器的訂閱周期是一個月,在此期間總部的通訊錄可能經過了多次修改,但一個月以后才會同步到訂閱服務器,那么這種場景的延時是非常高的。

            其次就是硬件和網絡的限制,比如將發布服務器和分發服務器設置在一臺服務器上,在現有的情況下CPU是否能夠承受這些負擔?或是使用快照復制,發布服務器和訂閱服務器之間的網絡寬帶是否能夠承受在一定發布周期內的數據量傳輸?

            在簡單了解了模式選擇的標準后,下面我們來看常用的幾種復制模式。

            以發布服務器為中心的復制模式

            這種模式多個訂閱服務器以一個發布服務器為中心進行訂閱,如圖1所示。

          圖1.多個訂閱服務器以發布服務器為中心的模式

            這種模式也是復制模式中最簡單的模式,這種模式可以使用快照發布和事務發布。不難看出,這種情景的自治性是比較低的,因此這種模式適用于以下幾種業務場景。

            ● 訂閱服務器用于報表生成.

            ● 發布服務器用來發布類似前文所說的員工通訊錄,產品資料等主(Master)信息

            ● 使用事務發布,使得訂閱服務器承擔部分負載

            ● 在發布服務器Down了以后,作為緊急備用服務器

            當然,這種模式的缺陷也是顯而易見的。

            ● 首先是發布服務器和分發服務器在同一臺服務器上對CPU和內存的消耗服務器硬件是否能夠承受是一個問題

            ● 在OLTP環境中如果每天要修改的數據量過大,比如超過10%,那么需要傳送到的訂閱服務器的數據量過大也是不得不考慮的一個問題

            以發布服務器和分發服務器為中心的復制模式

            這種模式其實和上一種模式區別不大,只是分離了發布服務器和分發服務器,如圖2所示。

          圖2.以發布服務器和分發服務器為中心的復制模式

            這種模式是將分發任務對CPU,內存和網絡帶來的負載轉移到另一臺分發服務器了。從而減輕發布服務器的壓力和支持更多的訂閱服務器。此外,我們知道一個分發服務器支持多個發布服務器的,因此也可以多個發布服務器使用一個分發服務器。

            這種模式還有一個好處是可以將分發服務器放到DMZ區域和訂閱服務器連接以避免發布服務器直接暴漏在外網。

            當然了,這種模式最重要的一點是發布服務器和分發服務器一定要有可靠的網絡連接,這種模式和圖1提到的第一種模式適用的業務場景基本一致。

            這種模式非常適合業務數據對等的環境,比如說這類業務場景,一個銷售公司在同一個城市有3個分店,這三個分店之間是對等的,它們之間通過復制來同步庫存。使得每個店都可以了解其它分店的庫存情況。這類業務場景適合使用多個發布服務器和多個訂閱服務器的復制模式。

            具有可更新訂閱的事務發布模式

            這種模式非常類似圖1中所說的模式,但這種模式允許訂閱服務器更新數據。如圖6所示。

          圖6.具有可更新訂閱事務的發布模式

            在這種模式下,比如訂閱服務器B更新了數據,這個數據會傳送回發布服務器,如果發布服務器接收了這個數據,那么這個數據會同時同步到其它訂閱服務器。

            合并發布模式

            合并發布模式適用于所有服務器共享一部分數據的場景,如圖7所示。

          圖7.合并發布模式

            這種模式下,每個服務器并不是互相訂閱,而是互相共享。這種模式同樣適用于圖5所述的業務模式。

            總結

            本文講述了復制的幾種模式以及它們的所適用的一些場景,很多更復雜的復制模式大多都是對以上幾種模式的組合或者拓展。理解上述簡單的復制模式是理解復雜復制模式的基礎。

          posted on 2012-07-11 09:29 順其自然EVO 閱讀(265) 評論(0)  編輯  收藏 所屬分類: 數據庫

          <2012年7月>
          24252627282930
          1234567
          891011121314
          15161718192021
          22232425262728
          2930311234

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 淅川县| 临西县| 白水县| 昆山市| 葵青区| 久治县| 休宁县| 罗定市| 翁牛特旗| 琼海市| 建湖县| 巴彦淖尔市| 石林| 尚义县| 临汾市| 昆山市| 临江市| 林西县| 西盟| 德保县| 涪陵区| 临邑县| 安远县| 邹城市| 凌源市| 土默特左旗| 金秀| 灵山县| 平泉县| 汕头市| 北辰区| 石棉县| 蓬莱市| 两当县| 兴城市| 郎溪县| 柘荣县| 将乐县| 墨脱县| 汉沽区| 呼图壁县|