帶有 PgPool 的 Postgres 的同步與異步流復制

Question

在閱讀了 PgPool 的文檔后，我對哪個選項最適合我的用例感到困惑。 我需要一個主數據庫實例來提供查詢和 1 個或多個主數據庫的副本（備用），用於災難恢復場景。 對我來說非常重要的是，所有成功提交到主節點的事務都保證最終被復制到副本，這樣當發生故障轉移時，副本數據庫實例會擁有所有事務，包括應用到它的最新事務。

在異步復制方面，我在 PgPool 文檔中沒有看到任何提及是否是這種情況，但是，它確實提到了一些潛在的數據丟失發生，這對我來說有點太模糊，無法得出任何結論。

為了防止這種數據丟失，文檔建議使用同步流復制，在主節點提交事務之前，確保所有副本也應用了該更改。 因此，這種方法比異步方法慢，但如果沒有數據丟失，它可能是可行的。

同步復制是允許我實現用例的唯一方法還是異步復制也能解決問題？ 另外，異步復制中潛在的數據丟失是什么？

Answer 1

異步復制意味着主服務器在向客戶端報告成功的COMMIT之前不會等待備用服務器。 因此，如果主服務器出現故障，客戶端可能認為某個事務已提交，但沒有一個備用服務器尚未收到 WAL 信息。 在高可用性設置中，在主服務器丟失的情況下升級備用服務器，這意味着您可能會丟失已提交的事務，盡管信息到達備用服務器通常只需要一瞬間。

使用同步復制，主服務器會等待，直到第一個可用的同步備用服務器報告它已收到並持久化 WAL 信息，然后才向客戶端報告成功的COMMIT （詳細信息，例如選擇了哪個備用服務器，其中有多少個必須返回報告，以及何時可以配置備用服務器接收到的 WAL 計數）。 因此，即使主服務器永久消失，已報告給客戶端的事務也不會丟失。

雖然配置同步復制在技術上很簡單，但它帶來了架構和設計問題，因此異步復制通常是更好的選擇：

• 同步復制大大減慢了所有數據修改的速度。 為了合理地工作，主服務器和備用服務器之間的網絡延遲必須非常低。 您通常無法合理地在不同數據中心之間使用同步復制。

• 同步復制降低了整個系統的可用性，因為備用服務器的故障會阻止任何數據修改成功。 因此，您需要至少有兩台同步備用服務器，一台保持同步，另一台作為備用服務器。

• 即使使用同步復制，也不能保證在寫入主數據庫后從備用數據庫讀取數據會給你新的數據，因為默認情況下，主數據庫不會等待 WAL 在備用數據庫上重放。 如果需要，您需要在主服務器上設置synchronous_commit = remote_apply 。 但是由於備用數據庫上的查詢可能與 WAL 重放沖突，您將不得不處理復制（和提交）延遲或取消備用數據庫上的查詢。 因此，只有當您可以處理在備用數據庫上不立即可見的數據修改時，才可以合理地使用同步復制作為水平擴展的工具。