瞭解 Databases for PostgreSQL 的高可用性及災難回復
高可用性服務或工作負載承受故障並根據某些預先定義的服務等級繼續提供處理能力的能力。 對於服務而言，可用性是在服務等級協議中定義的。 可用性包括計劃內和計劃外的事件，例如維護、故障和災難。 (HA) 是指服務在發生意外故障時仍能維持運作和存取的能力。 災難復原服務或工作負載從罕見的重大事故和大規模故障（如服務中斷）中恢復的能力。 這包括影響整個區域的實體災難、資料庫損毀或對工作負載有貢獻的服務遺失。 其影響超出了高可用性設計的處理能力。是將服務實例還原到工作狀態的過程。
Databases for PostgreSQL 是符合「標準」計畫的區域性服務，可達到所定義的 服務等級目標(SLO)。 如需詳細資訊，請參閱 服務層級協議(SLA)。 如需 site.data.keyword.databases-for-postgresql 可用 IBM Cloud 區域和資料中心的詳細資訊，請參閱 依地點列出的服務和基礎架構 可用性。
高可用性架構
Databases for PostgreSQL 提供複製、故障移轉和高可用性功能，保護您的資料庫和資料免於基礎結構維護、升級和某些故障的影響。 部署包含一個群集，其中有兩個資料成員 - leader 和 replica。 副本使用異步複製保持更新。 分散式共識機制用於維護叢集狀態和處理故障轉移。 如果領導者變得無法連線，群集會啟動故障移轉，複製品會升級為領導者，而新的複製品會重新加入群集成為複製品。 領袖和副本永遠處於 MZR 的不同區域。 如果副本失敗，則會建立新的副本。 如果區域故障導致成員失敗，則會在存活的區域中建立新的複製本。
您可以將 PostgreSQL 成員 加入群集，以擴大區域內的備援，或提供 唯讀複製 以進行跨區域故障移轉或讀取卸載，從而進一步擴展高可用性。
檢閱 PostgreSQL 有關 複製技術的文件，以瞭解與預設部署的異步複製策略相關的限制和取捨。
在資料庫變得嚴重不健康的情況下（例如領導者的伺服器當機），Databases for PostgreSQL 嘗試進行故障移轉。 此自動故障移轉功能的上限為從 leader 到 replica 的 16 MB 資料滯後（幾行資料一次佔更多 PostgreSQL 資料開銷），如果超過滯後閾值，則不會執行。 如果應用程式無法容忍 16 MB 的潛在資料遺失，請參閱下面的 同步複製。
以程式方式存取群集的工作負載必須遵循用戶端可用性重試邏輯，以維持可用性。
在正常操作下，服務有時會進行受控故障移轉。 這些故障移轉不會造成資料遺失，但會導致活動連線的重設。 有一段長達 15 秒的時間，重新連線可能會失敗。 有時候，由於作業環境中的意外事件，可能會發生計劃外的故障移轉。 這些過程最長可能需要 45 秒，但通常少於 30 秒。 例如，服務維護會觸發受控的故障移轉。
高可用性功能
Databases for PostgreSQL 支援下列高可用性功能：
| 特性 | 說明 | 考量 |
|---|---|---|
| 自動故障移轉 | 所有集群的標準配備，可抵擋區域或單一成員故障的影響 | |
| 成員計數 | 最少 - 2 名成員。 預設為標準雙組員部署。 雙人群集會自動從單一範例或區域故障中恢復（資料遺失會達到滯後閾值）。 在新副本的資料同步期間，群集會暴露於第二個故障，導致資料遺失。 三個成員，請參閱 新增 PostgreSQL 成員，在同一故障期間，兩個成員故障時的彈性 | 同步複製需要三個成員 |
| 同步抄寫 | 透過在資料寫入路徑中加入遠端成員同步，改善 RPO。 請參閱下面的 同步複製。 | 效能影響與成本。 |
| 唯讀複製 | 唯讀複製可在遠端區域提供本機存取，改善對潛在網路延遲或連線問題的可用性。 | 所有 Write 請求都必須專門指向與讀取複製器相關的讀寫群集 |
同步複製 Databases for PostgreSQL
預設情況下，串流複製是異步的。 如果領導者當機，一些已提交的事務可能還沒有同步到副本，造成資料遺失。Cloud Databases，可確保將資料遺失控制在最低限度的大量資料遺失；但是，同步複製提供了確認事務所做的所有變更都已同步到副本的能力。 這可確保叢集的一致性。 這種一致性來自於確認寫入已寫入次要區域，然後才以 success 返回連線用戶端。 有關同步複製的變數，請參閱 synchronous_commit 上的變更設定頁面。
同步複製將複製的可用性帶入主要寫入路徑。 如果沒有副本確認寫入，則會擱置直到有副本可用為止。 這需要至少三個成員才能可靠運作，因為同步複製在兩個成員的部署上不受支援。 在啟用同步複製之前，您_必須_水平擴充至至少三個成員。 請參閱 新增 PostgreSQL 成員。
雖然可能性不大，但仍有可能有一個以上的複製本同時無法使用。 如果發生這種情況，主資料庫將無法完成任何寫入動作，直到副本重新上線為止，這會有效地阻斷資料庫的所有寫入流量。 當您決定使用同步複製時，請衡量較高資料耐久性與潛在可用性問題的相對成本與效益。
配置同步複製會顯著增加寫入延遲並降低整體吞吐量。 為了獲得最佳效能，建議僅在需要最高資料耐用性的特定資料庫或工作負載上使用同步複製。
災難復原架構
災難復原的一般策略是建立新資料庫，就像下面的 Restore 資料庫。 新資料庫的內容可以是災難發生前建立的來源資料庫備份。 如果生產資料庫可用，則可使用時間點功能建立新資料庫。
災難復原功能
Databases for PostgreSQL 支援下列災難復原功能：
| 特性 | 說明 | 考量 |
|---|---|---|
| 備份還原 | 從先前建立的備份建立資料庫；請參閱 管理 Cloud Databases 備份。 | 還原資料庫的新連線字串必須在整個工作負載中引用。 |
| 復原點還原 | 使用 時間點恢復 從即時生產創建資料庫 | 只有當使用中的資料庫可用，且 RPO（災難）在支援的視窗內時，才有可能這樣做。 如果生產群集不可用，它就沒有用處。 還原資料庫的新連線字串必須在整個工作負載中引用。 |
| 推廣閱讀複製 | 在相同或遠端區域規劃災難時，建立 唯讀複本。 升級唯讀複本以 從災難中復原。 | 先前建立的讀取複製檔必須可用。 還原資料庫的新連線字串必須在整個工作負載中引用。 |
規劃災難回復
災難復原步驟必須定期練習。 當您建立計劃時，請考慮以下的失敗情況和解決方案。
| 失敗 | 解決方法 |
|---|---|
| 硬體故障（單點） | IBM 提供可避免區域內單點硬體故障的資料庫 - 無需設定。 |
| 區域故障 | 自動故障移轉 (#postgresql-high-availability). 資料庫成員分佈在區域之間。 配置三個成員將提供額外的彈性，以應對多個區域故障。
同步複製會以效能為代價降低 RPO。 |
| 資料毀損 | 備份還原。 將已還原的資料庫用於生產或源資料，以修正已還原資料庫中的損毀。
時間點還原。 將已還原的資料庫用於生產或源資料，以修正已還原資料庫中的損毀。 |
| 區域失敗 | 備份還原。 在生產中使用還原的資料庫。
推廣閱讀副本。 將只讀副本升級為讀/寫資料庫。 在生產中使用還原的資料庫 |
應用層級的高可用性
透過網路和雲端服務進行通訊的應用程式會受到瞬間連線故障的影響。 您要設計您的應用程式，以便在因暫時失去與部署或 IBM Cloud 的連線而造成錯誤時，重新嘗試連線。
由於 Databases for PostgreSQL 是受管理的服務，因此定期更新和資料庫維護是正常作業的一部分。 這偶爾會導致資料庫短暫不可用。 它也可以導致資料庫觸發優美的故障移轉、重試和重新連線。 資料庫需要很短的時間來判斷哪個成員是副本，哪個是領導者，因此您也可能會看到短暫的連線中斷。 故障移轉一般需時少於 30 秒。
您的應用程式必須設計成可以處理資料庫的暫時中斷、實作失敗資料庫指令的錯誤處理，以及實作重試邏輯以從暫時中斷中恢復。
預期不會出現數分鐘的資料庫無法使用或連線中斷情況。 如果您有超過一分鐘無法連線的情況，請開啟 支援個案 並說明詳細資料，以便我們進行調查。
連線限制
Databases for PostgreSQL 將 資料庫的最大連線數設定為 PostgreSQL 115。15 個連線保留給超級使用者，以維護資料庫的狀態和完整性，100 個連線則供您和您的應用程式使用。 達到連線上限後，任何啟動新連線的嘗試都會導致錯誤。 若要避免連線數量過多，請使用連線池或擴充您的部署，並增加其連線限制。 如需詳細資訊，請參閱 管理 PostgreSQL 連線 頁面。
您對 HA 和 DR 的責任
以下資訊可協助您建立並持續實作 HA 和 DR 的計劃。
從備份還原資料庫或使用時間點還原時，會使用新的連線字串建立新資料庫。 現有的工作負載和程序必須調整，以使用新的連線串。 將讀取複本升級到群集也會有類似的影響，不過工作負載的現有唯讀部分不會受到影響。
復原的資料庫也可能需要與災難資料庫相同的客戶建立的依賴 - 確保這些及其他服務存在於復原區域中：
- IBM® Key Protect for IBM Cloud®
- Hyper Protect Crypto Services
請記住，刪除資料庫也會刪除其相關的備份。 不過，已刪除的資料庫可能會在有限的時間內復原。 有關資料庫復原程序的具體詳細資訊，請參閱 說明文件。
不可能從 IBM Cloud 複製備份，因此可考慮使用資料庫特定工具來進行額外的備份。 它可能需要從惡意資料庫刪除後的資料庫復原中復原。 對資料庫的 IAM 存取進行仔細管理，有助於降低此問題的風險。
以下與每個特徵相關的核對表可以幫助您建立和實踐您的計劃。
- 備份還原
- 確認備份以所需頻率提供，以符合 RPO 要求。 管理 Cloud Databases 備份 文件備份頻率。 如果資料庫的關鍵性和大小允許，可考慮使用 IBM Cloud® Code Engine- 與定期定時器(cron)事件製作器合作，建立額外的按需備份，以改善 RPO。 但是，考慮到 PostgreSQL's PITR 功能，請仔細評估是否需要額外的備份。
- 資料庫還原區域有一些限制 - 請閱讀 管理 Cloud Databases 備份，確認您的還原目標可以達成。
- 確認備份的保留期限符合您的需求。
- 定期安排測試還原，以驗證實際還原時間是否符合定義的 RTO。 請記住，資料庫大小會顯著影響還原時間。 請考慮縮短還原時間的策略，例如將大型資料庫分解為較小、較易管理的單元，以及清除未使用的資料。
- 驗證 Key Protect 服務。
- 復原點還原
- 驗證之前涵蓋的程序。
- 確認視窗中有所需的備份。
- 推廣閱讀複製
- 驗證復原區域中是否存在讀取複本。
- 練習升級程序 - 在所需區域中建立臨時讀取複本。 臨時複本可以升級為讀/寫，並執行一些測試，對生產的影響很小。
要瞭解有關客戶與 IBM Cloud 之間使用 Databases for PostgreSQL 的責任所有權的更多資訊，請參閱 Cloud Databases 的共同責任。
隨時掌握最新資訊：IBM 通知
影響客戶工作負載的更新會透過 IBM Cloud 通知。 若要隨時瞭解與此服務相關的計劃維護、公告和發佈說明，請參閱「監控通知和狀態」頁面。 此外，請定期檢閱版本 政策 頁面，以取得有關生命週期結束版本和日期的最新更新。