TCP 負載平衡器是 Postgres 9.X 讀取從屬負載平衡器（如 pgPool II 或 pgBouncer）的替代品嗎？
為了擴展 PostgreSQL 流複製從屬上的讀取流量，我希望能夠對請求進行負載平衡。Postgres 文件建議使用 pgPool 和 pgBouncer 等工具，但我想知道在 postgres 讀取從站前面使用 TCP 負載均衡器（如 HAProxy 或 AWS Elastic Load Balancer）是否有問題（原則上）。
負載均衡器用作需要由客戶端發出的讀取請求的單個讀取端點。一個顯著的優勢是當讀取從伺服器關閉時讀取請求不會受到影響，因為負載平衡器中的其他伺服器可以承擔負載。
原則上沒有問題，雖然我自己還沒有使用過。
大多數客戶端應用程序保持長時間的會話 - 因此負載平衡實際上始終是“粘性的”。這很容易導致一個節點的負載比其他節點多得多。一種解決方法可以是故意限制連接持續時間，強制應用偶爾重新連接，並可能被分配一個不同的節點。這還可以讓您在負載較輕時通過將工作折疊到更少的節點上來縮小系統，而不是被大量節點卡住，每個節點大多空閒，只有一個或兩個活動連接。
您的應用程序必須仔細編寫以檢查所有返回程式碼/處理異常。他們必須重試由於連接失去等暫時錯誤而失敗的事務，這意味著他們必須記住他們所做的一切，直到他們送出每個事務。無論如何，這是一個很好的應用程序設計，如果斷開連接和事務中止不是日常操作的正常部分，則更容易擺脫懶惰。
從理論上講，PgPool 可以允許“透明”負載平衡來讀取副本，同時仍允許向主節點寫入查詢。在實踐中，我發現它通常很繁瑣而且很難正確處理，所以我通常希望應用程序知道單獨的“只讀”和“寫/主”連接。
PgBouncer 相對於 TCP 負載平衡的主要優勢是（在事務池模式下）它允許應用程序保持空閒連接，而不會在備份 PostgreSQL 伺服器上施加成本。因此，您可以針對 PgBouncer 進行一次昂貴的握手、SSL 協商、身份驗證等，並讓它僅在它正在做某事時才將連接綁定到池中的實際 PostgreSQL 後端。這允許 Pg 後端的最佳利用並減少閒置後端的數量，除了耗盡資源和等待工作之外什麼都不做。不過，這僅在您的應用程序可以處理事務池（或語句池）模式時才有價值；如果由於使用會話變數、偵聽/通知、諮詢鎖等而只能使用會話池模式，則沒有任何好處。
如果您使用 TCP 負載平衡，您應該能夠像使用 PgPool 或 PgBouncer 一樣進行 SSL 解除安裝，至少使用足夠智能的負載平衡器。但是，您將無法執行依賴於 pg_hba.conf 的客戶端證書身份驗證之類的操作。
大多數時候，我傾向於擴大規模而不是擴大規模，所以到目前為止，這還不是我需要探索的東西。不過，我有一些工作正在進行中，這將使使用 Pg 進行擴展變得非常有趣，所以我將不得不玩這個。