Troubleshooting Workflow

Delapan chapter sebelumnya membedah galat satu per satu, dari koneksi sampai penyimpanan. Chapter penutup ini menyusun semuanya menjadi satu kerangka kerja — urutan langkah yang sama untuk galat yang sudah dikenal maupun gejala asing yang belum pernah terlihat, dari tebakan menuju bukti.

Peta materi Chapter ini:

• Kerangka lima langkah, dari reproduksi sampai dokumentasi.
• Membaca pesan galat: nama kelas menunjuk lapisan, kode menunjuk penyebab.
• Contoh jalan singkat: menelusuri E11000 dari gejala sampai pulih.
• Kebiasaan baik versus buruk, dan rutinitas pasca-insiden.

Kerangka Lima Langkah #

Diagram di atas adalah peta jalan; isi tiap langkahnya sebagai berikut:

Urutannya disiplin: fakta mendahului hipotesis, hipotesis diuji sebelum perbaikan. Galat yang tidak bisa direproduksi di lingkungan pengembangan menuntut salinan data, rentang waktu kejadian, dan log dari production. Bila perbaikan hanya menggeser gejala, kerangka kembali ke langkah 3 — dengan fakta baru, bukan tebakan baru.

Membaca Pesan Galat: Kelas dan Kode #

Setiap pesan galat membawa dua lapis informasi. Nama kelasnya — MongoServerError, MongoNetworkError, MongoParseError — menunjuk lapisan tempat masalah terjadi. Kode numeriknya menunjuk penyebab spesifik:

Perhatikan dua baris terakhir: galat 18 terjadi sebelum operasi dimulai (identitas), sedangkan 10107 terjadi di tengah topologi yang berubah (replikasi) — kode 10107 termasuk kategori retriable, sehingga driver modern mencoba ulang write semacam itu secara otomatis. Pesan lengkap di bawah nama kelas selalu membawa bukti: keyValue pada E11000, errInfo pada kode 121.

Contoh Jalan Singkat: Menelusuri E11000 #

Kerangka di atas bekerja untuk galat apa pun; mari kita jalankan dari awal sampai akhir pada satu kasus klasik. Langkah 1 — reproduksi. Skrip berikut membuat collection pendaftar dengan unique index email, menyimpan satu pendaftar, lalu mencoba insert kedua dengan alamat yang sama:

use latihan_workflow
db.pendaftar.drop()
db.pendaftar.createIndex({ email: 1 }, { unique: true })
db.pendaftar.insertOne({ nama: "Budi Santoso", email: "[email protected]" })
try {
  db.pendaftar.insertOne({ nama: "Budi Pratama", email: "[email protected]" })
} catch (galat) {
  print("kelas  :", galat.constructor.name, "| kode:", galat.code)
  print("pesan  :", galat.message)
}

Output yang Dihasilkan:

switched to db latihan_workflow
true
email_1
{
  acknowledged: true,
  insertedId: ObjectId('6ad40eca466cd0f0bc2cb328')
}
kelas  : MongoServerError | kode: 11000
pesan  : E11000 duplicate key error collection: latihan_workflow.pendaftar index: email_1 dup key: { email: "[email protected]" }

Langkah 2 terjawab oleh dua baris terakhir: kelas MongoServerError berarti permintaan sampai ke server dan ditolak di sana — aplikasi, driver, dan jaringan dinyatakan bersih — dan kode 11000 menunjuk DuplicateKey. Langkah 3 mengumpulkan fakta di sisi data: index apa saja yang menunggangi collection, dan document mana yang sudah memegang nilai tersebut:

printjson(db.pendaftar.getIndexes())
db.pendaftar.find({ email: "[email protected]" }, { nama: 1 })

Output yang Dihasilkan:

[
  {
    v: 2,
    key: {
      _id: 1
    },
    name: '_id_',
    collation: {
      locale: 'simple'
    }
  },
  {
    v: 2,
    key: {
      email: 1
    },
    name: 'email_1',
    unique: true,
    collation: {
      locale: 'simple'
    }
  }
]

[ { _id: ObjectId('6ad40eca466cd0f0bc2cb328'), nama: 'Budi Santoso' } ]

Faktanya lengkap: index kedua memang unique: true di atas field email, dan document Budi Santoso telah menempati nilai yang sama. Langkah 4, hipotesis terkecil: bukan kerusakan index, melainkan dua pendaftaran yang berbagi satu alamat. Perbaikannya bergantung makna bisnisnya — bila keduanya orang yang sama, gabungkan lewat upsert; bila orang berbeda, sampaikan konfliknya ke pengguna. Langkah 5, terapkan strategi gabung lalu ukur hasilnya:

const hasil = db.pendaftar.updateOne(
  { email: "[email protected]" },
  { $set: { nama: "Budi Pratama" } },
  { upsert: true }
)
print("cocok:", hasil.matchedCount, "| berubah:", hasil.modifiedCount, "| baru:", hasil.upsertedCount)
print("jumlah dokumen dengan email tersebut:", db.pendaftar.countDocuments({ email: "[email protected]" }))
db.dropDatabase()

Output yang Dihasilkan:

cocok: 1 | berubah: 1 | baru: 0

jumlah dokumen dengan email tersebut: 1

{ ok: 1, dropped: 'latihan_workflow' }

cocok: 1 | baru: 0 membuktikan strategi gabung bekerja: document lama diperbarui dan jumlah dokumen untuk email tersebut tetap satu. Verifikasi yang sesungguhnya adalah menjalankan ulang pemicu aslinya — kedua insertOne di awal kini berjalan tanpa galat.

Kebiasaan Baik dan Buruk #

Rutinitas Pasca-Insiden #

Insiden yang selesai tanpa catatan akan kembali sebagai teka-teki baru. Post-mortem ringan — lima sampai sepuluh menit, bukan dokumen formal — cukup berisi empat hal:

• Gejala: apa yang dilihat pengguna, sejak kapan, dan seberapa luas cakupannya.
• Akar masalah beserta buktinya: pesan galat, baris log, atau explain yang menunjukkannya.
• Perbaikan dan verifikasi: apa yang diubah, dan pemicu mana yang kini berjalan bersih.
• Pencegahan: satu-dua tindakan konkret — index untuk query lambat, validator untuk data kotor, alert untuk ambang batas.

Rangkuman #

• Lima langkah: reproduksi → identifikasi lapisan → kumpulkan fakta → hipotesis terkecil → perbaiki, verifikasi, dokumentasikan.
• Nama kelas galat menunjuk lapisan; kode numerik menunjuk penyebab — E11000, 121, 18, dan 10107 adalah empat yang paling sering muncul.
• Fakta mendahului hipotesis: log mongod, serverStatus, currentOp, explain, dan system.profile adalah sumbernya.
• Post-mortem ringan menutup insiden dengan pencegahan yang konkret.