After Redis data is migrated, you must check whether the data is consistent between the source and destination instances.

Prerequisites

  • Redis data is migrated.
    Note For more information about how to migrate data in ApsaraDB for Redis, see Overview.
  • The source and destination Redis instances are in the following architectures: master-replica, standalone, open-source cluster, ApsaraDB for Redis cluster with proxy nodes, and TencentDB for Redis cluster with proxy nodes.
  • A Linux-based Elastic Compute Service (ECS) instance is created for running the redis-full-check tool. For more information, see Create an ECS instance.
  • The ECS instance can access the source and destination Redis instances.
    Note
    • If the ECS instance and the source or destination 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 Redis instance. For more information, see Set IP address whitelists.
    • If the ECS instance and the source or destination Redis instance are not in the same VPC, the ECS instance can access the Redis instance through the public endpoint. For more information, see Through the Internet.

Introduction to the redis-full-check tool

If an exception occurs during Redis data migration, the data is inconsistent between the source and destination Redis instances. You can use the redis-full-check tool to find the inconsistent data.

The redis-full-check tool is a Redis data verification tool developed by Alibaba Cloud. It can extract data from the source and destination instances, compare them for multiple times, and then record the comparison results in an SQLite3 database. This tool can be used to verify full data.

Note For more information about the redis-full-check tool, see redis-full-check on GitHub.

Procedure

  1. Log on to the ECS instance. For more information, see Connect to an ECS instance.
  2. Download the redis-full-check tool on the ECS instance.
    Note We recommend that you download the latest version.
  3. Run the following command to decompress the redis-full-check.tar.gz package:
    tar -xvf redis-full-check.tar.gz
  4. Run the following command to verify data:
    ./redis-full-check -s "<Endpoint 1 of the source Redis cluster:Port of endpoint 1;Endpoint 2 of the source Redis cluster:Port of endpoint 2;Endpoint 3 of the source Redis cluster:Port of endpoint 3;>" -p <Password of the source Redis cluster> -t <Endpoint of the destination Redis instance:Port> -a <Password of the destination Redis instance> --comparemode=1 --comparetimes=1 --qps=10 --batchcount=100 --sourcedbtype=1 --targetdbfilterlist=0

    The following table describes common parameters of the redis-full-check tool. For more information, see Configure redis-full-check.

    Table 1. Common parameters of redis-full-check
    Parameter Description Example
    -s The endpoint and port of the source Redis instance.
    Note
    • If the source Redis instance is a cluster, separate cluster endpoints with semicolons (;).
    • Enclose the cluster endpoints in a pair of double quotation marks (").
    • This parameter is required.
    r-bp1xxxxxxxxxxxxx.redis.rds.aliyuncs.com:6379
    "10.xx.xx.1:7000;10.xx.xx.1:7001;10.xx.xx.2:7002;10.xx.xx.2:7003"
    -p The password of the source Redis instance. SourcePwd233
    -t The endpoint and port of the destination Redis instance.
    Note
    • If the destination Redis instance is a cluster, separate cluster endpoints with semicolons (;).
    • Enclose the cluster endpoints in a pair of double quotation marks (").
    • This parameter is required.
    r-bp1xxxxxxxxxxxxx.redis.rds.aliyuncs.com:6379
    "10.xx.xx.1:7000;10.xx.xx.1:7001;10.xx.xx.2:7002;10.xx.xx.2:7003"
    -a The password of the destination Redis instance. TargetPwd233
    --sourcedbtype The type of the source Redis instance. Valid values:
    • 0: standalone or master-replica.
    • 1: cluster.
    • 2: ApsaraDB for Redis or TencentDB for Redis.
    --sourcedbtype=1
    --sourcedbfilterlist The databases for which you want to verify data in the source Redis instance.
    Note
    • This parameter is not required for open-source Redis clusters.
    • If you do not set this parameter, the data in all databases is verified.
    • Separate multiple databases with semicolons (;).
    --sourcedbfilterlist=0;1;2
    --targetdbtype The type of the destination Redis instance. Valid values:
    • 0: standalone or master-replica.
    • 1: cluster.
    • 2: ApsaraDB for Redis or TencentDB for Redis.
    --targetdbtype=0
    --targetdbfilterlist The databases for which you want to verify data in the destination Redis instance.
    Note
    • This parameter is not required for open-source Redis clusters.
    • If you do not set this parameter, the data in all databases is verified.
    • Separate multiple databases with semicolons (;).
    --targetdbfilterlist=0;1;2
    -d The name of the file for storing inconsistent keys. Default value: result.db. xxx.db
    --comparetimes The number of times that the data is verified.
    • Default value: 3.
    • Minimum value: 1.
    • We recommend that you set this parameter to a value that does not exceed 5.
    --comparetimes=1
    -m The verification mode. Valid values:
    • 1: verifies full data.
    • 2: only verifies the length of the value.
    • 3: only checks whether the keys exist.
    • 4: verifies full data except for big keys.
    1
    --qps The queries per second (QPS).
    Note
    • Minimum value: 1.
    • Maximum value: depends on the server performance.
    --qps=10
    --filterlist The keys to verify. Separate multiple keys with vertical bars (|).
    Note
    • abc*: matches all keys that start with abc.
    • abc: matches the abc key.
    --filterlist=abc*|efg|m*
    Note After the verification is completed, the comparison result appears on the CLI. For example, the following result indicates that two keys are inconsistent between the source and destination Redis instances. If the number of inconsistent keys is 0, the data is consistent between the source and destination Redis instances.
    all finish successfully, totally 2 keys or fields conflict
  5. Query the inconsistent keys in the SQLite3 database.
    1. Run the sqlite3 result.db.3 command.
      Note Inconsistent keys are stored in result.db.3 by default.
    2. Run the SELECT * FROM key; statement.
      Figure 1. Query inconsistent keys
      Note The SQLite3 database provides the key and field tables.
      • The key table stores the inconsistent keys.
      • The field table stores details about inconsistent data of the hash, set, zset, and list types.