Belajar MongoDB - Backup, Restore & Change Streams

#Pendahuluan

Tidak ada peringkat keberhasilan backup yang lebih baik daripada ujian kehilangan data. Aplikasi production selalu menghadapi skenario buruk: human error menghapus collection, bug menimpa ribuan dokumen, atau server terbakar. Dalam situasi itu, kalian tidak butuh alasan — kalian butuh backup yang bisa dipulihkan. Episode 18 mempersiapkan kalian untuk momen itu.

Roadmap-nya: pertama strategi backup/restore — mongodump/mongorestore untuk logical backup, kedua filesystem snapshots untuk physical backup, ketiga point-in-time restore di Atlas, dan keempat change streams untuk mendengarkan perubahan data secara real-time — keterampilan yang membuka pintu arsitektur event-driven. Mari mulai.

#Strategi Backup dan Restore

#mongodump / mongorestore: Logical Backup

mongodump menghasilkan logical backup — data diekspor sebagai file BSON yang berisi dokumen dan metadata. Ini paling fleksibel karena bisa memilih level: seluruh database, collection tertentu, bahkan dengan query filter:

mongodump --uri "mongodb://localhost:27017" --db app --out /backup/app-2026-08-03

mongodump --uri "mongodb://localhost:27017" \
  --db app --collection orders \
  --query '{ "status": "paid" }' \
  --out /backup/orders-paid

Hasilnya adalah folder berisi file .bson dan .metadata.json per collection. Pemulihannya memakai mongorestore — bisa memulihkan semuanya, atau satu collection:

mongorestore --uri "mongodb://localhost:27017" --drop /backup/app-2026-08-03

mongorestore --uri "mongodb://localhost:27017" \
  --db app --collection orders \
  /backup/app-2026-08-03/app/orders.bson

Opsi --drop menghapus collection sebelum restore — hati-hati, gunakan hanya saat memang ingin mengganti data yang ada.

Penting dipahami: mongodump melakukan snapshot konsisten saat dijalankan di replica set (dengan --oplog untuk konsistensi point-in-time), tapi ini bukan backup kontinu — ada jendela data yang masuk setelah dump selesai dan tidak ikut tercapture.

#Filesystem Snapshots: Physical Backup

Filesystem snapshot adalah salinan fisik dari seluruh data directory pada level OS/disk — menggunakan LVM, ZFS, atau cloud disk snapshots. Keuntungannya:

• Super cepat — snapshot pada banyak sistem hampir instan, tidak mengunci data.
• Konsisten penuh — menyalin datafile persis seperti adanya; titik pemulihan jelas.
• Ideal untuk besar — tidak perlu membaca seluruh data seperti mongodump.

lvcreate -L 20G -s -n mongo-snap /dev/vg/mongodata
mount /dev/vg/mongo-snap /mnt/backup

Untuk konsistensi yang sempurna, lakukan snapshot pada replica set dan ambil dari secondary — sehingga primary tidak terganggu dan data dijamin sinkron dari satu titik waktu yang sama.

#MongoDB Atlas Continuous Backup

Jika kalian memakai MongoDB Atlas (SaaS), backup dikelola otomatis: continuous backup menangkap perubahan data hampir real-time, sehingga memungkinkan Point-in-Time Restore — memulihkan cluster ke kondisi di menit (bahkan detik) tertentu. Ini sangat berharga saat harus memutar balik waktu ke sebelum sebuah kesalahan terjadi, tanpa kehilangan data yang masuk sesudahnya.

Atlas juga melakukan snapshot rutin (misal setiap 6 jam) dengan retensi bervariasi, dan seluruh prosesnya dikelola lewat UI atau API tanpa script manual. Trade-off-nya: kalian membayar layanan dan data tidak tersedia sebagai file yang bisa dibawa-bawa bebas.

#Change Streams: Mendengarkan Perubahan Real-time

#Konsep

Change streams memungkinkan aplikasi mendengarkan perubahan data pada collection, database, atau seluruh deployment secara real-time — insert, update, replace, dan delete. Ini adalah jembatan dari database "pasif" menjadi database "aktif" yang memberi tahu aplikasi saat data berubah.

Change streams bekerja lewat cursor tailable di atas oplog: aplikasi membuka stream, dan setiap perubahan data baru dikirim sebagai dokumen event. Fitur ini hanya tersedia di replica set.

#Studi Kasus Penggunaan

Change streams membuka pintu arsitektur event-driven. Kasus nyata yang paling umum:

• Real-time notifications — saat status order berubah, aplikasi mengirim notifikasi push ke user tanpa polling.
• Cache invalidation — saat dokumen produk di-update, cache Redis di-invalidasi atau diperbarui.
• Data sync ke search engine — setiap perubahan data didorong ke Elasticsearch/OpenSearch agar indeks pencarian selalu sinkron.
• Audit log — mencatat semua perubahan data untuk kepatuhan.

Mendengarkan perubahan pada collection orders (Node.js)

const pipeline = [
  {
    $match: {
      operationType: { $in: ["insert", "update"] },
      "fullDocument.status": "paid"
    }
  }
];
 
const changeStream = ordersCollection.watch(pipeline);
 
changeStream.on("change", (event) => {
  sendNotification(event.fullDocument);
});

Contoh di atas hanya bereaksi pada insert/update di mana status menjadi paid — lalu mengirim notifikasi. Bandingkan dengan pola polling yang memeriksa database setiap detik: change streams menghemat resource dan memberikan latensi hampir nol.

#Update Lookup

Perhatikan bahwa pada operasi update, dokumen lengkap tidak selalu tersedia di event. Untuk mengambil dokumen terbaru, aktifkan opsi fullDocument:

Mendapatkan dokumen lengkap saat update

const changeStream = ordersCollection.watch([], {
  fullDocument: "updateLookup"
});

Dengan "updateLookup", MongoDB menyertakan versi dokumen terkini di fullDocument setiap kali ada update — memudahkan sinkronisasi tanpa query tambahan.

#Penutup

Pada episode 18 ini kalian telah menyusun strategi penyelamatan data: mongodump/mongorestore untuk logical backup yang fleksibel di level database, collection, atau filter; filesystem snapshots via LVM/ZFS untuk physical backup yang cepat dan konsisten; point-in-time restore di Atlas untuk memutar balik waktu secara presisi; serta change streams untuk mendengarkan perubahan data secara real-time — membuka arsitektur event-driven seperti notifikasi, cache invalidation, dan sinkronisasi ke search engine.

Inti yang harus dibawa pulang:

• mongodump untuk backup logis fleksibel; snapshot untuk physical backup besar.
• Selalu uji restore — backup yang tidak bisa dipulihkan sama saja tidak ada.
• Atlas continuous backup menyediakan point-in-time restore otomatis.
• Change streams mengubah MongoDB menjadi sumber event real-time.
• Sinkronisasi dan notifikasi bisa dibangun tanpa polling berulang.

Di episode 19 berikutnya kita menjaga kesehatan sistem: Monitoring, Maintenance & Troubleshooting. Kalian akan memeriksa kesehatan dengan db.serverStatus, db.currentOp, mongostat, dan mongotop, memantau lewat Prometheus dan Grafana, melakukan maintenance seperti compact dan reIndex, serta menangani masalah umum seperti slow queries, memory pressure, dan replication lag. Sampai jumpa di episode 19!