# MemoryDB Multi-Region
MemoryDB Multi-Region is a fully managed, active-active, multi-Region database that enables you to build multi-Region applications with up to 99.999% availability and microsecond read and single-digit millisecond write latencies. You can improve both availability and resiliency from regional degradation, while also benefiting from low latency local reads and writes for multi-Region applications.
With MemoryDB Multi-Region, you can build highly available multi-Region applications for increased resiliency. It offers active-active replication so you can serve reads and writes locally from the Regions closest to your customers with microsecond read and single-digit millisecond write latency. MemoryDB Multi-Region asynchronously replicates data between Regions, and data is typically propagated within a second. It automatically resolves update conflicts and corrects data divergence issues, enabling you to focus on your application.
MemoryDB Multi-Region is currently supported in the following AWS Regions: US East (N. Virginia and Ohio), US West (Oregon, N. California), Europe (Ireland, Frankfurt, and London), and Asia Pacific (Tokyo, Sydney, Mumbai, Seoul and Singapore).
You can easily get started with MemoryDB Multi-Region with just a few clicks from the AWS Management Console or using the latest AWS SDK, or AWS CLI.
**Topics**
+ [Prerequisites and limitations](multi-region.prereq.md)
+ [How it works](multi-region.how.md)
+ [Consistency and conflict resolution](#multi-region.conflict)
+ [Using MemoryDB Multi-Region with the console](multi-Region.console.md)
+ [Using MemoryDB Multi-Region with the CLI](multi-Region.cli.md)
+ [Monitoring MemoryDB Multi-Region](multi-Region.monitoring.md)
+ [Scaling with MemoryDB Multi-Region](multi-Region.Scaling.md)
+ [Supported and unsupported commands](multi-Region.SupportedCommands.md)
# Prerequisites and limitations
Before getting started with MemoryDB Multi-Region, be aware of the following:
+ **MemoryDB Multi-Region replicates data between Regions of your choice** - By creating a Multi-Region cluster, you understand and agree that data will be moved between your selected Regions.
Removing a Region from the Multi-Region group also deletes the regional cluster in that region.
+ **Regional availability** - MemoryDB Multi-Region is supported in the following AWS Regions: US East (N. Virginia and Ohio), US West (Oregon, N. California), Europe (Ireland, Frankfurt, and London), and Asia Pacific (Tokyo, Sydney, Mumbai, Seoul and Singapore).
+ **Behaviors and settings** - All Multi-Region regional clusters will have the same number of shards, instance types, Valkey engine version, TLS and parameter group settings. You can choose differing IAM authentication, ACLs, snapshot windows, tags, Customer Managed Keys (CMKs), and maintenance windows for each of your regional clusters.
With MemoryDB multi-Region, clusters in different Regions can have a different number of replicas.
+ **Node types supported ** - MemoryDB Multi-Region is supported on R7g nodes of size XL and above.
MemoryDB Multi-Region supports Valkey engine version 7.3 and above.
+ **Data types supported** - MemoryDB Multi-Region currently supports most Redis OSS or Valkey data types, and we will add support for more data types in future. Supported data types include Strings, Hashes, Sets, and Sorted Sets, although not all commands that manipulates those data types are supported.
+ **Total number of Regions** - With MemoryDB Multi-Region, you will be able to automatically replicate MemoryDB cluster data between up to five AWS Regions.
+ **Supported options** - MemoryDB Multi-Region supports horizontal/vertical scaling, IAM integration, ACLs, automatic and on-demand snapshotting, automatic software patching, and monitoring.
+ **Backup and restore** - You can create snapshots to back up the data of your Multi-Region regional clusters. You can manually create a snapshot, or you can use MemoryDB’s automated snapshot scheduler to take a new snapshot each day at a time you specify individually for each regional cluster.
+ **Migration** - You can choose to restore any MemoryDB or Redis OSS/Valkey RDB format backups. To migrate the data from a backup, create a new MemoryDB Multi-Region regional cluster and specify the snapshot location from Amazon S3. If it is a MemoryDB snapshot you can also specify the name. MemoryDB Multi-Region will create the regional cluster with the data from the snapshot. As MemoryDB Multi-Region supports Strings, Hashes, Sets, Sorted Sets data types, you can migrate snapshot data for these supported data types only. If the backup file contains unsupported Redis OSS data types, MemoryDB Multi-Region will fail the migration operation by default.
+ **Resource reservation** - MemoryDB Multi-Region is designed to protect regional availability. Some resources are permanently reserved on each node to ensure that local read and write requests can be served independently of the workload in the peer regions. These resources also serve to protect the local availability during events in the peer regions, including during Regionisolation events and recovery thereof. This results in different performance characteristics compared to single-region MemoryDB. MemoryDB Multi-Region supports both horizontal and vertical scaling to expand the available resources.
+ **No RPO/RTO SLAs** - MemoryDB Multi-Region does not provide a stated RPO/RTO SLA. It will continue to accept writes in a AWS Region that has been isolated from other AWS Regions, potentially increasing cross replication lag indefinitely. We expect customers to detect isolation using the “MultiRegionClusterReplicationLag” metric and redirect their application traffic to another Region depending on the RPO they want.
+ **No single end-point or auto-failover:** - In case of a regional outage, you will have to manually redirect your customer traffic to their application stack in another Region. You will have to ensure they have properly configured multi-region access to MemoryDB clusters.
+ **No TTL support ** - MemoryDB Multi-Region does not support TTL (Time to live).
+ **No data tiering or vector search support ** - MemoryDB Multi-Region does not support vector search and data tiering features.
+ MemoryDB Multi-Region does not support read-modify-write commands (APPEND, RENAMENX, etc.).
+ Redis OSS transaction atomicity and consistency are not guaranteed in MemoryDB Multi-Region.
+ **Auth model** - MemoryDB Multi-Region API actions can be invoked from any supported region. The scope of permissions can be restricted by specifying the ARN of the multi-region cluster in an IAM policy. The format of the multi-region cluster ARN is `arn:aws:memorydb:::multiregioncluster/multi-region-cluster-name`. There is no region information in the ARN.
+ **Throughput limitations** - MemoryDB Multi-Region can support up to 1.3 GB/s read throughput per node in a Region and \$150 MB/s globally aggregated write throughput per shard.
+ **AWS policy** - The AWS ReadOnlyAccess policy provides read-only access to AWS services and resources, but will not automatically retrieve details about one or more multi-Region clusters. In order to retrieve details about one or more multi-Region clusters, use the [AmazonMemoryDBReadOnlyAccess](security-iam-awsmanpol.md#iam.identitybasedpolicies.predefinedpolicies-readonly) policy or create [ IAM customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) .
+ **Deleting a regional cluster** - When deleting a regional cluster any associated Customer Managed Keys (CMKs) must remain valid until the regional cluster has finished deleting. This ensures that the remaining regional clusters can converge to a consistent state.
# How it works
Here's how MemoryDB Multi-Region works.
+ **Concepts**
A Multi-Region cluster is a collection of one or more regional clusters, all owned by a single AWS account.
A regional cluster is a single cluster in a AWSRegion that is a part of a Multi-Region cluster. Each regional cluster stores the same set of data. Any given Multi-Region cluster can only have one regional cluster per AWS Region.
When you create a Multi-Region cluster, it consists of multiple regional clusters (one per Region) that MemoryDB treats as a single unit. When an application writes data to any regional cluster, MemoryDB automatically and asynchronously replicates that data to all other regional clusters within the Multi-Region cluster. You can add regional clusters to the Multi-Region cluster so that it can be available in additional Regions. You will be able to automatically replicate MemoryDB cluster data between up to five Regions.
+ **Availability and durability**
In the unlikely event of regional isolation or degradation of a Region, you can update your global DNS to redirect traffic to your application to one of the other healthy Regions without any database reconfiguration, simplifying the process of maintaining high availability for your applications. MemoryDB durably stores all writes from all Regions in the multi-AZ transactional log to ensure no data loss within the Region. MemoryDB Multi-Region keeps track of all writes that have been acknowledged in the Regionbut have not yet been replicated to all member clusters. In case a Region is isolated or degraded, it will still continue to accept local writes. When the isolated Region is connected to the Multi-Region cluster again, writes that have been acknowledged but not yet replicated to other Regions will be replicated to all Regions in the Multi-Region cluster. MemoryDB Multi-Region will also automatically reconcile the pending writes with any updates that may have occurred in other Regions during the outage using a CRDT mechanism.
+ **Connecting to MemoryDB Multi-Region clusters**
To write data to and read data from your regional cluster, you connect to it using one of the supported Redis OSS/Valkey clients (including Valkey GLIDE). Each regional cluster has an endpoint that your Redis OSS/Valkey client can connect to. You can retrieve your regional cluster endpoints using the AWS console, CLI or API. You can then use (or configure) this endpoint in your application to read/write data from regional clusters.
## Consistency and conflict resolution
Any updates made to a key in one of the regional clusters is propagated to other regional clusters asynchronously in the Multi-Region cluster, normally in under a second. If a Region becomes isolated or degraded, MemoryDB Multi-Region keeps track of any writes that have been performed but have not yet been propagated to all of the member clusters. When the Region comes back online, MemoryDB Multi-Region resumes propagating any pending writes from that Region to the member clusters in other Regions. It also resumes propagating writes from other member clusters to the Region that is now back online. All previously successful writes will be propagated eventually no matter how long the Region is isolated.
Conflicts can arise if your application updates the same key in different Regions at about the same time. MemoryDB Multi-Region uses the Conflict-free Replicated Data Type (CRDT) to reconcile between conflicting concurrent writes. CRDT is a data structure that can be updated independently and concurrently without coordination. This means that the write-write conflict is merged independently on each replica with eventual consistency.
In specifics, MemoryDB uses 2 levels of Last Writer Wins (LWW) to resolve conflicts. For the String data type, LWW resolves conflicts at a key level. For other data types, LWW resolves conflicts at a sub-key level. Conflict resolution is fully managed and happens in the background without any impact to application’s availability. Below is an example for Hash data type:
Region A executes “HSET K F1 V1” at timestamp T1; Region B executes “HSET K F2 V2” at timestamp T2; After replication, both Regions A and B will have key K with both fields. When different Regions are concurrently updating different sub-keys in the same collection, because MemoryDB resolves conflict at sub-key level for Hash data type, the two updates do not conflict with each other. Therefore, the final data would contain the effect of both updates.
| Time | Region A | Region B |
| --- | --- | --- |
| T1 | HSET K F1 V1 | |
| T2 | | HSET K F2 V2 |
| T3 | sync | sync |
| T4 | K: \$1F1:V1, F2:V2\$1 | K: \$1F1:V1, F2:V2\$1 |
### CRDT and examples
MemoryDB Multi-Region implements Conflict-free Replicated Data Types (CRDT) to resolve concurrent write conflict issued from multiple regions. CRDT allows different regions to independently achieve eventual consistency once they have eventually received the same set of operations regardless of ordering.
When a single key has is concurrently updated in multiple regions a write-write conflict needs to be resolved to achieve data consistency. MemoryDB Multi-Region uses Last Writer Wins (LWW) strategy to determine the winning operation and only the effects of the operation that “happens after“ are going to be eventually observed. We say an operation op1 “happened before” an operation op2 if the effects of op1 had been applied in the Regionit was original executed when op2 is executed.
For collections (Hash, Set and SortedSet) MemoryDB Multi-Region resolve conflict at element level. This allows MemoryDB Multi-Region to use LWW to resolve write/write conflict on each element. E.g. concurrently adding different elements to the same collection from multiple regions will result in the collection containing all the elements.
**Concurrent execution: Last writer wins**
In MemoryDB Multi-Region, when there is a concurrent creation of a key, the last operation that was executed on any Region will determine the result of the key. For example:
![\[Concurrent execution: Last writer wins.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/concurrent-ex-last-writer-wins.png)
The key x was created on Region B with value "b" but after that the same key was created in Region A with the value "a". Eventually the key will converge to have the value "a", since the operation in Region A was the last performed operation.
**Concurrent execution with conflicting data types: Last writer wins**
In the previous example the key was created with the same type in both regions. Similar behavior will also be observed if the key is created with different data types:
![\[Concurrent execution with conflicting data types: Last writer wins.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/concurrent-ex-conflict-data-types-last-writer-wins.png)
The key x was created as String on Region B with value "b". But after that, and before that operation was replicated to Region A, the same key is created in Region A as a Hash. Eventually the key will converge to have the Hash created on Region A, since the operation in Region A was the last performed operation.
**Concurrent create-deletion: Last writer wins**
In the scenario where there is a concurrent deletion and “creation” (meaning the replacement/addition of value), the last performed operation will win. The end result will be determined by the order of the deletion operation. If the deletion happens before:
![\[Concurrent creation-deletion: Last writer wins if deletion happens before.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/concurrent-create-delete-last-writer-wins-before.jpg)
The key x of type Set was deleted on Region B. After that a new member was added to that key on Region A. Eventually the key will converge to have the Set with the sole element added on Region A, since the operation on Region A was the last performed operation.
If the deletion happens after:
![\[Concurrent creation-deletion: Last writer wins if deletion happens after.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/concurrent-create-delete-last-writer-wins-after.jpg)
A new member was added to key x of type Set on Region A. Aafter that the key was deleted on Region B. Eventually it will converge to have the key deleted, since the operation on Region B was the last performed operation.
**Counters, concurrent operations: Full value replication with last writer wins**
Counters in MemoryDB Multi-Region behave similarly as non-counter types by doing full value replication and applying last-writer-strategy. Concurrent operation will not combine but the last operation will win instead. For example:
![\[Full value replication if last writer wins.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/concurrent-full-rep-last-writer-wins.jpg)
In this scenario the key x has the starting value 1. Then Region B increases the counter x by 2, then shortly afterwards Region A increased the counter by 1. Since region A was the last performed operation, the key x will eventually converge to the value 2 as increasing by 1 was the last operation performed.
**Non-deterministic commands are replicated as deterministic**
In order to guarantee consistency of the values across the different regions, in MemoryDB Multi-Region non-deterministic commands are replicated as deterministic. Non-deterministic commands are those that depend on external factors, such as SETNX. SETNX depends on the key being present or not, and the key may be present on a remote Region but not in the local Region receiving the command. For this reason, otherwise non-deterministic commands are replicated as full value replication. In the case of a string, it will be replicated as a SET command.
![\[Non-deterministic commands being replicated as deterministic.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/nondeterministic_commands.png)
In summary, all operations over String type are replicated as SET or DEL, all operations over Hash type are replicated as HSET or HDEL, all operations over Set type are replicated as SADD or SREM, and all operations over Sorted Sets are replicated as ZADD or ZREM.
# Using MemoryDB Multi-Region with the console
Here are ways to use MemoryDB Multi-Region with the console.
**Topics**
+ [Create a new cluster in MemoryDB Multi-Region](#multi-Region.console.create)
+ [Restore a snapshot to a new or existing cluster within a Multi-Region cluster](#multi-Region.console.restore)
+ [Modify clusters in MemoryDB Multi-Region](#multi-Region.console.modify)
+ [Delete clusters in MemoryDB Multi-Region](#multi-Region.console.delete)
## Create a new cluster in MemoryDB Multi-Region
1. Navigate to the create cluster section from the cluster list or dashboard.
![\[Create a cluster, console view.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/create-multi-region1.png)
1. In the **Cluster type** field, select **Multi-Region cluster**.
1. In the **Cluster creation method** field, select **Easy create**.
1. Fill in the **Name** and **Description**, verify the default values and select **Create**.
**Create and configure a cluster**
1. Navigate to the create cluster section from the cluster list or dashboard.
![\[Create and configure a cluster, console view.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/create-multi-region2-configure.png)
1. In the **Cluster type** field, select **Multi-Region cluster**.
1. In the **Cluster creation method** field, select **Create new cluster**.
1. Fill in the **Name** and **Description**, verify the values and select **Create**.
## Restore a snapshot to a new or existing cluster within a Multi-Region cluster
1. Navigate to the create cluster section from the cluster list or dashboard.
![\[Restore a cluster, console view.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/restore-multi-region-from-snapshot1.png)
1. In the **Cluster type** field, select **Multi-Region cluster**.
1. In the **Cluster creation method** field, select **Restore from snapshot**.
1. Select the source snapshot, then fill in the required fields. Review your selection, and then select **Restore**.
![\[Console view of selecting the source snapshot to restore to Multi-Region cluster.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/restore-multi-region-from-snapshot2-confirm.png)
1. To see your Multi-Region clusters, navigate to the cluster section:
![\[Console view of the cluster section for modifying Multi-Region clusters.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/restore-multi-region-from-snapshot3-confirm.png)
1. Now select the target multi regional cluster name.
![\[Console view of selecting the multi regional cluster to modify.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/restore-multi-region-from-snapshot4-confirm.png)
1. Now select the target regional cluster name.
![\[Console view of selecting theregional cluster to modify.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/restore-multi-region-from-snapshot5-confirm.png)
## Modify clusters in MemoryDB Multi-Region
1. Navigate to the cluster section. You should see all your current clusters.
![\[This is my image.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/modify-multi-region1.png)
Then depending on the type of cluster you want to modify, select from the following steps.
1. To modify a single cluster with a Muti-Region cluster, first select the Multi-Region it beloongs to. Then select the edit button on the actions (Top right). Then select the target single cluster. You can also modify this cluster from the **Details** page.
**Modify a regional cluster**
1. To modify a multi regional cluster, select the target Multi-Region cluster name.
![\[Console view of selecting a target Multi-Region cluster to modify.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/modify-multi-region2.png)
Then select the cluster, and select the **Edit** button on the actions (Top right) or from the details page.
1. To add a regional cluster, select the target Multi Region cluster selected, then go to the **Actions** dropdown and select **Add AWS Region**. You can also go to the details page for AWS Regions, select the target Multi Region cluster, and add from there.
![\[Console view of selecting a target Multi-Region cluster to add a regional cluster to.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/modify-multi-region3-add-regional-cluster.png)
1. To add a Region, select the target Region. Then fill in the required information and select **Add AWS Region**.
![\[Console view of selecting a target Multi-Region cluster to add a Region to.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/modify-multi-region4-add-region.png)
1. To add a new regional cluster to an empty Multi Region cluster, you will see the same options as in create Multi Region cluster. The only difference is that the multi regional cluster information is already present.
![\[Console view of selecting an empty Multi-Region cluster to add a new regional cluster to.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/modify-multi-region5-add-regional-cluster-to-empty.png)
## Delete clusters in MemoryDB Multi-Region
1. To delete a single cluster in a Region, select the target regional cluster. Then go to the action menu dropdown, select the individual cluster, and select **Delete**.
![\[Console view of selecting a single cluster to delete.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/delete-multi-region1-select.png)
You will be presented with a confirmation window, including the option to create a snapshot before deleting. If you still want to delete, enter "delete" into the text field and then select **Delete**.
![\[Consolve view of a confirmation window for deletion.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/delete-multi-region2-snapshot.png)
1. To delete all associated regional clusters with a Multi Region cluster, select the target multi regional cluster with one or more clusters in it. Then with the target multi regional cluster selected, go to the action menu dropdown and select **Delete**.
![\[Console view of selecting to delete all associated clusters with a Multi Region cluster.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/delete-multi-region3-associated-clusters.png)
1. To delete an entire multi regional cluster, select the target empty multi regional cluster. Then go to the action menu dropdown and select **Delete**.
![\[Console view of deleting an entire multi regional cluster.\]](http://docs.aws.amazon.com/memorydb/latest/devguide/images/delete-multi-region4-entire-mrc.png)
# Using MemoryDB Multi-Region with the CLI
Below are ways to use MemoryDB Multi-Region with the CLI
**Note**
MemoryDB Multi-Region only supports node type db.r7g.xlarge and above.
## Creating clusters with MemoryDBMulti Region
**Create a Multi Region cluster**
```
aws memorydb create-multi-region-cluster \
--multi-region-cluster-name-suffix my-multi-region-cluster \
--node-type db.r7g.xlarge \
--engine valkey \
--region us-east-1
```
**Create a regional cluster in US East (N. Virginia) Region**
```
aws memorydb create-cluster \
--cluster-name my-cluster \
--multi-region-cluster-name my-multi-region-cluster \
--node-type db.r7g.xlarge \
--acl-name open-access \
--region us-east-1 \
```
**Create a Region cluster in Europe (Ireland) Region**
```
aws memorydb create-cluster \
--cluster-name my-cluster \
--multi-region-cluster-name my-multi-region-cluster \
--node-type db.r7g.xlarge \
--acl-name open-access \
--region eu-west-1 \
```
**Describe the Multi Region cluster from any Region**
```
aws memorydb describe-multi-region-cluster \
--multi-region-cluster-name my-multi-region-cluster \
--region eu-west-1
```
## Update a Multi Region cluster
**Modifying Node Type**
```
aws memorydb update-multi-region-cluster \
--multi-region-cluster-name my-multi-region-cluster \
--node-type db.r7g.4xlarge \
--region us-east-1
```
**Modifying shard count**
```
aws memorydb update-multi-region-cluster \
--multi-region-cluster-name my-multi-region-cluster \
--shard-configuration \
ShardCount=3 \
--update-strategy COORDINATED \
--region us-east-1
```
## Scaling MemoryDB clusters
First, list the nodes that can scale up or down with the `list-allowed-node-type-updates` command:
```
aws memorydb list-allowed-node-type-updates \
--cluster-name my-cluster-name
```
This will provide a list of nodes that can be scaled up or down. To then update them, you can use the `update-cluster` command:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--node-type db.r6g.2xlarge
```
For more information on scaling with Multi-Region see [Scaling with MemoryDB Multi-Region](multi-Region.Scaling.md).
## Deleting clusters in MemoryDB Multi-Region
**Delete a regional cluster**
```
aws memorydb delete-cluster \
--cluster-name my-cluster \
--multi-region-cluster-name my-multi-region-cluster \
--region us-east-1
```
**Delete a Multi Region cluster**
```
aws memorydb delete-multi-region-cluster \
--multi-region-cluster-name my-multi-region-cluster \
--region us-east-1
```
# Monitoring MemoryDB Multi-Region
You can use Amazon CloudWatch to monitor the behavior and performance of a Multi-Region cluster. MemoryDB publishes the `MultiRegionClusterReplicationLag` metric for each regional cluster within the Multi-Region cluster.
`MultiRegionClusterReplicationLag` shows the elapsed time between when an update is written to the remote Multi-Region regional cluster multi-AZ transaction log, and when that update is written to the primary node in the local Multi-Region regional cluster. This metric is expressed in milliseconds, is emitted for every source- and destination-Region pair at shard level.
During normal operation, `MultiRegionClusterReplicationLag` should be fairly constant. An elevated value for `MultiRegionClusterReplicationLag` could indicate that updates from one regional cluster are not propagating to other regional clusters in a timely manner. Over time, this could result in other regional clusters *falling behind* because they no longer receive updates consistently.
`MultiRegionClusterReplicationLag` can increase if an AWS Region becomes isolated or degraded and you have a regional cluster in that Region. In this case, you can temporarily redirect your application's read and write activity to a different healthy AWS Region.
# Scaling with MemoryDB Multi-Region
As demand on your clusters changes, you might decide to improve performance or reduce costs by changing the node type or the number of shards in your MemoryDB cluster. Scaling a MemoryDB Multi-Region cluster scales all regional clusters in it. MemoryDB Multi-Region cluster supports online resharding. MemoryDB Multi-Region cluster does not support offline resharding.
Conditions under which you might decide to rescale your cluster include the following:
+ **Memory pressure**
If the nodes in your regional clusters are under memory pressure, you might decide to scale out or scale up so that you have more resources to better store data and serve requests.
You can determine whether your nodes are under memory pressure by monitoring the following metrics: FreeableMemory, SwapUsage, BytesUsedForMemoryDB, and MultiRegionClusterReplicationLag
+ **CPU or network bottleneck**
If latency/throughput issues are plaguing your cluster, you might need to scale out or scale up to resolve the issues.
You can monitor your latency and throughput levels by monitoring the following metrics: `CPUUtilization`, `NetworkBytesIn`, ` NetworkBytesOut`, `CurrConnections`, ` NewConnections`, ` and MultiRegionClusterReplicationLag`.
+ ** Your cluster is over-scaled**
Current demand on your cluster is such that scaling in or scaling down doesn't hurt performance and reduces your costs.
You can monitor your cluster's use to determine whether or not you can safely scale in or scale down using the following metrics: FreeableMemory, SwapUsage, BytesUsedForMemoryDB, CPUUtilization, NetworkBytesIn, NetworkBytesOut, CurrConnections, NewConnections and MultiRegionClusterReplicationLag
There are two ways to scale your MemoryDB Multi-Region cluster; horizontal and vertical scaling.
+ Horizontal scaling allows you to change the number of shards in the MemoryDB Multi-Region cluster by adding or removing shards. The online resharding process allows scaling in/out while the regional clusters continue serving incoming requests.
+ Vertical changes the node type to resize the MemoryDB Multi-Region cluster. The online vertical scaling allows scaling up/down while the regional clusters continue serving incoming requests.
Scaling uses the “coordinated” update strategy by default. This means that either all regional clusters successfully scale, or none of the regional clusters scale.
The scale-out operation supports the “uncoordinated” update strategy as well. This means some regional clusters may successfully scale-out, while some regional clusters fail a scale-out attempt. If one regional cluster scale-out was successful, then all other regional clusters continue to retry scale-out until each of those other scale-outs are also successful.
A Multi-Region cluster fails an “uncoordinated” scale-out if all regional clusters fail to scale-out.
**Note**
An “uncoordinated” scale-out can create prolonged imbalanced capacities among regional clusters when regional clusters scale-out at different times. It can cause increase in MultiRegionClusterReplicationLag metric and regional clusters data may diverge for long time.
MemoryDB Multi-Region cluster regional clusters can have different configurations for the number of replica nodes, but all shards in a regional cluster have same number of replica nodes.
If you are reducing the size and memory capacity of the MemoryDB Multi-Region cluster, by either scaling in or scaling down, ensure that the new configuration has sufficient memory and free IPs for your data, sufficent engine overhead, and that the MultiRegionClusterReplicationLag metrics for regional clusters are within seconds or a minute range.
You can horizontally and vertically scale your MemoryDB Multi-Region cluster using the AWS Management Console, the AWS CLI, and the MemoryDB API.
# Supported and unsupported commands
**Supported commands**
**Note**
SET command does not currently support the options EX, PX, EXAT, PXAT and KEEPTTL.
RESTORE command does not support setting TTL to a non-zero value. The options ABSTTL, IDLETIME and FREQ are also not supported.
| Data type | commands |
| --- | --- |
| String | SET\$1, DECR, DECRBY, GET, GETRANGE, SUBSTR, GETDEL, GETSET, INCR, INCRBY, INCRBYFLOAT, MGET, MSET, MSETNX, SETNX, STRLEN, LCS |
| Hash | HINCRBY, HINCRBYFLOAT, HDEL, HSET, HMSET, HGET, HEXISTS, HLEN, HKEYS, HVALS, HGETALL, HMGET, HSTRLEN, HSETNX, HRANDFIELD, HSCAN |
| Set | SADD, SREM, SISMEMBER, SMISMEMBER, SCARD, SMEMBERS, SRANDMEMBER, SSCAN, SUNION, SINTERCARD, SINTER, SDIFF, SPOP |
| Sorted Set | ZADD, ZINCRBY, ZSCORE, ZMSCORE, ZCARD, ZRANK, ZREVRANK, ZRANGE, ZRANGEBYSCORE, ZRANGEBYLEX, ZREVRANGE, ZREVRANGEBYLEX, ZREVRANGEBYSCORE, ZREMRANGEBYLEX, ZREMRANGEBYSCORE, ZREMRANGEBYRANK, ZUNION, ZINTER, ZINTERCARD, ZDIFF, ZLEXCOUNT, ZCOUNT, ZREM, ZMPOP, ZPOPMIN, ZPOPMAX, ZSCAN, ZRANDMEMBER |
| Generic | SCAN, DEL, UNLINK, DUMP, RESTORE\$1\$1, EXISTS, KEYS, RANDOMKEY, TYPE |
**Unsupported commands**
General categories of unsupported commands are the unsupported data types (Bitmaps, Hyperloglog, List, Geospatial and Stream), TTL related commands, blocking commands and functions related command. The full list is as follows:
| Data type | commands |
| --- | --- |
| String | APPEND, GETEX, SETEX, SETRANGE |
| Bitmap | BITCOUNT, BITFIELD, BITFIELD\$1RO, BITOP, BITPOS, GETBIT, SETBIT |
| Hyperloglog | PFADD, PFCOUNT, PFDEBUG, PFMERGE, PFSELFTEST |
| List | BLMOVE, BLMPOP, BLPOP, BRPOP, BRPOPLPUSH, LINDEX, LINSERT, LLEN, LMOVE, LMPOP, LPOP, LPOS, PUSH, LPUSHX, LRANGE, LREM, LSET, LTRIM, RPOP, RPOPLPUSH, RPUSH, RPUSHX |
| Set | SMOVE, SUNIONSTORE, SDIFFSTORE, SINTERSTORE |
| Sorted Set | BZMPOP, BZPOPMAX, BZPOPMIN, ZDIFFSTORE, ZINTERSTORE, ZRANGESTORE, ZUNIONSTORE |
| Geospatial | GEOADD, GEODIST, GEOHASH, GEOPOS, GEORADIUS, GEORADIUS\$1RO, GEORADIUSBYMEMBER, GEORADIUSBYMEMBER\$1RO, GEOSEARCH, GEOSEARCHSTORE |
| Stream | XACK, XADD, XAUTOCLAIM, XCLAIM, XDEL, XLEN, XPENDING, XRANGE, XREAD, XREADGROUP, XREVRANGE, XSETID, XTRIM, XGROUP, XINFO |
| Generic | COPY, FLUSHDB, FLUSHALL, MOVE, RENAME, RENAMENX, SORT, SORT\$1RO, SWAPDB, OBJECT, FUNCTION, FCALL, FCALL\$1RO, EXPIRE, EXPIREAT, EXPIRETIME, PERSIST, PEXPIRE, PEXPIREAT, PEXPIRETIME, PSETEX, PTTL, TTL |