Preparing your source and target Redis OSS nodes for migration - Amazon ElastiCache (Redis OSS)
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Preparing your source and target Redis OSS nodes for migration

You must ensure that all four of the prerequisites mentioned following are satisfied before you start the migration from ElastiCache console, API or Amazon CLI.

To prepare your source and target Redis OSS Nodes for migration

  1. Identify the target ElastiCache deployment and make sure that you can migrate data to it.

    An existing or newly created ElastiCache deployment should meet the following requirements for migration:

    • It is using Redis OSS engine version 5.0.6 or higher.

    • It doesn't have either encryption in-transit or encryption at-rest enabled.

    • It has Multi-AZ enabled.

    • It has sufficient memory available to fit the data from your Redis OSS cluster. To configure the right reserved memory settings, see Managing Reserved Memory.

    • For cluster-mode disabled, you can migrate directly from Redis OSS versions 2.8.21 onward to Redis OSS version 5.0.6 onward if are using the CLI or Redis OSS versions 5.0.6 onward using the CLI or console. For cluster mode enabled, you can migrate directly from any cluster-mode enabled Redis OSS version to Redis OSS version 5.0.6 onward if are using the CLI or Redis OSS versions 5.0.6 onward using the CLI or console.

    • Number of shards in source and target match.

    • It is not part of a global datastore.

    • It has data tiering disabled.

  2. Make sure that the configurations of your open-source Redis OSS and the ElastiCache (Redis OSS) deployment are compatible.

    At a minimum, all the following in the target ElastiCache deployment should be compatible with your Redis OSS configuration for Redis OSS replication:

    • Your Redis OSS cluster should not have Redis OSS AUTH enabled.

    • Redis OSS config protected-mode should be set to no.

    • If you have bind configuration in your Redis OSS config, then it should be updated to allow requests from ElastiCache nodes.

    • The number of logical databases should be the same on the ElastiCache node and your Redis OSS cluster. This value is set using databases in the Redis OSS config.

    • Redis OSS commands that perform data modification should not be renamed to allow replication of the data to succeed. for example sync, psync, info, config, command, and cluster.

    • To replicate the data from your Redis OSS cluster to ElastiCache, make sure that there is sufficient CPU and memory to handle this additional load. This load comes from the RDB file created by your Redis OSS cluster and transferred over the network to ElastiCache node.

    • All Redis OSS instances in the source cluster should be running on the same port.

  3. Make sure that your instances can connect with ElastiCache by doing the following:

    • Ensure that each instance's IP address is private.

    • Assign or create the ElastiCache deployment in the same virtual private cloud (VPC) as your Redis OSS on your instance (recommended).

    • If the VPCs are different, set up VPC peering to allow access between the nodes. For more information on VPC peering, see Access Patterns for Accessing an ElastiCache Cache in an Amazon VPC.

    • The security group attached to your Redis OSS instances should allow inbound traffic from ElastiCache nodes.

  4. Make sure that your application can direct traffic to ElastiCache nodes after migration of data is complete. For more information, see Access Patterns for Accessing an ElastiCache Cache in an Amazon VPC.