你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
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 托管实例适用于 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（1 个节点），则写入操作应采用 quorum_all（3 个节点），以便总和 4 大于复制因子 3。
注意
Azure Managed Instance for Apache Cassandra 的控制平面运算符仅部署在单个区域中。 区域是部署第一个数据中心时选择的区域。 如果发生区域完全中断的情况，我们承诺提供 3 小时的恢复时间，以便将控制平面故障转移到另一个区域。
由于数据中心仍应继续运行，因此此问题不会影响服务 的可用性 SLA 。 在此期间，可能无法从 Azure 门户或资源提供程序工具更改数据库配置。
复制
我们建议不时审核 keyspaces 及其复制设置，以确保数据中心之间进行了所需的复制配置。 在开发的早期阶段，我们建议使用 cqlsh 进行简单的测试。 例如，在连接到一个数据中心时插入一个值，并从另一个数据中心读取该值。
具体而言，在设置现有数据中心已有数据的第二个数据中心时，请确定已复制所有数据，并且系统已准备就绪。 建议通过 DBA 命令 nodetool netstats监视复制进度。 另一种方法是计算每个表中的行数。 请记住，由于 Cassandra 的分布式性质，在处理大数据时，此方法只能提供粗略的估计。
平衡灾难恢复的成本
如果应用程序是 主动-被动的，我们通常仍建议在每个区域中部署相同的容量。 此方法可帮助你的应用程序立即故障转移到辅助区域中的热备用数据中心。 如果发生区域性服务中断，此方法可确保性能不会降低。 大多数 Cassandra 客户端驱动程序都提供用于启动应用程序级故障转移的选项。 默认情况下，它们假定区域中断意味着应用程序也已关闭，因此故障转移应在负载均衡器级别发生。
若要降低预配第二个数据中心的成本，可能需要在次要区域中部署较小的 SKU 和更少的节点。 发生服务中断时，可通过统包式垂直和水平缩放，在 Azure Managed Instance for Apache Cassandra 中更轻松地纵向扩展。 当应用程序故障转移到次要区域时，可手动地横向扩展和纵向扩展辅助数据中心内的节点。 辅助数据中心充当成本较低的热备用服务器。 如果发生中断，则采用此方法需要与将系统还原到完整容量所需的时间进行均衡。 测试并实践在区域中断时发生什么情况，这一点很重要。
注意
纵向扩展节点的速度比横向扩展要快得多。考虑到垂直和水平缩放之间的平衡以及要部署在群集中的节点数时，请记住这一事实。
备份计划
在 Azure 托管的 Apache Cassandra 实例中，备份是自动的。 可以选择自己的每日备份计划。 建议选择负载更小的时间。 尽管备份配置为仅使用空闲 CPU，但在某些情况下，它们可能会在 Cassandra 中触发压缩，这可能会导致 CPU 使用率增加。 使用 Cassandra 可以随时进行压缩。 它们取决于工作负荷和所选压缩策略。
重要
备份的目的是缓解意外数据丢失或数据损坏。 我们不建议将备份作为灾难恢复策略。
备份没有异地冗余功能。 即使存在，从备份中恢复数据库可能需要很长时间。 因此，我们强烈建议使用多个区域部署，并尽可能启用可用性区域，以针对灾难方案进行缓解，并能够有效地从它们中恢复。 在极少数无法恢复失败区域的情况下，此方法尤其重要。 如果没有多区域复制，所有数据可能会丢失。
