The safest low-downtime Redis migration is to attach the new server as a replica of the existing master, let it synchronize, verify that it is current, then briefly stop writes and redirect clients. Redis performs an incremental PSYNC when the master’s replication backlog still contains the required history; otherwise it creates and transfers an RDB snapshot before streaming newer writes. Because replication is asynchronous, “caught up” must be measured and a rollback path retained until application checks pass.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
What master–replica migration does
A live replica migration keeps the old Redis instance serving the application while a destination instance builds a copy. The destination is configured with REPLICAOF <source-host> <source-port> (or the equivalent replicaof directive in redis.conf). Redis then connects to the source, authenticates if required, synchronizes the dataset, and continuously replays new writes.
As an Amazon Associate I earn from qualifying purchases.
This is different from exporting an RDB file and importing it manually. An export is a point-in-time copy: writes made after the export must be captured separately, and the final outage depends on how that delta is handled. A live replica receives the delta continuously, so the final cutover can usually be limited to quiescing writes and switching connection endpoints.
The method is appropriate when the destination can run compatible Redis commands and modules, the network can carry the initial copy and ongoing write stream, and you can schedule a short write pause for the final handoff. It does not provide zero risk: replication is asynchronous, so a source failure can still leave a small set of acknowledged writes unprocessed by the destination.
#1 Best Overall
- MADE FOR THE MAKERS: Create; Explore; Store; The T7 Portable SSD delivers fast speeds and durable features to back up any endeavor; Build your video editing empire, file your photographs or back up your blogs all in an instant
- SHARE IDEAS IN A FLASH: Don’t waste a second waiting and spend more time doing; The T7 is embedded with PCIe NVMe technology that brings fast read and write speeds up to 1,050/1,000 MB/s¹, making it almost twice as fast as the T5
- ALWAYS MAKE THE SAVE: Compact design with massive capacity; With capacities up to 4TB, save exactly what you need to your drive – from large working files to game data and everything in between
- ADAPTS TO EVERY NEED: Whether using a PC or mobile phone, count on the T7 for extensive compatibility²; It’s a true team player when it comes to heavy-duty application usage or file-saving
- HI RESOLUTION VIDEO RECORDING: Record Ultra High Resolution (4K 60fs) videos directly onto the T7 Portable SSD with your favorite camera or mobile devices; Supports iPhone 15 Pro Res 4K at 60fps video and more³
Plan the migration before touching Redis
Size the destination
- Memory: provide enough RAM for the complete dataset, allocator overhead, client buffers, replication buffers, and the temporary memory needed while loading an RDB. Leave headroom for normal growth.
- Disk: full synchronization creates or transfers an RDB and requires space for the file and temporary files. Confirm that the destination’s persistence settings and filesystem can sustain the write rate.
- Network: measure available bandwidth between source and destination. The initial dataset and the live command stream share this link; a saturated link increases lag and can make a partial resynchronization impossible.
- CPU and latency: snapshotting, compression, TLS, and RDB loading consume CPU. Match the destination’s latency and throughput requirements rather than sizing only for raw dataset bytes.
- Compatibility: use a Redis version and configuration that support every command, data type, module, eviction policy, and persistence feature used by the application.
Protect the replication channel
Permit the destination to reach the source only over the required network path. Apply firewall or security-group rules, restrict the source’s listening interfaces, and use TLS when traffic crosses an untrusted network. Replication credentials must have exactly the permissions needed for authentication and synchronization.
Record a rollback plan
Keep the old master intact and reachable after the client switch. Decide how clients will discover Redis (DNS, service discovery, a configuration variable, or a proxy), how you will reverse that change, and how long the source will be retained. Do not decommission it immediately after the first successful connection.
Configure the destination as a replica
Persistent configuration
On the destination, add the source address to redis.conf:
replicaof source.example.internal 6379Restart Redis according to your service-management procedure, then inspect its logs and runtime status. A configuration-file change is durable across restarts, which is important if synchronization takes longer than expected.
Runtime configuration
For a running destination, issue:
REPLICAOF source.example.internal 6379The runtime command takes effect immediately but is lost if the configuration is not also updated. To detach later, use REPLICAOF NO ONE; do this only at the deliberate promotion or cutover stage.
Password authentication
If the source uses password authentication, configure the destination’s replication password with masterauth in the configuration, or set the corresponding runtime option according to your deployment’s secret-management practice. The password must match the source’s authentication setup.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesRank #2
- Get NVMe solid state performance with up to 1050MB/s read and 1000MB/s write speeds in a portable, high-capacity drive(1) (Based on internal testing; performance may be lower depending on host device & other factors. 1MB=1,000,000 bytes.)
- Up to 3-meter drop protection and IP65 water and dust resistance mean this tough drive can take a beating(3) (Previously rated for 2-meter drop protection and IP55 rating. Now qualified for the higher, stated specs.)
- Use the handy carabiner loop to secure it to your belt loop or backpack for extra peace of mind.
- Help keep private content private with the included password protection featuring 256‐bit AES hardware encryption.(3)
- Easily manage files and automatically free up space with the SanDisk Memory Zone app.(5). Non-Operating Temperature -20°C to 85°C
ACL authentication on Redis 6 and later
With ACLs, create or designate a replication user on the source and configure both its username and password on the destination using masteruser and the associated secret. The account needs permission for PSYNC and the replication-related commands required by the source. A password alone is not sufficient when the source requires a named ACL user.
How Redis synchronizes the dataset
Partial synchronization with PSYNC
Redis records a replication ID and an offset for the stream of writes. When the destination connects, it sends the previous master ID and the offset it has processed. Redis has supported this PSYNC mechanism since Redis Open Source 2.8.0.
If the source still has the requested history in its replication backlog and the ID is valid, it sends only the missing commands. This is the fast path after a short network interruption or a restart where the destination retained its replication state.
Full synchronization with an RDB snapshot
A full sync occurs when the destination’s replication ID is unknown or the source’s backlog no longer contains the required offset. The source creates an RDB snapshot in the background, transfers it, and then sends the writes that accumulated while the snapshot was being created. The destination loads the snapshot and applies the streamed commands.
Loading the initial dataset happens in the destination’s main thread and can briefly block client connections, especially for a large database. Treat the first synchronization as an availability event for the new server, even though the old master can continue serving clients during most of the transfer.
Replication IDs after failover
Since Redis 4.0, a promoted replica can retain the old replication ID and offset, allowing a reconnecting replica to attempt partial synchronization after a failover when the necessary backlog is still available. This behavior helps failover recovery but does not eliminate the need to monitor offsets and backlog capacity.
Rank #3
- Capacity Display Variance: 250GB external ssd often appears as around 232GB on Windows. MacOS can show full 250 GB capacity. This is binary calculation difference and doesn’t affect SSD hard drive actual physical storage
- 1050 MB/s Speed: Instantly access to your files with blazing-fast 10Gbps external SSD read up to 1050MB/s and write up to 1000MB/s. LED Light indicates USB SSD instant activity
- Data Security: Solid state drives S.M.A.R.T. health diagnostics and adaptive TRIM optimizing data block management ensures consistent write speeds and extends the longevity of the portable SSD
- USB-C & USB-A Cable: Both cables featuring rapid USB 3.2 Gen2, this USB SSD effortlessly bridges devices, enabling seamless cross-platform file transfers and backup between computers, smartphones, tablets and iPhone
- Always Fast: No slowdowns for large file transfers. With SLC caching (25% of current available capacity allocated as high-speed cache), this external SSD delivers steady 10Gbps for transfers within the cache capacity
Monitor synchronization and decide when it is ready
Run INFO replication on the destination and source. The following fields are the most useful cutover signals:
| Check | Healthy indication | Why it matters |
|---|---|---|
master_link_status |
up |
The destination currently has a working link to its source. |
master_sync_in_progress |
0 |
The initial synchronization or a subsequent full sync has finished. |
master_repl_offset on the source |
Close to the destination’s processed offset | The difference is the current replication lag in bytes of the command stream. |
master_last_io_seconds_ago |
Recent and advancing during writes | Shows whether replication traffic is arriving rather than silently stalling. |
| Reconnect and sync counters | No repeated failures | Repeated reconnects can indicate authentication, network, resource, or backlog problems. |
The ROLE command provides a second view. On the destination it identifies the instance as a replica and reports its master connection state and replication offset. Compare the source’s current offset with the destination’s offset repeatedly under normal write load; a single close reading is not proof that the replica will remain current.
Free tools Windows power users keep installed
One-click scans. No signup required.
Capture these values during a representative busy period. If the gap grows continuously, the destination cannot process the incoming stream fast enough or the network is constrained. Do not schedule cutover until the gap is stable, the link remains up, and no synchronization failures recur.
Validate data before switching clients
Replication status proves that commands have been transferred; it does not prove that the application’s invariants are correct. Perform checks that match your data model:
- Read representative keys from both instances, including strings, hashes, lists, sets, sorted sets, streams, and module-owned data where applicable.
- Compare key counts or database-level counts when those metrics are meaningful for your workload. For very large datasets, use a documented sample rather than an exhaustive scan that would disturb production latency.
- Check TTL behavior on expiring keys. Confirm that remaining lifetimes are within an expected tolerance and that keys scheduled to expire are not unexpectedly persistent.
- Verify ACL users, command permissions, module versions, notifications, and configuration required by the application.
- Run application-level invariants: for example, totals, idempotency markers, session state, queue lengths, or referential relationships that a raw key count cannot detect.
- Exercise reads through the destination using a staging or controlled client before production traffic is redirected.
Redis does not define one universal checksum or validation command for every data type. Choose checks that are safe for your workload and record their results so the post-cutover comparison is objective.
Perform the final cutover
Prepare the change as a short, controlled write outage. The precise commands depend on your client-discovery system, but the sequence should be:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #4
- Easily store and access 2TB to content on the go with the Seagate Portable Drive, a USB external hard drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
- Announce or enforce write quiescence. Stop job workers and application writes, place the application in read-only or maintenance mode, or use an application-level gate. Existing connections can still issue writes unless the application is actually quiesced.
- Wait for the final stream to drain. Continue checking
INFO replicationandROLE. The source and destination offsets should converge and remain equal while writes are stopped. - Re-run critical validation. Check representative keys, TTLs, counts, and application invariants after the last write has been processed.
- Redirect clients. Change the service endpoint, DNS record, configuration value, or proxy target to the destination. Account for connection pools and DNS caching; restart or recycle clients when necessary.
- Confirm destination behavior. Verify reads and permitted writes through normal application paths. Watch latency, errors, memory, persistence, and replication state.
- Promote deliberately. If the destination is now the standalone master, issue
REPLICAOF NO ONEonly after clients are directed to it and your deployment design calls for detaching. If you are keeping a replica chain, configure the next relationship instead. - Retain the source for rollback. Do not erase or repurpose it until post-cutover checks pass for the retention period you selected.
Keeping writes stopped until the destination has processed the final offset avoids the most common migration error: switching clients while the replica is still missing the last acknowledged commands.
Understand the consistency and data-loss boundary
Redis uses asynchronous replication by default because it provides low latency and high performance for most use cases. The source does not wait for every replica to process each write. If the source fails while commands are in flight, the destination may not contain those writes.
The WAIT command can ask Redis to wait for a specified number of replicas to acknowledge writes. It can reduce the probability of losing a recent write, but Redis explicitly states that WAIT does not turn a group of instances into a strongly consistent CP system. Acknowledged writes can still be lost during some failover scenarios. Treat WAIT as a risk-reduction tool, not a replacement for a quiesced cutover and application validation.
Replication backlog, disconnects, and repeated full syncs
When the replication link breaks, the destination reconnects and requests a partial resynchronization. The source can satisfy that request only while the missing history remains in its backlog. A short backlog combined with a high write rate can overwrite the needed commands before the destination reconnects, forcing another full RDB transfer.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteBacklog sizing must reflect the largest plausible outage multiplied by the write-stream rate, with additional safety margin. Redis Software documents a product default of 1% of database size divided by shard count, bounded between 1 MB and 250 MB per shard. That figure is a Redis Software product default, not a universal Redis Open Source rule; measure your own stream rate and outage window instead of copying it blindly.
Repeated full syncs increase network, disk, and CPU consumption and can lengthen destination loading time. Investigate link drops, authentication failures, slow disks, insufficient memory, and a backlog that is too small. Alert on sync failures and on a lag that grows rather than merely checking whether the link is currently marked up.
Best Value
- NEARLY 2X FASTER THAN OUR PREVIOUS GENERATION(8) – move 1,000 high-res photos in under 60 seconds(6) with up to 2000MB/s transfer speeds(2).
- IP65 RATING AND UP TO 3M DROP PROTECTION(3) – protects against spills and drops.
- POCKET-SIZED – fits easily in pockets and small bags.
- SPACE TO OWN YOUR AI CONTENT – speed and capacity to download your high-res clips and photo edits.
- 256-BIT AES ENCRYPTION(4) – helps keep private files secure with password protection.
Decide whether replicas may serve stale data
With the upstream default, a replica can continue serving reads from its last dataset while disconnected. This may be useful for availability but can expose stale values. Set replica-serve-stale-data no if serving stale data is worse than returning an error. During a link outage, commands that require current master data then return a MASTERDOWN error until synchronization resumes.
Choose this setting per application. A cache or read-heavy feature may tolerate stale values; balances, inventory, authorization, and workflow state often require an explicit failure instead. Document the choice and test the application’s behavior when the error is returned.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Live replication versus RDB export/import
| Decision factor | Live replica migration | RDB export/import |
|---|---|---|
| Downtime tolerance | Usually a short write pause for final cutover; the initial copy runs while the source serves traffic. | Downtime depends on how writes after the export are captured and replayed; a simple export/import often requires a longer freeze. |
| Writes during transfer | Supported continuously; Redis streams writes generated during and after the snapshot. | Writes after the export are not included unless you build a separate delta process. |
| Bandwidth pattern | Initial RDB transfer plus an ongoing command stream; a failed partial sync may repeat the large transfer. | One planned file transfer, followed by whatever mechanism you use for post-export changes. |
| Dataset size | Large datasets are practical when the network, disk, and destination can handle RDB loading and streaming. | Can be simpler for a one-time offline copy, but the export file still needs storage and transfer capacity. |
| Rollback | Natural rollback path: keep the source and redirect clients back if validation fails. | Rollback requires retaining the original source and separately managing writes made after import. |
| Destination compatibility | Commands, modules, ACLs, and versions must be compatible while replication is active. | Import compatibility still matters, but you can validate the file before bringing the destination into service. |
| Ongoing synchronization | Built in until you detach or promote the replica. | Not provided by the file itself. |
Choose live replication when minimizing write downtime and preserving a simple rollback are priorities. Choose an RDB workflow when you can tolerate an offline or separately coordinated delta process, or when an isolated point-in-time file is easier to validate than a live link.
Troubleshoot common migration failures
The destination remains in full sync for a long time
- Check dataset size, available destination memory, temporary disk space, disk throughput, and network bandwidth.
- Inspect source and destination logs for fork, snapshot, authentication, or connection errors.
- Ensure the destination is not being overloaded by client traffic or expensive commands while it loads.
Authentication fails repeatedly
- For password authentication, verify
masterauthand the secret currently configured on the source. - For ACLs, verify
masteruser, its password, and permissions for PSYNC and replication commands. - Confirm that a firewall or TLS policy is not masking an authentication error as a connection failure.
Offsets never converge
- Compare source write rate with destination processing capacity and inspect CPU, memory pressure, latency, and disk I/O.
- Check for packet loss, bandwidth saturation, or unstable connections.
- Do not cut over while the gap is growing; reduce load, improve capacity, or reschedule.
Every reconnect triggers a full sync
- Estimate the command-stream bytes generated during the longest expected outage.
- Increase backlog capacity where supported and appropriate, then verify the effective setting after restart.
- Fix the underlying disconnect instead of relying on a larger backlog alone.
Reads look old after a disconnect
Determine whether replica-serve-stale-data is enabled. If stale reads are unacceptable, set it to no and make the application handle MASTERDOWN explicitly.
Operational checklist
- Destination memory, disk, CPU, network, Redis version, modules, and persistence are compatible.
- Firewall and TLS controls permit only the required replication path.
masterauthor ACLmasterusercredentials are tested and stored securely.REPLICAOFis configured persistently, not only at runtime.- Initial sync has completed;
master_link_statusisup;master_sync_in_progressis0. - Offsets remain close under representative write load and sync failures are absent.
- Keys, TTLs, data types, modules, ACLs, and application invariants have been validated.
- Writes are quiesced before the final offset check and client redirect.
- The old source remains available for rollback and is monitored after cutover.
Final decision
Attach the new Redis server with REPLICAOF, allow Redis to complete PSYNC or an RDB full sync, and use INFO replication plus ROLE to measure readiness. A short, explicit write pause followed by offset verification, application checks, client redirection, and retained rollback is the dependable way to migrate with minimal downtime. Plan for asynchronous-replication loss windows, backlog limits, stale-read behavior, and the resource cost of a full synchronization rather than treating a green connection status as proof that the migration is complete.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
