Verifying Redis Data Consistency After Migration

Constraints

• The Redis migration has been completed, or the incremental migration has started.
• The Redis-Full-Check open-source tool must be deployed on the ECS instance, and the ECS instance can communicate with the source and target networks.
• If the migration task is in the incremental state, data consistency cannot be ensured due to network latency between the source and target ends. If conditions permit, you are advised to stop writing data to the source end and then perform the verification.
• When Redis is used, an expiration time is usually set for keys. During migration, setting a key expiration time affects data consistency. If verification results show that data is inconsistent, the possible cause is that the key expiration time is inconsistent.

• During the migration, DTS writes temporary probing keys to Redis on the destination end. Non-service data may be detected during data verification, which is normal.

Procedure

1. Log in to the ECS and ensure that the ECS can connect to the source and destination Redis databases.
2. Deploy Redis-Full-Check.
3. Verify data.

   /redis-full-check -s {Source IP address}:{Source port} -p {Source password} -t {Destination IP address}:{Destination port} -a {Destination password} -m 1

   Table 1 Parameter description

   Parameter	Description	Example Value
   -s	Source Redis connection address and port number	-s 10.0.0.1:6379
   -p	Password of the source Redis database.	-
   -t	Destination Redis connection address and port number	-t 10.0.0.2:6379
   -a	Password of the destination Redis database.	-
   -m	Verification mode: Verify all key-value pairs. Only value length is verified. Only key integrity is verified. All key values are verified, but only the length of big keys is verified. By default, the second verification mode is used.	-m 1
   -q	Maximum QPS. The default value is 15000.	-q 5000
   -d	Name of the file for saving the verification result. The default value is result.db.	-d result.db

4. View the verification result file.

   By default, three rounds of verification are performed and three verification result files are generated. Generally, you only need to view the last verification result file.

   • Run the sqlite3 result.db.3 command.
   • Run the select * from key command.
   • Check whether abnormal keys exist.