使用 HAProxy 和 PGBouncer 的 PostgreSQL 高可用性/可擴展性
我有多個用於 Web 應用程序的 PostgreSQL 伺服器。通常一個主多從處於熱備模式(非同步流複製)。
我使用 PGBouncer 進行連接池:每個 PG 伺服器(埠 6432)上安裝一個實例,連接到本地主機上的數據庫。我使用事務池模式。
為了負載平衡我在從屬設備上的只讀連接,我使用 HAProxy (v1.5) 和 conf 或多或少像這樣:
listen pgsql_pool 0.0.0.0:10001 mode tcp option pgsql-check user ha balance roundrobin server master 10.0.0.1:6432 check backup server slave1 10.0.0.2:6432 check server slave2 10.0.0.3:6432 check server slave3 10.0.0.4:6432 check
因此,我的 Web 應用程序連接到 haproxy(埠 10001),即在每個 PG 從站上配置的多個 pgbouncer 上的負載平衡連接。
這是我目前架構的表示圖:
像這樣工作得很好,但我意識到有些實現這一點完全不同:Web 應用程序連接到單個 PGBouncer 實例,該實例連接到 HAproxy,該實例在多個 PG 伺服器上進行負載平衡:
最好的方法是什麼?第一個(我現在的)還是第二個?一種解決方案比另一種解決方案有什麼優勢嗎?
謝謝
你現有的 HAProxy 配置 -> PGBouncer -> PGServer approch 更好。這只有效。原因如下:HAProxy 將連接重定向到不同的伺服器。這會導致數據庫連接中的 MAC 地址發生變化。因此,如果 PGBouncer 高於 HAProxy,則每次池中的連接都會因為 MAC 地址更改而失效。
pgbouncer 在一個池中與一個 postgres 伺服器保持連接。TCP 連接建立時間在大容量環境中很重要。
發出大量數據庫請求的客戶端必須為每個請求設置與遠端 PGBouncer 的連接。這比在本地執行 PgBouncer 更昂貴(因此應用程序在本地連接到 pgbouncer)並且 pgBouncer 維護與遠端 PG 伺服器的連接池。
因此,IMO,PGBouncer -> HAProxy -> PGServer 似乎比 HAProxy -> PGBouncer -> PGServer 更好,尤其是當 PGBouncer 位於客戶端應用程序的本地時。