You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/cosmos-db/conflict-resolution-policies.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ ms.author: mjbrown
15
15
16
16
Conflicts and conflict resolution policies are applicable if your Cosmos account is configured with multiple write regions.
17
17
18
-
For Cosmos DB accounts configured with multiple write regions, update conflicts can occur when multiple writers concurrently update the same item in multiple regions. Update conflicts are classified into the following three types:
18
+
For Cosmos accounts configured with multiple write regions, update conflicts can occur when multiple writers concurrently update the same item in multiple regions. Update conflicts are classified into the following three types:
19
19
20
20
1.**Insert conflicts:** These conflicts can occur when an application simultaneously inserts two or more items with the same unique index (for example, ID property) from two or more regions. In this case, all the writes may succeed initially in their respective local regions, but based on the conflict resolution policy you choose, only one item with the original ID is finally committed.
Copy file name to clipboardExpand all lines: articles/cosmos-db/consistency-levels-tradeoffs.md
-14Lines changed: 0 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,20 +31,6 @@ Distributed databases relying on replication for high availability, low latency
31
31
32
32
- For a given type of write operation such as insert, replace, upsert, delete, etc. the write throughput for request units is identical for all consistency levels.
33
33
34
-
## Consistency levels and durability
35
-
36
-
Before a write operation is acknowledged to the client, the data is durably committed by a quorum of replicas within the region that accepts the write operations. Moreover, if the container is configured with consistent indexing policy, the index is also synchronously updated, replicated, and durably committed by the quorum of replicas before the acknowledgement of write operation is sent to the client.
37
-
38
-
The following table summarizes the potential data loss window in the event of a regional disaster for the Cosmos accounts that span several regions.
39
-
40
-
|**Consistency level**|**Potential data loss window in the event of a regional disaster**|
41
-
| - | - |
42
-
| Strong | Zero |
43
-
| Bounded Staleness | Confined to the “staleness window” you configure on the Cosmos account. |
44
-
| Session | Up to 5 seconds |
45
-
| Consistent Prefix | Up to 5 seconds |
46
-
| Eventual | Up to 5 seconds |
47
-
48
34
## Next steps
49
35
50
36
Next you can learn more about global distribution and general consistency tradeoffs in distributed systems using the following articles:
Copy file name to clipboardExpand all lines: articles/cosmos-db/high-availability.md
+31-19Lines changed: 31 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,23 +12,23 @@ ms.reviewer: sngun
12
12
13
13
---
14
14
15
-
# High Availability in Azure Cosmos DB
15
+
# High Availability with Azure Cosmos DB
16
16
17
17
Azure Cosmos DB transparently replicates your data across all the Azure regions associated with your Cosmos account. Cosmos DB employs multiple layers of redundancy for your data as shown in the following image:
- The data within Cosmos containers is horizontally partitioned.
22
22
23
23
- Within each region, every partition is protected by a replica-set with all writes replicated and durably committed by a majority of replicas. Replicas are distributed across as many as 10-20 fault domains.
24
24
25
25
- Each partition across all the regions is replicated. Each region contains all the data partitions of a Cosmos container and can accept writes and serve reads.
26
26
27
-
If your Cosmos account is distributed across N Azure regions, there will be at least N x 4 copies of all your data. In addition to providing low latency data access and scaling write/read throughput across the regions associated with your Cosmos account, having more regions (higher N) also improves availability.
27
+
If your Cosmos account is distributed across N Azure regions, there will be at least N x four copies of all your data. In addition to providing low latency data access and scaling write/read throughput across the regions associated with your Cosmos account, having more regions (higher N) also improves availability.
28
28
29
-
## SLAs for availability
29
+
## SLAs for availability
30
30
31
-
As a globally distributed database, Cosmos DB provides comprehensive SLAs that encompass throughput, latency at the 99th percentile, consistency, and high availability. In the following table, we describe the guarantees pertaining to high availability provided by Cosmos DB for single and multi-region accounts. For high availability, configure your Cosmos accounts to have multiple write regions.
31
+
As a globally distributed database, Cosmos DB provides comprehensive SLAs that encompass throughput, latency at the 99th percentile, consistency, and high availability. The table below shows the guarantees for high availability provided by Cosmos DB for single and multi-region accounts. For high availability, configure your Cosmos accounts to have multiple write regions.
32
32
33
33
|Operation type | Single region |Multi-region (single region writes)|Multi-region (multi-region writes) |
34
34
|---------|---------|---------|-------|
@@ -38,38 +38,50 @@ As a globally distributed database, Cosmos DB provides comprehensive SLAs that e
38
38
> [!NOTE]
39
39
> In practice, the actual write availability for bounded staleness, session, consistent-prefix and eventual consistency models is significantly higher than the published SLAs. The actual read availability for all consistency levels is significantly higher than the published SLAs.
40
40
41
-
## Regional outages
41
+
## High availability with Cosmos DB in the face of regional outages
42
42
43
-
Regional outages aren't uncommon, and Azure Cosmos DB makes sure your database is always available. The following details capture Cosmos DB behavior during an outage, depending on your Cosmos account's configuration:
43
+
Regional outages aren't uncommon, and Azure Cosmos DB makes sure your database is always available. The following details capture Cosmos DB behavior during an outage, depending on your Cosmos account's configuration:
44
44
45
-
-Multi-region accounts configured with multiple-write regions will remain highly available for both writes and reads. Regional failovers are instantaneous and do not require any changes from the application.
45
+
-With Cosmos DB, before a write operation is acknowledged to the client, the data is durably committed by a quorum of replicas within the region that accepts the write operations.
46
46
47
-
- Multi-region accounts with a single-write region: During a write region outage, these accounts will remain highly available for reads. However, for writes you must “enable automatic failover” on your Cosmos account to failover the impacted region to another region associated. The failover will occur in the order of region priority you’ve specified. Eventually, when the impacted region is back online, the unreplicated data present in the impacted write region during the outage is made available through the conflicts feed. Applications can read the conflicts feed, resolve the conflicts based on application-specific logic, and write the updated data back to the Cosmos container as appropriate. Once the previously impacted write region recovers, it becomes automatically available as a read region. You can invoke a manual failover and bring back the impacted region as the write region. You can do a manual failover by using [Azure CLI or Azure portal](how-to-manage-database-account.md#enable-manual-failover-for-your-cosmos-account).
47
+
- Multi-region accounts configured with multiple-write regions will be highly available for both writes and reads. Regional failovers are instantaneous and don't require any changes from the application.
48
+
49
+
- Multi-region accounts with a single-write region: During a write region outage, these accounts will remain highly available for reads. However, for writes you must “enable automatic failover” on your Cosmos account to failover the impacted region to another region associated. The failover will occur in the order of region priority you’ve specified. Eventually, when the impacted region is back online, the un-replicated data present in the impacted write region during the outage is made available through the conflicts feed. Applications can read the conflicts feed, resolve the conflicts based on application-specific logic, and write the updated data back to the Cosmos container as appropriate. Once the previously impacted write region recovers, it becomes automatically available as a read region. You can invoke a manual failover and configure the impacted region as the write region. You can do a manual failover by using [Azure CLI or Azure portal](how-to-manage-database-account.md#enable-manual-failover-for-your-cosmos-account).
48
50
49
51
- Multi-region accounts with a single-write region: During a read region outage, these accounts will remain highly available for reads and writes. The impacted region is automatically disconnected from the write region and will be marked offline. The Cosmos DB SDKs will redirect read calls to the next available region in the preferred region list. If none of the regions in the preferred region list is available, calls automatically fall back to the current write region. No changes are required in your application code to handle read region outage. Eventually, when the impacted region is back online, the previously impacted read region will automatically sync with the current write region and will be available again to serve read requests. Subsequent reads are redirected to the recovered region without requiring any changes to your application code. During both failover and rejoining of a previously failed region, read-consistency guarantees continue to be honored by Cosmos DB.
50
52
51
-
- Single-region accounts may lose availability in the event of regional outage. It's recommended to setup at least two regions (preferably, at least two write regions) with your Cosmos account to ensure high availability at all times.
53
+
- Single-region accounts may lose availability following a regional outage. It's recommended to set up at least two regions (preferably, at least two write regions) with your Cosmos account to ensure high availability at all times.
54
+
55
+
### Durability following a regional disaster
56
+
57
+
Before a write operation is acknowledged to the client, the data is durably committed by a quorum of replicas within the region that accepts the write operations. The table below shows the potential data loss window for each consistency level following an unrecoverable regional disaster for Cosmos accounts spanning several regions.
58
+
59
+
|**Consistency level**|**Potential data loss window following a regional disaster**|
60
+
| - | - |
61
+
| Strong | Zero |
62
+
| Bounded Staleness | Confined to the “staleness window” you configure on the Cosmos account. |
63
+
| Session | Up to 5 seconds |
64
+
| Consistent Prefix | Up to 5 seconds |
65
+
| Eventual | Up to 5 seconds |
52
66
53
67
## Building highly available applications
54
68
55
-
- To ensure high write and read availability, configure your Cosmos account to span at least two regions with multiple-write regions. This configuration will ensure the availability, lowest latency, and scalability for both reads and writes backed by SLAs. To learn more, see how to [configure your Cosmos account with multiple write-regions](tutorial-global-distribution-sql-api.md).
69
+
- To ensure high write and read availability, configure your Cosmos account to span at least two regions with multiple-write regions. This configuration will provide the availability, lowest latency, and scalability for both reads and writes backed by SLAs. To learn more, see how to [configure your Cosmos account with multiple write-regions](tutorial-global-distribution-sql-api.md).
56
70
57
71
- For multi-region Cosmos accounts that are configured with a single-write region, [enable automatic-failover by using Azure CLI or Azure portal](how-to-manage-database-account.md#enable-automatic-failover-for-your-cosmos-account). After you enable automatic failover, whenever there is a regional disaster, Cosmos DB will automatically failover your account.
58
72
59
-
- Even if your Cosmos account is highly available, your application may not be correctly designed to remain highly available. To ensure the end-to-end high availability for your application, periodically invoke the [manual failover by using Azure CLI or Azure portal](how-to-manage-database-account.md#enable-manual-failover-for-your-cosmos-account), as a part of your application testing or disaster-recovery (DR) drills.
73
+
- Even if your Cosmos account is highly available, your application may not be correctly designed to remain highly available. To test the end-to-end high availability for your application, periodically invoke the [manual failover by using Azure CLI or Azure portal](how-to-manage-database-account.md#enable-manual-failover-for-your-cosmos-account), as a part of your application testing or disaster-recovery (DR) drills.
60
74
61
75
## Next steps
62
76
63
77
Next you can learn about scaling throughput in the following article:
64
78
65
-
*[Scaling throughput](scaling-throughput.md)
66
-
67
-
*[Availability and performance tradeoffs for various consistency levels](consistency-levels-tradeoffs.md)
0 commit comments