Mekanisme Election pada MongoDB Replica Set
Dalam arsitektur MongoDB Replica Set, salah satu mekanisme terpenting yang menjamin high availability adalah proses election (pemilihan Primary). Artikel ini akan membahas secara teknis dan praktis bagaimana mekanisme election bekerja, kapan election terjadi, serta bagaimana cara memonitor dan mensimulasikannya.
Artikel ini merupakan lanjutan dari pembahasan sebelumnya tentang konfigurasi Replica Set di MongoDB.
Apa Itu Election di MongoDB?
Dalam Replica Set, hanya ada satu node Primary yang menerima operasi write. Jika Primary gagal atau tidak dapat diakses, maka Secondary akan melakukan proses election untuk memilih Primary baru.
Tujuan election:
- Menjaga ketersediaan layanan (high availability)
- Menghindari split-brain
- Memastikan konsistensi data
Kapan Election Terjadi?
Election biasanya terjadi ketika:
- Primary crash / service mongod berhenti
- Primary kehilangan koneksi jaringan
- Primary di-step down
- Konfigurasi replica set berubah
- Majority node tidak bisa melihat Primary
Bagaimana Proses Election Bekerja?
MongoDB menggunakan algoritma berbasis Raft-like consensus protocol (sejak MongoDB 3.2+ sudah lebih stabil dan deterministik).
Secara sederhana prosesnya:
Step 1 – Detection
Secondary mendeteksi Primary tidak merespons dalam waktu tertentu
(default electionTimeoutMillis = 10000 ms atau 10 detik).
Step 2 – Term Increment
Node kandidat menaikkan nilai term.
Step 3 – Voting Request
Node kandidat meminta vote ke anggota lain.
Step 4 – Majority Vote
Jika mendapat >50% suara (majority), maka node tersebut menjadi Primary baru.
Step 5 – Cluster Stabil
Node lain mengikuti Primary baru.
Konsep Penting dalam Election
1. Majority
Replica set dengan 3 node:
- Minimal 2 node harus aktif agar election bisa terjadi.
Replica set 5 node:
- Minimal 3 node aktif.
Rumus:
majority = (jumlah_node / 2) + 1
2. Priority
Setiap node memiliki parameter priority.
Contoh konfigurasi:
rs.conf()
{
_id: 0,
host: "mongo1:27017",
priority: 2
},
{
_id: 1,
host: "mongo2:27017",
priority: 1
}
Node dengan priority lebih tinggi lebih berpeluang menjadi Primary.
Jika ingin node tidak pernah jadi Primary:
priority: 0
3. Arbiter
Arbiter:
- Tidak menyimpan data
- Hanya ikut voting
- Berguna untuk jumlah node ganjil
Namun di production modern, penggunaan Arbiter mulai jarang direkomendasikan kecuali memang diperlukan.
4. Oplog dan Data Freshness
Node hanya bisa menjadi Primary jika:
- Datanya paling up-to-date
- Tidak tertinggal jauh dari oplog
Jika node terlalu tertinggal, ia tidak akan dipilih.
Simulasi Election
Misal kita punya 3 node:
- mongo1 (Primary)
- mongo2 (Secondary)
- mongo3 (Secondary)
Cek Status Replica Set
rs.status()
Lihat bagian:
"stateStr" : "PRIMARY"
Simulasikan Primary Down
Matikan service di Primary:
systemctl stop mongod
Atau jika dalam container:
docker stop mongo1
Amati Perubahan
Pada Secondary, jalankan:
rs.status()
Dalam beberapa detik, salah satu Secondary akan berubah menjadi:
"stateStr" : "PRIMARY"
Berarti election berhasil.
Monitoring Election
Beberapa indikator penting:
1. Log MongoDB
Cek log:
grep election /var/log/mongodb/mongod.log
Biasanya muncul:
Starting an election
Transition to PRIMARY
2. Cek Nilai Term
rs.status().term
Nilai term akan meningkat setiap kali terjadi election.
3. Periksa Replication Lag
rs.printSecondaryReplicationInfo()
Jika lag tinggi, election bisa gagal atau lambat.
Dampak Election ke Aplikasi
Saat election berlangsung:
- Write akan gagal sementara
- Client akan mendapat error: not master atau primary stepped down
Durasi downtime biasanya:
5–15 detik (default configuration)
Untuk meminimalkan impact:
- Gunakan connection string dengan multiple host
- Aktifkan retryWrites=true
- Gunakan driver terbaru
Contoh connection string:
mongodb://mongo1,mongo2,mongo3/?replicaSet=rs0&retryWrites=true
Best Practice Agar Election Stabil
- Gunakan jumlah node ganjil (3 atau 5)
- Hindari latency tinggi antar node
- Jangan campur node spesifikasi jauh berbeda
- Monitor replication lag
- Pastikan waktu server sinkron (NTP aktif)
