「適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器」的商務持續性概觀

適用於:適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器

適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器中的商務持續性是指讓企業面對中斷而繼續運作的機制、原則和程式,特別是其運算基礎結構。 在大部分情況下,適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器會處理雲端環境中可能發生的干擾性事件,並讓您的應用程式和商務程式保持執行。 不過,有些事件無法自動處理,例如:

  • 使用者不小心刪除或更新數據表中的數據列。
  • 地震造成停電,並暫時停用可用性區域或區域。
  • 修正 Bug 或安全性問題所需的資料庫修補。

適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器提供的功能可保護數據,並降低計劃性和非計劃性停機事件期間任務關鍵資料庫的停機時間。 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器建置在提供強固復原和可用性的 Azure 基礎結構之上,具有商務持續性功能,可提供另一個錯誤保護、解決復原時間需求,並減少數據遺失風險。 在架構應用程式時,您應該考慮停機時間容錯 - 復原時間目標 (RTO), 和數據遺失風險 - 恢復點目標 (RPO)。 例如,您的業務關鍵資料庫需要比測試資料庫更嚴格的運行時間。

下表說明 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器所提供的功能。

功能 說明 考量
自動備份 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器會自動執行資料庫檔案的每日備份,並持續備份事務歷史記錄。 備份至少可保留 7 天,最多則可保留達 35天。 您可以將資料庫伺服器還原到備份保留期間內的任何時間點。 RTO 取決於要還原的數據大小 + 執行記錄復原的時間。 它可以從幾分鐘到 12 小時。 如需詳細資訊,請參閱 概念 - 備份和還原 備份數據會保留在區域內。
區域備援高可用性 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器可以使用區域備援高可用性 (HA) 設定進行部署,其中主要和待命伺服器部署在區域內的兩個不同的可用性區域中。 此 HA 組態可保護您的資料庫免於區域層級失敗,也有助於在計劃性和非計劃性停機事件期間減少應用程式停機時間。 主伺服器的數據會以同步模式複寫至待命複本。 如果主伺服器發生任何中斷,伺服器會自動故障轉移至待命複本。 在大部分情況下,RTO 預期小於 120 年代。 RPO 應該會是零 (不會遺失任何資料)。 如需詳細資訊,請參閱 概念 - 高可用性 一般用途和記憶體優化計算層支援。 僅適用於多個區域可用的區域。
相同區域高可用性 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器可以使用相同的區域高可用性 (HA) 設定來部署,其中主要和待命伺服器部署在區域中的相同可用性區域。 此 HA 組態可保護您的資料庫免於節點層級失敗,也有助於在計劃性和非計劃性停機事件期間減少應用程式停機時間。 主伺服器的數據會以同步模式複寫至待命複本。 如果主伺服器發生任何中斷,伺服器會自動故障轉移至待命複本。 在大部分情況下,RTO 預期小於 120 年代。 RPO 應該會是零 (不會遺失任何資料)。 如需詳細資訊,請參閱 概念 - 高可用性 一般用途和記憶體優化計算層支援。
進階版 受控磁碟 資料庫檔案會儲存在高度耐用且可靠的進階受控儲存體中。 這能提供資料備援能力,會有三個複本儲存在具有自動資料復原功能的可用性區域內。 如需詳細資訊,請參閱 受控磁碟檔 儲存在可用性區域內的數據。
區域備援備份 如果區域支援可用性區域,適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器備份會自動且安全地儲存在區域內的區域備援記憶體中。 在布建伺服器的區域層級失敗期間,如果您的伺服器未設定區域備援,您仍然可以在不同的區域中使用最新的還原點來還原資料庫。 如需詳細資訊,請參閱 概念 - 備份和還原 僅適用於多個區域可用的區域。
異地備援備份 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器備份會複製到遠端區域。 有助於在主伺服器區域關閉時發生災害復原的情況。 此功能目前已在選取的區域啟用。 需要較長的 RTO 和較高的 RPO,視要還原的數據大小和要執行的復原數量而定。
讀取複本 您可以部署跨區域讀取複本,以保護資料庫免於區域層級失敗。 讀取複本會使用PostgreSQL的實體複寫技術以異步方式更新,而且可能會延隔主要複本。 如需詳細資訊,請參閱 概念 - 讀取複本 一般用途和記憶體優化計算層支援。

下表比較一般 工作負載 案例中的 RTO 和 RPO:

功能 高載 一般用途 記憶體最佳化
從備份還原的時間點 保留期間內的任何還原點
RTO - 變化
RPO < 15 分鐘
保留期間內的任何還原點
RTO - 變化
RPO < 15 分鐘
保留期間內的任何還原點
RTO - 變化
RPO < 15 分鐘
從異地複寫備份進行異地還原 RTO - 變化
RPO < 1 h
RTO - 變化
RPO < 1 h
RTO - 變化
RPO < 1 h
讀取複本 RTO - 分鐘*
RPO < 5 分鐘*
RTO - 分鐘*
RPO < 5 分鐘*
RTO - 分鐘*
RPO < 5 分鐘*

* 在某些情況下,RTO 和 RPO 可能更高 ,這取決於月台之間的延遲、要傳輸的數據量,以及重要的主資料庫寫入工作負載。

計劃性停機事件

以下是一些計劃性維護案例。 這些事件通常會造成最多幾分鐘的停機時間,且不會遺失數據。

案例 處理
計算調整 (使用者起始) 在計算調整作業期間,允許使用中的檢查點完成、用戶端連線已清空、取消任何未認可的交易、卸離記憶體,然後關閉。 新的 適用於 PostgreSQL 的 Azure 資料庫 具有相同資料庫伺服器名稱的彈性伺服器實例會使用調整的計算組態布建。 然後,記憶體會附加至新的伺服器,而且資料庫會在必要時開始執行復原,然後再接受用戶端連線。
相應增加記憶體 (使用者起始) 起始相應增加記憶體作業時,允許使用中檢查點完成、用戶端連線已清空,並取消任何未認可的交易。 之後,伺服器會關閉。 記憶體會調整為所需的大小,然後附加至新的伺服器。 在接受客戶端連線之前,會視需要執行復原。 請注意,不支援相應減少記憶體大小。
新軟體部署 (Azure 起始) 新功能推出或 Bug 修正會在服務的計劃性維護期間自動發生,而且您可以排程這些活動何時發生。 如需詳細資訊,請檢查您的 入口網站
次要版本升級 (Azure 起始) 適用於 PostgreSQL 的 Azure 資料庫 會自動將資料庫伺服器修補至 Azure 所決定的次要版本。 這是服務計劃性維護的一部分。 資料庫伺服器會自動以新的次要版本重新啟動。 如需詳細資訊,請參閱 XML 文件。 您也可以檢查入口 網站

當 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器實例設定為高可用性時,服務會先在待命伺服器上執行調整和維護作業。 如需詳細資訊,請參閱 概念 - 高可用性

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

由於基礎硬體故障、網路問題及軟體錯誤等未預期的中斷,可能會發生非計劃性的停機時間。 如果設定高可用性的資料庫伺服器意外關閉,則會啟動待命複本,且用戶端可以繼續其作業。 如果未設定高可用性 (HA),則如果重新啟動嘗試失敗,則會自動布建新的資料庫伺服器。 雖然無法避免非計劃性停機,但 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器可自動執行復原作業來協助減輕停機時間,而不需要人為介入。

雖然我們持續努力提供高可用性,但有時候 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器確實會造成資料庫無法使用,因而影響您的應用程式。 當服務監視偵測的問題會造成廣泛連線錯誤、失敗或效能問題時,服務會自動宣告中斷,以通知您。

服務中斷

在 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器中斷的情況下,您可以在下列位置看到與中斷相關的更多詳細數據:

  • Azure 入口網站 橫幅:如果您的訂用帳戶被識別為受到影響,您的 Azure 入口網站 通知中將會有服務問題的中斷警示。

 Screenshot showing notifications in Azure portal.

  • 說明 + 支援或支援 + 疑難解答:當您從 [說明 + 支援] 或 [支援 + 疑難解答] 建立支援票證時,將會有影響您資源之任何問題的相關信息。 選取 [檢視中斷詳細資料] 以取得詳細資訊和影響摘要。 新增支援要求頁面中也會有警示。

 Screenshot showing Help Support notifications in Azure portal.

  • 服務說明Azure 入口網站 中的 [服務健康情況] 頁面包含全域 Azure 數據中心狀態的相關信息。 在 Azure 入口網站的搜尋列中搜尋「服務健康狀態」,然後在 [作用中事件] 類別中檢視服務問題。 您也可以在 [說明] 功能表下任何資源的 [資源健康情況 ] 頁面中檢視個別資源的健康情況。 服務健康狀態頁面的範例螢幕擷取畫面,其中包含東南亞作用中服務問題的相關資訊。

 Screenshot showing service outage in Service Health portal.

  • 電子郵件通知:如果您已設定警示,當服務中斷影響您的訂用帳戶和資源時,電子郵件通知就會送達。 電子郵件會從「azure-noreply@microsoft.com」送達。 電子郵件的本文開頭為「活動記錄警示...是由 Azure 訂用帳戶的服務問題所觸發...。 如需有關服務健康狀態警示的詳細資訊,請參閱使用 Azure 入口網站在 Azure 服務通知上接收活動記錄警示

重要

顧名思義,PostgreSQL 中的臨時表空間會用於暫存物件,以及其他內部資料庫作業,例如排序。 因此,我們不建議您在臨時表空間中建立用戶架構對象,因為我們不保證伺服器重新啟動、HA 故障轉移等之後這類物件的持久性。

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

以下是一些非計劃性失敗案例和復原程式。

案例 復原程式
[未設定區域備援 HA 的伺服器]
復原程式
[使用區域備援 HA 設定的伺服器]
資料庫伺服器失敗 如果資料庫伺服器關閉,Azure 會嘗試重新啟動資料庫伺服器。 如果失敗,資料庫伺服器將會在另一個實體節點上重新啟動。

復原時間 (RTO) 取決於各種因素,包括錯誤時的活動,例如大型交易,以及資料庫伺服器啟動程式期間要執行的復原量。

使用 PostgreSQL 資料庫的應用程式必須以偵測和重試已卸除的連線和失敗交易的方式建置。
如果偵測到資料庫伺服器失敗,伺服器就會故障轉移至待命伺服器,進而減少停機時間。 如需詳細資訊,請參閱 HA概念頁面。 RTO 預期為 60-120,且數據不會遺失。
儲存體 失敗 應用程式不會看到任何記憶體相關問題的影響,例如磁碟失敗或實體區塊損毀。 當數據儲存在三個複本中時,數據複本會由倖存的記憶體提供。 損毀的數據區塊會自動修復,而且會自動建立新的數據複本。 對於任何罕見且無法復原的錯誤,例如無法存取整個記憶體,適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器實例會故障轉移至待命複本,以減少停機時間。 如需詳細資訊,請參閱 HA概念頁面
邏輯/用戶錯誤 若要從使用者錯誤中復原,例如意外卸除的數據表或不正確的更新數據,您必須執行 時間點復原 (PITR)。 執行還原作業時,您可以指定自定義還原點,也就是錯誤發生前的時間。

如果您想要只還原資料庫或特定數據表的子集,而不是資料庫伺服器中的所有資料庫,您可以在新的實例中還原資料庫伺服器、透過 pg_dump導出數據表,然後使用 pg_restore 將這些數據表還原到您的資料庫。
這些使用者錯誤不會受到高可用性的保護,因為所有變更都會同步復寫到待命複本。 您必須執行時間點還原,才能從這類錯誤中復原。
可用性區域失敗 若要從區域層級失敗中復原,您可以使用備份執行時間點還原,然後選擇具有最新還原時間的自定義還原點來還原最新數據。 新的 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器實例會部署在另一個非受影響的區域中。 還原所花費的時間取決於先前的備份和要復原的事務歷史記錄量。 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器會在 60-120 年代內自動故障轉移至待命伺服器,且數據不會遺失。 如需詳細資訊,請參閱 HA概念頁面
區域失敗 如果您的伺服器已設定異地備援備份,您可以在配對區域中執行異地還原。 新的伺服器將會布建並復原到最後一個複製到此區域的可用數據。

您也可以使用跨區域讀取複本。 如果區域失敗,您可以將讀取複本升階為獨立可寫入伺服器,以執行災害復原作業。 RPO 預期最多為 5 分鐘(可能遺失數據),但當 RPO 在失敗時,RPO 可能會接近複寫延遲的情況除外。
相同的程式。

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

重要

已刪除的伺服器可以還原。 如果您刪除伺服器,您可以依照我們的指引還原已卸除的 Azure 資料庫 - 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器進行復原。 使用 Azure 資源鎖定來協助防止伺服器意外遭到刪除。

下一步