# 25.1\. 不同解決方案的比較 共享磁盤失效切換 共享磁盤失效切換通過僅保存一份數據庫副本來避免花在同步上的開銷。 這個方案讓多臺服務器共享使用一個單獨的磁盤陣列。 如果主服務器失效，備份服務器將立即掛載該數據庫， 就像是從一次崩潰中恢復一樣。這個方案允許快速的失效切換并且不會丟失數據。 共享硬件的功能通常由網絡存儲設備提供， 也可以使用完全符合POSIX行為的網絡文件系統(參閱[Section 17.2.1](#calibre_link-1654))。 這種方案的局限性在于如果共享的磁盤陣列損壞了， 那么整個系統將會癱瘓。 另一個局限是備份服務器在主服務器正常運行的時候不能訪問共享的存儲器。 文件系統復制（塊設備） 一種改進的方案是文件系統復制：對文件系統的任何更改都將鏡像到備份服務器上。 這個方案的唯一局限是必須確保備份服務器的鏡像與主服務器完全一致— 特別是寫入順序必須完全相同。DRBD是Linux上的一種流行的文件系統復制方案。 事務日志傳送 熱備份服務器可以通過讀取WAL記錄流來保持數據庫的當前狀態。 如果主服務器失效，那么熱備份服務器將包含幾乎所有主服務器的數據， 并可以迅速的將自己切換為主服務器。這是一個異步方案， 并且只能在整個數據庫服務器上實施。 使用基于文件的日志傳送或流復制，或兩者相結合。 前者參閱[Section 25.2](#calibre_link-1133), 后者參閱[Section 25.2.5](#calibre_link-1048)。 請參閱[Section 25.5](#calibre_link-1047)獲取關于熱備的信息。 基于觸發器的主備復制 這個方案將所有修改數據的請求發送到主服務器。 主服務器異步向從服務器發送數據的更改信息。 從服務器在主服務器運行的情況下只應答讀請求。對于數據倉庫的請求來說， 從服務器非常理想的。 Slony-I是這個方案的一個例子，它支持針對每個表的粒度并支持多個從服務器。 因為它異步、批量的更新從服務器， 在失效切換的時候可能會有數據丟失。 基于語句的復制中間件 可以使用一個基于語句的復制中間件程序截取每一個SQL查詢， 并將其發送到某一個或者全部服務器。每一個服務器都獨立運行。 讀-寫請求發送給所有服務器，所以每個服務器接收到任何變化。但是只 讀請求則僅發送給某一個服務器，從而實現讀取的負載均衡。 如果只是簡單的廣播修改數據的SQL語句， 那么類似`random()`, `CURRENT_TIMESTAMP` 以及序列函數在不同的服務器上將生成不同的結果。 這是因為每個服務器都獨立運行并且廣播的是SQL語句而不是如何對行進行修改。 如果這種結果是不可接受的，那么中間件或者應用程序必須保證始終從同 一個服務器讀取這些值并將其應用到寫入請求中。 另外還必須保證每一個事務必須在所有服務器上全部提交成功或者全部回滾， 或者使用兩階段提交([PREPARE TRANSACTION](#calibre_link-903) 和[COMMIT PREPARED](#calibre_link-901))。 Pgpool-II和Continuent Tungsten是這種方案的實例。 異步多主服務器復制 對于那些不規則連接的服務器(比如筆記本電腦或遠程服務器)， 要在它們之間保持數據一致是很麻煩的。 在這個方案中，每臺服務器都獨立工作并周期性的與其他服務器通信以識別相互沖突的事務。 可以通過用戶或者沖突判決規則處理出現的沖突。 同步多主服務器復制 在這種方案中，每個服務器都可以接受寫入請求， 修改的數據將在事務被提交之前必須從原始服務器廣播到所有其它服務器。 過多的寫入動作將導致過多的鎖定，從而導致性能低下。 事實上，在多臺服務器上同時寫的性能總是比在單獨一臺服務器上寫的性能低。 讀請求將被均衡的分散到每臺單獨的服務器。 某些實現使用共享磁盤來減少通信開銷。 同步多主服務器復制方案最適合于讀取遠多于寫入的場合。 它的優勢是每臺服務器都能接受寫請求—因此不需要在主從服務器之間劃分工作負荷。 因為在服務器之間發送的是數據的變化， 所以不會對非確定性函數(比如`random()`)造成不良影響。 PostgreSQL不提供這種類型的復制。 但是PostgreSQL的兩階段提交([PREPARE TRANSACTION](#calibre_link-903)和 [COMMIT PREPARED](#calibre_link-901)) 可以用于在應用層或中間件代碼中實現這個功能。 商業解決方案 因為PostgreSQL是開放源代碼并且很容易被擴展， 許多公司在PostgreSQL的基礎上創建了商業的閉源解決方案， 提供獨特的失效切換、復制、負載均衡功能。 [Table 25-1](#calibre_link-1655)總結了以上所列的各種解決方案的能力。 **Table 25-1\. High Availability, Load Balancing, and Replication Feature Matrix** | 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工具集實現。