Azure Managed Instance for Apache Cassandra 是純開放原始碼 Apache Cassandra 叢集的完全受控服務。 服務允許根據每個工作負載的需求來改寫設定，以在需要的時候提供最大的彈性和控制。
Apache Cassandra 是建置高度彈性應用程式的絕佳選擇，因為它的分散式本質和點對點架構。 資料庫中的任何節點都可以提供與任何其他節點相同的功能。 此設計有助於 Cassandra 的強固性和復原能力。 本文提供如何優化高可用性以及如何處理災害復原的秘訣。
恢復點目標和復原時間目標
只要您有下列元素，恢復點目標 （RPO） 和復原時間目標 （RTO） 通常都很低，接近零：
- 具有跨區域複寫的多區域部署，以及複寫因數 3。
- 已啟用可用性區域。 當您在 Azure 入口網站或 使用 Azure CLI 建立叢集時，請設定此選項。
- 已在用戶端驅動程式中使用負載平衡原則設定應用程式層級容錯移轉，或已使用 Azure 流量管理員/Azure Front Door 設定負載平衡層級容錯移轉。
RTO 是您中斷的時間長度。 由於叢集在可用性區域和區域之間具有復原性，因此很低。 此外，Apache Cassandra 本身是一個點對點的系統，具有高度的容錯能力，所有節點預設都可以進行寫入操作。
RPO 是您中斷時可能會遺失的資料數量。 之所以較低，是因為數據在所有節點和數據中心之間同步。 中斷中的數據遺失將會是最少的。
附註
根據CAP定理，不可能同時達成 RTO=0 和 RPO=0。 評估一致性與可用性或最佳效能之間的取捨。
每個應用程式的平衡顯示會不同。 例如，如果您的應用程式的讀取量很大，最好處理跨區域寫入增加的延遲，以避免資料遺失，這樣做有助於維持一致性。 如果應用程式以大量寫入為主，且對延遲有嚴苛要求，那麼在主要地區中斷中遺失部分最新寫入資料的風險可能是可以接受的，這有利於提高可用性。
可用性區域
Cassandra 的點對點架構內建容錯功能。 Azure Managed Instance for Apache Cassandra 提供所選區域中的可用性區域支援。 此支援可增強基礎結構層級的復原能力。 對於 3 的復寫因數，可用性區域支援可確保每個複本都位於不同的可用性區域中。 這種方法可防止區域性中斷影響您的資料庫或應用程式。 建議您儘可能啟用可用性區域。
多區域備援
Cassandra 的架構，加上 Azure 可用性區域的支援，提供了容錯和復原的能力。 也請考慮應用程式區域中斷的影響。 為了防範區域層級中斷，強烈建議部署 多個區域叢集。 雖然不常發生，但潛在的影響很嚴重。
針對商務持續性，使用多個區域資料庫並不夠。 應用程式的其他部分也需要被分散，或具有適當的故障轉移機制。 如果您的使用者分散到許多地理位置，則資料庫的多個區域數據中心部署具有降低延遲的新增優點。 叢集中所有數據中心的所有節點都可以從最接近它們的區域提供讀取和寫入。
如果應用程式設定為 主動-主動，請考慮 CAP 定理 如何影響節點之間複製本的數據一致性，以及提供高可用性所需的取捨。
用 CAP 定理術語來說，Cassandra 預設是一個可用分割區容錯 (AP) 資料庫系統，具有高度可調一致性。 針對大多數的使用案例，我們建議使用 LOCAL_QUORUM 進行讀取。
在寫入操作中使用主動-被動模式時，可靠性和效能之間會有取捨。 為了可靠性，我們建議QUORUM_EACH，但對大多數使用者而言，LOCAL_QUORUM或 QUORUM 是很好的妥協。 如果發生區域性中斷，某些寫入可能會在 LOCAL_QUORUM 中遺失。
如果應用程式平行執行，建議在多數情況下使用 QUORUM_EACH 寫入以確保兩個資料中心之間的一致性。
如果您的目標是偏好一致性或較低的 RPO，而不是延遲或可用性，或較低的 RTO，您的一致性設定和復寫因數應該反映此目標。
一般而言，讀取所需的仲裁節點數目加上寫入所需的仲裁節點數目應該大於複寫因數。 例如，若您的複寫因數為 3，並且在讀取時使用 quorum_one (一個節點)，則應在寫入時使用 quorum_all (三個節點)，讓總和 4 大於複寫因數 3。
附註
適用於 Apache Cassandra 的 Azure 受控實例控制平面運算符只會部署在單一區域中。 區域是您部署第一個資料中心時選取的區域。 在極少發生的總區域中斷情況下，我們承諾在 3 小時內將控制平面移轉至其他區域以復原。
由於資料中心仍應繼續運作，因此此問題不會影響服務 的可用性 SLA 。 在此期間，可能無法從 Azure 入口網站或資源提供者工具變更資料庫組態。
複寫
建議您偶爾稽核 keyspaces 及其複寫設定，以確保已設定資料中心之間所需的複寫。 在開發初期階段，建議您使用 cqlsh執行簡單的測試。 例如，在連接到某個數據中心時插入值，並從另一個數據中心讀取該值。
特別是，當您設定第二個數據中心，其中現有的數據中心已經有數據時，請判斷您已復寫所有數據，且系統已就緒。 建議您使用DBA 命令 nodetool netstats來監視複製進度。 替代方法是計算每個數據表中的數據列。 請記住，由於 Cassandra 的分散式本質，面對大量數據時，這種方法只能提供粗略的估計。
平衡災害復原的成本
如果您的應用程式是 主動-被動，我們通常還是建議您在每個區域中部署相同的容量。 這種方法可協助您的應用程式立即切換至次要區域的 熱備用 數據中心。 如果發生區域性中斷，此方法可確保不會降低效能。 大部分的 Cassandra 用戶端驅動程式都提供可起始應用程式層級容錯移轉的選項。 根據預設，它們假設區域中斷表示應用程式也會關閉，因此故障轉移應該發生在負載平衡器層級。
若要降低布建第二個數據中心的成本，建議您在次要區域中部署較小的 SKU 和較少的節點。 發生中斷時，透過周全且立即可用的垂直和水平擴展，可以更輕鬆地在 Azure Managed Instance for Apache Cassandra 中進行擴展。 在應用程式容錯移轉至次要區域時，即可手動擴增和擴大次要資料中心中的節點。 您的次要資料中心可作為成本較低的暖待命。 當發生中斷時，必須在採用此方法和將系統還原至完整容量所需的時間之間取得平衡。 請務必測試及練習在區域遺失時會發生什麼狀況。
附註
節點的垂直擴充速度比水平擴展快得多。當您考慮垂直擴充與水平擴展之間的平衡，以及要在叢集中部署的節點數量時，請記住這一事實。
備份排程
備份會在適用於 Apache Cassandra 的 Azure 受控實例中自動進行。 您可以挑選自己的每日備份排程。 建議您選擇負載較少的時間。 雖然備份已設定為僅耗用閑置 CPU，但在某些情況下可能會在 Cassandra 中觸發壓縮，進而導致 CPU 使用量增加。 Cassandra 可以隨時進行壓縮。 它們取決於工作負載和選擇的壓縮策略。
重要事項
備份的目的純粹是減輕意外的數據遺失或數據損毀。 不建議使用備份作為災害復原策略。
備份不是異地備援。 即使有，從備份復原資料庫可能需要很長的時間。 因此，我們強烈建議使用多個區域部署，加上盡可能啟用可用性區域，以減輕災害案例，並能夠有效地從中復原。 在無法復原失敗區域的罕見案例中，這種方法特別重要。 如果沒有多重區域複寫，所有數據可能會遺失。
