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