You can use the sync mode of the redis-shake tool to migrate the data of an on-premises Codis or Redis cluster to an ApsaraDB for Redis instance.

Note For more information about how to migrate the data of a standalone Redis instance, see Use redis-shake to migrate data.

Prerequisites

  • An ApsaraDB for Redis instance is created as the destination of data migration. For more information about how to create an ApsaraDB for Redis instance, see Step 1: Create an instance.
  • An Elastic Compute Service (ECS) instance is created for running the redis-shake tool. The 64-bit Linux operating system is running on the ECS instance. For more information about how to create an ECS instance, see Create an ECS instance.
  • The ECS instance can access the destination ApsaraDB for Redis instance.
    Note
    • If the ECS instance and the destination ApsaraDB for Redis instance are in the same Virtual Private Cloud (VPC), you must add the internal IP address of the ECS instance to the whitelist of the destination ApsaraDB for Redis instance. For more information, see Set an IP address whitelist.
    • If the ECS instance and the destination ApsaraDB for Redis instance are not in the same VPC, the ECS instance can access the destination ApsaraDB for Redis instance through the public endpoint. For more information, see Through the Internet.

Limits

  • The sync mode applies to scenarios such as data migration from on-premises Redis to the cloud, data synchronization between on-premises Redis and ApsaraDB for Redis, and data synchronization between on-premises Redis databases. Currently, ApsaraDB for Redis instances of the cluster edition cannot act as the source of data migration in sync mode.
  • In sync mode, the source Redis must support the SYNC and PSYNC command.

Introduction to the redis-shake tool

The redis-shake tool is an open-source tool developed by Alibaba Cloud. You can use it to parse (decode mode), recover (restore mode), back up (dump mode), and synchronize (sync or rump mode) Redis data. In sync mode, the redis-shake tool runs the SYNC or PSYNC command to synchronize full or incremental data from the source Redis to the destination Redis. Incremental synchronization automatically starts after full synchronization is completed. This topic describes how to use the sync mode of the redis-shake tool to migrate the data of an on-premises Codis or Redis cluster to an ApsaraDB for Redis instance.

Note
  • The sync mode supports data synchronization between different Redis versions, for example, between Redis 2.8 and Redis 4.0.
  • For more information about the redis-shake tool, see redis-shake on GitHub or FAQ.

Procedure

  1. Log on to the ECS instance that can access the destination ApsaraDB for Redis instance.
  2. Download the redis-shake tool on the ECS instance.
    Note We recommend that you download the latest version.
  3. Run the following command to decompress the redis-shake.tar.gz package:
    tar -xvf redis-shake.tar.gz
    Note In the decompressed folder, the redis-shake file is a binary file that can run in the 64-bit Linux operating system. The redis-shake.conf file is the configuration file of the redis-shake tool. You must modify this configuration file in the next step.
  4. Modify the redis-shake.conf file. The following table describes the parameters for the sync mode of the redis-shake tool.
    Parameter Description Example
    source.type The type of the source Codis or Redis cluster. cluster
    source.address The endpoint and port of the source Codis or Redis cluster. 10.xx.xx.1:7000;10.xx.xx.1:7002;10.xx.xx.1:7003;10.xx.xx.1:7004
    source.password_raw The password of the source Codis or Redis cluster. SourcePass233
    target.type The type of the destination ApsaraDB for Redis instance. proxy
    target.address The endpoint and port of the destination ApsaraDB for Redis instance. For more information, see View endpoints. r-bpxxxxxxxxxxxxxxx.redis.rds.aliyuncs.com:6379
    target.password_raw The password of the destination ApsaraDB for Redis instance. TargetPass233
    rewrite Specifies whether to overwrite the existing keys that are identical to those in the RDB file. Valid values:
    • true
    • false
    Note Default value: true. We recommend that you back up the valid data of the destination ApsaraDB for Redis instance before migration. If you set this parameter to false and any keys are duplicate in the source and destination databases, an error message is returned.
    true
    target.db

    The database to which the data is migrated in the destination ApsaraDB for Redis instance.

    For example, to migrate data from the source on-premises Codis or Redis cluster to DB10 of the destination ApsaraDB for Redis instance, set this parameter to 10.

    If you set this parameter to -1, data in the source Codis or Redis cluster is migrated to the same database in the destination ApsaraDB for Redis instance. For example, the data of DB0 in the source Codis or Redis cluster is migrated to DB0 in the destination ApsaraDB for Redis instance, the data of DB1 in the source Codis or Redis cluster is migrated to DB1 in the destination ApsaraDB for Redis instance, and so on.

    0
    parallel The number of concurrent threads used to synchronize the RDB file. More concurrent threads improve synchronization performance.
    Note
    • Minimum value: 1.
    • Maximum value: depends on the server performance.
    • Recommended value: 64.
    64
  5. Run the following command to migrate data:
    ./redis-shake -type=sync -conf=redis-shake.conf
    Note You must run this command in the same directory as the redis-shake and redis-shake.conf files. Otherwise, you must specify the correct file path in the command.
  6. View synchronization logs to check the synchronization status. When sync rdb done appears, full synchronization is completed and incremental synchronization starts.
    Figure 1. Synchronization logs
    Note Whenever the data of a node in the Codis or Redis cluster is synchronized, sync rdb done appears.
  7. After the data of all nodes is synchronized, +forwardCommands=0 indicates that no data is written to the source database and no incremental data is being synchronized. In this case, switch your services to the new database.