PostgreSQL的高可用与数据复制方案
2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>
PostgreSQL是開(kāi)源的，有多種高可用與數(shù)據(jù)復(fù)制方案，這里做個(gè)簡(jiǎn)單的比較。
一、高可用性、負(fù)載均衡、復(fù)制方案
共享磁盤(pán)失效切換
????共享磁盤(pán)失效切換通過(guò)僅保存一份數(shù)據(jù)庫(kù)副本來(lái)避免花在同步上的開(kāi)銷(xiāo)。 這個(gè)方案讓多臺(tái)服務(wù)器共享使用一個(gè)單獨(dú)的磁盤(pán)陣列。 如果主服務(wù)器失效，備份服務(wù)器將立即掛載該數(shù)據(jù)庫(kù)， 就像是從一次崩潰中恢復(fù)一樣。這個(gè)方案允許快速的失效切換并且不會(huì)丟失數(shù)據(jù)。
????共享硬件的功能通常由網(wǎng)絡(luò)存儲(chǔ)設(shè)備提供， 也可以使用完全符合POSIX行為的網(wǎng)絡(luò)文件系統(tǒng)(參閱Section 17.2.1)。 這種方案的局限性在于如果共享的磁盤(pán)陣列損壞了， 那么整個(gè)系統(tǒng)將會(huì)癱瘓。 另一個(gè)局限是備份服務(wù)器在主服務(wù)器正常運(yùn)行的時(shí)候不能訪問(wèn)共享的存儲(chǔ)器。
文件系統(tǒng)復(fù)制（塊設(shè)備）
????一種改進(jìn)的方案是文件系統(tǒng)復(fù)制：對(duì)文件系統(tǒng)的任何更改都將鏡像到備份服務(wù)器上。 這個(gè)方案的唯一局限是必須確保備份服務(wù)器的鏡像與主服務(wù)器完全一致— 特別是寫(xiě)入順序必須完全相同。DRBD是Linux上的一種流行的文件系統(tǒng)復(fù)制方案。
事務(wù)日志傳送
????熱備份服務(wù)器可以通過(guò)讀取WAL記錄流來(lái)保持?jǐn)?shù)據(jù)庫(kù)的當(dāng)前狀態(tài)。 如果主服務(wù)器失效，那么熱備份服務(wù)器將包含幾乎所有主服務(wù)器的數(shù)據(jù)， 并可以迅速的將自己切換為主服務(wù)器。這是一個(gè)異步方案， 并且只能在整個(gè)數(shù)據(jù)庫(kù)服務(wù)器上實(shí)施。
????使用基于文件的日志傳送或流復(fù)制，或兩者相結(jié)合。 前者參閱Section 25.2, 后者參閱Section 25.2.5。 請(qǐng)參閱Section 25.5獲取關(guān)于熱備的信息。
基于觸發(fā)器的主備復(fù)制
????這個(gè)方案將所有修改數(shù)據(jù)的請(qǐng)求發(fā)送到主服務(wù)器。 主服務(wù)器異步向從服務(wù)器發(fā)送數(shù)據(jù)的更改信息。 從服務(wù)器在主服務(wù)器運(yùn)行的情況下只應(yīng)答讀請(qǐng)求。對(duì)于數(shù)據(jù)倉(cāng)庫(kù)的請(qǐng)求來(lái)說(shuō)， 從服務(wù)器非常理想的。
????Slony-I是這個(gè)方案的一個(gè)例子，它支持針對(duì)每個(gè)表的粒度并支持多個(gè)從服務(wù)器。 因?yàn)樗惒健⑴康母聫姆?wù)器， 在失效切換的時(shí)候可能會(huì)有數(shù)據(jù)丟失。
基于語(yǔ)句的復(fù)制中間件
????可以使用一個(gè)基于語(yǔ)句的復(fù)制中間件程序截取每一個(gè)SQL查詢， 并將其發(fā)送到某一個(gè)或者全部服務(wù)器。每一個(gè)服務(wù)器都獨(dú)立運(yùn)行。 讀-寫(xiě)請(qǐng)求發(fā)送給所有服務(wù)器，所以每個(gè)服務(wù)器接收到任何變化。但是只 讀請(qǐng)求則僅發(fā)送給某一個(gè)服務(wù)器，從而實(shí)現(xiàn)讀取的負(fù)載均衡。
????如果只是簡(jiǎn)單的廣播修改數(shù)據(jù)的SQL語(yǔ)句， 那么類(lèi)似random(),?CURRENT_TIMESTAMP?以及序列函數(shù)在不同的服務(wù)器上將生成不同的結(jié)果。 這是因?yàn)槊總€(gè)服務(wù)器都獨(dú)立運(yùn)行并且廣播的是SQL語(yǔ)句而不是如何對(duì)行進(jìn)行修改。 如果這種結(jié)果是不可接受的，那么中間件或者應(yīng)用程序必須保證始終從同 一個(gè)服務(wù)器讀取這些值并將其應(yīng)用到寫(xiě)入請(qǐng)求中。 另外還必須保證每一個(gè)事務(wù)必須在所有服務(wù)器上全部提交成功或者全部回滾， 或者使用兩階段提交(PREPARE TRANSACTION?和COMMIT PREPARED)。?Pgpool-II和Continuent Tungsten是這種方案的實(shí)例。
異步多主服務(wù)器復(fù)制
????對(duì)于那些不規(guī)則連接的服務(wù)器(比如筆記本電腦或遠(yuǎn)程服務(wù)器)， 要在它們之間保持?jǐn)?shù)據(jù)一致是很麻煩的。 在這個(gè)方案中，每臺(tái)服務(wù)器都獨(dú)立工作并周期性的與其他服務(wù)器通信以識(shí)別相互沖突的事務(wù)。 可以通過(guò)用戶或者沖突判決規(guī)則處理出現(xiàn)的沖突。
同步多主服務(wù)器復(fù)制
????在這種方案中，每個(gè)服務(wù)器都可以接受寫(xiě)入請(qǐng)求， 修改的數(shù)據(jù)將在事務(wù)被提交之前必須從原始服務(wù)器廣播到所有其它服務(wù)器。 過(guò)多的寫(xiě)入動(dòng)作將導(dǎo)致過(guò)多的鎖定，從而導(dǎo)致性能低下。 事實(shí)上，在多臺(tái)服務(wù)器上同時(shí)寫(xiě)的性能總是比在單獨(dú)一臺(tái)服務(wù)器上寫(xiě)的性能低。 讀請(qǐng)求將被均衡的分散到每臺(tái)單獨(dú)的服務(wù)器。 某些實(shí)現(xiàn)使用共享磁盤(pán)來(lái)減少通信開(kāi)銷(xiāo)。 同步多主服務(wù)器復(fù)制方案最適合于讀取遠(yuǎn)多于寫(xiě)入的場(chǎng)合。 它的優(yōu)勢(shì)是每臺(tái)服務(wù)器都能接受寫(xiě)請(qǐng)求—因此不需要在主從服務(wù)器之間劃分工作負(fù)荷。 因?yàn)樵诜?wù)器之間發(fā)送的是數(shù)據(jù)的變化， 所以不會(huì)對(duì)非確定性函數(shù)(比如random())造成不良影響。
????PostgreSQL不提供這種類(lèi)型的復(fù)制。 但是PostgreSQL的兩階段提交(PREPARE TRANSACTION和?COMMIT PREPARED) 可以用于在應(yīng)用層或中間件代碼中實(shí)現(xiàn)這個(gè)功能。
商業(yè)解決方案
????因?yàn)镻ostgreSQL是開(kāi)放源代碼并且很容易被擴(kuò)展， 許多公司在PostgreSQL的基礎(chǔ)上創(chuàng)建了商業(yè)的閉源解決方案， 提供獨(dú)特的失效切換、復(fù)制、負(fù)載均衡功能。
| 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 | • | • | • | • | ? | ? | • |
有幾個(gè)解決方案不適合上邊這些分類(lèi)：
數(shù)據(jù)分區(qū)
????數(shù)據(jù)分區(qū)將表拆分為數(shù)據(jù)集。每個(gè)數(shù)據(jù)集只有一臺(tái)服務(wù)器可以修改。 例如，數(shù)據(jù)可以按辦事處進(jìn)行分區(qū)，例如， 倫敦和巴黎，每個(gè)辦公室用一個(gè)服務(wù)器。 如果查詢需要倫敦和巴黎相結(jié)合的數(shù)據(jù)，應(yīng)用程序可以查詢兩臺(tái)服務(wù)器， 或主/備用復(fù)制可以用來(lái)保持每個(gè)服務(wù)器上有其他辦公室的只讀數(shù)據(jù)副本。
多服務(wù)器并行查詢執(zhí)行
????許多上述解決方案允許多個(gè)服務(wù)器來(lái)處理多個(gè)查詢， 但不是允許單個(gè)查詢使用多個(gè)服務(wù)器來(lái)更快完成。 此解決方案允許多個(gè)服務(wù)器上單個(gè)查詢同時(shí)運(yùn)行。 它通常被通過(guò)服務(wù)器之間的數(shù)據(jù)分開(kāi)而執(zhí)行其查詢的一部分， 并將結(jié)果返回到中央服務(wù)器，由它來(lái)聯(lián)合結(jié)果并返回給用戶。?Pgpool-II有這種能力。 也可以使用PL/Proxy工具集實(shí)現(xiàn)。
二、多節(jié)點(diǎn)集群方案比較
可以基于Replication Stream（流復(fù)制）。
| BSD | Stalled暫停 | Master-Master | Synchronous | No | Yes | No |
| BSD | Stable | Statement-Based Middleware | Synchronous | Yes | Yes | No |
| BSD | Recent release | Statement-Based Middleware | Synchronous | Yes | Yes | Yes |
| BSD | Stable | Master-Slave | Asynchronous | No | No | No |
| BSD | Stable | Master-Master, Master-Slave | Asynchronous | No | No | No |
| BSD | Stable | Master-Slave | Asynchronous | No | No | No |
| BSD | Stalled | Master-Slave | Asynchronous | No | No | No |
| MIT | Stalled | Master-Master, Master-Slave | Asynchronous | No | No | No |
| PostgreSQL (BSD) | Beta | Master-Master (no triggers needed) | Asynchronous | No | No | No |
| LGPL | Recent release | Statement-based Middleware (as an extension) | Synchronous | No | Yes | Yes |
- 本文來(lái)自于：https://my.oschina.net/liuyuanyuangogo/blog/497746
- 參考：
- 9.3官方文檔（中文）：http://58.58.27.50:8079/doc/html/9.3.1_zh/high-availability.html
- 復(fù)制、集群和連接池：?https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling
- 集群方案功能列表：?http://blog.osdba.net/46.html
轉(zhuǎn)載于:https://my.oschina.net/u/2306127/blog/2994090
總結(jié)
以上是生活随笔為你收集整理的PostgreSQL的高可用与数据复制方案的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： Java Scala 混合编程导致 编译
- 下一篇： HTML5与HTML4的区别（译文）