PostgreSQL的高可用與數據複製方案

時間 2019-11-09

標籤 postgresql 可用數據複製方案欄目 Postgre SQL 简体版

原文原文鏈接

PostgreSQL是開源的，有多種高可用與數據複製方案，這裏作個簡單的比較。html

1、高可用性、負載均衡、複製方案

共享磁盤失效切換sql

共享磁盤失效切換經過僅保存一份數據庫副原本避免花在同步上的開銷。這個方案讓多臺服務器共享使用一個單獨的磁盤陣列。若是主服務器失效，備份服務器將當即掛載該數據庫，就像是從一次崩潰中恢復同樣。這個方案容許快速的失效切換而且不會丟失數據。數據庫

共享硬件的功能一般由網絡存儲設備提供，也可使用徹底符合POSIX行爲的網絡文件系統(參閱Section 17.2.1)。這種方案的侷限性在於若是共享的磁盤陣列損壞了，那麼整個系統將會癱瘓。另外一個侷限是備份服務器在主服務器正常運行的時候不能訪問共享的存儲器。ruby

文件系統複製（塊設備）服務器

一種改進的方案是文件系統複製：對文件系統的任何更改都將鏡像到備份服務器上。這個方案的惟一侷限是必須確保備份服務器的鏡像與主服務器徹底一致— 特別是寫入順序必須徹底相同。DRBD是Linux上的一種流行的文件系統複製方案。網絡

事務日誌傳送負載均衡

熱備份服務器能夠經過讀取WAL記錄流來保持數據庫的當前狀態。若是主服務器失效，那麼熱備份服務器將包含幾乎全部主服務器的數據，並能夠迅速的將本身切換爲主服務器。這是一個異步方案，而且只能在整個數據庫服務器上實施。dom

使用基於文件的日誌傳送或流複製，或二者相結合。前者參閱Section 25.2, 後者參閱Section 25.2.5。請參閱Section 25.5獲取關於熱備的信息。異步

基於觸發器的主備複製函數

這個方案將全部修改數據的請求發送到主服務器。主服務器異步向從服務器發送數據的更改信息。從服務器在主服務器運行的狀況下只應答讀請求。對於數據倉庫的請求來講，從服務器很是理想的。

Slony-I是這個方案的一個例子，它支持針對每一個表的粒度並支持多個從服務器。由於它異步、批量的更新從服務器，在失效切換的時候可能會有數據丟失。

基於語句的複製中間件

可使用一個基於語句的複製中間件程序截取每個SQL查詢，並將其發送到某一個或者所有服務器。每個服務器都獨立運行。讀-寫請求發送給全部服務器，因此每一個服務器接收到任何變化。可是隻讀請求則僅發送給某一個服務器，從而實現讀取的負載均衡。

若是隻是簡單的廣播修改數據的SQL語句，那麼相似random(), CURRENT_TIMESTAMP 以及序列函數在不一樣的服務器上將生成不一樣的結果。這是由於每一個服務器都獨立運行而且廣播的是SQL語句而不是如何對行進行修改。若是這種結果是不可接受的，那麼中間件或者應用程序必須保證始終從同一個服務器讀取這些值並將其應用到寫入請求中。另外還必須保證每個事務必須在全部服務器上所有提交成功或者所有回滾，或者使用兩階段提交(PREPARE TRANSACTION 和COMMIT PREPARED)。 Pgpool-II和Continuent Tungsten是這種方案的實例。

異步多主服務器複製

對於那些不規則鏈接的服務器(好比筆記本電腦或遠程服務器)，要在它們之間保持數據一致是很麻煩的。在這個方案中，每臺服務器都獨立工做並週期性的與其餘服務器通訊以識別相互衝突的事務。能夠經過用戶或者衝突判決規則處理出現的衝突。

同步多主服務器複製

在這種方案中，每一個服務器均可以接受寫入請求，修改的數據將在事務被提交以前必須從原始服務器廣播到全部其它服務器。過多的寫入動做將致使過多的鎖定，從而致使性能低下。事實上，在多臺服務器上同時寫的性能老是比在單獨一臺服務器上寫的性能低。讀請求將被均衡的分散到每臺單獨的服務器。某些實現使用共享磁盤來減小通訊開銷。同步多主服務器複製方案最適合於讀取遠多於寫入的場合。它的優點是每臺服務器都能接受寫請求—所以不須要在主從服務器之間劃分工做負荷。由於在服務器之間發送的是數據的變化，因此不會對非肯定性函數(好比random())形成不良影響。

PostgreSQL不提供這種類型的複製。可是PostgreSQL的兩階段提交(PREPARE TRANSACTION和 COMMIT PREPARED) 能夠用於在應用層或中間件代碼中實現這個功能。

商業解決方案

由於PostgreSQL是開放源代碼而且很容易被擴展，許多公司在PostgreSQL的基礎上建立了商業的閉源解決方案，提供獨特的失效切換、複製、負載均衡功能。

Feature	Shared Disk Failover	File System Replication	Transaction Log Shipping	Trigger-Based Master-Standby Replication	Statement-Based Replication Middleware	Asynchronous Multimaster Replication	Synchronous Multimaster Replication
Most Common Implementation	NAS	DRBD	Streaming Repl.	Slony	pgpool-II	Bucardo
Communication Method	shared disk	disk blocks	WAL	table rows	SQL	table rows	table rows and row locks
No special hardware required		•	•	•	•	•	•
Allows multiple master servers					•	•	•
No master server overhead	•		•		•
No waiting for multiple servers	•		with sync off	•		•
Master failure will never lose data	•	•	with sync on		•		•
Standby accept read-only queries			with hot	•	•	•	•
Per-table granularity				•		•	•
No conflict resolution necessary	•	•	•	•			•

有幾個解決方案不適合上邊這些分類：

數據分區

數據分區將表拆分爲數據集。每一個數據集只有一臺服務器能夠修改。例如，數據能夠按辦事處進行分區，例如，倫敦和巴黎，每一個辦公室用一個服務器。若是查詢須要倫敦和巴黎相結合的數據，應用程序能夠查詢兩臺服務器，或主/備用複製能夠用來保持每一個服務器上有其餘辦公室的只讀數據副本。

多服務器並行查詢執行

許多上述解決方案容許多個服務器來處理多個查詢，但不是容許單個查詢使用多個服務器來更快完成。此解決方案容許多個服務器上單個查詢同時運行。它一般被經過服務器之間的數據分開而執行其查詢的一部分，並將結果返回到中央服務器，由它來聯合結果並返回給用戶。 Pgpool-II有這種能力。也可使用PL/Proxy工具集實現。

2、多節點集羣方案比較

能夠基於Replication Stream（流複製）。

Program	License	Maturity	Replication Method	Sync	Connection Pooling	Load Balancing	Query Partitioning
PgCluster	BSD	Stalled暫停	Master-Master	Synchronous	No	Yes	No
pgpool-I	BSD	Stable	Statement-Based Middleware	Synchronous	Yes	Yes	No
Pgpool-II	BSD	Recent release	Statement-Based Middleware	Synchronous	Yes	Yes	Yes
slony	BSD	Stable	Master-Slave	Asynchronous	No	No	No
Bucardo	BSD	Stable	Master-Master, Master-Slave	Asynchronous	No	No	No
Londiste	BSD	Stable	Master-Slave	Asynchronous	No	No	No
Mammoth	BSD	Stalled	Master-Slave	Asynchronous	No	No	No
rubyrep	MIT	Stalled	Master-Master, Master-Slave	Asynchronous	No	No	No
BDR (Bi-Directional Replication)	PostgreSQL (BSD)	Beta	Master-Master (no triggers needed)	Asynchronous	No	No	No
pg_shard	LGPL	Recent release	Statement-based Middleware (as an extension)	Synchronous	No	Yes	Yes