Status Replica Set

Replica set yang sehat jarang memberi kabar — primary tetap menerima tulisan, secondary terus menyalin, dan tidak ada election yang tak terduga. Tugas admin adalah membuktikan kesehatan itu secara berkala, bukan menunggu aplikasi turun lebih dulu. MongoDB menyediakan empat jendela pemeriksaan: rs.status() untuk kondisi anggota, rs.conf() untuk konfigurasi yang berlaku, rs.printReplicationInfo() untuk oplog, dan db.hello() untuk sudut pandang koneksi. Chapter ini membaca semuanya pada replica set rs0 milik server latihan kita.

Peta materi chapter ini:

• rs.status(): state, health, dan optime tiap anggota.
• rs.conf(): konfigurasi aktif versus kondisi berjalan.
• rs.printReplicationInfo(): ukuran dan jendela waktu oplog.
• db.hello() dari sudut pandang koneksi.

rs.status(): Potret Kesehatan Anggota #

Perintah rs.status() adalah pemeriksaan pertama setiap pagi. Identitas set dan state proses lokal kita bisa diambil singkat:

const st = rs.status()
[ st.set, st.myState ]

Output yang Dihasilkan:

[ 'rs0', 1 ]

Nilai myState angka 1 adalah kode untuk PRIMARY — proses yang kita sambangi adalah anggota yang menerima tulisan. Detail tiap anggota ada di array members:

st.members

Output yang Dihasilkan:

[
  {
    _id: 0,
    name: '127.0.0.1:27017',
    health: 1,
    state: 1,
    stateStr: 'PRIMARY',
    uptime: 25832,
    optime: { ts: Timestamp({ t: 1792268144, i: 4 }), t: Long('8') },
    optimeDate: ISODate('2026-10-17T20:15:44.000Z'),
    optimeWritten: { ts: Timestamp({ t: 1792268144, i: 4 }), t: Long('8') },
    optimeWrittenDate: ISODate('2026-10-17T20:15:44.000Z'),
    lastAppliedWallTime: ISODate('2026-10-17T20:15:44.846Z'),
    lastDurableWallTime: ISODate('2026-10-17T20:15:44.846Z'),
    lastWrittenWallTime: ISODate('2026-10-17T20:15:44.846Z'),
    lastStableRecoveryTimestamp: Timestamp({ t: 1792268123, i: 182 }),
    syncSourceHost: '',
    syncSourceId: -1,
    infoMessage: '',
    electionTime: Timestamp({ t: 1792242323, i: 1 }),
    electionDate: ISODate('2026-10-17T13:05:23.000Z'),
    configVersion: 1,
    configTerm: 8,
    self: true,
    lastHeartbeatMessage: ''
  }
]

Server latihan kita memang hanya punya satu anggota, jadi array itu berisi satu elemen dengan self: true. Field-fieldnya adalah kunci bacaan kesehatan:

Nilai stateStr yang mungkin Anda jumpai:

Pada set multi-anggota, replication lag dibaca dari selisih optimeDate anggota secondary terhadap primary — pembahasan mendalamnya ada di chapter Replication Lag pada section Replication; di sini kita cukup tahu posisi angka-angkanya.

rs.conf(): Konfigurasi yang Berlaku #

rs.status() melaporkan kondisi; rs.conf() melaporkan aturan mainnya — konfigurasi yang saat ini dipakai set:

rs.conf().members

Output yang Dihasilkan:

[
  {
    _id: 0,
    host: '127.0.0.1:27017',
    arbiterOnly: false,
    buildIndexes: true,
    hidden: false,
    priority: 1,
    tags: {},
    secondaryDelaySecs: Long('0'),
    votes: 1
  }
]

Setiap anggota membawa atribut peran: priority menentukan peluang menjadi primary (0 berarti tidak pernah), votes memberi hak suara election, hidden menyembunyikan anggota dari driver, dan secondaryDelaySecs menjadikan anggota tertunda sebagai lapisan pengaman. Konfigurasi ini hanya berubah lewat rs.reconfig() — perintah level cluster yang tidak kita jalankan di server bersama; mekanisme lengkapnya dibahas di chapter Konfigurasi Replication.

Oplog: rs.printReplicationInfo() #

Oplog adalah collection khusus yang merekam semua perubahan — bahan bakar replikasi. Ringkasan kapasitasnya:

rs.printReplicationInfo()

Output yang Dihasilkan:

actual oplog size
'990 MB'
---
configured oplog size
'990 MB'
---
log length start to end
'26892 secs (7.47 hrs)'
---
oplog first event time
'Sat Oct 17 2026 12:47:32 GMT+0000 (Coordinated Universal Time)'
---
oplog last event time
'Sat Oct 17 2026 20:15:44 GMT+0000 (Coordinated Universal Time)'
---
now
'Sat Oct 17 2026 20:15:54 GMT+0000 (Coordinated Universal Time)'

Dua baris terpenting: ukuran oplog (990 MB, dibatasi 5% dari disk secara bawaan untuk set kecil) dan log length — jendela waktu yang masih tersimpan, di server ini sekitar 7 jam. Jendela inilah batas keselamatan: secondary yang putus lebih lama dari jendela oplog harus menjalani initial sync ulang, bukan sekadar melanjutkan. Untuk beban tulisan tinggi, oplog bisa dibesarkan kapan saja lewat replSetResizeOplog tanpa mematikan anggota — dibahas di chapter Oplog.

db.hello(): Sudut Pandang Koneksi #

Terakhir, db.hello() menjawab pertanyaan dari sisi klien: “kepada siapa saya terhubung dan bolehkah menulis?”:

const h = db.hello()
[ h.setName, h.isWritablePrimary, h.secondary, h.primary, h.me ]

Output yang Dihasilkan:

[ 'rs0', true, false, '127.0.0.1:27017', '127.0.0.1:27017' ]

Lima jawaban sekaligus: kita terhubung ke set bernama rs0, proses ini adalah primary yang bisa menerima tulisan (isWritablePrimary: true), bukan secondary, dan alamat primary memang alamat yang kita sambangi. Inilah perintah yang dipanggil driver secara berkala untuk memantau topologi — ketika primary turun dan election berlangsung, klien menemukan primary baru lewat mekanisme yang sama (chapter Elections dan Failover). Sebagai pemeriksaan cepat kesehatan set dari aplikasi, pola db.hello().isWritablePrimary sudah cukup.

Rangkuman #

• rs.status() adalah pemeriksaan pertama: health, stateStr, uptime, dan optimeDate tiap anggota; lag = selisih optimeDate secondary terhadap primary.
• rs.conf() menampilkan aturan (priority, votes, hidden, secondaryDelaySecs) — hanya berubah lewat rs.reconfig().
• rs.printReplicationInfo() menunjukkan ukuran oplog dan jendela waktunya — secondary yang tertinggal melewati jendela ini harus initial sync ulang.
• db.hello() memberi sudut pandang koneksi: isWritablePrimary, primary, dan me — dasar yang juga dipakai driver untuk mengikuti topologi.