不同解決方案的比較

共享磁碟故障轉移

共享磁碟故障轉移透過僅擁有一個資料庫副本來避免同步開銷。它使用由多臺伺服器共享的單個磁碟陣列。如果主資料庫伺服器發生故障，備用伺服器能夠掛載並啟動資料庫，就像從資料庫崩潰中恢復一樣。這允許快速故障轉移而不會丟失資料。

共享硬體功能在網路儲存裝置中很常見。也可以使用網路檔案系統，但必須注意檔案系統是否具有完整的POSIX行為（請參見第 18.2.2 節）。此方法的一個重大限制是，如果共享磁碟陣列發生故障或損壞，主伺服器和備用伺服器都將無法執行。另一個問題是，在主伺服器執行時，備用伺服器永遠不應訪問共享儲存。

檔案系統（塊裝置）複製

共享硬體功能的一個修改版本是檔案系統複製，其中對檔案系統的所有更改都會映象到駐留在另一臺計算機上的檔案系統。唯一的限制是映象必須以確保備用伺服器具有檔案系統的一致副本的方式進行 — 具體而言，對備用伺服器的寫入必須按照與主伺服器相同的順序進行。DRBD是一種流行的 Linux 檔案系統複製解決方案。

事務日誌傳送

透過讀取預寫日誌 ( WAL ) 記錄流，溫備用伺服器和熱備用伺服器可以保持最新狀態。如果主伺服器發生故障，備用伺服器將包含主伺服器的幾乎所有資料，並可以快速成為新的主資料庫伺服器。這可以是同步的，也可以是非同步的，並且只能針對整個資料庫伺服器執行。

備用伺服器可以使用基於檔案的日誌傳送（第 26.2 節）或流複製（參見第 26.2.5 節）或兩者結合來實現。有關熱備用的資訊，請參見第 26.5 節。

基於觸發器的主備複製

主備複製設定將所有資料修改查詢傳送到主伺服器。主伺服器非同步將資料更改傳送到備用伺服器。備用伺服器可以在主伺服器執行時回答只讀查詢。備用伺服器是資料倉儲查詢的理想選擇。

Slony-I是此類複製的一個示例，具有表級粒度，並支援多個備用伺服器。由於它以非同步方式（批次）更新備用伺服器，因此在故障轉移期間可能會丟失資料。

基於語句的複製中介軟體

使用基於語句的複製中介軟體，程式會攔截每個 SQL 查詢並將其傳送到一臺或所有伺服器。每臺伺服器獨立執行。讀寫查詢必須傳送到所有伺服器，以便每臺伺服器都能收到任何更改。但只讀查詢可以只傳送到一臺伺服器，從而允許讀取工作負載在它們之間分配。

如果查詢只是未經修改地廣播，那麼諸如random()、CURRENT_TIMESTAMP和序列之類的函式在不同的伺服器上可能會有不同的值。這是因為每個伺服器都獨立執行，並且 SQL 查詢是廣播的（而不是實際修改的行）。如果這是不可接受的，那麼中介軟體或應用程式必須從單個伺服器查詢這些值，然後在寫入查詢中使用這些值。另一種選擇是將此複製選項與傳統的主備設定一起使用，即，資料修改查詢僅傳送給主伺服器並透過主備複製傳播到備用伺服器，而不是透過複製中介軟體。還必須注意所有事務在所有伺服器上提交或中止，也許使用兩階段提交（PREPARE TRANSACTION和COMMIT PREPARED）。Pgpool -II和Continuent Tungsten是此類複製的示例。

非同步多主複製

對於不經常連線或通訊鏈路較慢的伺服器（如膝上型電腦或遠端伺服器），保持伺服器之間的資料一致是一項挑戰。使用非同步多主複製，每臺伺服器獨立工作，並定期與其他伺服器通訊以識別衝突的事務。衝突可以由使用者或衝突解決規則解決。Bucardo 就是這種複製型別的一個例子。

同步多主複製

在同步多主複製中，每臺伺服器都可以接受寫入請求，並且修改後的資料在每次事務提交之前都會從原始伺服器傳輸到其他每臺伺服器。大量的寫入活動可能會導致過多的鎖定和提交延遲，從而導致效能不佳。讀取請求可以傳送到任何伺服器。一些實現使用共享磁碟來減少通訊開銷。同步多主複製最適合大多數讀取工作負載，但它的一大優勢是任何伺服器都可以接受寫入請求 — 無需在主伺服器和備用伺服器之間劃分工作負載，並且由於資料更改是從一臺伺服器傳送到另一臺伺服器的，因此不會出現非確定性函式的問題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	•	•	•	•	•		•