確保高可用性 Patroni 設定的可靠性和品質,對於維持資料庫持續運作及盡量減少停機時間至關重要。本頁提供 Patroni 叢集測試的完整指南,涵蓋各種失敗情境、複寫一致性和容錯移轉機制。
測試 Patroni 設定
連線至任一 patroni 執行個體 (
alloydb-patroni1
、alloydb-patroni2
或alloydb-patroni3
),然後前往 AlloyDB Omni patroni 資料夾。cd /alloydb/
檢查 Patroni 記錄。
docker compose logs alloydbomni-patroni
最後的項目應會反映 Patroni 節點的相關資訊。您應該會看到類似下列的內容。
alloydbomni-patroni | 2024-06-12 15:10:29,020 INFO: no action. I am (patroni1), the leader with the lock alloydbomni-patroni | 2024-06-12 15:10:39,010 INFO: no action. I am (patroni1), the leader with the lock alloydbomni-patroni | 2024-06-12 15:10:49,007 INFO: no action. I am (patroni1), the leader with the lock
連線至任何執行 Linux 的執行個體,該執行個體必須與主要 Patroni 執行個體
alloydb-patroni1
建立網路連線,並取得執行個體的相關資訊。您可能需要執行sudo apt-get install jq -y
來安裝jq
工具。curl -s http://alloydb-patroni1:8008/patroni | jq .
畫面會顯示類似以下的內容。
{ "state": "running", "postmaster_start_time": "2024-05-16 14:12:30.031673+00:00", "role": "master", "server_version": 150005, "xlog": { "location": 83886408 }, "timeline": 1, "replication": [ { "usename": "alloydbreplica", "application_name": "patroni2", "client_addr": "10.172.0.40", "state": "streaming", "sync_state": "async", "sync_priority": 0 }, { "usename": "alloydbreplica", "application_name": "patroni3", "client_addr": "10.172.0.41", "state": "streaming", "sync_state": "async", "sync_priority": 0 } ], "dcs_last_seen": 1715870011, "database_system_identifier": "7369600155531440151", "patroni": { "version": "3.3.0", "scope": "my-patroni-cluster", "name": "patroni1" } }
在 Patroni 節點上呼叫 Patroni HTTP API 端點,會公開 Patroni 管理的特定 PostgreSQL 執行個體狀態和設定的各種詳細資料,包括叢集狀態資訊、時間軸、WAL 資訊,以及指出節點和叢集是否正常運作的健康狀態檢查。
測試 HAProxy 設定
在可連上網路的電腦上開啟瀏覽器,然後前往 HAProxy 節點的下列網址:
http://haproxy:7000
。或者,您也可以使用 HAProxy 執行個體的外部 IP 位址,而非主機名稱。您應該會看到類似下圖的畫面。
圖 1. HAProxy 狀態頁面,顯示 Patroni 節點的健康狀態和延遲時間。
在 HAProxy 資訊主頁中,您可以查看主要 Patroni 節點
patroni1
的健康狀態和延遲時間,以及兩個副本patroni2
和patroni3
的健康狀態和延遲時間。您可以執行查詢,檢查叢集中的複寫統計資料。透過 pgAdmin 等用戶端連線至 HAProxy,然後連線至主要資料庫伺服器,並執行下列查詢。
SELECT pid, usename, application_name, client_addr, state, sync_state FROM pg_stat_replication;
畫面應會顯示類似下圖的內容,指出
patroni2
和patroni3
正在從patroni1
串流。圖 2:pg_stat_replication 輸出內容,顯示 Patroni 節點的複製狀態。
測試自動容錯移轉
在本節中,我們會在三個節點的叢集中,停止附加的 Patroni 容器,模擬主要節點發生中斷。您可以停止主要節點上的 Patroni 服務,模擬中斷情形,或是強制執行某些防火牆規則,停止與該節點的通訊。
在主要 Patroni 執行個體上,前往 AlloyDB Omni Patroni 資料夾。
cd /alloydb/
停止容器。
docker compose down
您應該會看到類似下列的輸出內容。這應該會驗證容器和網路已停止。
[+] Running 2/2 ✔ Container alloydb-patroni Removed ✔ Network alloydbomni-patroni_default Removed
重新整理 HAProxy 資訊主頁,查看容錯移轉的過程。
圖 3:HAProxy 資訊主頁,顯示從主要節點容錯移轉至待命節點的過程。
patroni3
執行個體成為新的主要執行個體,而patroni2
是唯一剩下的副本。先前的主要執行個體patroni1
已停止運作,且健康狀態檢查失敗。Patroni 會透過監控、共識和自動化調度管理,執行及管理容錯移轉作業。只要主要節點未在指定逾時時間內續約,或回報失敗,叢集中的其他節點就會透過共識系統辨識出這個情況。其餘節點會協調作業,選取最適合升級為新主節點的副本。選取候選副本後,Patroni 會套用必要變更 (例如更新 PostgreSQL 設定,以及重新播放任何未處理的 WAL 記錄),將這個節點升級為主要節點。接著,新的主要節點會更新共識系統的狀態,其他副本則會重新設定,以追蹤新的主要節點,包括切換複製來源,以及可能趕上任何新交易。HAProxy 會偵測新的主要節點,並據此重新導向用戶端連線,確保服務中斷時間降到最低。
透過 pgAdmin 等用戶端連線至 HAProxy,然後連線至資料庫伺服器,並在容錯移轉後檢查叢集中的複製統計資料。
SELECT pid, usename, application_name, client_addr, state, sync_state FROM pg_stat_replication;
您應該會看到類似下圖的內容,顯示目前只有
patroni2
正在串流。圖 4. pg_stat_replication 輸出內容,顯示容錯移轉後 Patroni 節點的複製狀態。
您的三節點叢集可以再承受一次中斷。如果停止目前的主要節點
patroni3
,系統會再次執行容錯移轉。圖 5. HAProxy 資訊主頁顯示從主要節點
patroni3
到待命節點patroni2
的容錯移轉。
備用注意事項
容錯移轉後,備用程序會還原先前的來源節點。一般來說,我們不建議在高可用性資料庫叢集中使用自動回復功能,因為這會導致多項重大問題,例如復原不完整、發生腦裂情況的風險,以及複寫延遲。
在 Patroni 叢集中,如果您啟動模擬中斷的兩個節點,這些節點會以待命副本的身分重新加入叢集。
圖 6:HAProxy 資訊主頁,顯示 patroni1
和 patroni3
還原為待命節點。
現在 patroni1
和 patroni3
會從目前的主要執行個體 patroni2
複製資料。
圖 7. pg_stat_replication 輸出內容,顯示備援後 Patroni 節點的複製狀態。
如要手動還原為初始主要執行個體,可以使用 patronictl 指令列介面。選擇手動回復,可確保復原程序更可靠、一致且經過徹底驗證,維持資料庫系統的完整性和可用性。