Astra DB replication and distribution
By default, each Astra DB Serverless database is deployed to one region, also known as the primary region. You select this region when you create the database.
You can deploy databases to additional regions (multi-region databases). When you deploy a database to an additional region, data is streamed from the primary region.
Triple replication
Within each deployed region, Astra DB replicates data across three availability zones. This promotes uptime and ensures data integrity.
For each keyspace, the replication factor is 3 and the replication strategy is NetworkTopologyStrategy.
These settings are configured by DataStax as part of the Astra managed service offering.
You cannot change the replication strategy, replication factor, or independently manage, restrict, or modify replicas.
In Apache Cassandra-based databases, data is organized into tables that use primary keys to identify unique records. When the replication factor is greater than 1, data is stored on multiple nodes that are known as replicas. If a replica is busy or fails, read/write requests can be forwarded to other replicas that store the same data.
In Astra, the total amount of data managed by the cluster is represented as a ring. Astra divides the ring into a number of token ranges equal to the number of nodes. Table data is partitioned across the nodes based on row keys that correspond to token ranges. When reading or writing a row, Astra uses the row key to determine the token and locate the node responsible for that token range.
Eventual consistency
Astra DB follows an eventual consistency model: when you write to an Astra DB database, the data is eventually replicated across all of the database’s replicas.
When you write to a multi-region database, the data is eventually replicated across all regions where the database is deployed, regardless of the region that received the original write request.
The time required to replicate data across all regions and availability zones depends on the number of regions, workload volume, and network resources. Generally, data replication takes minutes, but it can take hours or days if there are failures or outages.
Repair cycles
If a write request succeeds in one region and fails in another, Astra DB attempts to repair the inconsistency. Generally, repair cycles range from a few minutes to a few hours, but they can take days if a network disruption occurs between regions. Network disruptions can limit or prevent the following operations:
-
Schema changes
-
Table truncation
-
Lightweight transactions (LWTs), also known as compare-and-set (CAS) or read-before-write operations
-
Data repair
Consistency levels
Consistency levels determine the number of replicas that must acknowledge a read or write operation before it’s considered successful. For information about supported and default consistency levels, see Consistency levels.