使用 Azure Cosmos DB 達成高可用性
適用於：
NoSQL MongoDB Cassandra Gremlin Table
若要建置高可用性的解決方案，您必須評估其所有元件的可靠性特性。 Azure Cosmos DB 會提供功能和設定選項來協助您的解決方案達到高可用性。
本文使用下列字詞：
- 復原時間目標 (RTO)：中斷開始影響 Azure Cosmos DB 到復原至完全可用之間的時間。
- 復原點目標 (RPO)：最後一次正確還原的寫入到中斷開始影響 Azure Cosmos DB 之間的時間。
注意
預期和最大的 RPO 和 RTO 取決於 Azure Cosmos DB 所經歷的中斷類型。 例如，單一節點中斷的預期 RTO 和 RPO 會與整個區域中斷的情況不同。
本文詳述可能會影響 Azure Cosmos DB 可用性的事件，以及對應的 Azure Cosmos DB 設定選項。
複本維護
Azure Cosmos DB 是多租用戶服務，能夠以透明的方式管理個別計算節點的所有詳細資料。 使用者不必擔心任何類型的修補和計劃性維護。 Azure Cosmos DB 可透過系統執行的所有自動維護作業來保證可用性的 SLA 和 P99 延遲。
複本中斷
複本中斷是指部署在 Azure 區域的 Azure Cosmos DB 叢集中發生個別節點的中斷。
Azure Cosmos DB 保證在四個複本仲裁內帳戶的每個 Azure 區域中務必至少有三個資料複本，以自動緩解複本中斷。 這項保證可讓個別節點中斷的 RTO 為 0 及 RPO 為 0，且不需要變更或設定應用程式。
在許多 Azure 區域中，您可以將 Azure Cosmos DB 叢集分散到可用性區域。 可用性區域可提高 SLA，因為其在實體上是分開的，可提供不同的電源、網路和冷卻。 當您使用可用性區域部署 Azure Cosmos DB 帳戶時，Azure Cosmos DB 可提供 RTO = 0 和 RPO = 0，即使在區域中斷中也是如此。
在單一 Azure 區域中部署時，無需額外的使用者輸入，Azure Cosmos DB 可在節點中斷時復原。 啟用跨可用性區域的備援，可讓 Azure Cosmos DB 復原區域中斷，但代價是增加費用。
只有在您將新區域新增至 Azure Cosmos DB 帳戶時，才能設定區域備援。 針對現有的區域，您可以透過移除區域，然後在啟用區域備援的情況下將其重新增加來啟用區域備援。 針對單一區域帳戶，此方法會要求您新增用於暫時容錯移轉的區域，然後移除並新增已啟用區域備援的所需區域。
Azure Cosmos DB 帳戶依預設不會使用多個可用性區域。 您可以透過以下方式啟用跨多個可用性區域的部署：
如果您的 Azure Cosmos DB 帳戶分散在 N 個 Azure 區域中，則所有資料會有 N x 4 個複本。 如需有關 Azure Cosmos DB 如何在每個區域中複寫資料的詳細資料，請參閱Azure Cosmos DB 的全域散發。 在兩個以上的區域擁有 Azure Cosmos DB 帳戶可以提高應用程式的可用性，並在相關的區域之間提供低延遲。
區域中斷
區域中斷是指 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 帳戶會透過服務管理容錯移轉將次要區域升級為新的主要寫入區域，原始寫入區域將不會在復原後自動升級回寫入區域。 您必須使用 PowerShell、Azure CLI 或 Azure 入口網站切換回復原的區域來作為寫入區域 (在可安全執行此動作後，如上述所述)。
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 SDK 的預期行為，以及影響其的設定。
若要確保高寫入和讀取可用性，請將 Azure Cosmos DB 帳戶設定為至少跨越兩個區域 (若使用強式一致性，則設定為至少跨越三個區域)。 若要深入了解，請參閱教學課程：使用 API for NoSQL 來設定 Azure Cosmos DB 全域散發。
針對使用單一寫入區域設定的多區域 Azure Cosmos DB 帳戶，請使用 Azure CLI 或 Azure 入口網站來啟用服務管理容錯移轉。 啟用服務管理容錯移轉後，無論何時發生區域性災害，Azure Cosmos DB 都會對您的帳戶進行容錯移轉，而不需任何使用者輸入。
即使您的 Azure Cosmos DB 帳戶具有高可用性，您的應用程式也可能無法正確設計以維持高可用性。 若要在應用程式測試或災害復原 (DR) 演練期間，測試應用程式的端對端高可用性，請暫時停用帳戶的服務管理容錯移轉。 使用 PowerShell、Azure CLI 或 Azure 入口網站叫用手動容錯移轉，然後監視您的應用程式。 完成測試之後，您可以容錯移轉到主要區域，並還原帳戶的服務管理容錯移轉。
重要
請勿在來源或目的地區域的 Azure Cosmos DB 中斷期間叫用手動容錯移轉。 手動容錯移轉需要區域連線來維護資料一致性，因此不會成功。
在全域分散式資料庫環境內，當發生全區域中斷情況時，一致性層級與資料持久性之間具有直接關聯性。 當您開發商務持續性計劃時，您必須了解應用程式在干擾性事件之後完全復原所需的最大可接受時間 (也就是 RTO)。 您也必須了解在干擾性事件之後復原時，應用程式可忍受遺失最近資料更新的期間上限 (也就是 RPO)。 如需有關 RTO 和 RPO 的詳細資訊，請參閱 Azure Cosmos DB 中的一致性層級。
Azure Cosmos DB 區域中斷期間的預期情況
若是單一區域帳戶，用戶端會在 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 的帳戶，此復原會使用最後寫入者優先。 |
下一步
接下來，您可以閱讀下列文章：