All Products
Search

This Product

    Tair (Redis® OSS-Compatible):Verify migrated data

    Document Center

    Tair (Redis® OSS-Compatible):Verify migrated data

    Last Updated:Aug 27, 2025

    After the Tair (Redis OSS-compatible) migration is complete, you can use the redis-full-check tool to verify data consistency.

    Prerequisites

    • The data migration is complete.

    • An ECS instance that runs Linux has been created. 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 a Redis instance are in the same VPC and zone, add the private IP address of the ECS instance to the whitelist of the Redis instance. For more information, see Configure an IP whitelist.

      • If the ECS instance and a Redis instance are not in the same VPC or zone, use the public endpoint of the Redis instance to connect. For more information, see Use a public endpoint to connect to an instance.

    Scenarios

    If an exception occurs during data migration, data may become inconsistent between the source and destination instances. You can use the redis-full-check tool to find inconsistent data. The tool provides a reliable basis for data alignment.

    redis-full-check is a data verification tool developed by Alibaba Cloud for Redis. It extracts and compares data from the source and destination instances. The tool runs multiple comparison rounds and records the results in an SQLite3 database to verify the full dataset.

    Note

    For more information about the redis-full-check tool, see the redis-full-check homepage on Git.

    Procedure

    1. Log on to the ECS instance that can access the Tair (Redis OSS-compatible) instance. For more information, see Connect to an ECS instance.

    2. On the ECS instance, download redis-full-check.

      Note

      Download the latest version.

    3. Decompress the redis-full-check.tar.gz file. 

      tar -xvf redis-full-check.tar.gz

    4. Run the following command to verify the data: 

      ./redis-full-check -s "<Source endpoint 1:Port;Source endpoint 2:Port;...>" -p <Source password> -t <Destination endpoint:Port> -a <Destination password> --m=1 --sourcedbfilterlist=0;2 --targetdbfilterlist=0;2

      Example command:

      ./redis-full-check -s "10.xx.xx.1:6379" -p SourcePwd233 -t "r-bp1zc********.redis.rds.aliyuncs.com:6379" -a testaccount:Test1234 --m=1 --sourcedbfilterlist=0;2 --targetdbfilterlist=0;2

      The following table describes common options. For more information, see RedisFullCheck configuration.

      Table 1. Common options for redis-full-check

      Option

      Description

      Example value

      -s

      The endpoint and port of the source Redis instance.

      Note

      • If the source Redis instance is a cluster, separate the cluster endpoints with semicolons (;).

      • Enclose the cluster endpoints in double quotation marks (").

      • This option 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 username and password for the source Redis instance. Use the <username>:<password> format. Example: testaccount:Test1234. If the instance does not have a username, enter only the password. If the instance does not have a password, you can leave this option empty.

      SourcePwd233 or testaccount:Test1234

      -t

      The endpoint and port of the destination Redis instance.

      Note

      • If the destination Redis instance is a cluster, separate the cluster endpoints with semicolons (;).

      • Enclose the cluster endpoints in double quotation marks (").

      • This option 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 username and password for the destination Redis instance. Use the <username>:<password> format. Example: testaccount:Test1234. If the instance does not have a username, enter only the password. If the instance does not have a password, you can leave this option empty.

      TargetPwd233 or testaccount:Test1234

      --sourcedbtype

      The type of the source database.

      • 0 (default): Single Node Edition or Standard Edition

      • 1: Cluster Edition in direct connection mode

      • 2: Cluster Edition in proxy mode

      --sourcedbtype=1

      --sourcedbfilterlist

      The DBs to verify in the source Redis instance.

      Note

      • This option is not required for open source Redis clusters.

      • For other cluster types, if you do not specify this option, all DBs are verified.

      • Separate multiple DBs with semicolons (;).

      --sourcedbfilterlist=0;1;2

      --targetdbtype

      The type of the destination database.

      • 0 (default): Single Node Edition or Standard Edition

      • 1: Cluster Edition in direct connection mode

      • 2: Cluster Edition in proxy mode

      --targetdbtype=0

      --targetdbfilterlist

      The DBs to verify in the destination Redis instance.

      Note

      • This option is not required for open source Redis clusters.

      • For other cluster types, if you do not specify this option, all DBs are verified.

      • Separate multiple DBs with semicolons (;).

      --targetdbfilterlist=0;1;2

      -d

      The name of the file that stores the list of inconsistent data. The default name is result.db.

      xxx.db

      --comparetimes

      The number of verification rounds. The default value is 3. The minimum value is 1. There is no maximum value, but the recommended maximum is 5.

      --comparetimes=1

      -m

      The verification mode.

      • 1: Verifies full data.

      • 2 (default): Verifies only the length of the value.

      • 3: Checks only if the key exists.

      • 4: Verifies full data but ignores large keys.

      -m=1

      --qps

      The throttling threshold. The default value is 15000.

      Note

      • The minimum value is 1.

      • The maximum value depends on server performance.

      --qps=10

      --filterlist

      The list of keys to compare. Separate keys with a vertical bar (|).

      Note

      • abc*: Matches all keys that start with abc.

      • abc: Matches only the key abc.

      --filterlist=abc*|efg|m*

      Note

      After you run the command, the verification result is displayed in the command line. The following output indicates that two keys are inconsistent. If the number of inconsistent keys is 0, the data is consistent. 

      all finish successfully, totally 2 keys or fields conflict

    5. Check the SQLite3 database that stores the inconsistent keys.

      1. Run the sqlite3 result.db.3 command.

        Note

        By default, the list of inconsistent data is saved to the result.db.3 file.

      2. Run the SELECT * FROM key; command.

        Figure 1. View the list of inconsistent data

        Note

        The SQLite3 database contains the `key` and `field` tables.

        • The `key` table stores the inconsistent keys.

        • The `field` table stores details about inconsistencies in hash, set, zset, and list data types.