Engula

Docs
Docs

Redis 7.2 → Engula migration

Step 2 of the migration — the engine migration. Engula is a drop-in for Redis 7.2 and the two can replicate to each other, so it reuses the same rolling-failover mechanism as Step 1; client code needs no changes and rollback is cleaner.

The main flow uses standalone master/replica; Redis Cluster differences are in the supplement at the end.

Applicability & prerequisites

  • Prerequisite: the source is already Redis 7.2 (if still on 6.x, do Step 1 first).
  • Engula matches Redis 7.2 in protocol / commands / replication / RDB and can act as master or replica in both directions — the basis for both this step and its rollback.

Before the migration

  • Config alignment: keep Engula and the source Redis consistent on maxmemory and eviction policy, persistence, auth, connections / timeouts, TLS, etc.
  • Compatibility spot-check: though it is a drop-in, still extract high-frequency / critical usage from real command logs and spot-check behavior on the Engula replica (return values, TTL semantics, pipeline / transaction boundaries).
  • Backup & baseline: run one BGSAVE on the source; record latency / memory baselines to compare gains after migration.

Migration flow (main: standalone master/replica)

① Add Engula replica Engula replicates from the Redis 7.2 master; catch up ② Verify Catch-up + sample consistency + key command behavior ③ (optional) load test / compare latency / memory on real workload ④ Failover to Engula Pause writes → wait Engula to catch up offset → promote Engula → repoint clients ⑤ Soak Keep the Redis node as an Engula replica (duration up to you); monitor + observe gains ⑥ Wrap up Retire the Redis node

Key actions (example commands, adjust per environment)

  • Add replica: on Engula, REPLICAOF <redis-master-ip> <port> (set masterauth if needed); wait for initial sync.
  • Catch-up check: INFO replication shows master_link_status:up, offset aligned; sample-compare Key + Value + TTL.
  • Failover (establish a consistency point, then promote):
    1. On the old master (Redis 7.2), CLIENT PAUSE WRITE <ms> to briefly pause writes.
    2. Record the old master's master_repl_offset from INFO replication.
    3. Wait for the Engula replica's offset to reach that value.
    4. REPLICAOF NO ONE on Engula to promote it.
    5. Repoint clients to Engula.
  • Blue-green retention: after failover, point the original Redis node at Engula with REPLICAOF <engula-master> so it follows Engula as a warm standby — since replication is bidirectional, Redis follows Engula normally and rollback can be lossless.

Redis Cluster supplement

Cluster can reuse the "per-shard add replica, catch up, manual failover" idea, but a separate dry run before production is recommended — do not extrapolate single-instance results to Cluster.

Same core flow; the differences are commands and cutover:

  • Add replica: Engula node CLUSTER MEET to join, then CLUSTER REPLICATE <master-node-id>.
  • Failover: on the target Engula replica, CLUSTER FAILOVER, one shard at a time (verify cluster_state:ok, role:master before the next). CLUSTER FAILOVER already pauses the primary, ships the offset, and waits for the replica to catch up before completing, so you don't add a bare CLIENT PAUSE; by default do not use FORCE / TAKEOVER.
  • Cutover: Cluster clients follow the topology automatically — no manual repointing.
  • Blue-green retention: keep the Redis node as a replica of the Engula master for that shard, for rollback.
  • Retirement order: remove Redis replicas first, the Redis master last.

Verification checkpoints

Stage Check Pass criteria
After add replica catch-up master_link_status:up, offset aligned
Before failover sample consistency, key commands sampled data matches, key usage behaves as expected
After failover new master role Engula role:master (Cluster: cluster_state:ok)
Soak latency / errors / connections / memory no regression; memory lower than Redis as expected

Rollback

Engula and Redis are bidirectional master/replica, so rollback is cleaner than Step 1:

  • During the soak the kept Redis replica follows the Engula master and stays in sync. To roll back, re-promote that Redis node and repoint clients (Cluster: CLUSTER FAILOVER back).
  • Because data follows in real time, rollback can be essentially lossless; for consistency-sensitive workloads still briefly freeze writes at cutover / rollback to get a definite consistency point.
  • Keep the Redis nodes during the soak — do not rebuild them — so rollback stays available.

After migration: validate the gains

  • Live Proof — compatibility / performance / RDB / memory-efficiency results.

Back to Migration overview · Previous: Redis 6.x → 7.2.

ON THIS PAGE