RDB

Snapshot RDB: pemicu SAVE/BGSAVE, perilaku fork, berkas dump.rdb, dan proses pemulihan.

Daftar isi

RDB adalah mekanisme persistensi Redis yang menyimpan seluruh dataset sebagai snapshot, yaitu potret data pada satu titik waktu, dalam satu berkas biner ringkas yang secara default bernama dump.rdb. Topik ini membahas dua perintah pemicu snapshot, perilaku fork dan copy-on-write di baliknya, pengaturan save point, berkas hasilnya, serta proses pemulihan. Setelah membacanya, alur kerja RDB dapat diikuti dari pemicu sampai data kembali di memori, termasuk risiko kehilangan data yang menyertainya.

SAVE dan BGSAVE: dua pemicu snapshot#

Redis menyediakan dua perintah untuk memicu snapshot secara manual. Perintah SAVE mengerjakan seluruh proses penyimpanan di proses server utama, sehingga tidak ada perintah klien yang dilayani sampai berkas selesai ditulis. Perintah BGSAVE menyerahkan pekerjaan itu ke proses anak, sehingga server tetap melayani klien selama snapshot berlangsung. Keduanya menghasilkan berkas snapshot yang sama, sedangkan perbedaannya ada pada siapa yang mengerjakan dan apakah klien terblokir.

Lab pada topik ini menjalankan server khusus di port 6385 dengan direktori data di /tmp/lab-rdb. Konfigurasi save diisi 60 1, yaitu satu save point (pemicu otomatis) yang menjalankan snapshot apabila minimal satu key berubah dalam 60 detik. Log server diarahkan ke berkas terpisah agar terminal tetap bersih.

bash
# kosongkan direktori lab dan siapkan kembali di /tmp
rm -rf /tmp/lab-rdb
mkdir -p /tmp/lab-rdb
# hentikan sisa server dari sesi sebelumnya, bila ada
redis-cli -p 6385 shutdown nosave 2>/dev/null || true
# nyalakan server khusus topik ini dengan save point 60 detik dan satu perubahan
redis-server --port 6385 --bind 127.0.0.1 --daemonize yes --dir /tmp/lab-rdb --save "60 1" --protected-mode no --logfile /tmp/lab-rdb-server.log
# tunggu server siap, lalu pastikan koneksi hidup
sleep 1
redis-cli -p 6385 PING
text Keluaran
PONG
bash
# simpan key contoh
redis-cli -p 6385 set rdb:nama Ali
text Keluaran
OK
bash
# picu snapshot di background
redis-cli -p 6385 bgsave
text Keluaran
Background saving started

Pesan Background saving started berarti proses anak sudah dibuat dan sedang menulis berkas. Berkasnya terlihat di direktori data setelah proses anak selesai.

bash
# beri waktu proses anak menulis berkas snapshot
sleep 1
# tampilkan isi direktori data
ls /tmp/lab-rdb
text Keluaran
dump.rdb

Perintah SAVE dapat dicoba juga untuk membandingkan perilakunya. Keluaran OK baru muncul setelah seluruh berkas selesai ditulis, dan selama itu server tidak melayani perintah lain.

bash
# picu snapshot secara blokir untuk membandingkan perilakunya
redis-cli -p 6385 save
text Keluaran
OK

Perilaku fork dan copy-on-write#

BGSAVE bekerja dengan memanggil fork(), yaitu fungsi sistem operasi yang membuat salinan proses. Proses induk tetap melayani klien, sedangkan proses anak mewarisi salinan dataset dan menulis seluruhnya ke berkas snapshot. Ketika proses anak selesai, berkas sementara yang ditulisnya diganti nama menjadi dump.rdb, sehingga berkas lama tetap utuh sampai snapshot baru siap sepenuhnya. Diagram berikut merangkum alur tersebut.

Proses utamamelayani klienProses anakmenulis snapshotBerkas sementaratemp-*.rdbdump.rdbsnapshot siapfork()tulisrenamePerubahan selama snapshot berjalan ditangani mekanisme copy-on-writeProses utama tetap melayani klien hingga snapshot selesai
Alur BGSAVE: fork, penulisan snapshot oleh proses anak, lalu rename menjadi dump.rdb

Pemanggilan fork() terasa cepat meskipun dataset besar karena sistem operasi tidak menyalin halaman memori sejak awal. Induk dan anak berbagi halaman memori yang sama melalui mekanisme copy-on-write (salin saat ditulis), yaitu halaman yang diubah diduplikasi lebih dahulu sehingga kedua proses tidak saling mengganggu. Selama snapshot berjalan, tulisan dari klien menimbulkan duplikasi halaman, sehingga penggunaan memori dapat naik mendekati ukuran dataset pada kondisi terburuk. Server yang beroperasi dekat batas memori perlu mengantisipasi perilaku ini.

Berkas snapshot dan save point#

Hasil snapshot adalah satu berkas biner yang ringkas karena berisi representasi data, bukan rangkaian perintah, sehingga cepat ditulis dan cepat dimuat kembali. Nama berkasnya diatur melalui konfigurasi dbfilename, sedangkan lokasinya diatur melalui konfigurasi dir. Konfigurasi save memuat daftar save point yang menentukan kapan snapshot otomatis dijalankan.

bash
# tampilkan save point yang sedang aktif
redis-cli -p 6385 config get save
# tampilkan nama berkas snapshot yang dikonfigurasi
redis-cli -p 6385 config get dbfilename
text Keluaran
save
60 1
dbfilename
dump.rdb

Server lab menetapkan satu save point berisi 60 1, sedangkan Redis tanpa pengaturan tambahan memuat tiga save point bawaan, yaitu 3600 1, 300 100, dan 60 10000. Save point yang lebih rapat mengurangi risiko kehilangan data, tetapi menaikkan frekuensi fork dan penulisan berkas.

Status snapshot terakhir dapat dilihat pada bagian persistence dari perintah INFO. Nilai rdb_changes_since_last_save menyatakan jumlah perubahan sejak snapshot terakhir, sedangkan rdb_last_bgsave_status menyatakan berhasil atau tidaknya BGSAVE terakhir. Blok berikut diberi tanda tidak-dijalankan karena keluarannya memuat waktu proses dan ukuran berkas yang selalu berubah.

bash
# tidak-dijalankan
# keluaran INFO persistence memuat uptime, timestamp, dan ukuran berkas yang terus berubah
redis-cli -p 6385 info persistence

Pemulihan dari snapshot#

Ketika server dimulai dan AOF tidak aktif, Redis membaca berkas snapshot dari direktori kerja lalu memuatnya ke memori sebelum menerima koneksi. Pemulihan dapat diuji dengan mematikan server menggunakan shutdown nosave, yaitu opsi yang melompati penyimpanan akhir, kemudian menyalakannya kembali dengan konfigurasi yang sama.

bash
# matikan server tanpa menyimpan ulang ke disk
redis-cli -p 6385 shutdown nosave
# nyalakan ulang server, data dimuat dari dump.rdb
redis-server --port 6385 --bind 127.0.0.1 --daemonize yes --dir /tmp/lab-rdb --save "60 1" --protected-mode no --logfile /tmp/lab-rdb-server.log
# tunggu server siap menerima koneksi, paling lama sepuluh detik
for i in $(seq 1 40); do redis-cli -p 6385 PING >/dev/null 2>&1 && break; sleep 0.25; done
# baca kembali key contoh
redis-cli -p 6385 get rdb:nama
text Keluaran
Ali

Nilai Ali kembali karena key rdb:nama dibaca dari dump.rdb yang ditulis BGSAVE sebelumnya. Pemulihan ini tidak bergantung pada cara server dimatikan sebelumnya, asalkan berkas snapshot ada dan sah.

Percobaan pada topik ini selesai, sehingga server lab dimatikan dan direktori datanya dibiarkan berisi dump.rdb hasil uji terakhir.

bash
# matikan server khusus topik ini
redis-cli -p 6385 shutdown nosave

Risiko kehilangan data pada RDB#

Snapshot hanya melindungi data pada titik waktu ketika snapshot itu dibuat. Seluruh perubahan setelah snapshot terakhir berada di memori saja, sehingga proses yang mati mendadak menimbulkan kehilangan sebesar perubahan sejak snapshot terakhir. Pada konfigurasi lab, save point 60 1 berarti kehilangan dapat mencapai tulisan selama sekitar 60 detik terakhir. Kelonggaran interval menurunkan beban disk, tetapi memperlebar jendela risikonya.

Waktu snapshot terakhir dapat diperiksa dengan perintah LASTSAVE, sedangkan kegagalan penulisan berkas, misalnya karena disk penuh, terlihat pada rdb_last_bgsave_status.

Kesalahan umum#

  • BGSAVE gagal dan rdb_last_bgsave_status berisi err. Penyebab yang paling umum adalah disk penuh atau izin direktori kerja yang salah. Perbaikannya dengan menyediakan ruang disk, memastikan konfigurasi dir menunjuk ke direktori yang dapat ditulis, lalu jalankan BGSAVE kembali.
  • Fork gagal ketika sistem operasi menolak permintaan memori, biasanya karena RAM yang tersedia terlalu kecil dibanding ukuran dataset. Percobaan BGSAVE tidak jalan dan pesan errornya tercatat di log server. Naikkan memori yang tersedia atau kurangi ukuran dataset.
  • Snapshot dianggap mutakhir padahal berkasnya lama. Periksa waktu snapshot terakhir dengan LASTSAVE sebelum mengandalkan dump.rdb untuk pemulihan.

Ringkasan#

  • BGSAVE membuat proses anak melalui fork dan menulis snapshot tanpa memblokir server, sedangkan SAVE mengerjakan pekerjaan yang sama secara blokir.
  • Snapshot tersimpan sebagai satu berkas biner dump.rdb dan dapat dipicu manual maupun otomatis melalui save point.
  • Pemulihan dilakukan dengan memuat berkas snapshot ke memori saat server dimulai, selama AOF tidak aktif.
  • Perubahan setelah snapshot terakhir tidak dilindungi, sehingga save point yang dipilih menentukan jendela kehilangan data.

Referensi#