適用於 PostgreSQL 的 Azure 資料庫 flexible server 中業務持續性概覽

適用於 PostgreSQL 的 Azure 資料庫中的商務持續性是指可讓您的企業在面對中斷時繼續運作的機制、原則和程序,尤其是其運算基礎結構。 在大多數情況下,適用於 PostgreSQL 的 Azure 資料庫 會處理雲端環境中可能發生的干擾事件,並維持您的應用程式與業務流程正常運作。 然而,有些事件無法自動處理,例如:

  • 使用者不小心刪除或更新了資料表中的某一列。
  • 地震會導致停電,並暫時使可用區域或區域失效。
  • 修正 Bug 或安全性問題所需的資料庫修補。

適用於 PostgreSQL 的 Azure 資料庫 提供保護資料並減輕關鍵任務資料庫在計畫性及非預期停機事件中停機的功能。 適用於 PostgreSQL 的 Azure 資料庫建置在提供強大復原和可用性的 Azure 基礎結構之上,具有商務持續性功能,可提供另一個錯誤保護、解決復原時間需求,以及減少資料遺失風險。 當您架構應用程式時,請考慮停機容錯 - 復原時間目標 (RTO),以及資料遺失暴露 - 復原點目標 (RPO)。 例如,相較於測試資料庫,業務關鍵資料庫需要更嚴格的運作時間。

下表說明 適用於 PostgreSQL 的 Azure 資料庫 所提供的功能。

Feature 說明 考量
自動備份 適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體會自動執行資料庫檔案的每日備份,並持續備份交易記錄。 備份期限可從7天延長到35天不等。 您可以將資料庫伺服器還原到備份保留期間內的任何時間點。 RTO 取決於還原資料大小以及日誌還原所需的時間。 時間從幾分鐘到12小時不等。 如需詳細資訊,請參閱 概念 - 備份和還原 備份資料會保留在區域內。
區域冗餘高可用性 你可以部署一個 適用於 PostgreSQL 的 Azure 資料庫 靈活伺服器實例,採用區域冗餘高可用性(HA)配置,主要伺服器和備用伺服器部署在同一區域內的兩個不同可用性區域。 此 HA 配置可保護您的資料庫免於區域層級故障,並有助於減少計畫內外停機事件中的應用程式停機時間。 主要伺服器中的資料以同步模式複寫到待命複本。 在主要伺服器發生任何中斷的事件中,伺服器會自動容錯移轉至待命複本。 在大多數情況下,RTO 預期小於 120 秒。 RPO 應該會是零 (不會遺失任何資料)。 欲了解更多資訊,請參閱 概念 - 高可用性 支援一般用途與記憶體最佳化的計算層。 僅適用於有多個區域 (zone) 的區域 (region)。
相同區域高可用性 你可以部署一個 適用於 PostgreSQL 的 Azure 資料庫 靈活伺服器實例,採用相同的區域高可用性(HA)配置,主要伺服器和備用伺服器部署在同一區域的可用性區域。 此 HA 配置可保護您的資料庫免於節點層級故障,並有助於減少計畫內外停機事件中的應用程式停機時間。 主要伺服器中的資料以同步模式複寫到待命複本。 在主要伺服器發生任何中斷的事件中,伺服器會自動容錯移轉至待命複本。 在大多數情況下,RTO 預期會少於 120 秒。 RPO 應該會是零 (不會遺失任何資料)。 如需詳細資訊,請參閱 [概念 - 高可用性]/azure/reliability/reliability-postgresql-flexible-server。 支援一般用途與記憶體最佳化的計算層。
進階受控磁碟 資料庫檔案會儲存在高度耐用且可靠的進階受控儲存體中。 此儲存提供資料冗餘,三份副本存放於具自動資料復原功能的可用性區域內。 如需詳細資訊,請參閱 管理的磁碟文件 資料會儲存於可用性區域中。
區域備援備份 如果區域支援可用性區域,則適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體備份會自動安全地儲存在區域內的區域備援儲存體中。 當您伺服器所佈建的區域發生區域層級故障時,如果您的伺服器未設定區域備援,您仍然可以使用其他區域中的最新還原點來還原資料庫。 如需詳細資訊,請參閱 概念 - 備份和還原 僅適用於提供多個區域 (zone) 的區域 (region)。
異地備援備份 適用於 PostgreSQL 的 Azure Database 彈性伺服器執行個體的備份會被複製到遠端區域。 此功能有助於在主伺服器區域當機時進行災難復原。 此功能目前已在選取的區域啟用。 其需要較長的 RTO 與較高的 RPO,視要還原的資料大小及要執行的復原數量而定。
讀取複本 您可以部署跨區域只讀複本以保護資料庫免受區域層級故障的影響。 讀取副本會透過 PostgreSQL 的實體複製技術非同步更新,可能會延遲主副本。 如需詳細資訊,請參閱概念 - 讀取複本 支援一般用途與記憶體最佳化的計算層。

下表比較 RTO 和 RPO 在典型的 工作負載 情境中:

能力 可高載 生產 SKU(一般用途/記憶體最佳化)
從備份進行時間點還原 保留期間內的任何還原點
RTO - 不定
RPO < 5 分鐘
保留期間內的任何還原點
RTO - 不定
RPO < 5 分鐘
從異地複寫備份進行異地還原 RTO - 不定
RPO < 1 小時
RTO - 不定
RPO < 1 小時
讀取複本 不適用 RTO - 數分鐘*
RPO - 通常範圍為 30 秒到 5 分鐘*
高可用性 不適用 RTO < 120 秒
RPO = 0

計劃性停機事件

下表描述了一些常見的計畫性維護情境。 這些事件通常會導致幾分鐘的停機,但不會導致資料遺失。

場景 過程
計算調整 (由使用者初始化) 在運算資源擴展作業期間,此程序會允許進行中的檢查點完成、排空用戶端連線、取消所有未提交的交易、卸離儲存體,然後關閉。 此過程會配置一個新的 適用於 PostgreSQL 的 Azure 資料庫 靈活伺服器實例,使用相同資料庫伺服器名稱但採用擴展計算配置。 該程序會將儲存裝置附加到新伺服器並啟動資料庫,資料庫在接受用戶端連線前進行必要的復原。
擴大儲存體 (由使用者初始化) 當您啟動擴充儲存體作業時,此程序會允許作用中的檢查點完成、清空用戶端連線,並取消任何未認可的交易。 之後,這個程序會關閉伺服器。 這個過程會將儲存空間縮放到所需的大小,然後再連接到新的伺服器。 此程序會先在必要時執行復原,再接受用戶端連線。 請注意,不支援縮小儲存體大小。
新的軟體部署 (由 Azure 初始化) 該服務會自動推出新功能或錯誤修正,作為計畫維護的一部分。 你可以安排這些活動的時間。 如需詳細資訊,請檢查您的 入口網站
次要版本升級 (由 Azure 初始化) 適用於 PostgreSQL 的 Azure 資料庫會自動將資料庫伺服器修補為 Azure 所判斷的次要版本。 此補丁是服務計畫維護的一部分。 此程序會自動重新啟動資料庫伺服器,使用新的次要版本。 如需詳細資訊,請參閱 。 您也可以查看您的入口網站

當你設定 適用於 PostgreSQL 的 Azure 資料庫 靈活伺服器實例並具備高可用性時,服務會先在備用伺服器上執行擴展和維護操作。 如需詳細資訊,請參閱 [概念 - 高可用性]/azure/reliability/reliability-postgresql-flexible-server。

非計劃性停機風險降低措施

可能會因為未預期的中斷 (例如基礎硬體故障、網路問題與軟體 Bug) 而發生非計劃性停機。 若設定為高可用性的資料庫伺服器意外當機,服務會啟動備用副本,客戶端即可恢復運作。 如果你沒有設定伺服器具備高可用性(HA),當重新啟動失敗時,服務會自動配置新的資料庫伺服器。 雖然無法避免意外停機,但 適用於 PostgreSQL 的 Azure 資料庫 能自動執行復原操作,無需人工介入,幫助減輕停機時間。

雖然工程團隊持續努力提供高可用性,但有時 適用於 PostgreSQL 的 Azure 資料庫 會發生故障,導致資料庫無法使用,進而影響您的應用程式。 當服務監控偵測到導致廣泛連線錯誤、故障或效能問題的問題時,服務會自動宣告中斷以隨時通知您。

服務中斷

如果 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器實例當機,您可以在以下地方找到更多關於中斷的詳細資訊:

  • Azure 入口網站橫幅:如果您的訂閱受到影響,Azure 入口網站通知會顯示服務問題的故障警示。

 顯示 Azure 入口網站中通知的螢幕快照。

  • 幫助+支援支援+故障排除:當你從 「幫助+支援 」或 「支援+故障排除」建立支援單時,入口網站會包含影響你資源的任何問題資訊。 選取 [檢視中斷詳細資料] 以取得詳細資訊和影響摘要。 新支援請求頁面也包含警示。

 顯示 Azure 入口網站中說明支援通知的螢幕擷取畫面。

  • 服務健康:Azure 入口網站中的服務健康頁面包含全球 Azure 資料中心狀態資訊。 在 Azure 入口網站的搜尋欄搜尋「service health」,然後在「Active events」類別中查看服務問題。 您也可以在 [說明] 功能表下任何資源的資源健康狀態頁面中檢視個別資源的健全狀況。 以下 Service Health 頁面的螢幕擷取畫面顯示有關東南亞目前發生之服務問題的資訊。

 顯示服務健康狀態入口網站中服務中斷的螢幕快照。

  • 電子郵件通知:如果您設定了警示,當您的訂閱與資源因服務中斷時,您會收到電子郵件通知。 這些郵件來自「azure-noreply@microsoft.com」。 電子郵件本文開頭是「活動記錄警示...由 Azure 訂用帳戶的服務問題觸發...」。 欲了解更多關於服務健康警示的資訊,請參閱使用 Azure 入口網站接收 Azure 服務通知的活動日誌警示

這很重要

顧名思義,PostgreSQL 中的暫存表格空間會用於暫存物件,以及其他內部資料庫作業,例如排序。 因此,不要在暫存的表格空間建立使用者結構物件,因為這些物件在伺服器重啟、HA 故障轉移及類似事件後的持久性並不保證。

非計劃性停機:失敗案例與服務復原

下表描述了常見的意外失效情境及復原流程。

場景 復原程式
[未設定區域備援 HA 的伺服器]
復原程式
[已設定區域備援 HA 的伺服器]
資料庫伺服器失敗 如果資料庫伺服器當機,Azure 會嘗試重新啟動資料庫伺服器。 如果嘗試失敗,Azure 會重新啟動另一個實體節點上的資料庫伺服器。

復原時間(RTO)取決於多種因素,包括故障發生時的活動,例如大型交易,以及在資料庫伺服器啟動過程中需要執行的復原量。

使用 PostgreSQL 資料庫的應用程式需要偵測並重試中斷連線與失敗的交易。
若偵測到資料庫伺服器故障,伺服器會切換至備用伺服器,從而減少停機時間。 如需詳細資訊,請參閱 [HA 概念頁面]/azure/reliability/reliability-postgresql-flexible-server。 預計 RTO 為 60-120 秒,且零資料遺失。
記憶體失敗 應用程式不會因磁碟故障或實體區塊損壞等儲存相關問題而受到影響。 由於資料儲存在三個副本中,存續的儲存空間會服務於資料的副本。 損毀的資料區塊會自動修復,並自動建立新的資料複本。 對於任何罕見且無法復原的錯誤,例如整個儲存無法存取時,適用於 PostgreSQL 的 Azure 資料庫 靈活伺服器實例會切換到備用副本以減少停機時間。 如需詳細資訊,請參閱 [HA 概念頁面]/azure/reliability/reliability-postgresql-flexible-server。
邏輯錯誤或使用者錯誤 若要因應使用者錯誤進行復原,例如意外刪除的資料表或錯誤更新的資料,請執行 時間點復原(PITR)。 執行還原操作時,請指定自訂還原點,也就是錯誤發生前的時間點。

如果你只想還原部分資料庫或特定資料表,而非資料庫伺服器中的所有資料庫,你可以在新實例中還原資料庫伺服器,透過 pg_dump 匯出資料表,然後用 pg_restore 將這些資料表還原到資料庫中。
這些使用者錯誤並未受到高可用性保護,因為所有變更都會同步複製到備用副本。 你需要執行即時還原才能從這些錯誤中恢復。
可用性區域失敗 若要從區域層級失敗中復原,請使用備份執行時間點還原,並選擇一個自訂還原點,以最新還原時間還原最新資料。 在另一個未受影響的區域部署一個新的 適用於 PostgreSQL 的 Azure 資料庫 靈活伺服器實例。 還原所花費的時間取決於先前的備份,以及要復原的交易記錄量。 適用於 PostgreSQL 的 Azure 資料庫 的彈性伺服器實例會在 60-120 秒內自動切換到備用伺服器,且不會遺失任何資料。 如需詳細資訊,請參閱 [HA 概念頁面]/azure/reliability/reliability-postgresql-flexible-server。
區域失敗 若您的伺服器已設定異地備援備份,則可以在配對的區域中執行異地還原。 Azure 會佈建新的伺服器,並將其恢復到已複製到此區域的最後可用資料。

您也可以使用跨區域讀取複本。 若區域故障,您可以透過將讀取副本升級為獨立可寫伺服器來執行災難復原操作。 RPO 預計最多為五分鐘(可能發生資料遺失),但若發生嚴重的區域性故障,RPO 可能會接近故障發生時的複寫延遲。
相同的程序。

從區域失敗復原之後設定資料庫

這很重要

你可以還原已刪除的伺服器。 如果你刪除伺服器,請依照 「還原已刪除伺服器 」的指引來恢復。 使用 Azure 資源鎖定來協助防止伺服器意外遭到刪除。