Arsitektur Replica Set

Replica set bukan sekadar beberapa proses mongod yang kebetulan menyimpan data sama — arsitekturnya menentukan siapa yang boleh menulis, bagaimana primary dipilih, dan berapa anggota yang boleh gagal sebelum layanan terganggu. Chapter ini membedah anatomi anggota replica set beserta perannya, membaca konfigurasi anggota melalui rs.conf(), lalu menutup dengan cara aplikasi terhubung ke seluruh anggota. Seluruh keluaran perintah di bawah diambil dari replica set latihan rs0.

Jenis-Jenis Anggota Replica Set #

Setiap baris pada rs.conf().members disebut member document — deskripsi satu anggota beserta perannya. MongoDB mengenal lima peran utama:

Peran	Menyimpan data	Memiliki suara	Keterangan
Data-bearing voting member	Ya	Ya	Bentuk standar: bisa menjadi primary
Arbiter	Tidak	Ya	Hanya memenuhi kuorum; hemat sumber daya
Priority 0 member	Ya	Ya	Tidak pernah jadi primary; cocok untuk anggota cadangan/regional
Hidden member	Ya	Ya	Tidak terlihat klien; dipakai untuk analitik atau backup
Delayed member	Ya	Ya	Datanya tertunda (mis. 1 jam) — jaring pengaman kesalahan tulis

Arbiter ada untuk satu skenario sempit: replica set dua data-bearing anggota yang tidak sanggup menambah mesin ketiga. Tanpa anggota ketiga, tidak ada mayoritas saat salah satu node gagal; arbiter memberi suara tambahan tanpa menyalin data. Hidden dan delayed dibangun di atas priority 0, karena anggota yang diprioritaskan untuk tugas khusus tidak boleh ikut merebut posisi primary.

Membaca Konfigurasi Anggota: rs.conf() #

Perintah rs.conf() mengembalikan seluruh konfigurasi replica set. Pada rs0 keluarannya ringkas karena hanya berisi satu anggota:

js
rs.conf()

Output yang Dihasilkan:

text
{
  _id: 'rs0',
  version: 1,
  term: 8,
  members: [
    {
      _id: 0,
      host: '127.0.0.1:27017',
      arbiterOnly: false,
      buildIndexes: true,
      hidden: false,
      priority: 1,
      tags: {},
      secondaryDelaySecs: Long('0'),
      votes: 1
    }
  ],
  protocolVersion: Long('1'),
  writeConcernMajorityJournalDefault: true,
  settings: {
    chainingAllowed: true,
    heartbeatIntervalMillis: 2000,
    heartbeatTimeoutSecs: 10,
    electionTimeoutMillis: 10000,
    catchUpTimeoutMillis: -1,
    catchUpTakeoverDelayMillis: 30000,
    getLastErrorModes: {},
    getLastErrorDefaults: { w: 1, wtimeout: 0 },
    replicaSetId: ObjectId('6ad36e64b4c2fb6d4d659c51')
  }
}

Bagian settings mengatur perilaku seluruh set — interval heartbeat, batas waktu election, hingga opsi chaining — dan kita bedah satu per satu di Chapter Konfigurasi Replication. Mari kita telaah field pada member pertama:

_id: 0: nomor identitas anggota di dalam set — unik dan tidak berubah setelah dibuat.
host: '127.0.0.1:27017': alamat jaringan anggota; di cluster produksi berupa mongod-1.example.com:27017 dan seterusnya.
arbiterOnly: false: anggota ini menyimpan data — bukan arbiter.
buildIndexes: true: anggota membangun index seperti anggota lain; hanya anggota priority 0 yang boleh mematikannya (buildIndexes: false).
hidden: false: anggota terlihat oleh klien dan boleh menerima baca dengan read preference tertentu.
priority: 1: peluang anggota menjadi primary pada election; anggota dengan priority 0 tidak pernah terpilih.
tags: {}: label kustom untuk mengarahkan baca — dasar fitur tag sets pada read preference.
secondaryDelaySecs: 0: penundaan replikasi dalam detik; nilai di atas nol menjadikan anggota ini delayed member.
votes: 1: anggota memiliki hak suara pada election.

Field version mencatat revisi konfigurasi (naik setiap rs.reconfig()), sedangkan term mencatat periode kepemimpinan primary saat ini — keduanya menjadi rujukan cepat usia konfigurasi.

Quorum: Semua Saling Terhubung, Mayoritas yang Menentukan #

Anggota replica set saling terhubung penuh — setiap node mengirim heartbeat ke setiap node lain setiap 2 detik. Keputusan penting (memilih primary, mengonfirmasi write majority) membutuhkan suara dari mayoritas anggota voting, bukan dari satu node tertentu:

flowchart TB subgraph RS [Replica set 3 anggota — semua saling terhubung] A[mongod-1<br/>PRIMARY] <--> B[mongod-2<br/>SECONDARY] A <--> C[mongod-3<br/>SECONDARY] B <--> C end

Dari 2n+1 anggota voting, mayoritas adalah n+1 suara. Cluster tiga anggota butuh 2 suara: selama 2 dari 3 node hidup, masih ada mayoritas dan primary bisa dipilih. Saat 2 node sekaligus gagal, tersisa 1 suara — bukan mayoritas — sehingga replica set sengaja berhenti menerima write daripada berisiko menulis tanpa jaminan replikasi. Inilah cara replica set mencegah dua primary aktif bersamaan ketika jaringan terbelah.

Konfigurasi	Data-bearing	Arbiter	Mayoritas	Toleransi kegagalan
P-S-S	3	0	2 dari 3	1 node
P-S-A	2	1	2 dari 3	1 node (data tetap utuh pada 1 salinan)
P-S-S-S-S	5	0	3 dari 5	2 node

Perhatikan baris P-S-A: toleransi kegagalan sama dengan P-S-S, tetapi saat satu data-bearing node gagal, data hanya tersisa satu salinan. Arbiter menaikkan ketersediaan, bukan ketahanan data.

Direct Connection vs Replica Set Connection #

Ada dua cara klien terhubung, dan keduanya penting dipahami sebelum mengoperasikan replica set:

Mode	Connection string	Perilaku
Replica set	`mongodb://mongod-1:27017,mongod-2:27017,mongod-3:27017/?replicaSet=rs0`	Driver memantau seluruh anggota, otomatis mengikuti primary baru setelah failover
Direct	`mongodb://127.0.0.1:27017/?directConnection=true`	Driver menempel pada satu host saja — tanpa pemantauan topologi

Mode replica set adalah mode produksi: cukup sebutkan satu atau dua host dari daftar, driver akan menemukan anggota lainnya lewat perintah hello (field hosts pada keluaran db.hello() di Chapter sebelumnya) lalu menjaga koneksi ke primary dan secondary sekaligus. Mode direct dipakai untuk operasi administratif pada satu node — misalnya memperbaiki anggota tertentu tanpa memicu failover.

js
db.getMongo()

Output yang Dihasilkan:

text

mongodb://127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&appName=mongosh+2.13.0

mongosh menambahkan parameter serverSelectionTimeoutMS dan appName miliknya sendiri di belakang URI, tetapi kuncinya tetap satu: directConnection=true. Untuk mematikan server atau menjalankan tugas maintenance, mode direct memang yang benar; untuk aplikasi biasa, selalu gunakan mode replica set agar failover berlangsung mulus.

Rangkuman #

Member document pada rs.conf() mendefinisikan peran tiap anggota: priority, hidden, secondaryDelaySecs, votes, dan arbiterOnly.
Semua anggota saling bertukar heartbeat; keputusan election dan write majority memerlukan suara n+1 dari 2n+1 anggota voting.
Arbiter menambah suara tanpa data — menaikkan ketersediaan P-S-A, tetapi tidak menambah salinan data.
Aplikasi produksi terhubung dengan replicaSet=rs0 dan daftar host; mode directConnection=true hanya untuk administrasi satu node.

Chapter berikutnya memasuki ruang mesin: bagaimana primary menerima write dan secondary menyalinnya melalui oplog.