Replication Overview

Satu proses mongod di satu mesin adalah titik kegagalan tunggal: saat mesin mati, jaringan terputus, atau disk rusak, aplikasi berhenti bekerja dan data berisiko hilang. Replikasi adalah mekanisme MongoDB untuk menjawab risiko tersebut dengan menjaga beberapa salinan data pada sekelompok server yang saling memantau. Chapter ini membuka Section Replication dengan memetakan alasan menjalankan replikasi, memperkenalkan konsep replica set, lalu memeriksa replica set rs0 yang dipakai sepanjang latihan kita.

Peta materi Chapter ini:

• Tiga alasan utama replikasi: ketersediaan, ketahanan data, dan distribusi baca.
• Replica set sebagai grup mongod dengan salinan data yang sama.
• Aturan mayoritas dan kenapa replica set butuh anggota voting berjumlah ganjil.

Tiga Alasan Menjalankan Replikasi #

Replikasi menyalin data dari satu server ke server lain secara otomatis dan berkelanjutan. Setiap alasan di bawah ini muncul dari masalah operasional nyata:

Ketiganya bermuara pada satu prinsip: ketersediaan layanan dan ketahanan data tidak boleh bergantung pada satu mesin. MongoDB menjalankan prinsip itu melalui konstruksi bernama replica set.

Replica Set: Grup mongod dengan Data Sama #

Replica set adalah sekelompok proses mongod — biasanya di mesin terpisah — yang menyimpan set data yang sama. Satu anggota menerima seluruh operasi tulis dan disebut primary; anggota lain disebut secondary dan terus menyalin perubahan dari primary. Bila primary berhenti bekerja, anggota secondary yang tersisa memilih primary baru di antara mereka.

Diagram di atas memperlihatkan alur dasarnya: aplikasi menulis hanya ke primary, lalu primary menuliskan setiap perubahan ke oplog — log berurutan yang akan disalin setiap secondary. Detail oplog dibedah tuntas di Chapter Oplog; untuk saat ini, bayangkan oplog sebagai daftar putar perubahan yang selalu diputar ulang oleh secondary.

Memeriksa Replica Set Latihan: rs0 #

Server latihan kita adalah replica set bernama rs0 — satu anggota di 127.0.0.1:27017. Perintah db.hello() mengungkap identitas replica set dari sisi koneksi saat ini:

const h = db.hello()
({
  setName: h.setName,
  isWritablePrimary: h.isWritablePrimary,
  secondary: h.secondary,
  primary: h.primary,
  hosts: h.hosts
})

Output yang Dihasilkan:

{
  setName: 'rs0',
  isWritablePrimary: true,
  secondary: false,
  primary: '127.0.0.1:27017',
  hosts: [ '127.0.0.1:27017' ]
}

Mari kita bedah tiap field:

1. setName: 'rs0': koneksi ini menempel pada replica set bernama rs0. Server standalone tidak memiliki field ini.
2. isWritablePrimary: true: node yang kita hubungi adalah primary — satu-satunya anggota yang boleh menerima write.
3. secondary: false: kebalikan dari field di atas; node ini bukan secondary.
4. primary: '127.0.0.1:27017': alamat primary saat ini — driver memakai field ini untuk mengarahkan write ke node yang tepat.
5. hosts: daftar seluruh anggota replica set; pada rs0 hanya ada satu.

Status keseluruhan set dapat dibaca dari rs.status(). Kita ambil bagian ringkasnya:

const st = rs.status()
({
  set: st.set,
  myState: st.myState,
  jumlahAnggota: st.members.length,
  stateAnggota: st.members.map(m => m.stateStr)
})

Output yang Dihasilkan:

{
  set: 'rs0',
  myState: 1,
  jumlahAnggota: 1,
  stateAnggota: [ 'PRIMARY' ]
}

myState: 1 adalah kode numerik untuk state PRIMARY, dan array members berisi tepat satu anggota. Output ini akan berubah bentuk di cluster produksi: members berisi satu entri per server beserta kesehatan, posisi replikasi, dan pesan heartbeat-nya — kerangka itu yang akan kita baca berulang kali di chapter-chapter berikutnya.

Mayoritas: Berapa Anggota yang Cukup #

Pemilihan primary baru memerlukan mayoritas anggota voting — lebih dari separuh — agar tidak ada dua primary terpilih bersamaan di dua sisi jaringan yang terputus. Karena itu jumlah anggota voting sebaiknya ganjil: dari 2n+1 anggota, mayoritas adalah n+1, sehingga cluster tetap punya primary selama paling banyak n anggota gagal.

Konfigurasi minimum produksi adalah tiga anggota data-bearing (Primary–Secondary–Secondary), atau dua anggota data ditambah satu arbiter (P-S-A) bila sumber daya terbatas — arbiter adalah anggota voting tanpa data yang perannya hanya memenuhi kuorum. Kedua varian itu dibahas detail di Chapter Arsitektur Replica Set.

Rangkuman #

• Replikasi menjaga salinan data berlebih untuk tiga tujuan: ketersediaan saat kegagalan, ketahanan data, dan distribusi beban baca.
• Replica set adalah grup mongod dengan data sama: satu primary menerima semua write, secondary menyalin perubahan lewat oplog.
• Pemilihan primary baru butuh suara mayoritas; jumlah anggota voting ganjil (3, 5, 7) memberi toleransi kegagalan maksimal.
• Server latihan rs0 adalah replica set satu anggota — cukup untuk mempelajari seluruh mekanisme berbasis oplog secara nyata.

Chapter berikutnya membedah anatomi replica set: jenis-jenis anggota, perhitungan quorum, dan cara klien terhubung ke seluruh anggotanya.