Migrate From Redis

Plan The Migration

Use a fresh standalone Lavik target with enough disk and memory for the source dataset. Attaching a source can replace destination data. Do not use a Meta-managed / --cluster-enabled target: beta.1 rejects Redis replication in that mode. Take a source backup and rehearse the complete move before the production cutover.

Beta.1 imports RDB versions 1–11 and logical databases 0–15. A newer Redis release or an unsupported encoding can prevent full synchronization. Self-describing Module 2 and Function-library records may be skipped with a warning; older or unknown formats can be rejected. Inventory these separately and recreate only features supported by Lavik. Unsupported incremental commands stop replication. Check your command set, scripts, TTLs, ACL requirements and client settings. Use a length-delimited full-sync stream: configure repl-diskless-sync no on each Redis source through your normal configuration process. Coordinate that source-side change with its owner and account for RDB disk space and fork overhead.

Check Command And Client Compatibility →

Attach The Redis Source

The command examples assume private, trusted endpoints with no authentication for a rehearsal. Set LAVIK_HOST, LAVIK_PORT, REDIS_HOST and REDIS_PORT to the actual endpoints. Lavik must be able to reach Redis directly; localhost refers to Lavik’s own host or container. Configure upstream credentials and TLS before attaching authenticated sources; never put passwords in copied terminal commands or expose an unauthenticated instance publicly.

# Run from a trusted host with redis-cli; use a fresh standalone Lavik target.
# These variables must identify your private-network endpoints.
redis-cli -h "$LAVIK_HOST" -p "$LAVIK_PORT" REPLICAOF "$REDIS_HOST" "$REDIS_PORT"
redis-cli -h "$LAVIK_HOST" -p "$LAVIK_PORT" INFO replication

Watch INFO replication and the Lavik logs until master_link_status is up and master_sync_in_progress is 0. Perform real reads as well. A process restart requests a new FULLRESYNC; Redis offsets are not crash-persisted in beta.1. Do not route production traffic to a target still synchronizing.

Catch Up And Cut Over

An OK response acknowledges the role change; it does not mean the copy is complete. Keep the target attached until initial sync finishes and normal reads work. Pause every source writer, including scheduled jobs. Capture each source’s replication offset after the write pause, identify the Lavik replica connection, and confirm its ACK reaches that captured watermark. Replication PINGs and expiration traffic can continue advancing offsets. Compare representative values, data types, key counts and TTLs. Cluster sources require this check independently for every primary. Do not detach during LOADING: an incomplete load can be discarded. If a stream fails or any data type is missing, keep the source authoritative and fix the problem before cutover.

# Only after source writers are paused and all source streams are caught up.
# Never detach a target that is still LOADING or incompletely synchronized.
redis-cli -h "$LAVIK_HOST" -p "$LAVIK_PORT" REPLICAOF NO ONE
redis-cli -h "$LAVIK_HOST" -p "$LAVIK_PORT" ROLE
# Runtime attachment turns Tomb Raider off. Re-enable its cleanup schedule.
redis-cli -h "$LAVIK_HOST" -p "$LAVIK_PORT" TOMBRAIDER INTERVAL 1000

After ROLE reports master, point applications at the Lavik endpoint and resume writes there. Run a small application read/write check before restoring full traffic. Keep Redis fenced against writes. Rollback is a routing change only before Lavik accepts new writes; afterwards reconcile or replay those writes before returning to Redis. REPLICAOF is not a bidirectional migration or a zero-data-loss guarantee.