Belajar MongoDB - Replica Sets (High Availability & Read Scaling)

#Pendahuluan

Sejauh ini kalian menjalankan MongoDB sebagai satu instance tunggal. Itu menyenangkan untuk belajar, tapi tidak cukup untuk produksi: jika instance mati — server crash, network down, proses tewas — aplikasi kalian ikut mati, dan data bisa hilang. Di sinilah Replica Set menjadi tulang punggung deployment MongoDB yang serius.

Episode 15 membangun pemahaman high availability. Roadmap-nya: pertama konsep dan arsitektur replica set — primary, secondary, dan arbiter, kedua mekanisme failover otomatis lewat election, ketiga read preference untuk read scaling, dan keempat langkah praktis mengonfigurasi replica set tiga anggota. Mari mulai.

#Konsep Replica Set

Replica Set adalah sekumpulan instance mongod yang menyimpan dataset yang sama. Data di-primary direplikasi ke semua secondary secara kontinu. Fungsinya ganda: redundansi (data aman jika satu server hilang) dan failover otomatis (jika primary mati, secondary terpilih menggantikan tanpa campur tangan manusia).

Replica set adalah komponen fundamental MongoDB — bahkan satu instance pun sebenarnya bisa dijalankan sebagai replica set satu anggota. Sharding di episode 16 juga dibangun di atas replica set sebagai unit shard-nya.

#Arsitektur Replica Set

#Primary, Secondary, dan Arbiter

Setiap replica set terdiri dari tiga peran:

• Primary — satu-satunya node yang menerima operasi tulis. Semua write mengalir ke primary, lalu direplikasi ke secondary.
• Secondary — node yang menyimpan salinan data primary. Secara default read-only. Bisa diarahkan untuk menerima read (read scaling), dan bisa terpilih menjadi primary berikutnya.
• Arbiter — node yang hanya ikut voting dalam election, tanpa menyimpan data. Digunakan untuk mencapai mayoritas genap, biasanya saat jumlah data nodes genap.

                +----------------+
                |    Clients     |
                +----------------+
                        |
                        v
              +--------------------+
              |   PRIMARY mongod   |  <- tulis + baca default
              +--------------------+
                   |          |
            replicate|          |replicate
                   v          v
        +----------------+  +----------------+
        |  SECONDARY 1   |  |  SECONDARY 2   |
        +----------------+  +----------------+

#Bagaimana Data Direplikasi?

Setiap perubahan di primary dicatat ke oplog (operations log) — log tulis berurutan. Secondary menarik oplog ini dan menerapkan perubahannya ke data mereka sendiri. Inilah mekanisme replikasi yang berjalan terus-menerus. Kecepatan "mengejar" secondary mengukur seberapa cepat ia mereplikasi; jika ketinggalan terlalu jauh, muncul masalah replication lag yang kita bahas di episode 19.

#Automatic Failover Election

Saat primary mati (crash, network terputus), anggota lain mendeteksi tidak ada detak jantung dari primary, lalu mengadakan election untuk memilih primary baru. Election memakai protokol mayoritas — dibutuhkan suara mayoritas anggota agar sebuah election sah.

Inilah mengapa jumlah anggota yang ganjil sangat penting. Dengan tiga anggota, mayoritas adalah 2 — satu secondary mati, dua sisanya masih bisa membentuk mayoritas dan memilih primary baru. Dengan dua anggota saja, satu mati berarti hanya tersisa satu suara, tidak cukup mayoritas, dan cluster menjadi read-only.

rs.status()

rs.status() menampilkan setiap anggota, perannya, dan kondisi health-nya. Setelah failover, kalian akan melihat nama anggota yang menggantikan primary — dan seluruh proses terjadi otomatis dalam hitungan detik.

#Read Preference

Secara default, semua read (dan write) menuju primary. Untuk menskalakan pembacaan — memanfaatkan secondary yang menganggur — aplikasi bisa mengatur read preference. Ada lima mode:

Mengatur read preference di driver Node.js

const collection = db.collection("orders");
const cursor = collection.find({ userId: userId }).readPref("secondary");

Baca dari secondary punya konsekuensi penting: data secondary bisa sedikit tertinggal dari primary (replication lag). Untuk data yang harus selalu terkini — saldo, stok — tetap pakai primary. Mode secondary cocok untuk laporan dan data yang toleran terhadap keterlambatan. Ini adalah keputusan trade-off antara performa dan konsistensi.

#Konfigurasi Replica Set Tiga Anggota

Sekarang mari membangun replica set lengkap. Cara tercepat mempraktikkannya di mesin sendiri adalah dengan Docker, menjalankan tiga instance mongod dalam satu network:

docker network create mongors
docker run -d --name mongo1 --network mongors -p 27017:27017 mongo:7 mongod --replSet rs0
docker run -d --name mongo2 --network mongors -p 27018:27017 mongo:7 mongod --replSet rs0
docker run -d --name mongo3 --network mongors -p 27019:27017 mongo:7 mongod --replSet rs0

Ketiga kontainer berjalan dengan flag --replSet rs0, menandakan mereka anggota dari replica set bernama rs0. Sekarang inisiasi replica set dan daftarkan ketiganya:

mongosh "mongodb://localhost:27017" --eval '
rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "mongo1:27017" },
    { _id: 1, host: "mongo2:27017" },
    { _id: 2, host: "mongo3:27017" }
  ]
})
'

Setelah inisiasi, verifikasi status dan health:

rs.status()
rs.isMaster()

rs.isMaster() menunjukkan siapa primary saat ini. Setiap anggota punya stateStr yang jelas: PRIMARY, SECONDARY, atau ARBITER. Untuk menguji failover, matikan primary (docker stop mongo1) dan perhatikan — dalam hitungan detik, salah satu secondary terpilih menjadi primary baru. Data tidak hilang, dan aplikasi bisa terus berjalan.

#Penutup

Pada episode 15 ini kalian telah memahami konsep replica set sebagai fondasi high availability: sekumpulan mongod dengan dataset sama yang menyediakan redundansi dan failover otomatis. Kalian mengenal peran primary yang menerima write, secondary yang mereplikasi data dan melayani read, serta arbiter yang hanya voting. Kalian memahami mekanisme election berbasis mayoritas, memanfaatkan read preference untuk menskalakan pembacaan, dan mempraktikkan konfigurasi replica set tiga anggota penuh di Docker beserta uji failover.

Inti yang harus dibawa pulang:

• Replica set = redundansi data + failover otomatis; tulang punggung produksi MongoDB.
• Write selalu ke primary; oplog menggerakkan replikasi ke secondary.
• Election butuh mayoritas — jumlah anggota ganjil itu penting.
• Read preference memindahkan read ke secondary untuk menskalakan pembacaan.
• Replikasi berarti secondary bisa tertinggal — konsistensi vs performa adalah trade-off.

Di episode 16 berikutnya kita melangkah lebih jauh: Sharding (Horizontal Scalability). Kalian akan memahami kapan dataset perlu di-sharding, arsitektur sharded cluster yang terdiri dari shard, config servers, dan mongos, serta memilih shard key yang tepat antara ranged dan hashed sharding. Sampai jumpa di episode 16!