Redis Database Migration Across Servers: A Practical Guide from Data Dump to Full Deployment

Core Concepts of Redis Database Migration

Redis, as an in-memory database, differs significantly from traditional relational databases like MySQL in its data persistence mechanism. MySQL typically migrates data via SQL export/import, while Redis relies on RDB (Redis Database) snapshot files. This distinction stems from Redis's memory-first architecture, where data primarily resides in RAM and is periodically or on-demand persisted to disk.

The RDB file (commonly named dump.rdb) is a binary snapshot of Redis data, containing the complete state of the database at a specific point in time. Migrating a Redis database essentially involves creating a copy of this file and using it to initialize a new instance on the target server. This approach avoids complex replication setups and is suitable for one-time complete migration scenarios.

Detailed Migration Process

The migration process can be divided into four phases: data dumping, file transfer, target server configuration, and verification startup. Each phase requires precise operations to ensure data integrity and service continuity.

Data Dumping Phase

On the source server (referred to as Server A), the first step is to create the latest data snapshot. Redis offers two commands: SAVE and BGSAVE. The SAVE command blocks the Redis server until the snapshot is complete, preventing other requests during this period but guaranteeing data consistency. In contrast, BGSAVE executes in the background, allowing the server to continue handling requests, but may result in minor data desynchronization during the snapshot.

For migration scenarios, using SAVE is recommended to ensure complete data consistency. Before execution, confirm the RDB file storage location:

redis-cli CONFIG GET dir

This returns a path like /var/lib/redis/, indicating the default location of dump.rdb. Then execute:

redis-cli SAVE

After the command returns OK, the snapshot file is updated. Note that Redis also automatically saves snapshots periodically based on configuration, but manual execution ensures the data is up-to-date at migration time.

File Transfer Phase

Transfer dump.rdb from Server A to the target server (Server B). Using the scp command enables secure copying:

scp /var/lib/redis/dump.rdb user@B:/tmp/dump.rdb

Here, /tmp/dump.rdb is a temporary storage location to avoid directly overwriting existing files on the target server. After transfer, verify file integrity, e.g., by comparing MD5 hashes.

Target Server Configuration

On Server B, stop the Redis service to replace the data file:

sudo service redis-server stop

Then copy the file to the Redis data directory and set correct permissions:

sudo cp /tmp/dump.rdb /var/lib/redis/dump.rdb
sudo chown redis:redis /var/lib/redis/dump.rdb

Permission settings are critical, as the Redis process typically runs as the redis user, and lack of proper permissions can cause startup failures.

Startup and Verification

Start the Redis service:

sudo service redis-server start

Verify successful migration: Connect to the Redis CLI and check data completeness, e.g., using the INFO keyspace command to view key counts. Simultaneously, monitor log files (e.g., /var/log/redis/redis-server.log) to confirm no errors.

Advanced Considerations

Version compatibility is a key factor in migration. The target server's Redis version should be equal to or higher than the source server's, as the RDB format may change with version updates. For example, RDB files from Redis 5.0 might contain data structures unsupported by Redis 4.0. Referring to the official RDB version history can prevent compatibility issues.

For large databases, the blocking time of SAVE might be lengthy, affecting production environments. In such cases, consider executing during off-peak hours or using BGSAVE combined with brief service pauses. Another option is using the redis-cli --rdb command to export data, but ensure Redis configuration permits this operation.

File permission errors are common issues. Beyond chown, check if security modules like SELinux or AppArmor restrict file access. In cloud environments, instance storage types (e.g., SSD vs. HDD) may impact RDB file loading speed.

Alternative Approaches and Supplements

While SAVE is the standard method, BGSAVE can be used for non-blocking migration, suitable for scenarios intolerant to service interruptions. However, this may lead to data inconsistencies during migration, requiring handling at the application layer.

Replication is another migration method, involving setting up master-slave relationships to synchronize data, then promoting the slave to master. But as noted in the question, this is for continuous synchronization rather than one-time migration.

Tools like redis-rdb-tools can parse RDB files for data auditing or conversion, but add complexity to migration.

Conclusion

Redis database migration is a multi-step process centered on properly handling RDB snapshot files. By creating a consistent snapshot with the SAVE command, securely transferring the file, and configuring permissions before starting on the target server, smooth migration can be achieved. Version compatibility, permission management, and data verification are keys to success. For production environments, it is advisable to conduct trial runs on test servers and back up original data as a precaution. As the Redis ecosystem evolves, more efficient migration tools may emerge, but the current RDB-based method remains a reliable choice.