?
Dieses Dokument verwendet PHP-Handbuch für chinesische Websites Freigeben
共享磁盤失效切換通過僅保存一份數(shù)據(jù)庫副本來避免花在同步上的開銷。 這個方案讓多臺服務(wù)器共享使用一個單獨(dú)的磁盤陣列。 如果主服務(wù)器失效,備份服務(wù)器將立即掛載該數(shù)據(jù)庫,就像是從一次崩潰中恢復(fù)一樣。這 個方案允許快速的失效切換并且不會丟失數(shù)據(jù)。
共享硬件的功能通常由網(wǎng)絡(luò)存儲設(shè)備提供,也可以使用完全符合POSIX行為的網(wǎng)絡(luò)文件系統(tǒng)(NFS)。 這種方案的局限性在于如果共享的磁盤陣列損壞了,那么整個系統(tǒng)將會癱瘓。 另一個局限是備份服務(wù)器在主服務(wù)器正常運(yùn)行的時候不能訪問共享的存儲器。
一種改進(jìn)的方案是文件系統(tǒng)復(fù)制:對文件系統(tǒng)的任何更改都將鏡像到備份服務(wù)器上。 這個方案的唯一局限是必須確保備份服務(wù)器的鏡像與主服務(wù)器完全一致,特別是寫入順序必須完全相同。 DRBD是Linux上的一種流行的文件系統(tǒng)復(fù)制方案。
熱備份服務(wù)器可以通過讀取WAL記錄流來保持?jǐn)?shù)據(jù)庫的當(dāng)前狀態(tài)。 如果主服務(wù)器失效,那么熱備份服務(wù)器將包含幾乎所有主服務(wù)器的數(shù)據(jù),并可以迅速的將自己切換為主服務(wù)器。 這是一個異步方案,并且只能在整個數(shù)據(jù)庫服務(wù)器上實(shí)施。
使用基于文件的日志傳送或流復(fù)制,或兩者相結(jié)合實(shí)現(xiàn)PITR備份服務(wù)器。前者參閱Section 25.2, 后者參閱Section 25.2.5。請參閱Section 25.5獲取關(guān)于熱備的信息。
這個方案將所有修改數(shù)據(jù)的請求發(fā)送到主服務(wù)器。主服務(wù)器異步向從服務(wù)器發(fā)送數(shù)據(jù)的更改信息。 從服務(wù)器在主服務(wù)器運(yùn)行的情況下只應(yīng)答讀請求。對于數(shù)據(jù)倉庫的請求來說,從服務(wù)器非常理想的。
Slony-I是這個方案的一個例子,它支持針對每個表的粒度并支持多個從服務(wù)器。 因?yàn)樗惒?、批量的更新從服?wù)器,在失效切換的時候可能會有數(shù)據(jù)丟失。
以使用一個基于語句的復(fù)制中間件程序截取每一個SQL查詢,并將其發(fā)送到某一個或者全部服務(wù)器。 每一個服務(wù)器都獨(dú)立運(yùn)行。 寫請求發(fā)送給所有服務(wù)器,讀請求則僅發(fā)送給某一個服務(wù)器,從而實(shí)現(xiàn)讀取的負(fù)載均衡。
如果只是簡單的廣播修改數(shù)據(jù)的SQL語句,
那么類似random()
,CURRENT_TIMESTAMP
以及序列函數(shù)在不同的服務(wù)器上將生成不同的結(jié)果。
這是因?yàn)槊總€服務(wù)器都獨(dú)立運(yùn)行并且廣播的是SQL語句而不是如何對行進(jìn)行修改。
如果這種結(jié)果是不可接受的,那么中間件或者應(yīng)用程序必須保證始終從同一個服務(wù)器讀取這些值并將其應(yīng)用到寫入請求中。
另外還必須保證每一個事務(wù)必須在所有服務(wù)器上全部提交成功或者全部回滾,
或者使用兩階段提交(PREPARE TRANSACTION
和COMMIT PREPARED)。
Pgpool-II和Sequoia是這種方案的實(shí)例。
對于那些不規(guī)則連接的服務(wù)器(比如筆記本電腦或遠(yuǎn)程服務(wù)器),要在它們之間保持?jǐn)?shù)據(jù)一致是很麻煩的。 在這個方案中,每臺服務(wù)器都獨(dú)立工作并周期性的與其他服務(wù)器通信以識別相互沖突的事務(wù)。 可以通過用戶或者沖突判決規(guī)則處理出現(xiàn)的沖突。
在這種方案中,每個服務(wù)器都可以接受寫入請求,修改的數(shù)據(jù)將在事務(wù)被提交之前必須從原始服務(wù)器廣播到所有其它服務(wù)器。
過多的寫入動作將導(dǎo)致過多的鎖定,從而導(dǎo)致性能低下。
事實(shí)上,在多臺服務(wù)器上同時寫的性能總是比在單獨(dú)一臺服務(wù)器上寫的性能低。
讀請求將被均衡的分散到每臺單獨(dú)的服務(wù)器。
某些實(shí)現(xiàn)使用共享磁盤來減少通信開銷。同步多主服務(wù)器復(fù)制方案最適合于讀取遠(yuǎn)多于寫入的場合。
它的優(yōu)勢是每臺服務(wù)器都能接受寫請求因此不需要在主從服務(wù)器之間劃分工作負(fù)荷。因
為在服務(wù)器之間發(fā)送的是數(shù)據(jù)的變化,所以不會對非確定性函數(shù)(比如random()
)造成不良影響。
PostgreSQL不提供這種類型的復(fù)制。 但是PostgreSQL的兩階段提交(PREPARE TRANSACTION和COMMIT PREPARED)可以用于在應(yīng)用層或中間件代碼中實(shí)現(xiàn)這個功能。
因?yàn)镻ostgreSQL是開放源代碼并且很容易被擴(kuò)展,許多公司在PostgreSQL的基礎(chǔ)上創(chuàng)建了商業(yè)的閉源解決方案, 提供獨(dú)特的失效切換、復(fù)制、負(fù)載均衡功能。
Table 25-1總結(jié)了以上所列的各種解決方案的能力。
Table 25-1. 高可用性,負(fù)載均衡,和復(fù)制功能矩陣
Feature | SharedDiskFailover | FileSystemReplication | Hot/WarmStandbyUsingPITR | Trigger-BasedMaster-StandbyReplication | Statement-BasedReplicationM iddleware | AsynchronousMultimasterReplication | SynchronousMultimasterReplication |
---|---|---|---|---|---|---|---|
MostCommonImplementation | NAS | DRBD | PITR | Slony | pgpool-II | Bucardo | ? |
CommunicationMethod | shareddisk | diskblocks | WAL | tablerows | SQL | tablerows | tablerowsandrowlocks |
Nospecialhardwarerequired | ? | ? | ? | ? | ? | ? | ? |
Allowsmultiplemasterservers | ? | ? | ? | ? | ? | ? | ? |
Nomasterserveroverhead | ? | ? | ? | ? | ? | ? | ? |
Nowaitingformultipleservers | ? | ? | ? | ? | ? | ? | ? |
Masterfailurewillneverlosedata | ? | ? | ? | ? | ? | ? | ? |
Standbyacceptread-onlyqueries | ? | ? | Hotonly | ? | ? | ? | ? |
Per-tablegranularity | ? | ? | ? | ? | ? | ? | ? |
Noconflictresolutionnecessary | ? | ? | ? | ? | ? | ? | ? |
有幾個解決方案不適合上邊這些分類:
數(shù)據(jù)分區(qū)將表拆分為數(shù)據(jù)集。每個數(shù)據(jù)集只有一臺服務(wù)器可以修改。例如,數(shù)據(jù)可以按辦事處進(jìn)行分區(qū),例如,倫敦和巴黎,每個辦公室用一個服務(wù)器。 如果查詢需要倫敦和巴黎相結(jié)合的數(shù)據(jù),應(yīng)用程序可以查詢兩臺服務(wù)器,或主/備用復(fù)制可以用來保持每個服務(wù)器上有其他辦公室的只讀數(shù)據(jù)副本。
許多上述解決方案允許多個服務(wù)器來處理多個查詢,但不是允許單個查詢使用多個服務(wù)器來更快完成。 此解決方案允許多個服務(wù)器上單個查詢同時運(yùn)行。它通常被通過服務(wù)器之間的數(shù)據(jù)分開而執(zhí)行其查詢的一部分, 并將結(jié)果返回到中央服務(wù)器,由它來聯(lián)合結(jié)果并返回給用戶。Pgpool-II有這種能力。 也可以使用PL/Proxy工具集實(shí)現(xiàn)。