Skip to content

Commit f1bea2a

Browse files
author
Theo van Kraay
committed
review updates
1 parent 4e11e39 commit f1bea2a

File tree

1 file changed

+3
-3
lines changed

1 file changed

+3
-3
lines changed

articles/managed-instance-apache-cassandra/resilient-applications.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@ keywords: azure high availability disaster recovery cassandra resiliency
1414

1515
Azure Managed Instance for Apache Cassandra provides automated deployment and scaling operations for managed open-source Apache Cassandra datacenters. Apache Cassandra is a great choice for building highly resilient applications due to it's distributed nature and masterless architecture – any node in the database can provide the exact same functionality as any other node – contributing to Cassandra’s robustness and resilience. This article provides tips on how to optimize high availability and how to approach disaster recover.
1616

17-
## Availability Zones
17+
## Availability zones
1818

1919
Cassandra's masterless architecture brings fault tolerance from the ground up, and Azure Managed Instance for Apache Cassandra provides support for [availability zones](../availability-zones/az-overview.md#azure-regions-with-availability-zones) in selected regions to enhance resiliency at the infrastructure level. Given a replication factor of 3, availability zone support ensures that each replica is in a different availability zone, thus preventing a zonal outage from impacting your database/application. We recommend enabling availability zones where possible.
2020

@@ -28,7 +28,7 @@ In CAP theorem terms, Cassandra is by default an AP (Available Partition-toleran
2828

2929
- In active-passive for writes there's a trade-off between reliability and performance: for reliability we recommend QUORUM_EACH but for most users LOCAL_QUORUM or QUORUM is a good compromise. Note however that in the case of a regional outage, some writes might be lost in LOCAL_QUORUM.
3030
- In the case of an application being run in parallel QUORUM_EACH writes are preferred for most cases to ensure consistency between the two data centers.
31-
- If your goal is to favor consistency (lower RPO) rather than latency or availability (lower RTO), this should be reflected in your consistency settings and replication factor. As a rule of thumb, the number of quorum nodes required for a read plus the number of quorum nodes required for a write should be greater than the replication factor. For example, if you have a replication factor of 3, and quorum_one on reads (1 node), you should do quorum_all on writes (3 nodes), so that the total of 4 is greater then the replication factor of 3.
31+
- If your goal is to favor consistency (lower RPO) rather than latency or availability (lower RTO), this should be reflected in your consistency settings and replication factor. As a rule of thumb, the number of quorum nodes required for a read plus the number of quorum nodes required for a write should be greater than the replication factor. For example, if you have a replication factor of 3, and quorum_one on reads (1 node), you should do quorum_all on writes (3 nodes), so that the total of 4 is greater than the replication factor of 3.
3232

3333

3434
## Replication
@@ -54,7 +54,7 @@ Backups are automatic in Azure Managed Instance for Apache Cassandra, but you ca
5454
> [!IMPORTANT]
5555
> The intention of backups is purely to mitigate accidental data loss or data corruption. We do **not** recommend backups as a disaster recovery strategy. Backups are not geo-redundant, and even if they were, it can take a very long time to recover a database from backups. Therefore, we strongly recommend a multi-region deployments, coupled with enabling availability zones where possible, to mitigate against disaster scenarios, and to be able to recover effectively from them. This is particularly important in the rare scenarios where the failed region cannot be covered, where without multi-region replication, all data may be lost.
5656
57-
:::image type="content" source="./media/resilient-applications/backup.png" alt-text="Backup schedule configuration page" lightbox="./media/resilient-applications/backup.png" border="true":::
57+
:::image type="content" source="./media/resilient-applications/backup.png" alt-text="Backup schedule configuration page." lightbox="./media/resilient-applications/backup.png" border="true":::
5858

5959
## Next steps
6060

0 commit comments

Comments
 (0)