Cut over: migrate from Amazon ElastiCache to KiviDB

Cut over. Migrate to KiviDB: Move from Redis, Valkey, ElastiCache, Redis Cloud, Aiven, Aerospike, Hazelcast and more: getting the data out, loading it, cuttin

  1. Rehearse. Do a full copy into a test KiviDB, run your test suite against it, and run the verify script. Time the copy.
  2. Start the long copy. RedisShake with ksn = true (node-based), or RIOT with --mode LIVE. Leave it running. On Serverless, or with a backup file, there is no catch-up: plan a write freeze that covers the copy.
  3. Check it has caught up. Every few seconds RedisShake logs read_count, write_count and read_ops. When the two counts are equal and read_ops only follows your application's write rate, it has caught up. Run the verify script while it runs; a few keys changing in flight is expected.
  4. Stop writes to ElastiCache. Put the application in maintenance mode, or stop the writers. Revoke write access if you can: aws elasticache modify-user --user-id app --access-string "on ~* +@read".
  5. Let the last changes arrive (a few seconds), stop the copy, and run the verify script. The key counts should now match exactly.
  6. Switch the application to KiviDB (see below) and start it.
  7. Watch errors and latency. Keep ElastiCache, untouched, until you are sure.

Rolling back. Decide how you would go back before you switch, because copying data from KiviDB back to ElastiCache is limited today:

  • ElastiCache refuses KiviDB's DUMP payloads, so RedisShake and RIOT's default mode copy nothing in that direction.
  • RIOT with --struct does work, but only from a KiviDB database with Lua turned on (RIOT reads through Lua scripts; on KiviDB Cloud, Lua is chosen when the database is created). It leaves stream consumer groups and per-field hash TTLs behind, and its exit code is 0 even when it fails, so read its output.

The dependable rollback is to keep ElastiCache current until you are sure: have the application write to both for a while after the switch (reads from KiviDB), then stop writing to ElastiCache once you no longer need the way back. For a cache the application can rebuild, there is nothing to copy back: point it at ElastiCache again and let it fill.

For a cache whose contents your application can rebuild, there is a simpler way in: point the application at an empty KiviDB and let it fill.