Migration from Tair (Redis OSS-Compatible) to GeminiDB Redis API

1. Select ApsaraDB for Redis Enhanced Edition (Tair) as the source. To use an EIP for migration, select Public IP Address for the destination database and enter the EIP for Hostname or IP address. To use a direct connection, select Self-managed Database on ECS for the destination database, enter the ECS IP address for Hostname or IP address, and enter a forwarding port for Port Number. Enter the database password and click Test Connectivity and Proceed. You will proceed with the next step if the test is successful. If there is an exception, check whether the entire migration flow is normal and whether the whitelist configuration is correct.
   Figure 1 Source and destination database configurations
   

2. Select Full Data Migration or Full Data Migration + Incremental Data Migration. Select Precheck and Report Errors and select the database to be migrated.
   

   You can also select multiple databases. If only one database can be migrated, select 0.

   Figure 2 Database to be migrated
   
   Figure 3 Advanced settings
   

3. After the precheck is complete, click Next: Purchase Instance.
   Figure 4 Precheck
   

4. Select the bandwidth for the migration and click Buy and Start.
   Figure 5 Bandwidth configuration
   

5. If Full Data Migration + Incremental Data Migration is selected, the migration task will not automatically stop. If there is no delay (0 ms), the full synchronization is complete.
   Figure 6 Task status
   

1. After the migration, stop the data synchronization task.
   Figure 7 Stopping the data migration task
   

After the migration is complete, you can check data consistency.

• Data has been migrated, or incremental migration has started.
• Redis-full-check must be deployed on the ECS, and the ECS is connected to the source and destination databases.
• During incremental migration, data may be inconsistent due to network latency between the source and destination databases. You are advised to stop writing data to the source and then verify data consistency.
• When Redis is used, an expiration time is usually set for keys. During migration, setting a key expiration time affects data consistency. Data may be inconsistent due to inconsistent expiration time.

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

Procedure

1. Log in to the ECS and ensure it is connected to the source and destination 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 database address and port	-s 10.0.0.1:6379
   -p	Source database password	-
   -t	Destination database address and port	-t 10.0.0.2:6379
   -a	Destination database password	-
   -m	Verification mode: All key-value pairs Value length only Key integrity only 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 a file saving the verification result. The default value is result.db.	-d result.db

4. Check 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 there are abnormal keys.