Database Maintenance

Mesin yang sehat butuh perawatan berkala, dan database tidak terkecuali: struktur B-tree perlu dites integritasnya, ruang disk bekas hapus perlu dikembalikan, dan pekerjaan berat harus dijadwalkan di jendela yang aman. Kabar baiknya, maintenance MongoDB sehari-hari ringan — sebagian besar perawatan berat sudah otomatis di level storage engine. Chapter ini membahas perintah validate untuk menguji integritas collection, siklus compact dan alasan reIndex sudah tidak relevan, peran checkpoint dan journal, serta cara menyusun jadwal maintenance.

Peta materi chapter ini:

• db.coll.validate(): uji integritas data dan index.
• Memantau ruang terpakai ulang (file bytes available for reuse).
• Mengapa reIndex tidak lagi diajarkan.
• Checkpoint, journal, dan penyusunan jadwal maintenance.

validate: Menguji Integritas Collection #

Perintah validate memeriksa struktur internal sebuah collection: keterbacaan setiap document, konsistensi antara data dan index, serta statistik jumlah record. Ini adalah alat diagnosis setelah insiden — misalnya disk penuh saat menulis atau crash — bukan rutinitas harian. Siapkan collection kecil lalu jalankan:

use latihan_admin
db.dropDatabase()
db.pembelian.insertMany([
  { _id: 1, pelanggan: "Budi", total: 150000 },
  { _id: 2, pelanggan: "Siti", total: 275000 },
  { _id: 3, pelanggan: "Dewi", total: 98000 }
])

Output yang Dihasilkan:

switched to db latihan_admin
{ ok: 1, dropped: 'latihan_admin' }
{ acknowledged: true, insertedIds: { '0': 1, '1': 2, '2': 3 } }

db.pembelian.validate()

Output yang Dihasilkan:

{
  valid: true,
  repaired: false,
  repairMode: 'None',
  ns: 'latihan_admin.pembelian',
  uuid: UUID('6c6be212-abd4-460e-a72a-949a15750c13'),
  fastCountType: 'legacySizeStorer',
  warnings: [],
  errors: [],
  extraIndexEntries: [],
  missingIndexEntries: [],
  nInvalidDocuments: 0,
  nNonCompliantDocuments: 0,
  nrecords: 3,
  corruptRecords: [],
  nIndexes: 1,
  keysPerIndex: { _id_: 3 },
  indexDetails: {
    _id_: {
      valid: true,
      spec: { v: 2, key: { _id: 1 }, name: '_id_' },
      isMultikey: false
    }
  },
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1792268074, i: 4 }),
    signature: {
      hash: Binary.createFromBase64('AAAAAAAAAAAAAAAAAAAAAAAAAAA=', 0),
      keyId: Long('0')
    }
  },
  operationTime: Timestamp({ t: 1792268074, i: 4 })
}

Hasil sehat ditandai empat hal utama:

Mode bawaan sudah memeriksa seluruh document; opsi { full: true } menambah pemeriksaan mendalam yang jauh lebih lambat, sedangkan { full: false } memakai jalur cepat berbasis metadata. Pada collection produksi berukuran besar, validate membaca seluruh data — jalankan hanya pada anggota secondary atau di jendela sepi, satu collection per satu jendela.

Memantau Ruang dan Efek Penghapusan #

Menghapus document tidak mengecilkan berkas .wt — WiredTiger hanya menandai ruangnya agar bisa dipakai ulang. Metric kuncinya bisa dibaca langsung:

const s = db.pembelian.stats()
[ s.count, s.size, s.storageSize, s.wiredTiger["block-manager"]["file bytes available for reuse"] ]

Output yang Dihasilkan:

[ 3, 135, 4096, 0 ]

Sekarang hapus dua dari tiga document, lalu baca ulang metriknya:

db.pembelian.deleteMany({ _id: { $gte: 2 } })
db.pembelian.stats().wiredTiger["block-manager"]["file bytes available for reuse"]

Output yang Dihasilkan:

{ acknowledged: true, deletedCount: 2 }
0

Data tersisa hanya satu document, tetapi storageSize tetap 4096 byte dan ruang terpakai ulang masih 0 — halaman 4 KB masih menampung sisa data, sehingga tidak ada yang perlu dikembalikan. Pada collection besar yang kehilangan porsi signifikan, angka file bytes available for reuse akan membengkak: itulah sinyal bahwa compact (chapter Storage Management) layak dijadwalkan untuk mengembalikan ruang ke sistem operasi. Tren yang layak dicatat tiap bulan: size (BSON logis), storageSize (disk), dan ruang reuse — jika reuse terus naik sementara size stabil, aplikasi Anda punya pola hapus-besar yang berulang.

reIndex: Mengapa Tidak Lagi Diajarkan #

Tutorial lama sering menyarankan reIndex — membangun ulang semua index sebuah collection sekaligus. Perintah ini resmi deprecated sejak MongoDB 4.2 karena biayanya jauh melebihi manfaatnya: seluruh index dijatuhkan dan dibangun dari nol dalam satu operasi yang memblokir collection, padahal index WiredTiger modern menjaga diri sendiri lewat proses reconciliasi. Diagnosis modern tidak membutuhkannya: jika satu index bermasalah (terlihat dari validate atau db.coll.stats().indexDetails), bangun ulang hanya index itu dengan drop + create; jika masalahnya fragmentasi, alatnya compact. Jika Anda menemui reIndex di artikel lama, anggap tanggal kedaluwarsanya 2019.

Checkpoint dan Journal di Balik Layar #

Sebagian besar “perawatan” yang dulu manual kini otomatis. WiredTiger membuat checkpoint — snapshot konsisten seluruh data ke disk — secara bawaan setiap 60 detik atau setiap 2 GB data journal. Di antara checkpoint, setiap tulisan dicatat lebih dulu ke journal di direktori journal/ dengan sinkronisasi sekitar 100 milidetik. Konsekuensinya untuk perawatan:

• Shutdown sopan (chapter Proses Server Database) memicu checkpoint terakhir, sehingga menyala kembali cepat.
• Crash memaksa replay journal saat startup — lama pemulihan sebanding dengan jumlah journal sejak checkpoint terakhir, umumnya di bawah satu menit.
• Tidak ada rutinitas “defrag berkala” yang wajib; compact tetap opsional berbasis kebutuhan.

Menyusun Jadwal Maintenance #

Dua baris terakhir bukan pekerjaan engine, melainkan kebersihan schema — dan keduanya sudah punya chapter sendiri di section sebelumnya. Prinsipnya satu: pekerjaan berat dijadwalkan, bukan direaksikan saat masalah sudah terjadi. Checklist operasional lengkap harian-mingguan-bulanan menyusul di chapter penutup section ini.

Rangkuman #

• db.coll.validate() menguji integritas data dan index; hasil sehat ditandai valid: true, array kosong, dan keysPerIndex yang selaras.
• Penghapusan tidak mengecilkan berkas — pantau file bytes available for reuse sebagai sinyal kapan compact bermanfaat.
• reIndex deprecated sejak 4.2; bangun ulang index secara individual atau pakai compact bila perlu.
• Checkpoint otomatis tiap 60 detik/2 GB dan journal ~100 ms membuat pemulihan crash cepat tanpa rutinitas manual.
• Susun jadwal maintenance tertulis: tren storage bulanan, validate kuartalan, compact sesuai kebutuhan.