Konfigurasi replica set adalah dokumen hidup: cluster yang hari ini beranggota tiga bisa tumbuh menjadi lima, anggota baru butuh priority berbeda, dan parameter heartbeat kerap perlu disetel sesuai jaringan. MongoDB menyimpan seluruh keputusan itu dalam satu dokumen konfigurasi yang bisa dibaca dengan rs.conf() dan diubah dengan rs.reconfig(). Chapter ini membedah isi dokumen tersebut pada rs0, menunjukkan bentuk lengkap rs.initiate() untuk cluster baru, lalu menutup dengan perilaku default read/write concern yang berpindah sejak MongoDB 5.0.

Membaca Settings: rs.conf() #

Kita sudah membaca blok members di Chapter Arsitektur Replica Set; kali ini fokus ke blok settings — parameter perilaku seluruh set:

js 
rs.conf().settings

Output yang Dihasilkan:

text 
{
  chainingAllowed: true,
  heartbeatIntervalMillis: 2000,
  heartbeatTimeoutSecs: 10,
  electionTimeoutMillis: 10000,
  catchUpTimeoutMillis: -1,
  catchUpTakeoverDelayMillis: 30000,
  getLastErrorModes: {},
  getLastErrorDefaults: { w: 1, wtimeout: 0 },
  replicaSetId: ObjectId('6ad36e64b4c2fb6d4d659c51')
}

Mari kita bedah parameter demi parameter:

  1. chainingAllowed: true: secondary boleh menyalin oplog dari secondary lain (chained replication), bukan hanya dari primary — dibahas khusus di bagian akhir chapter ini.
  2. heartbeatIntervalMillis: 2000: setiap anggota mengirim heartbeat ke anggota lain setiap 2 detik.
  3. heartbeatTimeoutSecs: 10: anggota dianggap tidak sehat bila heartbeat-nya tidak tiba dalam 10 detik — pemicu diagnosis lebih lanjut atau election.
  4. electionTimeoutMillis: 10000: tenggat election setelah primary terdeteksi hilang; peran sentralnya dibahas di Chapter Elections dan Failover.
  5. catchUpTimeoutMillis: -1: setelah terpilih, primary baru diberi waktu mengejar oplog primary lama; -1 berarti memakai batas waktu internal default.
  6. catchUpTakeoverDelayMillis: 30000: jeda sebelum secondary yang lebih maju boleh merebut posisi primary baru yang belum selesai mengejar.
  7. getLastErrorModes dan getLastErrorDefaults: mekanisme write concern lama — keduanya deprecated dan tidak lagi menjadi acuan; penggantinya dibahas dua bagian di bawah.
  8. replicaSetId: identitas set yang tidak berubah sejak dibuat.

Di luar settings, dua field level atas juga menarik: protocolVersion: 1 menandai versi protokol replikasi (versi 0 untuk MongoDB lawas telah ditinggalkan), dan writeConcernMajorityJournalDefault: true mengatur jurnal untuk write concern majority bila j tidak disebutkan.

rs.initiate: Membentuk Replica Set Baru #

Replica set terbentuk dari satu perintah di node pertama: rs.initiate() dengan dokumen konfigurasi awal. Replica set rs0 kita sudah berjalan sehingga perintah berikut tidak dijalankan ulang — bentuk lengkapnya untuk cluster tiga anggota adalah:

js 
// mdtest: skip — rs0 sudah berjalan; bentuk lengkap untuk cluster baru
rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "mongod-1.example.com:27017" },
    { _id: 1, host: "mongod-2.example.com:27017" },
    { _id: 2, host: "mongod-3.example.com:27017" }
  ]
})

Tiga hal wajib ada di dokumen awal: _id set (harus sama dengan replSetName di file konfigurasi mongod setiap anggota), daftar members dengan _id unik per anggota, dan host yang bisa dijangkau seluruh anggota lain. Field lain — priority, votes, hidden — boleh ditambah langsung atau belakangan lewat rs.reconfig(). Setelah initiate, node pertama mengadakan election satu-satunya dan menjadi primary; node berikutnya bergabung melalui rs.add() lalu menjalankan initial sync.

rs.reconfig: Mengubah Cluster Berjalan #

Semua perubahan pada cluster hidup melewati satu pintu: ambil konfigurasi dengan rs.conf(), ubah objeknya, lalu kirim dengan rs.reconfig(). Pola untuk menaikkan priority anggota pertama menjadi 2:

js 
// mdtest: skip — mengubah konfigurasi server latihan bersama tidak dilakukan
const cfg = rs.conf()
cfg.members[0].priority = 2
rs.reconfig(cfg)

rs.reconfig() otomatis menaikkan version dan menyebarkan konfigurasi baru ke seluruh anggota; anggota yang tidak menerima konfigurasi terbaru akan menolak perannya sampai sinkron. Praktik aman yang berlaku: ubah satu hal per reconfig, tunggu anggota baru selesai initial sync (state STARTUP2 → SECONDARY) sebelum menambah anggota lain, dan jangan mengubah votes bersamaan dengan penambahan anggota — dua perubahan berisiko tinggi sebaiknya tidak bertumpuk dalam satu langkah.

Anggota dihapus dengan rs.remove("host:port"); sebelum menghapus primary, rs.stepDown() lebih dulu agar anggota itu turun ke posisi secondary dan election berlangsung terkendali.

Default Read/Write Concern: Field Lawas vs getDefaultRWConcern #

Field getLastErrorDefaults di settings mudah menyesatkan: nilainya { w: 1, wtimeout: 0 }, tetapi sejak MongoDB 5.0 field ini deprecated dan tidak lagi menentukan write concern default. Kewenangan itu berpindah ke mekanisme default RW concern di level set, yang bisa dibaca dengan perintah admin:

js 
const d = db.adminCommand({ getDefaultRWConcern: 1 })
({
  defaultReadConcern: d.defaultReadConcern,
  defaultWriteConcern: d.defaultWriteConcern,
  sumberReadConcern: d.defaultReadConcernSource,
  sumberWriteConcern: d.defaultWriteConcernSource
})

Output yang Dihasilkan:

text 
{
  defaultReadConcern: { level: 'local' },
  defaultWriteConcern: { w: 'majority', wtimeout: 0 },
  sumberReadConcern: 'implicit',
  sumberWriteConcern: 'implicit'
}

Dua hal terbaca dari keluaran ini. Pertama, default write concern efektif rs0 adalah w: "majority" — bukan w: 1 seperti yang ditunjukkan getLastErrorDefaults. Kedua, sumber: 'implicit' berarti nilai itu dihitung server, bukan diatur eksplisit operator; administrator bisa menetapkan default sendiri dengan setDefaultRWConcern, dan kolom sumber akan berubah menjadi 'custom'. Algoritma implisitnya memilih majority untuk mayoritas konfigurasi, sehingga write tanpa write concern eksplisit di cluster modern sudah diakui mayoritas anggota secara bawaan.

Chained Replication #

Setting chainingAllowed: true mengizinkan secondary menyalin oplog dari secondary lain, bukan selalu dari primary:

Rantai seperti ini mengurangi beban jaringan primary: cukup satu secondary yang menarik langsung, secondary berikutnya menarik dari secondary pertama. Konsekuensinya, lag berlapis — secondary kedua menunggu dua lompatan replikasi — sehingga cluster yang sensitif terhadap lag kerap menonaktifkan chaining (chainingAllowed: false) agar semua secondary menyalin langsung dari primary. Di rs0 setting ini tidak berpengaruh karena hanya ada satu anggota, tetapi nilainya true dan itu default MongoDB.

Rangkuman #

  • rs.conf().settings memuat parameter perilaku set: heartbeat 2 detik, batas 10 detik, election timeout 10 detik, dan chaining replikasi.
  • rs.initiate() membentuk set baru dengan _id, members, dan host; perubahan pada cluster berjalan selalu lewat pola rs.conf() → ubah → rs.reconfig().
  • getLastErrorDefaults sudah deprecated; write concern default efektif dibaca dari db.adminCommand({ getDefaultRWConcern: 1 }) — pada rs0 berupa w: "majority" sumber implisit.
  • Chained replication menurunkan beban primary dengan biaya lag berlapis; dinonaktifkan lewat chainingAllowed: false.

Konfigurasi hanyalah peta — chapter berikutnya menyaksikan peta itu dipakai saat keadaan darurat: primary hilang dan election dimulai.