七八年前，老馮手里維護(hù)著一百套大規(guī)模 PostgreSQL 集群，兩百多臺頂配物理機(jī)，開始做高可用方案選型。 那段時間我把市面上能叫得出名字的方案都翻了一遍：Patroni、Corosync + Pacemaker、repmgr、Stolon、pgpool-II……

最后選了 Patroni?；谒?HA，上線后效果很穩(wěn)：這些年碰到幾十次真實(shí)硬件故障，RTO 基本都在二三十秒?yún)^(qū)間。 最爽的是：。

回頭看，這個選擇屬于 “少走七年彎路”。今天無論你看傳統(tǒng) Linux 發(fā)行版方案（Percona、AutoBase 等）， 還是 K8S Operator（Crunchy PGO 等），主流 PG 發(fā)行版高可用幾乎都繞不開 Patroni。 Patroni 在 GitHub 上的 Star (8.1K) 也超過其他這些 HA 組件的總和。

那么，為什么是 Patroni 成為了事實(shí)標(biāo)準(zhǔn)？它到底好在哪里？ PostgreSQL 高可用到底應(yīng)該怎么做？今天我們就來聊聊這個話題。

可用性，RTO與RPO

可用性 （Availability）是一個服務(wù)指標(biāo)，一般用 “服務(wù)可用時間/總時間窗口” 的百分比來計算，時間窗口一般是整年或者整月。 通常 99.99% 以上的可用性（4個9）被稱作高可用 —— 意味著年度故障預(yù)算 52 分鐘，或月度故障預(yù)算 4.3 分鐘。

但可用性是業(yè)務(wù)連續(xù)性指標(biāo)，不是數(shù)據(jù)庫的 技術(shù)能力。一個經(jīng)典誤區(qū)是：你完全可以單憑運(yùn)氣做到 100% 的可用性，這很常見。 云廠商承諾幾個9的SLA，本質(zhì)上也不是歷史戰(zhàn)績，而是代金券對賭協(xié)議。

真正重要的是，發(fā)生故障的頻率與恢復(fù)時間。對于數(shù)據(jù)庫來說，你控制不了故障發(fā)生的頻率（MTBF）； 但你能控制的是：發(fā)生故障后最多丟多少數(shù)據(jù)，以及要多長時間恢復(fù)。這就是兩個核心可靠性指標(biāo) —— RPO 與 RTO：

RPO（Recovery Point Objective，恢復(fù)點(diǎn)目標(biāo)） : 定義了在主庫發(fā)生故障時，允許丟失的最大數(shù)據(jù)量。

RTO（Recovery Time Objective，恢復(fù)時間目標(biāo)） : 定義了在主庫發(fā)生故障時，系統(tǒng)恢復(fù)寫入能力所需的最長時間。

RTO 和 RPO 代表了真正 抗事的能力，也是我們考察高可用方案的關(guān)鍵所在。

那么 RPO / RTO 要多好才算好？這里有幾個相關(guān)的國際/國家標(biāo)準(zhǔn)，規(guī)定了各個行業(yè)要求的 RPO / RTO 水平。 比如 SHARE-78，GB/T 20988-2025，SOX / HIPPA / Basel III 都對 RTO/RPO 提出了合規(guī)要求。 于今年元旦開始實(shí)行的國內(nèi)的 《網(wǎng)絡(luò)安全技術(shù) 信息系統(tǒng)災(zāi)難恢復(fù)規(guī)范》將災(zāi)難恢復(fù)劃分為六個等級：

最高等級的容災(zāi)要求，通常要求 RTO 在分鐘級（幾十秒的量級），RPO = 0 不丟失數(shù)據(jù)。 十幾年前，你可能要花幾百萬上千萬采購專有軟硬件來滿足這樣的要求。 而在 2026 年的當(dāng)下，有了 Patroni + PostgreSQL，實(shí)現(xiàn)這種容災(zāi)水平的軟件成本已經(jīng)無限接近于零。

但顯然，因?yàn)樾畔⒉粚ΨQ，很多人并不知道這件事。所以今天我就來給大家講講 PostgreSQL 高可用的 SOTA 事實(shí)標(biāo)準(zhǔn) —— Patroni。

太長不看

Patroni 在合理配置的情況下，可以輕松做到 RTO < 30s，RPO = 0 的水平，這是經(jīng)過理論推演與實(shí)戰(zhàn)檢驗(yàn)的結(jié)果。 在 RPO 上，Patroni 可以實(shí)現(xiàn) Oracle 最大性能/最大可用/最大保護(hù)模式，甚至提供了比 Oracle 最大保護(hù)模式更強(qiáng)的數(shù)據(jù)一致性選項(xiàng)。 在 RTO 上，Patroni 可以在常規(guī)硬件上實(shí)現(xiàn)端到端 RTO < 30s 的水平，包含從故障檢測，主從切換，到負(fù)載均衡器健康檢查的全鏈路耗時。 接下來，我們將詳細(xì)介紹高可用中 RPO 與 RTO 的利弊權(quán)衡。

RPO 利弊權(quán)衡

RPO 定義了主庫故障時允許丟失的最大數(shù)據(jù)量。對于金融交易這類數(shù)據(jù)完整性至關(guān)重要的場景，通常要求 RPO = 0，即不允許任何數(shù)據(jù)丟失。

然而更嚴(yán)格的 RPO 指標(biāo)是有代價的：它會引入更高的寫入延遲，降低系統(tǒng)吞吐量，并且存在從庫故障導(dǎo)致主庫不可用的風(fēng)險。 因此對于常規(guī)場景，通常可以接受一定量的數(shù)據(jù)丟失（例如不超過 1MB），以換取更高的可用性與性能。

在異步復(fù)制場景下，從庫和主庫之間會存在一定的復(fù)制延遲（取決于網(wǎng)絡(luò)和吞吐量，正常在 10KB～100KB / 100μs～10ms 的數(shù)量級）。 這意味著主庫故障時，從庫可能還沒有完全同步最新數(shù)據(jù)。此時如果發(fā)生故障切換，新主庫可能會丟失一些尚未復(fù)制的數(shù)據(jù)。

實(shí)現(xiàn)原理

Patroni 提供了一個參數(shù) maximum_lag_on_failover，用于控制潛在數(shù)據(jù)丟失量的上限，默認(rèn)為 1048576 （1MB）。 這意味著自動故障轉(zhuǎn)移時，最多可以容忍 1MB 的數(shù)據(jù)丟失。當(dāng)主庫宕機(jī)時，如果有任何一個從庫的復(fù)制延遲在這個值以內(nèi)，Patroni 將自動提升該從庫為新主庫。

然而當(dāng)所有從庫的復(fù)制延遲都超出這個閾值時，Patroni 將拒絕進(jìn)行自動故障切換以避免數(shù)據(jù)丟失。 此時需要人工介入決策：等待主庫恢復(fù)（可能永遠(yuǎn)不會恢復(fù)），還是接受數(shù)據(jù)損失并強(qiáng)制提升一個從庫。

這就引入了第一項(xiàng)利弊權(quán)衡：你需要根據(jù)業(yè)務(wù)需求配置這個值，在 可用性 和 一致性 之間進(jìn)行 利弊權(quán)衡。 增大這個值可以提高自動故障切換的成功率（降低不可用時長），但也會增加潛在的數(shù)據(jù)丟失量上限。

在不允許任何數(shù)據(jù)丟失的場景下，你可以使用 Patroni 的同步模式與嚴(yán)格同步模式，來確保 RPO = 0。

Oracle 類比

對于熟悉 Oracle 的用戶來說，Patroni 的復(fù)制模式可以類比 Oracle Data Guard 提供的三種數(shù)據(jù)保護(hù)模式：最大性能、最大可用、最大保護(hù)。

實(shí)際上，通過配置 Patroni 和 PostgreSQL，你甚至可以實(shí)現(xiàn)比 Oracle 最大保護(hù)模式更強(qiáng)的數(shù)據(jù)一致性選項(xiàng)。 例如 Oracle Data Guard 的最大保護(hù)模式只要求一個同步從庫確認(rèn)寫入，而 Patroni 可以配置多個同步從庫確認(rèn)寫入， 甚至確認(rèn)重放完成（remote_apply），來進(jìn)一步提高數(shù)據(jù)持久性與一致性。

JEPSEN 提供了一個非常罕見的例子，我們會有一篇專門的文章詳細(xì)介紹。

對于絕大多數(shù)業(yè)務(wù)來說，異步復(fù)制（最大性能）模式提供的 RPO 保證已經(jīng)足夠。 對于對數(shù)據(jù)完整性要求極高的場景，可以使用最大可用 / 最大保護(hù)模式來確保 RPO = 0。

RTO 利弊權(quán)衡

RTO 定義了主庫故障時，系統(tǒng)恢復(fù)寫入能力所需的最長時間。

當(dāng)主庫故障時，整個恢復(fù)流程涉及多個階段：檢測故障、DCS 鎖過期、新主選舉、執(zhí)行 promote、負(fù)載均衡器感知新主庫。因此不同于 RPO，RTO 不可能等于零。

而且需要注意，RTO 并非越小越好。更短的 RTO 意味著縮短各階段的超時時間，這會使集群對網(wǎng)絡(luò)抖動更加敏感，從而增加誤切風(fēng)險。 RTO 設(shè)置的太小，切換耗時雖然變短，但是誤切概率上升了，切換頻率增加，整體可用性反而下降了。

這就引出了第二項(xiàng)利弊權(quán)衡，你需要根據(jù)實(shí)際網(wǎng)絡(luò)條件選擇合適的配置，在 恢復(fù)耗時 與 誤切概率 之間取得平衡： 網(wǎng)絡(luò)質(zhì)量越差，越應(yīng)該選擇保守的配置；網(wǎng)絡(luò)質(zhì)量越好，越可以選擇激進(jìn)的配置。

關(guān)于 RTO 的營銷話術(shù)

因?yàn)?RPO 這個指標(biāo)沒什么好吹的，RTO 已經(jīng)淪為數(shù)據(jù)庫營銷吹牛的重災(zāi)區(qū)。有時候是拿特例場景樂觀路徑來以點(diǎn)蓋面，或者在驅(qū)動 / 連接池層面排隊(duì)并用統(tǒng)計口徑做文章。因此討論 RTO 的時候，需要明確幾個因素：

故障域 :是計算節(jié)點(diǎn)故障，還是存儲故障、網(wǎng)絡(luò)故障？

測量口徑 :可用標(biāo)準(zhǔn)是數(shù)據(jù)庫可寫入，還是 LB，APP，連接池/驅(qū)動層可用？

統(tǒng)計量 :使用的是最優(yōu)值、最差值，還是平均值與中位數(shù)？

網(wǎng)絡(luò)條件 :是同機(jī)柜、同機(jī)房、同城，還是跨大洲的全球復(fù)制？

通常來說，在同機(jī)柜網(wǎng)絡(luò)條件中，常見故障路徑下，RTO < 30s 算是業(yè)界頂級水平。 如果有人不帶場景、故障域、統(tǒng)計口徑說自己 RTO < 10 秒，通?？梢耘卸榇蹬?。

嚴(yán)肅的 RTO 的討論非常復(fù)雜，在下面，我們會討論四種典型網(wǎng)絡(luò)條件下的參數(shù)配置，兩種主要故障路徑下的 RTO 拆解，以及最優(yōu)，平均，最劣三種情況； 并使用更為嚴(yán)格的 HAPRXOY 端側(cè)接受連接寫入作為 RTO 的測量口徑，如果沒有特別解釋，我們討論的是用于兜底的 最劣 情況，而非平均或最優(yōu)情況。

架構(gòu)原理

RTO 無法脫離架構(gòu)，場景，環(huán)境，資源來討論，因此我們需要先來介紹一下基于 Patroni / Etcd / HAProxy 的經(jīng)典高可用架構(gòu)，在這個架構(gòu)中：

?PostgreSQL 使?標(biāo)準(zhǔn)流復(fù)制搭建物理從庫，主庫故障時由從庫接管。?Patroni 負(fù)責(zé)管理 PostgreSQL 服務(wù)器進(jìn)程，處理高可用相關(guān)事宜。?Etcd 提供分布式配置存儲（DCS）能力，并用于故障后的領(lǐng)導(dǎo)者選舉?Patroni 依賴 Etcd 達(dá)成集群領(lǐng)導(dǎo)者共識，并對外提供健康檢查接口。?HAProxy 對外暴露集群服務(wù)，并利? Patroni 健康檢查接口，自動分發(fā)流量至健康節(jié)點(diǎn)。

在這套架構(gòu)中，高可用 RTO 主要取決于 Patroni 參數(shù)，次要取決于 Haproxy 參數(shù)。

參數(shù)配置

Patroni 中關(guān)于 RPO 的核心參數(shù)只有三個，但考慮 RTO 時，總共要納入的參數(shù)有 10 個： Patroni 5 個，HAProxy 健康檢查 5 個。這十個參數(shù)的組合決定了 RTO 的表現(xiàn)。

請注意，默認(rèn)參數(shù)的表現(xiàn)并不是最優(yōu)的。我在長期實(shí)踐中提出了四組不同網(wǎng)絡(luò)條件下的參數(shù)優(yōu)化配置：fast、normal、slow、safe。

四種模式實(shí)際上對應(yīng)著四組不同的參數(shù)配置，如下所示：

這四種模式下，RTO 的最壞，最好，平均表現(xiàn)水平如下圖所示。

我們以最壞口徑作為討論的基準(zhǔn)， 在默認(rèn)配置下 RTO < 45s，最優(yōu)模式下 RTO < 30s。 更寬容的模式則設(shè)置有 90s / 150s 的 RTO 上線目標(biāo)。

這里特別需要提到的是，市面上絕大多熟 PG 高可用方案幾乎都沒有修改 Patroni 默認(rèn)參數(shù)， 盡管默認(rèn)參數(shù)在常規(guī)被動故障切換中提供 RTO < 45 秒的表現(xiàn)，但默認(rèn) primary_start_timeout 的 300 秒配置， 會導(dǎo)致 PG 主庫崩潰重新拉起這個故障場景中，最劣表現(xiàn)高達(dá) 324 秒，違背常規(guī)的 RTO 目標(biāo)。

如果你自己手搓 Patroni 高可用，這一點(diǎn)務(wù)必注意。

故障路徑

那么這個圖里的數(shù)據(jù)是怎么計算得到的呢？這里我們就要討論 故障路徑 了。

在 Patroni 這套高可用架構(gòu)中，有 10 種典型故障：節(jié)點(diǎn)宕機(jī) / 假活、PG 崩潰 / 拒絕連接 / 假活、Patroni 崩潰 / 假活、主庫 / DCS 網(wǎng)絡(luò)中斷、存儲故障等等。 這些故障總體可以劃分為五條 RTO 拆解路徑，在討論最壞情況時，歸并到兩條典型的故障路徑：

被動檢測 : Patroni 掛了或者網(wǎng)絡(luò)隔離，主庫無法續(xù)租，觸發(fā)集群選舉

主動檢測 : Patroni 活著，嘗試修復(fù) PG 掛了這種問題，超時后觸發(fā)集群選舉

這兩種故障路徑殊途同歸，可以用下面的流程圖表示：

這兩條故障路徑的 RTO 計算方式有差異，下面會簡要介紹，詳細(xì)完整的分析報告請參閱下面的文檔： http://pigsty.cc/docs/concept/ha/failure/[1]

這里的 RTO 時序拆解，給出了 RTO 的下界和上界。 我們在設(shè)定的時候，以上界最悲觀的情況設(shè)置，確保滿足最嚴(yán)格的容災(zāi)等級要求。

考慮 平均 情況的話 fast 檔位在 23-24 秒，默認(rèn) norm 檔位在 34-35 秒的水平。

關(guān)于 RAC 與分布式數(shù)據(jù)庫

有些數(shù)據(jù)庫承諾非常低的 RTO，甚至號稱秒級切換、RTO = 0。這些方案通常使用共享存儲 RAC 架構(gòu)，或者分布式 Raft/Paxos 協(xié)議。 但仔細(xì)推敲就會發(fā)現(xiàn)，這些聲稱往往只針對特定故障域成立，而且會因?yàn)榧軜?gòu)上的利弊權(quán)衡引入其他局限性。

以 Oracle RAC 為例，多個計算節(jié)點(diǎn)訪問同一個底層磁盤陣列。在實(shí)例故障時確實(shí)可以快速切換，但當(dāng)?shù)讓哟鎯Τ霈F(xiàn)單點(diǎn)故障時，RTO 就直接炸了 —— 所有節(jié)點(diǎn)一起完蛋。 這本質(zhì)上是把復(fù)雜度和風(fēng)險下推到存儲層，逼著你購買價格高昂的企業(yè)級 SAN 存儲來兜底。 而且真要做跨區(qū)域容災(zāi)，還是得靠 Data Guard 這類主從復(fù)制技術(shù)。然后 RTO 又回到幾十秒的量級了。 所以 Oracle RAC 的營銷宣傳在我看來極具誤導(dǎo)性。

一些 NewSQL 分布式數(shù)據(jù)庫稍微誠實(shí)一點(diǎn)。比如 CockroachDB 用 Raft 協(xié)議管理多節(jié)點(diǎn)集群，在主要故障場景下號稱 RPO = 0、RTO < 9s。 這個數(shù)字是可信的，但代價是什么？翻了幾倍的寫入延遲，幾分之一的性能吞吐，以及更高的架構(gòu)/運(yùn)維復(fù)雜度。 關(guān)于這一點(diǎn)，老馮在《》中詳細(xì)探討過（還有《DDIA 第六章：復(fù)制》）。 說到底一切都是利弊權(quán)衡，只要你不在乎代價，AWS 開源的 pgactive PG 擴(kuò)展號稱能把 RTO 做到亞秒級。

相比之下，無共享架構(gòu)（Shared Nothing）的思路就清爽得多：顯式管理多套存儲副本，每個節(jié)點(diǎn)都是自治的，沒有存儲單點(diǎn)。 共享存儲方案很難水平擴(kuò)展，而無共享架構(gòu)可以輕松拉出幾十個從庫 —— OpenAI 1 主 40 從 ，我們在探探1主32從的 PG 集群就是這么玩的。 這也是為什么過去二十年，無共享架構(gòu)逐漸成為數(shù)據(jù)庫高可用的主流選擇。

老馮自己的看法是，這年頭鼓吹共享存儲高可用方案，有大概率是為了給硬件/云盤帶貨。 老馮對這種事向來不感冒，本文就進(jìn)一步具體展開批判了。但后面也許會專門寫一篇，聊聊 RAC 與分布式數(shù)據(jù)庫的真實(shí)表現(xiàn)與實(shí)際代價， 順便講講 Corosync + Pacemaker 這種極其繁瑣的老古董 PG 高可用方案為什么該進(jìn)博物館了。

關(guān)于實(shí)操

聊完原理，說說落地。我知道很多人看到這里會想：道理我都懂，但讓我自己一臺一臺去配 Etcd、Patroni、HAProxy，俺做不到啊。

放心，老馮自己也不會干這種傻事。

我把這套 PG 高可用方案做成了開源免費(fèi)、一鍵部署的完整解決方案：Pigsty。

你也可以用別的 —— AutoBase，Percona，各種 K8S PG Operator 也大同小異。 反正高可用部分的核心架構(gòu)基本都是一樣的 Patroni + etcd + Haproxy。

不過，很多用著 patroni 的方案幾乎都清一色用著默認(rèn)參數(shù)。 看起來沒人認(rèn)真優(yōu)化過，也沒人做過精細(xì)的 RTO 時序分析，也許是放到“企業(yè)級”方案里去了吧。 而 Pigsty 在大規(guī)模生產(chǎn)環(huán)境中實(shí)戰(zhàn)打磨出來，針對不同網(wǎng)絡(luò)條件提供了多種 RTO/RPO 策略可選， 除此之外，還內(nèi)置了連接池、自動故障切換、完整的監(jiān)控告警體系 —— 開箱即用不操心。

另外提醒一句：光有高可用還不夠。硬件故障 Patroni 能扛，但誤刪數(shù)據(jù)、邏輯錯誤這類場景，還得靠 PITR 來兜底。 所以今天講的是 PostgreSQL 高可用的事實(shí)標(biāo)準(zhǔn)——Patroni，后面還會介紹備份恢復(fù)的事實(shí)標(biāo)準(zhǔn) —— pgBackRest。

朋友們，別折騰手搓 PG 高可用了！土法自建對技術(shù)成長和業(yè)務(wù)發(fā)展都沒啥幫助 —— 把原理搞明白會用就行。 與其重復(fù)造輪子，不如折騰折騰怎么用好 PG 本身，這里能玩的擴(kuò)展太多了，可比折騰什么 HA PITR 有意思多了。

小結(jié)

通過精細(xì)的參數(shù)調(diào)優(yōu)，Patroni 的 RTO 上界可以被精確控制在不同檔位。 在常規(guī)網(wǎng)絡(luò)環(huán)境下，30 秒的 RTO 水平觸手可及。 這些年我在生產(chǎn)環(huán)境中經(jīng)歷的幾十次真實(shí)故障切換，監(jiān)控數(shù)據(jù)顯示 RTO 穩(wěn)定在 20～30 秒，完全滿足最嚴(yán)苛的金融級容災(zāi)要求。

七年前做這個選型時，Patroni 還是個小眾方案。當(dāng)時不少人覺得它不夠"企業(yè)級"，不如商業(yè)方案有保障。 現(xiàn)在再看，那些迷信復(fù)雜架構(gòu)和昂貴軟件的團(tuán)隊(duì)，要么還在為高可用焦頭爛額，要么早就悄悄換成了 Patroni。

技術(shù)選型這件事，從來不是看誰更復(fù)雜、誰更貴，而是看誰能真正把問題解決掉。 Patroni 用最簡潔的架構(gòu)實(shí)現(xiàn)了最可靠的效果，這就是它成為事實(shí)標(biāo)準(zhǔn)的原因。