Key concepts
This page explains how clusters, shards, nodes, high availability, backups, and parameter groups are structured and operated in the MemStore service. For how to create and manage each resource, see the relevant How-to Guides.
| Concept | Description |
|---|---|
| Cache only | Cache service that stores all data in memory without using disk |
| Cluster | Management unit in MemStore that includes shards and nodes |
| Shard | Unit that distributes and stores data in a cluster where cluster mode is enabled |
| Node | MemStore execution unit with a Primary or Replica role |
| Automatic failover | Feature that supports service continuity through automatic action when a node fails |
| Promotion | Feature that converts a Replica node to a Primary node |
| Endpoint | Access address provided to connect to a cluster or node |
| Backup | Data copy that stores cluster information and is used for restore |
| Parameter group | Object that manages Valkey and Redis OSS configuration parameters by group |
Cache only
In MemStore, the Redis service offered stores all data in memory without writing to disk, so you can use it solely for caching.
Cluster
A cluster is a collection of one or more nodes, automatically managed as a unit. A cluster consists of multiple shards and nodes, each serving as Primary or Replica. You can add or remove shards or Replica nodes as needed.
For how to create clusters, see Create cluster. For how to view and manage clusters, see Manage clusters.
Valkey cluster lifecycle and status
Unlike Redis OSS, Valkey clusters and nodes have independent status values regardless of whether cluster mode is enabled.
Lifecycle of a Valkey cluster and its nodes when cluster mode is enabled
| State | Description |
|---|---|
Init | Initial state before cluster creation starts |
Creating | Nodes are being created and the cluster is being configured |
Running | Cluster is operating normally |
Scaling(horizontal) | Shards or nodes are being added or deleted |
Scaling(vertical) | Node flavors are being changed |
Modifying | Another cluster configuration, such as a security group, is being changed |
Deleted | Cluster deletion is complete |
Deleting | Cluster deletion is in progress |
Failed | Cluster creation is delayed, a service failure occurred, all nodes failed, or the latest cluster status has not been received for a specified period |
Switching | Node promotion is in progress |
Warning | At least one node is in the Failed state |
Redis OSS cluster lifecycle, status values, and billing
The lifecycle and status values for a Redis OSS cluster are as follows.
- When cluster mode enabled
- When cluster mode disabled
When cluster mode is enabled, the state of shards and each node depends on the cluster status, meaning they share the same status as the cluster.
| State | Description |
|---|---|
Init | Initial state before the cluster creation starts |
Creating | Creating resources |
Running | Operating normally |
Scaling(horizontal) | Adding/deleting shards or adding/deleting nodes is in progress |
Scaling(vertical) | Changing the node flavor is in progress |
Modifying | Security group being updated for cluster |
Deleting | Deleting resources |
Failed | Permanent error occurred; cannot return to normal, only deletion is possible |
| State | Description |
|---|---|
Init | Immediately after cluster creation begins |
Provisioning | All nodes in the cluster are preparing required resources |
Replicating | The roles of nodes are being configured and endpoints are being created |
Running | Service is fully configured and ready for access |
Scaling(horizontal) | Creating a new node or deleting a specific Replica node is in progress |
Scaling(vertical) | Changing the node flavor is in progress |
SwitchingOver | Promoting a Replica to Primary |
ScalingOut | Adding a new node and assigning it as Replica |
Recovering | The cluster with HA is automatically handling node failure |
Modifying | Modifying cluster (e.g., changing security group) |
Terminating | Deleting the cluster |
Terminated | Cluster deletion completed |
Warning | Temporary error occurred; can return to normal if resolved |
Failed | Permanent error occurred; cannot return to normal, only deletion allowed |
Shard
A shard is a group of nodes in cluster mode that stores a partition of the cluster data set.
For Valkey, a cluster can have 3 to 12 shards. For Redis OSS, a cluster can have 1 to 12 shards. With either engine, each shard can have 2 to 5 nodes.
For how to manage shards and nodes in clusters where cluster mode is enabled, see Manage shards and nodes.
Node
A node is a VM (Virtual Machine) included in the cluster. When you create or delete a node, necessary operations are performed and the status automatically changes. Each node in the cluster is assigned the role of Primary or Replica. When cluster mode is disabled, you can configure up to 6 nodes in a cluster.
For how to manage nodes in clusters where cluster mode is disabled, see Manage nodes. For how to change node types, see Change node type.
| Role | Description |
|---|---|
| Primary | The node typically used by the user for read/write operations |
| Replica | Read-only node to reduce load on the Primary |
Node types
When creating a node, the user selects a type based on data size and load. More specialized node types will be supported later.
| Node type | vCPU | Memory (GB) |
|---|---|---|
m2a.large | 2 | 8 |
m2a.xlarge | 4 | 16 |
m2a.2xlarge | 8 | 32 |
m2a.4xlarge | 16 | 64 |
m2a.8xlarge | 32 | 128 |
m2a.12xlarge | 48 | 192 |
m2a.16xlarge | 64 | 256 |
m2a.24xlarge | 96 | 384 |
r2a.large | 2 | 16 |
r2a.xlarge | 4 | 32 |
r2a.2xlarge | 8 | 64 |
r2a.4xlarge | 16 | 128 |
r2a.8xlarge | 32 | 256 |
r2a.12xlarge | 48 | 384 |
r2a.16xlarge | 64 | 512 |
r2a.24xlarge | 96 | 768 |
t1i.small | 2 | 2 |
t1i.medium | 2 | 4 |
t1i.large | 2 | 8 |
t1i.xlarge | 4 | 16 |
t1i.2xlarge | 8 | 32 |
t1i instance types may take several minutes to tens of minutes to transition to the Running state after initial creation.
If CPU credit balance is low, workloads with high CPU usage may not function normally.
Node lifecycle, status, and billing
The node lifecycle and status values differ by engine.
- Valkey
- Redis OSS
| State | Description | Billing |
|---|---|---|
Init | Node creation starts according to the cluster configuration | Not billed |
Creating | Node creation and Valkey service preparation are in progress | Not billed |
Running | Valkey service is operating normally | Billed |
Deleted | Node deletion is complete | Not billed |
Deleting | Node deletion is in progress | Not billed |
Resizing | Node flavor is being changed | Billed |
Warning | Node health checks are delayed | Billed |
Failed | Cluster creation is delayed, the control agent failed, or a service failure occurred | Not billed |
| State | Description |
|---|---|
Init | Each node begins creation when the cluster is being set up |
Provisioning | The VM resources for service operation are being created - This step may take several minutes |
Starting | After VM creation, Redis service is being installed and started |
Running | Service is running normally and accessible |
Modifying | Security group or other configuration change is in progress |
Terminating | The user requested node deletion, and deletion is in progress |
Terminated | The node has been deleted - After this, the node info is no longer accessible |
Warning | Temporary error occurred; may return to normal when resolved |
Failed | Permanent error occurred; cannot recover to normal state, only deletion possible |
Automatic failover
MemStore provides a high availability feature to ensure continuous service operation even when a node fails.
When cluster mode is enabled, automatic failover is enabled by default and cannot be disabled. When cluster mode is disabled, automatic failover is enabled automatically for Valkey clusters with two or more nodes. For Redis OSS, you can choose whether to enable it when creating a cluster and change the setting during operation. You can check whether high availability is used on the cluster details tab. Even when high availability is used, you can add or remove nodes, and any added node will automatically be included within the HA scope.
For how to configure high availability, see Configure high availability.
Node failures
Node failures are handled differently depending on the node role:
| Role | Description |
|---|---|
| Primary node failure | If a Primary node fails, the system automatically promotes the Replica with the most recent data to Primary (Automatic Failover) and then creates a new Replica to maintain the replica count (Auto Healing) |
| Replica node failure | If a Replica node fails, the system automatically replaces it with a new node to maintain replica count |
Promotion
When using cluster mode or high availability, users cannot request promotion; the service automatically performs promotion when needed. When high availability is not used, manual promotion is provided: if the Primary node fails, the user can promote a Replica node to Primary.
For how to promote nodes, see Promote node.
Endpoint
When creating a cluster, MemStore provides endpoints that clients can use to connect. This address is accessible within your selected private network (subnet) and the access permissions and security are automatically configured.
For how to connect to a cluster, see Connect to MemStore cluster.
- When cluster mode is disabled, MemStore provides a Primary endpoint and a read-only endpoint.
- When cluster mode is enabled, MemStore provides a cluster endpoint.
Backup
You can back up the created cluster information for later restoration.
For how to view and manage backups, see Manage backups.
Valkey backup status values
| State | Description | Billing |
|---|---|---|
Available | Backup is available for use | Billed |
Copying | Backup is being copied | Billed |
Creating | Backup is being created | Not billed |
Deleted | Backup deletion is complete | Not billed |
Deleting | Backup deletion is in progress | Not billed |
Error | Backup creation failed or an existing backup cannot be read from Object Storage | Not billed |
Exporting | Backup is being exported to the user's Object Storage | Billed |
Pending | Backup is waiting to be created | Not billed |
Restoring | Backup is being used to restore a cluster | Billed |
Backup status values
| State | Description |
|---|---|
Available | Backup is complete and can be used for restore, copy or export |
Pending | Backup request accepted but not started |
Creating | Backup ongoing or being copied from original |
Restoring | Being used for provisioning |
Copying | Being copied to create another backup |
Exporting | Being exported to user’s Object Storage |
Error | Error occurred during backup |
Deleting | Backup deletion in progress |
Parameter group
You can create and manage MemStore parameter values by group.
For how to create and modify parameter groups, see Manage parameter groups. For how to change the parameter group applied to a cluster, see Change parameter group.
Parameter application status
| State | Description |
|---|---|
Pending | Awaiting parameter application |
Applying | Parameters are currently being applied to the cluster |
In-Sync | Parameters have been applied successfully to the cluster |
Error-Sync | Failed to apply parameters to the cluster - You can retry parameter application, and when retried, the state changes to Applying |
Suspended | Waiting for next task because the preceding cluster failed parameter application during sequential application - When the state changes from Pending to Suspended, you can retry parameter application- When retried, the state changes to Applying |