Share via


適用於 MongoDB 的 Azure Cosmos DB 虛擬核心中的可靠性

適用於: MongoDB 虛擬核心

本文包含可用性區域的區域復原和適用於 MongoDB 的 Azure Cosmos DB 虛擬核心的跨區域災害復原和商務持續性的詳細資訊。

有關 Azure 可靠性的結構概觀,請參閱 Azure 可靠性

可用性區域支援

Azure 可用性區域是每個 Azure 區域內至少三個實體上獨立的資料中心群組。 每個區域內的資料中心都配備了獨立的電源、冷卻和網路基礎結構。 可用性區域的作用是在一個區域受影響時 (例如本機區域失敗時),讓其餘兩個區域支援區域服務、容量和高可用性。

這類失敗的範圍可從軟體和硬體故障,擴及到如地震、淹水和火災的事件。 Azure 服務的備援和邏輯隔離功能可以容錯。 如需深入了解 Azure 的可用性區域,請參閱區域和可用性區域

已啟用 Azure 可用性區域的服務是設計來提供正確的可靠性和彈性層級。 您可以透過兩種方式加以設定。 可採用區域備援 (可跨區域自動複寫) 或分區 (將執行個體釘選在特定區域)。 兩種方法可以結合使用。 如需區域與區域備援結構的詳細資訊,請參閱使用可用性分區和區域的建議

若要取得可用性區域支援,您必須啟用高可用性 (HA)。

HA 可藉由維護叢集中每個分區的待命複本來避免資料庫停機。 如果分區關閉,Azure Cosmos DB for MongoDB 虛擬核心會將來自失敗分區的連入連線切換至其待命複本。

在支援可用性區域的區域中啟用HA時,HA 複本分區會布建在與其主要分區不同的可用性區域中。 除非主要分區失敗,否則HA複本不會接收來自用戶端的要求。

如果 HA 已停用,則每個分區都有自己的本地備援記憶體 (LRS),且有三個同步複本由 Azure 儲存體 服務維護。 如果單一複本失敗,Azure 儲存體 服務會偵測到失敗,並透明地重新建立相關數據。 如需 LRS 記憶體持久性,請參閱 備援選項摘要。 不過,在發生區域失敗時,您會執行大量停機時間和可能遺失數據的風險。

必要條件

您必須在下列區域中建立適用於 MongoDB 的 Azure Cosmos DB 虛擬核心叢集:

  • 澳大利亞東部
  • 東南亞
  • 加拿大中部
  • 歐洲北部
  • 英國南部
  • 西歐
  • 美國中部
  • 美國東部
  • 美國東部 2
  • 美國中南部
  • 美國西部 2

建立已啟用可用性區域的資源

若要啟用可用性區域,您必須在建立叢集時或在 Azure 入口網站 中現有叢集的 [調整] 區段中啟用高可用性 (HA)。

跨區域災害復原和商務持續性

災害復原 (DR)是指從重大影響事件中復原,例如自然災害或不成功的部署 (導致停機和資料遺失)。 無論原因為何,解決災害的最佳辦法是定義完善且經過測試的 DR 方案,以及主動支援 DR 的應用程式設計。 開始制定災害復原方案之前,請參閱設計災害復原策略的建議

Microsoft 在災害復原方面,採取共同責任模型。 在共同責任模型中,Microsoft 確保基準基礎結構和平台服務可供使用。 此時許多 Azure 服務不會自動複寫資料,或從故障區域恢復並交叉複寫到另一個已啟用的區域。 您需要為這些服務制定適合您工作負載的災害復原方案。 在 Azure 平台即服務 (PaaS) 供應項目上執行的多數服務,都有提供支援災害復原的功能和指導,您可以使用特定服務功能快速復原,制定災害復原方案。

Azure Cosmos DB for MongoDB 虛擬核心不提供內建的自動容錯移轉或災害復原。 隨著解決方案的擴展,高可用性規劃是關鍵的一步。

單一區域地理位置的災害復原

為了充分發揮您的執行時間,請事先規劃以維護商務持續性,並使用 Azure Cosmos DB for MongoDB 虛擬核心做好災害復原的準備。

雖然 Azure 服務的設計目的是將運行時間最大化,但仍可能發生非計劃性的服務中斷。 災害復原計劃可確保您已安排相應策略來處理區域服務中斷。

Azure Cosmos DB for MongoDB 虛擬核心會自動地定期備份您的資料。 自動備份的進行不會影響資料庫作業的效能或可用性。 所有備份都是在背景自動執行,並與來源資料分開儲存於儲存體服務中。 不小心刪除或修改資源,且稍後需要原始版本時,這些自動備份就可派上用場。

根據叢集目前為使用中或最近遭刪除,自動備份會以各種間隔進行保留。

保留期限
使用中叢集 35
遭刪除叢集 7

高可用性設計

應針對執行生產工作負載的關鍵 Azure Cosmos DB for MongoDB 虛擬核心叢集啟用高可用性 (HA)。 在啟用 HA 的叢集中,每個分區都會充當主分區,並在另一個可用性區域中配置一個熱待命分區。 主要和次要分區之間的復寫會預設為同步。 在收到資料庫回應之前,對資料庫的任何修改都會保留在主要分區和次要分區 (熱待命) 上。

此服務會維護叢集各主要分區和次要分區的健康情況檢查和活動訊號。 如果主要分區因為區域或區域中斷而無法使用,則次要分區會自動提升為新的主要分區,並為新的主要分區建置後續的次要分區。 此外,如果次要分區變成無法使用,服務會自動建立新的次要分區,其中包含來自主要分區的完整資料複本。

如果服務觸發從主要分區到次要分區的容錯移轉,連線將在幕後無縫路由到新的主分區。

主要分區和次要分區之間的同步複寫可確保發生容錯移轉時不會遺失資料。

下一步