Multi-Region strong consistency
Note
Multi-Region strong consistency (MRSC) is available in preview and is subject to change.
Multi-Region strong consistency (MRSC) is a new DynamoDB global tables capability available in preview. A global table configured for MRSC provides the ability to perform a strongly consistent read with multi-Region scope. Performing a strongly consistent read on an MRSC table ensures you're always reading the latest version of an item, irrespective of the Region in which you're performing the read.
You can use multi-Region strongly consistent global tables to build applications with a recovery point objective (RPO) of zero. An RPO of zero ensures your applications can always read the latest version of DynamoDB data, even if an application interruption causes you to shift traffic to a different AWS Region.
MRSC preview is only supported for global tables version 2019.11.21 (Current).
Topics
Consistency modes for global tables
When you create a global table, you can configure its consistency mode. Global tables offer the following multi-Region consistency modes: Eventual consistency and Strong consistency (preview).
If you don’t specify a consistency mode when creating a global table, the global table defaults to multi-Region eventual consistency (MREC). A global table can’t contain replicas configured with different consistency modes. You can't change a global table’s consistency mode.
Multi-Region eventual consistency (MREC)
Multi-Region eventually consistent (MREC) is the default consistency mode for
global tables. Changes that you make to an item in an MREC global table replica
are replicated to all other replicas, typically within a second or less. This
means read operations made with the ConsistentRead parameter set to true (a strongly
consistent read) will always return the latest version of an item if the item
was updated in the Region where the read occurred, but might return stale data
if the item was updated in a different Region.
Conflicts that occur because of the same item being modified in multiple Regions simultaneously are resolved with a last writer wins approach.
MREC global tables will have lower write and strongly-consistent read latencies compared to MRSC global tables.
You should use the MREC mode when:
-
Your application can tolerate stale data returned from strongly consistent read operations if that data was updated in another Region.
-
You prioritize lower write and strongly consistent read latencies over multi-Region read consistency.
-
Your multi-Region high availability strategy can tolerate an RPO greater than zero.
Multi-Region strong consistency (preview)
Note
Multi-Region strong consistency (MRSC) is available in preview and is subject to change.
Changes that you make to an item in an MRSC global table replica can
immediately be read in any other replica table in the global table with a
strongly consistent read. This means read operations made with the
ConsistentRead parameter set to true (a strongly
consistent read) will always return the latest version of an item from any
replica table.
If a write operation would modify an item that is already being modified in
another Region, that write operation will fail with a
ReplicatedWriteConflictException. Writes that fail with the
ReplicatedWriteConflictException can be retried, and will
succeed if the conflicting update has been resolved and no other conflicting
updates are in progress.
MRSC global tables will have higher write and strongly-consistent read latencies compared to MREC global tables.
You should use the MRSC mode when:
-
You need strongly consistent read guarantees with a multi-Region scope.
-
You prioritize global read consistency over lower write latency.
-
Your multi-Region high availability strategy requires an RPO of zero.
Region availability for MRSC preview
The MRSC preview is available in the following AWS Regions:
-
US East (N. Virginia) – us-east-1
-
US East (Ohio) – us-east-2
-
US West (Oregon) – us-west-2
MRSC preview considerations
When you use global tables with MRSC, the following considerations apply for the preview:
Workload considerations
-
Global tables with MRSC are available in preview only. You shouldn't use them for production workloads.
-
The performance and throughput characteristics of MRSC tables might change throughout the preview.
Feature support
-
Only Amazon owned keys are supported for the preview.
-
AWS managed keys aren't supported in preview.
-
Customer managed keys aren't supported in preview.
-
Resource-based policies can't be used to interrupt replication between Regions.
-
CloudWatch Contributor Insights information is only reported for the Region in which operations occurred for MRSC global tables in preview.
-
Time to Live (TTL) isn't supported for MRSC global tables in preview.
-
Local secondary indexes (LSIs) aren't supported for MRSC global tables in preview.
-
Transaction APIs aren't supported in preview.
Behavior differences from MREC global tables
-
The MRSC preview is available in a limited set of Regions.
-
An MRSC global table must contain exactly three replica tables.
-
You must create an MRSC global table by adding two replica tables to an existing single-Region table that doesn't contain any data.
-
You can't delete a single replica table from an MRSC global table. To delete an MRSC global table, you must delete two replica tables in a single action, resulting in a single-Region table. You can then delete the remaining single-Region table.
-
Global secondary index key violations might occur beyond the initial backfilling period.
Quotas
-
An AWS account can have a maximum of three global tables with MRSC.
-
Write throughput in provisioned capacity mode is limited to 10,000 replicated Write Capacity Units (rWCUs).
-
Read throughput in provisioned capacity mode is limited to 10,000 Read Capacity Units (RCUs).
-
Write throughput in on-demand capacity mode is limited to 10,000 replicated Write Request Units (rWRUs).
-
Read throughput in on-demand capacity mode is limited to 10,000 Read Request Units (RRUs).
