Migrasi Redis ke Valkey di VPS: 6 Langkah Replikasi Tanpa Kehilangan Data

Lisensi Redis berubah pada 2024: dari BSD ke model *source-available* (RSALv2 dan SSPLv1). Dari situ Valkey lahir — fork yang kini dikelola Linux Foundation — dan pada 26 Oktober 2026 garis stabilnya sudah mencapai Valkey 9.1.3. Kalau VPS kita masih menjalankan Redis untuk cache Laravel, session WordPress, lock Nextcloud, atau antrean job n8n, sekarang waktu yang masuk akal untuk mempertimbangkan migrasi Redis ke Valkey. Kabar baiknya: kita tidak perlu mematikan aplikasi untuk memindahkan datanya.

Oke, lanjuutt.. Cara paling aman bukan ekspor-impor dump, tapi replikasi: Valkey dijadikan replica dari Redis yang sedang hidup, data disalin sambil server tetap melayani permintaan, lalu aplikasi diarahkan ke Valkey dan Redis lama dipensiunkan. Cara ini juga jalur yang didokumentasikan sendiri oleh proyek Valkey.

Kenapa Migrasi Redis ke Valkey Masuk Akal Sekarang

Ada dua alasan yang bisa kita pegang, dan keduanya bisa dicek sendiri.

Pertama, irama rilisnya sehat. Halaman rilis resmi Valkey mencatat 9.1.3 keluar 26 Oktober 2026, bersamaan dengan patch untuk garis lama: 9.0.7, 8.1.11, 8.0.12, dan 7.2.15 di tanggal yang sama. Artinya pengguna versi lama tetap dapat perbaikan, bukan dipaksa lompat. Sementara 9.2.0 masih berstatus release candidate (16 September 2026), jadi garis stabil yang layak dipakai produksi hari ini adalah 9.1.x.

Kedua, kompatibilitasnya tinggi. Valkey memakai protokol RESP yang sama, mendengarkan port 6379, dan bisa dibaca oleh client Redis biasa — predis, phpredis, ioredis, sampai redis-cli. Pindah ke Valkey biasanya berarti mengganti nama image dan menyesuaikan beberapa baris konfigurasi, bukan menulis ulang kode aplikasi.

Yang berubah terutama urusan lisensi dan tata kelola: Valkey berjalan di bawah payung Linux Foundation dengan lisensi BSD-3-Clause, bukan dikendalikan satu vendor. Satu catatan supaya tidak salah paham: sejak Redis 8, Redis kembali dirilis dengan tiga pilihan lisensi — RSALv2, SSPLv1, atau AGPLv3 — jadi Redis hari ini bukan lagi produk tertutup. Alasan pindah ke Valkey lebih ke tata kelola yang netral dan lisensi BSD-3-Clause yang paling longgar untuk dipaketkan di produk komersial, bukan semata karena “Redis sudah tutup”.

Apa yang Sama dan Apa yang Berbeda

Sebelum menyentuh server, penting kita tahu garis batasnya.

Yang tetap sama:

Protokol dan perintah inti (GET, SET, HSET, ZADD, SUBSCRIBE, EVAL).
Port default 6379 dan format URL redis://.
Client library lama tetap jalan tanpa perubahan kode.
Format RDB dan AOF dari Redis bisa dibaca Valkey.

Yang berbeda:

Nama binary: valkey-server dan valkey-cli, bukan redis-server dan redis-cli.
Nama image Docker: valkey/valkey (tag 9.1 tersedia dan dipush 27 Oktober 2026).
Modul pihak ketiga tidak otomatis ada. RedisJSON, RediSearch, RedisBloom tidak ikut di dalam Valkey inti; proyek Valkey punya modul sendiri (valkey-search, antara lain) yang harus dipasang terpisah kalau memang dibutuhkan.

Kalau aplikasi kita hanya memakai Redis sebagai cache, session store, rate limiter, atau queue, poin terakhir tidak jadi masalah.

Empat Pemeriksaan Sebelum Mulai

Jalankan dulu di server lama, jangan langsung eksekusi:


redis-cli INFO server | grep redis_version
redis-cli MODULE LIST
redis-cli DBSIZE
redis-cli INFO memory | grep -E "used_memory_human|maxmemory_human"

Yang kita cari:

Versi Redis. Rilis 7.2 ke atas paling mulus. Versi sangat lama masih mungkin, tapi uji dulu di staging.
Daftar modul. Kalau MODULE LIST tidak kosong dan aplikasi bergantung pada modul itu, migrasi butuh rencana tambahan.
Jumlah key. Angka DBSIZE ini yang nanti kita bandingkan setelah replikasi selesai — bukti paling sederhana bahwa data benar-benar tersalin.
Password dan ACL. Kalau Redis memakai requirepass atau user ACL, Valkey butuh kredensial itu untuk bisa menarik data.

6 Langkah Migrasi Redis ke Valkey di VPS

Asumsi: Redis lama di 10.0.0.5:6379 dengan password, Valkey kita jalankan di VPS yang sama pada port 6380. Menjalankan di port berbeda membuat keduanya bisa hidup berdampingan tanpa bentrok.

1. Siapkan container Valkey sebagai replica


services:
  valkey:
    image: valkey/valkey:9.1
    container_name: valkey
    command:
      - valkey-server
      - --port
      - "6380"
      - --replicaof
      - 10.0.0.5
      - "6379"
      - --masterauth
      - "passwordRedisLama"
      - --appendonly
      - "yes"
    ports:
      - "127.0.0.1:6380:6380"
    volumes:
      - ./valkey-data:/data
    restart: unless-stopped

Perhatikan 127.0.0.1 di bagian ports: Valkey tidak boleh terbuka ke internet. Kalau Redis lama memakai user ACL, tambahkan --masteruser nama-user sebelum baris --masterauth.


docker compose up -d
docker compose logs -f valkey

2. Tunggu sinkronisasi penuh


docker exec -it valkey valkey-cli -p 6380 INFO replication

Yang kita tunggu: master_link_status:up dan master_sync_in_progress:0. Kalau masih down, biasanya password salah, port tertutup firewall, atau bind di Redis lama hanya menerima 127.0.0.1.

3. Bandingkan jumlah key


redis-cli -p 6379 DBSIZE
docker exec -it valkey valkey-cli -p 6380 DBSIZE

Dua angka itu harus sama. Selisih satu-dua key wajar kalau ada key ber-TTL pendek yang kedaluwarsa di tengah proses; selisih ratusan berarti replikasi belum selesai atau ada database index yang tidak ikut.

4. Uji baca dari Valkey

Ambil beberapa key nyata dan bandingkan isinya:


docker exec -it valkey valkey-cli -p 6380 GET nama-key

Di tahap ini jangan menulis ke Valkey. Replica bersifat read-only, dan itu justru pengaman: kalau ada yang salah, Redis lama tetap memegang data asli.

5. Pindahkan aplikasi

Ini bagian yang benar-benar menyentuh layanan. Ubah konfigurasi aplikasi dari port 6379 ke 6380, lalu restart aplikasinya satu per satu — bukan semuanya sekaligus. Setelah tiap restart, cek log: error koneksi, READONLY You can't write against a read only replica, atau lonjakan latency.

Kalau aplikasi memakai URL, bentuknya cukup redis://:[email protected]:6380/0.

6. Promosikan Valkey, baru matikan Redis lama

Setelah semua penulis sudah pindah:


docker exec -it valkey valkey-cli -p 6380 REPLICAOF NO ONE
docker exec -it valkey valkey-cli -p 6380 INFO replication

Baris pertama memutus hubungan replikasi sehingga Valkey menjadi primary dan bisa menerima tulisan. Baris kedua memastikan role:master. Baru setelah itu Redis lama dimatikan — dan sebaiknya tunggu 24 jam sebelum menghapus container serta volume-nya, sebagai jalan pulang.

Jebakan yang Paling Sering Ketinggalan

Replikasi menyalin data, bukan konfigurasi. maxmemory, maxmemory-policy, appendonly, dan save adalah setelan per server. Valkey yang baru berdiri akan memakai default-nya sendiri, dan pada VPS kecil itu berbahaya: tanpa maxmemory, cache bisa memakan seluruh RAM lalu memicu OOM killer. Set ulang setelah promosi:


valkey-cli -p 6380 CONFIG SET maxmemory 512mb
valkey-cli -p 6380 CONFIG SET maxmemory-policy allkeys-lru

Database index. Kalau aplikasi memakai SELECT 2, pastikan Valkey memang menyimpan database itu. Default databases 16 biasanya cukup, tapi jangan diasumsikan.

Dua penulis sekaligus. Kalau ada worker yang masih menulis ke Redis lama setelah cutover, datanya masuk ke tempat yang salah dan tidak akan pernah muncul di Valkey. Matikan worker lama lebih dulu, atau arahkan semuanya sebelum promosi.

Rollback harus disiapkan sebelum dibutuhkan. Simpan dump lama (redis-cli SAVE) dan catat nilai konfigurasi aplikasi yang lama. Rollback yang direncanakan berjalan dalam hitungan menit; rollback yang improvisasi bisa berjam-jam.

Setelah Cutover: Kunci Konfigurasi Valkey

Beberapa setelan yang layak dipasang begitu Valkey jadi primary:

bind 127.0.0.1 (atau IP privat) plus protected-mode yes.
Password atau ACL file, bukan port terbuka tanpa autentikasi.
appendonly yes kalau data tidak boleh hilang saat restart; kalau murni cache, RDB periodik sudah cukup.
restart: unless-stopped di Compose, atau unit systemd kalau dipasang langsung di host.
Pantau INFO memory, INFO stats, dan INFO replication secara berkala — Healthchecks atau Grafana bisa memanggil valkey-cli INFO dari cron.

Untuk mengukur apakah Valkey menangani beban sebaik Redis lama, valkey-benchmark sudah tersedia di dalam image yang sama:


docker exec -it valkey valkey-benchmark -p 6380 -q -n 100000 -c 50

Jalankan saat trafik sedang rendah, dan bandingkan dengan angka dari Redis lama memakai beban yang sama. Tanpa pembanding, angkanya tidak berarti apa-apa.

Kesimpulan

Migrasi Redis ke Valkey di VPS tidak harus berarti jam maintenance tengah malam. Dengan replikasi, Valkey menarik data dari Redis yang masih hidup, kita memverifikasi jumlah key dan isi beberapa key, memindahkan aplikasi satu per satu, baru mempromosikan Valkey menjadi primary. Total waktunya biasanya ditentukan oleh besar dataset dan jumlah layanan yang harus di-restart, bukan oleh rumitnya perintah.

Yang perlu diingat cuma tiga: replikasi tidak menyalin konfigurasi, modul pihak ketiga harus dicek lebih dulu, dan Redis lama jangan langsung dihapus. Sisanya soal ketelitian membaca INFO. Kalau hari ini kita sempat mencatat DBSIZE dan maxmemory server lama, besok prosesnya akan terasa jauh lebih tenang. Selamat mencoba — dan kalau ada key yang jumlahnya tidak cocok, itu petunjuk, bukan bencana.