標籤:
1.2不同類型的複製
現在,您已經完全地理解了物理和理論的局限性,可以開始學習不同類型的複製了。
1.2.1 同步和非同步複製
我們可以做的第一個區分是同步複製和非同步複製的區別。
這是什麼意思呢?假設我們有兩台伺服器,希望從一台伺服器(the master)複製資料到第二台伺服器(the slave)。說明了同步和非同步複製的概念:
我們可以使用一個簡單的事務如下所示:
BEGIN:
INSERT INTO foo VALUES (‘bar‘);
COMMIT;
在非同步複製的情況下,事務被提交到master之後資料才可以被複製。換句話說,slave從不會超前master,就寫操作而言,通常滯後於master一些。此延遲(delay)被稱為滯後性(lag)。
同步複製強制執行了較高的一致性規則。如果您決定使用同步複製(如何做到這一點實際上將在第五章中討論,建立同步流複製),系統必須確保通過事務寫入的資料至少事務同時在兩台伺服器上提交。這意味著:slave 不滯後於master,而且終端使用者在兩台伺服器上看到的資料是一致的。
[有些系統也將使用仲裁伺服器來決定。因此,它不是總是關於只有兩個或者更多的伺服器。如果一個仲裁伺服器被使用,超過一半的伺服器必須同意叢集內的行動。]
理解複製和資料丟失
當一個事務從master複製到slave,很多事情必須考慮到,尤其是當涉及到像資料丟失的事情。
假設我們正在以以下方式非同步複製資料:
- 事物發送到master。
- 事物提交到master。
- 在事物發送到slave之前,master宕機。
- slave永遠都不會收到這個事務。
在非同步複製的情況下,有一個視窗(滯後),在滯後視窗期間資料會丟失。滯後視窗的大小因設定類型的不同而不同。它的大小非常短(幾毫秒)或非常長(幾分鐘,幾小時,幾天)。一個重要的事實是:資料可能丟失。一個小的滯後只會是資料丟失的可能性較小,但,任何大於零的滯後都容易導致資料丟失。
如果您想確保資料永遠不丟失,您必須切換到同步複製。正如您在這個章節已經看到的,一個同步事務是同步的,因為如果事物提交到了兩台伺服器它是有效。
考慮效能問題
正如您在關於光速和延遲章節所瞭解到的,通過網路發送不必要的訊息的開銷是昂貴的和費時的。如果一個事務採用同步的方式複製,PostgreSQL必須確保資料到達第二個節點,這樣就會導致延遲問題。
在許多方面,同步複製比非同步複製要昂貴很多,因此如果這種消耗確實需要和調整,人們應該三思而後行。(只在需要的時候使用同步複製)
[當真的需要的時候,才使用同步複製。]
1.2.2單master複製與多master複製
各種複製設定的第二種分類方法是單masster複製和多master複製。
單master意味著寫操作只能發送到一個伺服器,該伺服器分配資料到內部設定的slave上。slave只能接收讀操作但是不會接收寫操作。
相對於單master複製,多master複製允許寫操作發送到所有叢集內部的伺服器。顯示了系統如何在一個概念層面工作:
可以寫到叢集內部的任何節點聽起來像一個優點,但它不是一個必須的優點。其原因是多master複製給系統添加了不少複雜性。在只有一個master的情況下,哪個資料是正確的,資料會流向哪個方向是非常清楚的,而且在複製過程中很少有衝突。多master複製是完全不同的,寫操作可以同時被發送到多個節點,叢集必須非常清楚衝突並妥善地處理它們。使用鎖來解決這個問題是一個可供選擇的方法,但這種方法會產生其自身的問題。
[請記住,解決衝突的需要會產生網路通訊,並且這可以瞬間變成由延遲引起的可擴充性問題。]
1.2.3 邏輯複製與物理複製
分類複製的另一種方式是邏輯複製和物理複製之間進行的區分。
不同是細微的,但非常重要。物理複製指系統將移動資料到遠程伺服器。
因此,如果有東西被插入。遠程伺服器將擷取資料的二進位格式,而不是通過SQL。
邏輯複製意味著一個變化,相當於即將到來的資料被複製。
讓我們看一個例子,充分理解兩者的差異:
test=# CREATE TABLE t_test (t date);
CREATE TABLE
test=# INSERT INTO t_test VALUES (now())
RETURNING *;
t
------------
2013-02-08
(1 row)
INSERT 0 1
我能看到這裡執行了兩個事務:第一個事務建立了一個表。一旦這個完成後,第二個事務向表裡增加了一個簡單的日期並提交。
在邏輯複製的情況下,改變將被以邏輯形式發送到某種隊列,因此系統不發送普通的SQL,但也許是如下的東西:
test=# INSERT INTO t_test VALUES (‘2013-02-08‘);
INSERT 0 1
注意,函數調用已被替換為實際的值。如果slave重新計算now()函數,這將是一個巨大的災難,因為在遠程伺服器的日期可能是一個完全不同的日期。
[有些系統把基於語句的複製作為核心技術。例如:MySQL使用一個所謂的bin-log來複製,這實際上並不是二進位,而是某種形式的邏輯複製。]
物理複製將工作在一個完全不同的方式:不是發送一些SQL(或其它),這在邏輯上是等價的,系統會發送PostgreSQL內部所做的二進位替代物。
下面是一些二進位替代物,我們的兩個事務可能被觸發(到目前為止,還不是一個完整的列表):
- 添加一個8k的塊到pg_class並插入一條新的記錄(表明表是目前的狀態)。
- 添加行到pg_attribute儲存列名。
- 執行這些表內的各種變化。
- 記錄提交狀態等等。
物理複製的目標是在相同的物理層級建立一個系統的副本。這意味著在所有的伺服器上相同的資料將在您的表的相同的地方。在邏輯複製的情況下,但是不論內容是否在相同的地方,沒有任何不同,內容應該是相同的。
何時使用物理複製
物理複製使用起來非常方便,尤其是容易建立。當目標是建立系統的相同副本(建立一個備份後,簡單地擴充)時,物理複製被廣泛使用。
在許多設定中,物理複製是標準的方法,該方法把儘可能最低的複雜性暴露給終端使用者。它是理想的向外擴張資料的方法。
何時使用邏輯複製
通常邏輯複製的設定有點難,但它提供了更大的靈活性。當涉及到升級現有的資料庫時,它也是特別地重要。物理複製完全不適合版本跳躍,因為您不能簡單地依靠每個版本的PostgreSQL具有相同的磁碟布局的事實。儲存格式可能會隨時間而改變,因此二進位複製顯然是不適合從一個版本跳躍到另一個版本的。
邏輯複製允許解耦合資料存放區方式和資料轉送,複製方式。通過使用中性協議,該協議並不和特定版本的PostgreSQL綁定,很容易從一個版本跳躍到另一個版本。
PostgreSQL Replication之第一章 理解複製概念(2)