Troubleshooting Replica Set

Replica set yang sehat nyaris tidak terdengar; yang bermasalah berbicara lewat sinyal-sinyal khas: state anggota yang aneh, lag yang membesar, election yang datang silih berganti, atau klien yang tiba-tiba menolak perintah. Menjadi operator yang baik berarti mengenali sinyal itu dan tahu urutan pertanyaan yang tepat — bukan panik mengulang restart. Chapter ini menyusun pola diagnosis dari pemeriksaan cepat hingga kasus-kasus spesifik, lalu menutup dengan tabel rujukan gejala-penyebab-tindakan.

Pemeriksaan Cepat: Enam Puluh Detik Pertama #

Dua perintah membuka setiap sesi diagnosis: rs.status() untuk kesehatan anggota, dan rs.printReplicationInfo() untuk jendela oplog. Dari rs.status() kita rangkum yang penting:

const st = rs.status()
({
  set: st.set,
  anggota: st.members.map(m => ({ name: m.name, state: m.stateStr, health: m.health })),
  votingMembers: st.votingMembersCount,
  majorityVoteCount: st.majorityVoteCount,
  writeMajorityCount: st.writeMajorityCount
})

Output yang Dihasilkan:

{
  set: 'rs0',
  anggota: [ { name: '127.0.0.1:27017', state: 'PRIMARY', health: 1 } ],
  votingMembers: 1,
  majorityVoteCount: 1,
  writeMajorityCount: 1
}

Pembacaannya berurutan: health: 0 berarti heartbeat anggota itu gagal; stateStr yang bukan PRIMARY/SECONDARY menunjukkan anggota sedang dalam masa transisi; dan tiga penghitung terakhir menjawab soal kuorum — bila votingMembers melebihi majorityVoteCount dikurangi satu, berarti ada anggota voting yang tidak ikut. Setelah kesehatan, lanjut ke posisi replikasi tiap secondary:

print("posisi secondary:")
rs.printSecondaryReplicationInfo()
print("(tidak ada baris di atas — rs0 tidak memiliki secondary)")

Output yang Dihasilkan:

posisi secondary:

(tidak ada baris di atas — rs0 tidak memiliki secondary)

Keluaran kosong itu jujur: rs.printSecondaryReplicationInfo() mencetak satu blok per secondary — sync source anggota, posisi syncedTo, dan estimasi ketinggalannya — dan replica set satu anggota kita memang tidak punya secondary. Di cluster nyata, blok itu adalah bacaan lag tercepat: 0 secs behind the freshest node berarti sehat; angka yang tumbuh menunjuk ke bottleneck yang dibahas di Chapter *Replication Lag`.

Node RECOVERING dan ROLLBACK #

Dua state ini paling sering memicu kepanikan padahal maknanya berbeda jauh:

• RECOVERING: anggota sedang mengejar ketertinggalan internal dan menolak melayani baca sampai selesai. Penyebab umumnya restart yang lama atau sedang membangun kembali state pasca-sync. Selama lag menyusut dan state kembali ke SECONDARY, tindakan terbaik adalah menunggu dan memantau. Bila anggota justru terus tertinggal hingga mentok, periksa jendela oplog — kasus berikutnya.
• ROLLBACK: mantan primary yang kembali bergabung dengan write yang tidak sempat direplikasi mayoritas. Cluster mengharuskannya menggulung write itu agar identik dengan primary baru. Document yang digulung tetap disimpan oleh MongoDB sehingga operator dapat memeriksanya — detail format penyimpanannya dirinci di dokumentasi resmi bagian Rollback. Setelah selesai menggulung, anggota kembali sebagai SECONDARY.

Aturan praktisnya: RECOVERING adalah menunggu, ROLLBACK adalah menelaah data yang digulung lalu memutuskan apakah perlu dimasukkan ulang secara manual.

Jendela Oplog Habis #

Gejalanya khas: secondary terlihat tertinggal makin jauh, lalu berhenti total di RECOVERING, dan log mongodnya menyebut keadaan terlalu lawas untuk melanjutkan sinkronisasi. Diagnosisnya satu baris — bandingkan waktu henti secondary dengan keluaran log length start to end dari rs.printReplicationInfo() (Chapter Oplog menunjukkan cara membacanya). Bila waktu henti melebihi jendela itu, entri oplog yang dibutuhkan sudah tertimpa.

Pemulihannya hanya satu: initial sync ulang — kosongkan direktori data anggota tersebut lalu nyalakan kembali mongod; anggota menyalin seluruh data dari anggota sehat mana pun. Pencegahannya lebih murah daripada obatnya: perbesar oplog (--oplogSize atau replSetResizeOplog) dan jaga lag tetap kecil.

Election Storm #

Election sesekali adalah replikasi bekerja normal. Election storm — primary berganti-ganti dalam hitungan menit dengan term yang melompat-lompat — hampir selalu gejala infrastruktur: jaringan antar anggota yang putus-nyambang membuat heartbeat gagal berulang, atau satu anggota yang sangat lambat membuat primary lain tidak pernah tenang. Diagnosisnya: baca electionDate tiap anggota dari rs.status(), lalu periksa latensi dan stabilitas jaringan antar node, lalu pastikan spesifikasi tiap anggota sepadan. Solusinya jarang berupa penyetelan MongoDB — biasanya memperbaiki jaringan atau mesin bermasalah, kadang menurunkan priority anggota yang lemah agar tidak terus merebut jabatan.

Klien Salah Sasaran: Direct Connection ke Secondary #

Galat paling sering di sisi aplikasi muncul bukan karena cluster sakit, tetapi karena koneksi menempel pada anggota yang salah. Dengan directConnection=true ke sebuah secondary, driver tidak memantau topologi — semua perintah dikirim mentah ke node itu:

// mdtest: skip — rs0 tidak memiliki secondary; skenario direct ke secondary
// mongosh "mongodb://mongod-2.example.com:27017/?directConnection=true"
// db.pesanan.insertOne({ kode: "PSN-999" })
// // => galat NotWritablePrimary, kode 10107
// db.pesanan.find()
// // => tanpa read preference, galat NotPrimaryNoSecondaryOk, kode 13435

Dua kode galat itu layak dihafal. 10107 (NotWritablePrimary) menolak write di node tanpa hak menulis; 13435 (NotPrimaryNoSecondaryOk) menolak baca yang dikirim tanpa read preference ke anggota non-primary. Perbaikannya bukan pada server, melainkan pada string koneksi: gunakan mode replica set (replicaSet=rs0 dengan daftar host) agar driver selalu mengarah dengan benar, atau bila memang harus direct ke secondary, pasang readPreference=secondary pada koneksi itu.

Tabel Rujukan: Gejala, Penyebab, Tindakan #

Rangkuman #

• Diagnosis dibuka dengan rs.status() (health, state, kuorum) dan ditutup dengan rs.printSecondaryReplicationInfo() (posisi tiap secondary).
• RECOVERING berarti menunggu pengejaran; ROLLBACK berarti menelaah write yang digulung mantan primary.
• Jendela oplog yang habis dipulihkan dengan initial sync ulang dan dicegah dengan oplog yang lebih besar serta lag yang kecil.
• Election storm hampir selalu masalah infrastruktur, bukan konfigurasi; kode galat 10107 dan 13435 hampir selalu masalah connection string.

Section Replication tuntas — primary, oplog, election, hingga jaminan baca-tulis kini berada dalam kendali kita. Section berikutnya melangkah ke arsitektur yang lebih besar lagi: sharding, tempat data tidak hanya disalin tetapi juga dipecah.