Keputusan durability

Memilih RDB, AOF, atau keduanya per beban kerja, termasuk pendekatan hibrida pada Redis 8.

Daftar isi

RDB dan AOF bukan pilihan yang saling meniadakan, karena Redis memungkinkan keduanya aktif dalam satu server. Topik ini merangkum kekuatan dan kelemahan tiap mekanisme, menunjukkan konfigurasi yang menyalakan keduanya, lalu memandu pemilihan sesuai beban kerja. Hasil akhirnya adalah keputusan durability (tingkat jaminan data dapat dipulihkan dari kegagalan) yang disadari konsekuensinya, bukan sekadar mengikuti nilai bawaan konfigurasi.

Konfigurasi RDB dan AOF sekaligus#

Konfigurasi persistensi bertumpu pada dua saklar. Save point mengatur RDB melalui konfigurasi save, sedangkan AOF dinyalakan melalui konfigurasi appendonly yang disertai kebijakan appendfsync. Menyalakan keduanya memberi peran berbeda pada tiap mekanisme, yaitu AOF menjaga tulisan terbaru tetap tersimpan, sedangkan snapshot menyediakan arsip ringkas dan pemulihan cepat.

Nilai bawaan Redis menyalakan RDB saja, yaitu tiga save point aktif dengan AOF mati. Server yang baru diinstal dengan demikian sudah membuat snapshot tanpa pengaturan apa pun, sedangkan AOF baru mencatat setelah appendonly dinyalakan. Server lab pada topik ini menyalakan keduanya di port 6387, dan save point bawaannya sengaja dipertahankan agar keduanya dapat dibandingkan langsung.

bash

# kosongkan direktori lab dan siapkan kembali di /tmp
rm -rf /tmp/lab-dur
mkdir -p /tmp/lab-dur
# hentikan sisa server dari sesi sebelumnya, bila ada
redis-cli -p 6387 shutdown nosave 2>/dev/null || true
# nyalakan server dengan AOF aktif dan save point RDB bawaan
redis-server --port 6387 --bind 127.0.0.1 --daemonize yes --dir /tmp/lab-dur --appendonly yes --appendfsync everysec --protected-mode no --logfile /tmp/lab-dur-server.log

bash

# tampilkan save point RDB yang tetap aktif
redis-cli -p 6387 config get save
# tampilkan kebijakan fsync AOF
redis-cli -p 6387 config get appendfsync
# tampilkan format basis berkas AOF
redis-cli -p 6387 config get aof-use-rdb-preamble

text Keluaran

save
3600 1 300 100 60 10000
appendfsync
everysec
aof-use-rdb-preamble
yes

Keluaran menunjukkan tiga save point bawaan tetap aktif di samping AOF. Konfigurasi aof-use-rdb-preamble berisi yes, yang berarti basis berkas AOF ditulis dalam format RDB. Inilah pendekatan hibrida pada Redis 8, yaitu dataset utama dipulihkan cepat dari basis RDB, kemudian perubahan sejak basis itu dimainkan ulang dari berkas incr.

Konfigurasi gabungan tetap menjalani siklus uji yang sama, yaitu simpan data, matikan server, nyalakan kembali, lalu pastikan data kembali.

bash

# simpan key contoh
redis-cli -p 6387 set dur:nama Citra
# matikan dan nyalakan ulang server
redis-cli -p 6387 shutdown nosave
redis-server --port 6387 --bind 127.0.0.1 --daemonize yes --dir /tmp/lab-dur --appendonly yes --appendfsync everysec --protected-mode no --logfile /tmp/lab-dur-server.log
# tunggu server siap, lalu baca kembali key contoh
sleep 1
redis-cli -p 6387 get dur:nama

text Keluaran

OK
Citra

Nilai Citra kembali karena AOF dimainkan ulang, termasuk basis RDB yang berada di dalamnya. Ketika server dimulai dengan keduanya aktif, Redis memilih AOF sebagai sumber pemulihan karena catatannya lebih rinci, sedangkan snapshot tetap berguna sebagai arsip dan sumber pemulihan tercepat.

Percobaan pada modul persistensi ditutup di sini dengan mematikan server lab terakhir.

bash

# matikan server khusus topik ini, seluruh server lab modul persistensi kini mati
redis-cli -p 6387 shutdown nosave

Perbandingan RDB, AOF, dan hibrida#

Tabel berikut menyandingkan ketiganya pada aspek yang paling sering menentukan keputusan.

Aspek	RDB saja	AOF saja	Keduanya (hibrida)
Risiko kehilangan data	sejak snapshot terakhir, biasanya menit	paling banyak sekitar satu detik pada everysec	paling banyak sekitar satu detik, sama seperti AOF
Kecepatan pemulihan	cepat, memuat satu berkas biner	lebih lambat, memainkan ulang perintah	cepat, basis RDB lalu ekor incr yang pendek
Ukuran berkas di disk	ringkas	lebih besar, perlu rewrite berkala	basis ringkas ditambah ekor incr
Beban proses	fork saat snapshot	fork saat rewrite	fork saat snapshot dan rewrite
Cocok untuk	cache dan data yang dapat dihitung ulang	counter, session, dan antrean	data campuran yang menuntut keduanya

Tidak ada baris yang menang di seluruh aspek, dan justru di situ keputusannya berada. Kombinasi keduanya mengambil keunggulan tiap mekanisme, yaitu kehalusan AOF untuk tulisan terbaru dan kecepatan RDB untuk pemulihan, dengan biaya tambahan berupa fork yang lebih sering dan ruang disk yang lebih besar. Dampak fork paling terasa ketika dataset mendekati kapasitas memori mesin, karena lebih banyak halaman berpeluang diduplikasi selama snapshot berjalan.

Memilih per beban kerja#

Pemilihan berangkat dari besaran tulisan terakhir yang boleh hilang saat kegagalan terjadi. Besaran itu berbeda antar beban kerja, dan pola berikut dapat dijadikan titik awal.

Cache murni: dataset dapat dibangun ulang dari sumber aslinya, sehingga RDB dengan save point longgar sudah memadai, dan server tanpa persistensi pun layak bila kehilangan cache dapat ditanggung.
Session dan penghitung: nilai ditulis terus-menerus dan sulit dihitung ulang, sehingga AOF dengan appendfsync everysec memberi jendela kehilangan sekitar satu detik.
Data yang tidak boleh kehilangan tulisan apa pun: naikkan appendfsync ke always, dengan konsekuensi setiap perintah tulis menunggu disk selesai.
Dataset campuran: aktifkan RDB dan AOF bersamaan seperti konfigurasi lab, dengan AOF sebagai sumber pemulihan utama dan RDB sebagai arsip cepat.

Keputusan ini bukan keputusan sekali jalan. Perubahan beban kerja, ukuran dataset, dan jadwal rewrite dapat menggeser pilihan, sehingga konfigurasi persistensi perlu ditinjau ulang seiring waktu. Pemantauan pada INFO persistence dan pengujian pemulihan berkala membantu memastikan keputusan yang dipilih masih sesuai kondisi terkini.

Kesalahan umum#

Menyalakan persistensi tanpa menguji pemulihannya. Konfigurasi baru terbukti bekerja hanya setelah siklus shutdown dan start dipraktikkan pada server uji, lengkap dengan pemeriksaan datanya.
Memilih appendfsync no demi kecepatan pada data yang sebenarnya penting. Jendela kehilangannya tidak dapat dihitung karena bergantung pada sistem operasi, sehingga nilainya perlu dikembalikan ke everysec atau always.
Menetapkan save point terlalu jarang pada data yang berubah cepat. Jendela kehilangan data membesar sesuai intervalnya, dan fork yang lebih jarang tidak selalu sepadan dengan risikonya.

Ringkasan#

RDB dan AOF dapat aktif bersamaan, dengan AOF menjaga tulisan terbaru dan RDB menyediakan arsip ringkas serta pemulihan cepat.
Pada Redis 8, basis berkas AOF ditulis dalam format RDB, sehingga pola hibrida bekerja tanpa konfigurasi tambahan.
Kebijakan appendfsync menentukan jendela kehilangan data, sedangkan beban kerja menentukan mekanisme yang perlu disalakan.
Replikasi tidak menggantikan persistensi karena keduanya menyelesaikan masalah yang berbeda.

Referensi#

Redis persistence — Redis — Dokumentasi resmi yang membandingkan kelebihan dan kekurangan RDB serta AOF.
Database persistence — Redis Enterprise — Pilihan persistence dan durability pada produk terkelola Redis.
CONFIG SET — Redis — Mengubah konfigurasi persistensi seperti appendfsync saat server berjalan.