Key components of MemoryDB
An outline of the main elements of a MemoryDB deployment is provided below.
- Clusters
- Nodes
- Shards
- Parameter groups
- Subnet Groups
- Access Control Lists
- Users
Clusters
A group of one or more nodes that serve a single dataset is called a cluster. Each shard of a Amazon MemoryDB dataset contains a primary node and up to five optional replica nodes. A replica only handles read requests; a primary node handles both write and read requests. A replica node can be promoted to the new primary node for that shard when a primary node fails over to it. MemoryDB uses either Redis OSS or Valkey as its database engine, and you may choose which version to use when you build a cluster. The AWS Management Console, the MemoryDB API, or the AWS CLI can all be used to create and change a cluster.
A Redis OSS or Valkey engine version is used by each MemoryDB cluster. Every engine version supports a different set of functionality. Furthermore, the behaviour of the clusters that each engine version handles is controlled by a group of settings.
The type of node in a cluster determines its compute and memory capacity. The node type that best suits your requirements can be chosen. You can switch up the types of nodes if your requirements vary over time.
Using the Amazon Virtual Private Cloud (Amazon VPC) service, you operate a cluster on a virtual private cloud (VPC). You are in charge of your virtual networking environment when you use a VPC. You may set up routing and access control lists, build subnets, and select your own range of IP addresses. MemoryDB controls software patching, recovery, automatic failure detection, and snapshots. Operating your cluster in a VPC comes at no extra cost.
A large number of MemoryDB actions target clusters:
- Establishing a cluster
- Changing a cluster
- Capturing images of a cluster
- Eliminating a cluster
- Seeing the components in a group
- Cost allocation tags can be added or removed from a cluster.
Nodes
The simplest component of a MemoryDB deployment is a node, which is powered by an Amazon EC2 instance. The engine version selected when you formed your cluster is used by each node. Within a cluster, a node is a part of a shard.
When you formed your cluster, you selected the version of the engine that each node runs. A cluster’s nodes can be scaled up or down to a different kind if needed.
A cluster’s nodes are all of the same type. There is support for a variety of node kinds with different memory capacities.
Shard
A shard is a collection of one to six nodes, five of which are read replicas and one of which is the primary write node. There is always at least one shard in a MemoryDB cluster.
Your data is divided across the 500 shards that MemoryDB clusters can contain. A 500 node cluster, for instance, can be set up with 83 shards (one primary and five replicas per shard) or 500 shards (one primary and no replicas). Verify that there are enough IP addresses accessible to handle the growth. Common problems include subnets in the subnet group that are shared and heavily used by other clusters, or subnets with a CIDR range that is too small.
One read/write primary node and one to five replica nodes make up a multiple node shard, which is how replication is implemented.
Parameter groups
Managing the engine’s runtime settings on your cluster is simple with parameter groups. Memory utilisation, item sizes, and other things are managed using parameters. You can apply a named collection of engine-specific parameters to a cluster called a MemoryDB parameter group, and every node in that cluster is configured in the same way.
Subnet Groups
For your clusters operating in an Amazon Virtual Private Cloud (VPC) environment, you can create a subnet group, which is a grouping of subnets (usually private).
You have the option to utilise the default subnet group or specify one when you construct a cluster in an Amazon VPC. MemoryDB selects a subnet and IP addresses within that subnet to link to your nodes using that subnet group.
Access Control Lists
A group of one or more users is called an access control list. Access strings allow users to access Redis OSS or Valkey commands and data by adhering to the ACL requirements.
Users
On your MemoryDB cluster, a user is used to access data and issue commands. They have a user name and password. You can utilise the Access Control List (ACL) that a user is a part of to find out their rights on MemoryDB clusters.
Selecting Availability Zones and Regions
Resources for AWS Cloud computing are kept in highly accessible data centre buildings. These data centre facilities are situated in many physical locations to offer extra scalability and dependability. These places are divided into Availability Zones and regions.
AWS Regions are sizable and extensively distributed over various geographical areas. Within an AWS Region, Availability Zones are discrete areas designed to be insulated from other Availability Zone failures. In the same AWS Region, they offer low-cost, low-latency network connectivity to different Availability Zones.
Use the appropriate regional service endpoint to establish or interact with a cluster in a certain region.
MemoryDB Multi-Region offers low latency local reads and writes for Multi-Region applications, while simultaneously enhancing availability and resilience.
Finding your nodes
Clusters with a minimum of one duplicate must be dispersed throughout AZs. A cluster made up of single-node shards is the only way to find everything in a single AZ.
MemoryDB removes the possibility that a failure, like a power outage, in one AZ may result in loss of availability by placing the nodes in separate AZs.
- Setting up a cluster for MemoryDB
- Making changes to a MemoryDB cluster
Endpoints and Regions Supported
MemoryDB is accessible across several AWS regions. This implies that MemoryDB clusters can be started in any location that suits your needs. For instance, you can launch in the AWS Region that is nearest to your clients or in a specific AWS Region to comply with regulatory requirements. Additionally, MemoryDB supports the two most recent MAJOR.MINOR versions available for the new AWS Region at the time of availability expansion.
The US-East (N. Virginia) Region is referenced by default in the MemoryDB console, AWS SDKs, AWS CLI, and MemoryDB API. You can utilise new endpoints for these regions in your HTTP queries, the AWS SDKs, the AWS CLI, and the console when MemoryDB extends its availability to new regions.
Every Region is intended to be totally separate from every other Region. There are several Availability Zones (AZ) in each region. The most fault tolerance is attained by launching your nodes in many AZs.
Region Name/Region | Endpoint | Protocol |
---|---|---|
US East (Ohio) Regionus-east-2 | memory-db.us-east-2.amazonaws.com | HTTPS |
US East (N. Virginia) Regionus-east-1 | memory-db.us-east-1.amazonaws.com | HTTPS |
US West (N. California) Regionus-west-1 | memory-db.us-west-1.amazonaws.com | HTTPS |
US West (Oregon) Regionus-west-2 | memory-db.us-west-2.amazonaws.com | HTTPS |
Canada (Central) Regionca-central-1 | memory-db.ca-central-1.amazonaws.com | HTTPS |
Asia Pacific (Hong Kong) Regionap-east-1 | memory-db.ap-eastl-1.amazonaws.com | HTTPS |
Asia Pacific (Mumbai) Regionap-south-1 | memory-db.ap-south-1.amazonaws.com | HTTPS |
Asia Pacific (Tokyo) Regionap-northeast-1 | memory-db.ap-northeast-1.amazonaws.com | HTTPS |
Asia Pacific (Seoul) Regionap-northeast-2 | memory-db.ap-northeast-2.amazonaws.com | HTTPS |
Asia Pacific (Singapore) Regionap-southeast-1 | memory-db.ap-southeast-1.amazonaws.com | HTTPS |
Asia Pacific (Sydney) Regionap-southeast-2 | memory-db.ap-southeast-2.amazonaws.com | HTTPS |
Europe (Frankfurt) Regioneu-central-1 | memory-db.eu-central-1.amazonaws.com | HTTPS |
Europe (Ireland) Regioneu-west-1 | memory-db.eu-west-1.amazonaws.com | HTTPS |
Europe (London) Regioneu-west-2 | memory-db.eu-west-2.amazonaws.com | HTTPS |
EU (Paris) Regioneu-west-3 | memory-db.eu-west-3.amazonaws.com | HTTPS |
Europe (Stockholm) Regioneu-north-1 | memory-db.eu-north-1.amazonaws.com | HTTPS |
Europe (Milan) Regioneu-south-1 | memory-db.eu-south-1.amazonaws.com | HTTPS |
South America (São Paulo) Regionsa-east-1 | memory-db.sa-east-1.amazonaws.com | HTTPS |
China (Beijing) Regioncn-north-1 | memory-db.cn-north-1.amazonaws.com.cn | HTTPS |
China (Ningxia) Regioncn-northwest-1 | memory-db.cn-northwest-1.amazonaws.com.cn | HTTPS |