# Chapter 25\. 高可用性與負載均衡，復制 **Table of Contents** + 25.1\. 不同解決方案的比較 + 25.2\. 日志傳送備份服務器 + 25.2.1\. 規劃 + 25.2.2\. 備用服務器操作 + 25.2.3\. 為備用服務器準備主服務器 + 25.2.4\. 建立備用服務器 + 25.2.5\. 流復制 + 25.2.6\. Cascading Replication + 25.2.7\. 同步復制 + 25.3\. 失效切換 + 25.4\. 日志傳送的替代方法 + 25.4.1\. 實施 + 25.4.2\. 基于記錄的日志傳送 + 25.5\. 熱備 + 25.5.1\. 用戶概述 + 25.5.2\. 處理查詢沖突 + 25.5.3\. 管理員概述 + 25.5.4\. 熱備參數參考 + 25.5.5\. Caveats 多個數據庫服務器可以協同工作， 比如在主服務器失效的時候備份服務器立即取代它的位置(高可用性)， 或者幾臺機器同時服務于同一個數據庫(負載均衡)。 理想狀態多臺服務器之間可以無縫協作。 為靜態頁面提供服務的Web服務器可以輕松的通過將web請求分攤到多臺機 器從而實現負載均衡。 事實上，只讀數據庫也能輕松的以相同的方法實現負載均衡。 不幸的是，大多數數據庫服務器都需要同時處理混合的讀/寫請求， 將這些數據庫聯合起來工作是件很麻煩的事。 雖然只讀數據只需要在每臺服務器上復制一份即可， 但是在任何一臺服務器上的寫動作都必須傳播到其它所有服務器上， 這樣才能保證將來對這些已修改數據的讀取返回一致的結果。 這個寫同步問題就是導致多臺服務器協同工作麻煩重重的最基本原因。 有多種解決此問題的方法，其思路也各不相同， 但都不是既簡單又高效的方案。 有一種解決方案是僅允許單獨的一臺"主"服務器修改數據， 可以修改數據的服務器稱為只讀/寫，_master_或者_primary_服務器。 跟蹤“主”服務器數據變化的叫_備_ 或者_從_服務器。 備用服務器不能連接到主服務器，直到它晉升為_熱備_服務器。 可以接受連接而且只讀服務器稱為_熱備_服務器。 一些方案是"同步的"， 意思是直到所有服務器都完成了某個修改數據的事務之后， 該事務才被認為是已經完成的。 這將確保失效切換不會丟失任何數據并且所有服務器都將返回一致的結果。 另一些方案是"異步的"，這種方案允許在事務提交之后 與傳播到所有其它服務器之間有一小段延時， 但是在切換到備份服務器的時候某些事務可能會丟失， 并且不同的服務器可能返回不一致的結果。 當同步可能會很慢的時候可以使用異步通信。 還可以按照粒度對解決方案進行分類。 某些方案只能將整個數據庫集群作為一個整體， 而某些方案可以針對每個數據庫或每張表分別做不同的處理。 在選擇任何失效切換或負載均衡方案的時候都必須考慮性能因素。 功能和性能不可兼得，比如，一個完全同步的解決方案在慢速網絡上可能削減性能一半以上， 而完全異步的方案可能僅對性能有極其微小的影響。 下面的部分大致描述了各種常見的失效切換、復制、負載均衡方案。 [glossary](http://www.postgres-r.org/documentation/terms) 也是可用的。