Migrating to Engula · Overview#

Engula is a drop-in equivalent of Redis 7.2: identical protocol, command set, and replication behavior, and the two can replicate to each other as master/replica. Existing client code, SDKs, and operational tooling need essentially no changes. As a result, migrating a live Redis / Valkey deployment to Engula can reuse the familiar Redis rolling upgrade (replica + planned failover) flow — a smooth switch that keeps a rollback path (the two steps roll back differently — see below).

This guide covers method and key points only; exact commands and parameters vary by deployment form (standalone master/replica vs. Cluster) and environment. The Engula support team can help tailor the rollout.

---

Approach: introduce one variable at a time#

Migrating from an older Redis (e.g. 6.x) to Engula usually crosses two things at once: a Redis version difference and an engine difference. Stacking both makes root-causing hard. We recommend a two-step path — each step introduces one variable and is reversible (though the two steps roll back differently):

• Step 1: Redis 6.x → 7.2 — a pure version upgrade following Redis's official rolling-upgrade practice. Rollback means "back to the cutover point": old 6.x cannot load a 7.2 RDB, so after switching back, writes made to 7.2 after cutover do not return to 6.x. See Redis 6.x → 7.2 upgrade.
• Soak period — cover at least one full business cycle (weekends / promotions / settlement peaks); duration is up to you.
• Step 2: Redis 7.2 → Engula — a pure engine migration. Because Engula is a drop-in for 7.2 and they replicate to each other, Redis can keep following Engula as a warm-standby replica, so rollback is cleaner. See Redis 7.2 → Engula migration.

Both steps are reversible, but with different meaning: Step 1 is "back to the cutover point" (not lossless — writes to 7.2 after cutover are lost); Step 2 keeps Redis as an Engula warm-standby replica, so rollback is cleaner. For simple workloads (pure cache, rebuildable from a database) you may also evaluate migrating directly; the two-step path is the more robust default.

---

Recommended method: rolling failover (replica + failover)#

Because Engula and Redis 7.2 can be mutual master/replica, both steps use the same proven mechanism:

• No dual-write, no special proxy required — short path, low cost.
• Blue-green variant: after failover, keep the old-version / old-engine nodes as replicas during a soak period; remove them once healthy, or switch back quickly if not.
• Works for both standalone master/replica and Redis Cluster (Cluster uses CLUSTER FAILOVER, one shard at a time; a dedicated dry run for Cluster is recommended — see the execution docs).

---

An alternative approach: proxy dual-write + gradual read cutover#

When you cannot rely on replication failover, or need percentage-based gradual read cutover and strong control across data centers, there is an industry "proxy dual-write" approach:

It turns migration into an observable, gradual, seconds-to-roll-back process, but usually cannot be adopted with zero development — the proxy / access layer must provide or implement the following. The table lists each development requirement and its purpose in the migration:

Development requirement	Purpose in the migration
Dual-write: write to source and target simultaneously	Keep the target absorbing incremental writes and in sync before read cutover
Dual-write failure handling: distinguish source-write vs target-write failure	Fail on source-write error to protect main-path correctness; record (not fail) target-write errors
Circuit breaker: auto-stop target writes on failure/timeout rate over threshold	One-click degrade when the target misbehaves, protecting the main path
Gradual read cutover: 10%→30%→…→100%, roll back in seconds	Ramp read-traffic risk in stages, verify each stage, revert instantly on anomaly
Idempotency / retry control for non-idempotent commands (INCR, LPUSH, …)	Prevent duplicate writes under dual-write + retries
Side-channel validation: sample-compare Key + Value + TTL	Continuously detect divergence and alert, especially for hot / core keys
Command audit / observability metrics	Provide quantitative acceptance criteria and troubleshooting for each stage

This approach requires custom development against your specific access layer and is not given here as a standard procedure. contact us to evaluate such needs.

---

Pre-migration checklist#

Confirm item by item with Ops / DBA and the business side (high-level; thresholds are up to you):

• Commands & compatibility: inventory the commands / usage actually used in production from real command logs (Lua, Streams, blocking commands, Module, etc.); mirror production traffic via shadow mode to verify consistency.
• Workload profile: command pattern (simple KV vs complex structures); role of Redis (pure cache, rebuildable vs primary store, must not lose); client timeouts and connection pools.
• Stability requirements: whether a sub-second write blip is acceptable; tolerance for small deviations on non-idempotent commands; acceptable P99 increase.
• Resources & windows: how many nodes can run at once (old + new + soak retention); low-traffic / change-freeze windows.

---

Universal risk-control principles#

• Establish a consistency point before failover: briefly pause writes, wait for the target replica to catch up to the old master's final replication offset, then promote.
• Rollback semantics differ by step: Step 1 (6.x→7.2) is "back to the cutover point" (not lossless); Step 2 (7.2→Engula) keeps Redis as an Engula warm-standby replica for a cleaner switch-back. Old nodes retain their data until the switch completes — do not restart / rebuild them during the soak.
• Planned over automatic: proactively timed failover beats waiting for auto-failover.
• Verify at each step: move one node at a time, verify replication and cluster state before continuing.
• Continuous validation: sample-compare Key + Value + TTL, alert on mismatch; special checks for hot / core keys.

Watch out for

• Snapshots are not backward-compatible across major versions: after a major upgrade the older version generally cannot load the newer version's snapshot. Rollback relies on keeping old nodes — do not restart / rebuild them during the soak.
• Non-idempotent commands: INCR, LPUSH, etc. may double-write during switchover / retries; require business tolerance or idempotent wrapping.

---

Pre-launch checklist#

• Binary platform and build match (OS, CPU architecture, glibc, SHA256 checksum).
• Backup and restore drills completed.
• Monitoring, alerting, and logging integrated.
• Rollback commands and responsible owners defined.

Editions & licensing

• Engula Developer Edition — up to 6 Engula nodes.
• Engula Enterprise — for larger scale or production use; licensing and support defined by the commercial contract.

For commercial or production migrations, use Engula Enterprise. See the Download page and the EULA.

---

After migration: validate the gains#

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

For a migration assessment or a tailored plan, contact us.