適用於 NoSQL 的 Azure Cosmos DB 中的高可用性 （可靠性）
本文說明適用於 NoSQL 的 Azure Cosmos DB 中的高可用性（可靠性）支援，並涵蓋 可用性區域，以及 跨區域災害復原和商務持續性。
可用性區域支援
Azure 可用性區域是每個 Azure 區域內至少三個實體獨立的資料中心群組。 每個區域內的資料中心都配備了獨立的電源、冷卻系統和網路基礎結構。 在本機區域失敗的案例中，可用性區域的設計在於，當一個區域受影響時，讓其餘兩個區域支援區域服務、容量和高可用性。
這類失敗的範圍可從軟體和硬體故障，擴及到如地震、淹水和火災的事件。 透過 Azure 服務的備援和邏輯隔離，實現對失敗的容錯。 如需深入了解 Azure 的可用性區域，請參閱區域和可用性區域。
已啟用 Azure 可用性區域的服務旨在提供正確程度的可靠性和彈性。 您可以透過兩種方式加以設定。 它們可以是區域備援，具有跨區域自動複寫功能，或者是區域性的，將執行個體釘選在特定區域。 兩種方法可以結合使用。 如需深入了解區域和區域備援結構，請參閱使用可用性區域和區域的建議。
Azure Cosmos DB 是多租用戶服務，能夠以透明的方式管理個別計算節點的所有詳細資料。 您不必擔心任何類型的修補或計劃性維護。 Azure Cosmos DB 可透過系統執行的所有自動維護作業來保證可用性的 SLA 和 P99 延遲。
Azure Cosmos DB 供應專案：
個別節點中斷復原。 Azure Cosmos DB 藉由保證帳戶在四個復本仲裁內，在每個 Azure 區域中至少有三個數據複本，來自動降低 複 本中斷。 這項保證可讓個別節點中斷的 RTO 為 0 及 RPO 為 0，且不需要變更或設定應用程式。
區域中斷復原能力。 當您使用 可用性區域部署 Azure Cosmos DB 帳戶時，Azure Cosmos DB 會提供 0 的 RTO 和 0 的 RPO，即使在區域中斷時也是如此。 如需 RTO 的資訊，請參閱 復原目標。
啟用可用性區域后，適用於 NoSQL 的 Azure Cosmos DB 支援 區域備援 設定。
必要條件
使用可用性區域的影響
可用性區域對適用於 NoSQL 資料庫的 Cosmos DB 高可用性的影響取決於帳戶的一致性層級，以及已啟用可用性區域的區域。 在許多情況下，如果帳戶是多重區域，可用性區域不會增加值或新增最小值（除非設定強式一致性）。
請參閱下表，以評估在目前帳戶設定中使用可用性區域的影響：
| 帳戶一致性層級 | 已啟用可用性區域的區域 | 使用可用性區域的影響 |
|---|---|---|
| 異步 （限定過期或較弱） | 任何數目的次要讀取區域。 | 提供最小值，因為 SDK 已在讀取區域失敗時提供讀取的無縫重新導向。 |
| 同步 （強） | 兩個或多個次要讀取區域 | 提供臨界值，因為系統可以利用動態仲裁，如果讀取區域失去可用性，允許寫入繼續。 |
| 同步 （強） | 一個次要讀取區域 | 提供更大的值，因為此案例中的讀取區域遺失可能會影響寫入可用性。 |
| 全部 | 寫入區域和任意數目的次要區域 | 確保區域性失敗的寫入作業可用性更高。 |
| 全部 | 單一區域 | 單一區域無法受益於多重區域故障轉移功能。 使用可用性區域可防範因區域性失敗而導致的總可用性遺失。 |
SLA 改善項目
由於可用性區域在實體上是分開的，而且提供不同的電源、網路和冷卻，因此可用性 SLA（服務等級協定）比單一區域 （99.99%） 的帳戶更高（99.99%）。 啟用可用性區域的區域會以 25% 的進階付費，而沒有可用性區域的區域則不會產生進階費用。 此外，針對設定多重區域寫入的帳戶和/或以自動調整模式設定的集合，會免除可用性區域的進階定價。
將額外的區域新增至 Cosmos DB 帳戶通常會將現有帳單增加 100%（加總不會乘以遞增），但跨區域的成本差異很小。 如需詳細資訊，請參閱 定價頁面。
啟用 AZ， 新增其他區域或開啟多重區域寫入可以視為一種分層方法，以在方法的每個步驟中增加給定 Cosmos DB 帳戶的復原性和可用性 -- 從單一區域無 AZ 組態的 4 9 可用性，到 4 和 9 的 AZ，一路到啟用多重區域寫入選項的多區域設定 5 9 的可用性。 如需每個設定的SLA 摘要，請參閱下表。
| KPI | 沒有可用性區域的單一區域寫入 | 具有可用性區域的單一區域寫入 | 沒有可用性區域的多區域、單一區域寫入 | 具有可用性區域的多區域、單一區域寫入 | 具有或沒有可用性區域的多區域寫入 |
|---|---|---|---|---|---|
| 寫入可用性 SLA | 99.99% | 99.995% | 99.99% | 99.995% | 99.999% |
| 讀取可用性 SLA | 99.99% | 99.995% | 99.999% | 99.999% | 99.999% |
| 區域失敗：資料遺失 | 資料遺失 | [無資料遺失] | [無資料遺失] | [無資料遺失] | [無資料遺失] |
| 區域失敗：可用性 | 可用性遺失 | 沒有可用性遺失 | 沒有可用性遺失 | 沒有可用性遺失 | 沒有可用性遺失 |
| 區域中斷：資料遺失 | 資料遺失 | 資料遺失 | 相依於一致性層級。 如需詳細資訊，請參閱一致性、可用性和效能權衡。 | 相依於一致性層級。 如需詳細資訊，請參閱一致性、可用性和效能權衡。 | 相依於一致性層級。 如需詳細資訊，請參閱一致性、可用性和效能權衡。 |
| 區域中斷：可用性 | 可用性遺失 | 可用性遺失 | 讀取區域失敗不會遺失可用性，寫入區域失敗是暫時的 | 讀取區域失敗不會遺失可用性，寫入區域失敗是暫時的 | 受影響區域中沒有讀取可用性遺失、暫時寫入可用性遺失 |
| 價格 (1) | 不適用 | 已佈建的 RU/秒 x 1.25 費率 | 已佈建的 RU/秒 x N 個區域 | 已佈建的 RU/秒 x 1.25 費率 x N 個區域 (2) | 多區域寫入費率 x N 個區域 |
1 對於無伺服器帳戶，RU 會乘以係數 1.25。
2 1.25 費率僅適用於啟用可用性區域的區域。
建立已啟用可用性區域的資源
只有在您將新區域新增至 Azure Cosmos DB NoSQL 帳戶時，才能設定可用性區域。
若要啟用可用性區域支援，您可以使用：
移轉至可用性區域支援
若要瞭解如何將 Cosmos DB 帳戶移轉至可用性區域支援，請參閱 將適用於 NoSQL 的 Azure Cosmos DB 遷移至可用性區域支援）。
跨區域災害復原和商務持續性
災害復原 (DR)是指從重大影響事件中復原，例如自然災害或不成功的部署 (導致停機和資料遺失)。 無論原因為何，解決災害的最佳辦法是定義完善且經過測試的 DR 方案，以及主動支援 DR 的應用程式設計。 開始思考建立災害復原方案之前，請參閱設計災害復原策略的建議。
Microsoft 在災害復原方面採取共同責任模型。 在共同責任模型中，Microsoft 確保基準基礎結構和平台服務可供使用。 此時，許多 Azure 服務不會自動複寫資料，或從失敗區域回復為交叉複寫到另一個已啟用的區域。 您需要為這些服務制定適合工作負載的災害復原方案。 大多數在 Azure 平台即服務 (PaaS) 供應項目執行的服務，皆提供支援災害復原的功能和指導，您可以使用支援快速復原的特定服務功能來開發災害復原方案。
區域中斷是指 Azure 區域的所有可用性區域中，發生影響所有 Azure Cosmos DB 節點的中斷。 在罕見的區域中斷案例中，您可以設定 Azure Cosmos DB 來支援各種持久性和可用性結果。
持久性
當 Azure Cosmos DB 帳戶部署在單一區域時，通常不會遺失任何資料。 在受影響區域中復原 Azure Cosmos DB 服務之後，資料存取就可還原。 僅在 Azure Cosmos DB 區域發生無法復原的災害時，才可能發生資料遺失。
為了協助您防止因區域中重大災害而導致完整資料遺失，Azure Cosmos DB 提供兩種不同的備份模式：
- 連續備份會每隔 100 秒備份一次每個區域。 其可讓您以 1 秒的資料粒度，將資料還原到任何時間點。 在每個區域中，備份皆會依存於該區域中所認可的資料。 如果區域已啟用可用性區域，則備份會儲存在區域備援記憶體帳戶中。
- 定期備份會從您帳戶下的所有容器中對所有分割區進行完整備份，但不會跨分割區進行同步。 最小備份間隔為 1 小時。
若在多個區域中部署 Azure Cosmos DB 帳戶，則資料持久性取決於帳戶上所設定的一致性層級。 下表詳細說明，當 Azure Cosmos DB 帳戶部署在至少兩個區域中時，所有一致性層級的 RPO。
| 一致性層級 | 區域中斷的 RPO |
|---|---|
| 工作階段、開頭一致、最終 | 少於 15 分鐘 |
| 限定過期 | K 和 T |
| 強式 | 0 |
K = 項目的版本數目 (也就是更新次數)。
T = 自上次更新後的時間間隔。
針對多區域帳戶，K 和 T 的最小值為 100,000 個寫入作業或 300 秒。 此值會定義使用限定過期時資料的最小 RPO。
如需一致性層級差異的詳細資訊，請參閱 Azure Cosmos DB 中的一致性層級。
服務受控故障轉移
如果您的解決方案需要在區域中斷期間持續提供可用時間，您可以設定 Azure Cosmos DB 在多區域中複寫資料，並在需要時以透明方式容錯移轉到操作區域。
單一區域帳戶在區域性中斷后可能會失去輔助功能。 為了確保一直保持商務持續性，建議您使用單一寫入區域和至少一秒（讀取）區域來設定 Azure Cosmos DB 帳戶，並啟用服務管理的故障轉移。
服務管理的故障轉移可讓 Azure Cosmos DB 故障轉移多區域帳戶的寫入區域，以因數據遺失而保留商務持續性，如持久性一節稍早所述。 在 Azure Cosmos DB 用戶端中偵測並處理區域容錯移轉。 這些容錯移轉不須對應用程式進行任何變更。 如需如何啟用多個讀取區域和服務管理容錯移轉的指示，請參閱使用 Azure 入口網站管理 Azure Cosmos DB 帳戶。
重要
如果您已選擇具有多個讀取區域的單一區域寫入設定，強烈建議您設定用於生產工作負載的 Azure Cosmos DB 帳戶，以啟用服務管理容錯移轉。 此設定可讓 Azure Cosmos DB 將帳戶資料庫容錯移轉至可用的區域。 在沒有此設定的情況下，帳戶將會在寫入區域中斷的所有持續時間內發生寫入可用性遺失的情況。 手動容錯移轉不會成功，因為缺乏區域連線。
警告
即使已啟用服務管理容錯移轉，部分中斷仍可能需要 Azure Cosmos DB 服務小組手動介入。 在這些案例中，容錯移轉最多可能需要1小時 (或更多時間) 才會生效。 為了在部分中斷期間提供更好的寫入可用性，除了服務管理容錯移轉之外，建議啟用可用性區域。
多重寫入區域
您可以設定 Azure Cosmos DB 來接受多個區域中的寫入。 此設定對於減少地理分散式應用程式中的寫入延遲很有用。
當 Azure Cosmos DB 帳戶已設定多重寫入區域時，不支援強式一致性且可能會發生寫入衝突。 如需有關如何解決這些衝突的詳細資訊，請參閱使用多個寫入區域時的衝突類型和解決原則。
重要
經常更新相同的文件標識碼 (或經常在 TTL 或刪除之後重新建立相同的文件標識碼)，將會因系統中產生的衝突數目增加而影響複寫效能。
衝突解決區域
當 Azure Cosmos DB 帳戶已設定多重區域寫入時，其中一個區域將在寫入衝突時作為仲裁程式。
多區域寫入的最佳做法
以下是寫入多個區域時要考慮的一些最佳做法。
在本機流量保留在本機
當您使用多區域寫入時，應用程式應該將源自本機區域的讀取和寫入流量嚴格地發送到本機 Cosmos DB 區域。 為獲得最佳效能，請避免進行跨區域呼叫。
請務必避免下列反模式，將應用程式的衝突降到最低：
將相同的寫入作業傳送至所有區域，以增加快速回應時間的機率
根據每個要求隨機判斷讀取或寫入作業的目標區域
使用迴圈配置資源原則來判斷每個要求讀取或寫入作業的目標區域。
避免與復寫延遲產生相依性
您無法針對多區域寫入帳戶設定強式一致性。 寫入的目的地區域會在 Azure Cosmos DB 在本機複寫資料後立即回應，同時以非同步方式全域複寫資料。
雖然不常發生，但當您進行異地資料復寫時，複寫延遲可能會發生在一個或幾個分割區上。 復寫延遲可能會因為網路流量中罕見的暫時變化，或衝突解決率高於平時而發生。
例如，應用程式寫入區域 A 但從區域 B 讀取的架構，會在兩個區域之間引入復寫延遲的相依性。 不過，如果應用程式讀取和寫入相同區域，即使存在復寫延遲，效能仍可保持不變。
評估寫入作業的工作階段一致性用法
在工作階段一致性中，您會使用工作階段權杖來進行讀取和寫入作業。
針對讀取作業，Azure Cosmos DB 會將快取的工作階段權杖傳送至伺服器，並保證接收對應至指定 (或較新) 工作階段權杖的資料。
針對寫入作業，Azure Cosmos DB 會將工作階段權杖傳送至資料庫，並保證只有在伺服器已趕上提供的工作階段權杖時，才保存資料。 在單一區域寫入帳戶中，絕對可保證寫入區域已趕上工作階段權杖。 不過，在多區域寫入帳戶中，您寫入的區域可能會尚未趕上另一個區域發出的寫入作業。 如果用戶端透過來自區域 B 的工作階段權杖寫入區域 A，則在區域 A 趕上區域 B 中所做的變更之前，其無法儲存資料。
當您在用戶端執行個體之間傳遞工作階段權杖時，最好只針對讀取作業使用工作階段權杖，而不在寫入作業中使用。
降低相同文件的快速更新次數
當相同文件重複更新時，為解決或確認沒有衝突的伺服器更新可能會與應用程式觸發的寫入發生衝突。 快速地持續重複更新相同文件會在衝突解決期間經歷更高的延遲。
雖然重複更新相同文件的突發狀況無法避免，但您可以考慮探索這樣的結構：當穩定狀態流量在較長期間內看到相同文件的快速更新時，改為建立新文件。
讀取和寫入中斷
在還原服務之前，單一區域帳戶的用戶端將遇到讀取和寫入可用性遺失的狀況。
多區域帳戶會根據下列設定和中斷類型，而經歷不同的行為。
| 組態 | Outage | 可用性影響 | 持久性影響 | 解決方式 |
|---|---|---|---|---|
| 單一寫入區域 | 讀取區域中斷 | 所有用戶端都會自動將讀取重新導向至其他區域。 所有設定都不會遺失讀取或寫入可用性。 例外狀況是兩個區域具有強式一致性的設定，這會在還原服務之前失去寫入可用性。 或者，如果您啟用服務管理容錯移轉，服務會將區域標示為失敗，並發生容錯移轉。 | 無資料遺失。 | 在中斷期間，請確保其餘的區域中有足夠的佈建要求單位 (RU) 以支援讀取流量。 當中斷結束時，請視情況重新調整已佈建的 RU。 |
| 單一寫入區域 | 寫入區域中斷 | 用戶端會將讀取重新導向至其他區域。 如果沒有服務管理容錯移轉，用戶端會遇到寫入可用性遺失的情況。 中斷結束時會自動還原寫入可用性。 若使用服務管理容錯移轉，在服務設法容錯移轉至您選取的新寫入區域之前，用戶端會遇到寫入可用性遺失的情況。 |
如果您未選取強式一致性層級，服務可能不會將某些資料復寫到剩餘的作用中區域。 此複寫取決於您選取的一致性層級 。 如果受影響區域遭受永久性資料遺失，您可能會失去未複寫的資料。 | 在中斷期間，請確保其餘的區域中有足夠的佈建 RU 以支援讀取流量。 「請勿」在中斷期間觸發手動容錯移轉，因為不會成功。 當中斷結束時，請視情況重新調整已佈建的 RU。 使用 NoSQL API 的帳戶，也可以從衝突摘要復原失敗區域中未複寫的資料。 |
| 多重寫入區域 | 任何區域中斷 | 可能會發生暫時的寫入可用性遺失，這類似於使用服務管理容錯移轉的單一寫入區域。 如果在中斷時發生大量的衝突寫入，則衝突解決區域的容錯移轉也可能導致寫入可用性遺失。 | 取決於選取的一致性層級，最近在失敗區域中更新的資料可能無法在其餘的使用中區域中使用。 如果受影響區域遭受永久性資料遺失，您可能會失去未複寫的資料。 | 在中斷期間，請確保其餘的區域中有足夠的佈建 RU 以支援更多流量。 當中斷結束時，您可以視情況重新調整已佈建的 RU。 可能的話，Azure Cosmos DB 會自動復原失敗區域中未複製的資料。 此自動復原使用的衝突解決方法是您為使用 NoSQL API 的帳戶所設定的方法。 對於使用其他 API 的帳戶，此自動復原會使用最後寫入者優先。 |
讀取區域中斷的其他資訊
受影響的區域已中斷連線並標示為離線。 Azure Cosmos DB SDK 會將讀取呼叫重新導向至慣用的區域清單中的下一個可用區域。
如果慣用區域清單中的區域都無法使用，呼叫會自動切換回目前的寫入區域。
不需要對應用程式的程式碼做任何變更來處理讀取區域中斷。 受影響的讀取區域重新上線時，便會與目前的寫入區域同步，並在進度完全趕上之後再次處理讀取要求。
無須對您應用程式的程式碼進行任何變更，後續的讀取就會重新導向到已復原的區域。 在容錯移轉及重新加入先前失敗的區域期間，Azure Cosmos DB 會繼續遵守讀取一致性保證。
如果您的多區域 Azure Cosmos DB 帳戶設定為強式一致性，則即使在 Azure 寫入區域永久無法復原的罕見不幸情況下，資料也不會遺失。 多區域 Azure Cosmos DB 帳戶具有先前持久性區段中指定的持久性特性。
寫入區域中斷的其他資訊
在寫入區域中斷期間，當 Azure Cosmos DB 帳戶上已設定服務管理容錯移轉時，Azure Cosmos DB 帳戶會將次要區域升級為新的主要寫入區域。 容錯移轉會依您指定的區域優先順序，在另一個區域進行容錯移轉。
來源或目的地區域發生中斷時，不應觸發手動容錯移轉，而且也不會成功。 原因是容錯移轉程程序包含一致性檢查，而這需要區域之間的連線。
當先前受影響的區域重新上線時，任何在此區域失敗時未複寫的寫入資料都將透過衝突摘要提供。 應用程式可以讀取衝突摘要，根據應用程式的特定邏輯解決衝突，再視情況將更新後的資料寫回 Azure Cosmos DB 容器。
在先前受影響的寫入區域復原之後，其會在 Azure 入口網站中顯示為「線上」，並可作為讀取區域使用。 此時，使用 [PowerShell、Azure CLI 或 Azure 入口網站]（/azure/cosmos-db/how-to-manage-database-account#perform-manual-failover-on-an-azure-cosmos-db-account-on-an-azure-cosmos-db-account，切換回復原的區域是安全的。 在您切換寫入區域之前、期間或之後，不會有任何資料或可用性遺失。 應用程式可繼續保有高可用性。
警告
如果寫入區域中斷，Azure Cosmos DB 帳戶會透過服務管理容錯移轉將次要區域升級為新的主要寫入區域，原始寫入區域將不會在復原後自動升級回寫入區域。 您必須使用 PowerShell、Azure CLI 或 Azure 入口網站切換回復原的區域來作為寫入區域 (在可安全執行此動作後，如上述所述)。
中斷偵測、通知及管理
若是單一區域帳戶，用戶端會在 Azure Cosmos DB 區域中斷期間發生讀取和寫入可用性遺失的情況。 多區域帳戶會遇到不同的行為，如下表所述。
| 寫入區域 | 服務管理容錯移轉 | 預期的情況 | 解決方式 |
|---|---|---|---|
| 單一寫入區域 | 未啟用 | 如果在不使用強式一致性的情況下讀取區域發生中斷，所有用戶端都會重新導向至其他區域。 讀取或寫入可用性不會遺失，資料也不會遺失。 當您使用強式一致性時，如果保留少於兩個讀取區域，則讀取區域中的中斷可能會影響寫入可用性。 如果寫入區域發生中斷，用戶端將遇到寫入可用性遺失的情況。 如果您未選取強式一致性，服務可能不會將某些資料復寫到剩餘的作用中區域。 此複寫取決於選取的一致性層級。 如果受影響區域遭受永久性資料遺失，您可能會失去未複寫的資料。 Azure Cosmos DB 會在中斷結束時還原寫入可用性。 |
在中斷期間，請確保其餘的區域中有足夠的佈建 RU 以支援讀取流量。 「請勿」在中斷期間觸發手動容錯移轉，因為不會成功。 當中斷結束時，請視情況重新調整已佈建的 RU。 |
| 單一寫入區域 | 已啟用 | 如果在不使用強式一致性的情況下讀取區域發生中斷，所有用戶端都會重新導向至其他區域。 讀取或寫入可用性不會遺失，資料也不會遺失。 當您使用強式一致性時，如果保留少於兩個讀取區域，讀取區域的中斷可能會影響寫入可用性。 如果寫入區域發生中斷，用戶端將遇到寫入可用性遺失的情況，直到 Azure Cosmos DB 根據您的偏好設定，選擇新的區域作為新的寫入區域為止。 如果您未選取強式一致性，服務可能不會將某些資料復寫到剩餘的作用中區域。 此複寫取決於選取的一致性層級。 如果受影響區域遭受永久性資料遺失，您可能會失去未複寫的資料。 |
在中斷期間，請確保其餘的區域中有足夠的佈建 RU 以支援讀取流量。 「請勿」在中斷期間觸發手動容錯移轉，因為不會成功。 中斷結束時，您可以將寫入區域移回原始區域，並視情況重新調整已佈建的 RU。 使用 NoSQL API 的帳戶，也可以從衝突摘要復原失敗區域中未複寫的資料。 |
| 多重寫入區域 | 不適用 | 最近在失敗區域中更新的資料可能無法在其餘的使用中區域中使用。 最終、開頭一致和工作階段一致性層級可保證過期時間低於 15 分鐘。 根據設定的不同，限定過期保證少於 K 次更新或 T 秒。 如果受影響區域遭受永久性資料遺失，您可能會失去未複寫的資料。 | 在中斷期間，請確保其餘的區域中有足夠的佈建 RU 以支援更多流量。 當中斷結束時，您可以視情況重新調整已佈建的 RU。 可能的話，Azure Cosmos DB 會復原失敗區域中未複製的資料。 此復原使用的衝突解決方法是您為使用 NoSQL API 的帳戶所設定的方法。 對於使用其他 API 的帳戶，此復原會使用最後寫入者優先。 |
測試高可用性
即使您的 Azure Cosmos DB 帳戶具有高可用性，您的應用程式也可能無法正確設計以維持高可用性。 若要在應用程式測試或災害復原 (DR) 演練期間，測試應用程式的端對端高可用性，請暫時停用帳戶的服務管理容錯移轉。 使用 PowerShell、Azure CLI 或 Azure 入口網站叫用手動容錯移轉，然後監視您的應用程式。 完成測試之後，您可以容錯移轉到主要區域，並還原帳戶的服務管理容錯移轉。
重要
請勿在來源或目的地區域的 Azure Cosmos DB 中斷期間叫用手動容錯移轉。 手動容錯移轉需要區域連線來維護資料一致性，因此不會成功。