Database Replication dan Failover: Memastikan High Availability

Database Replication dan Failover: Memastikan High Availability

6/2/2026 • Database • By Tech Writers
DatabaseHigh AvailabilityReplikasiFailoverArsitektur Sistem

Daftar Isi

Pendahuluan

Dalam aplikasi web modern, database biasanya menjadi komponen yang paling kritis. Jika server web mati, load balancer bisa dengan mudah mengarahkan traffic ke instance lainnya. Namun, bagaimana jika database kamu yang mati? Seluruh layanan aplikasi bisa langsung lumpuh total. Menjaga database agar tetap dapat diakses meskipun terjadi kerusakan hardware, gangguan jaringan, atau lonjakan traffic yang tinggi disebut sebagai High Availability (HA).

Untuk membangun arsitektur database yang andal dan selalu aktif, kamu perlu memahami dua konsep utama: replikasi (menyalin data ke beberapa instance database) dan failover (otomatis mempromosikan instance cadangan menjadi primary saat instance utama mengalami kegagalan).

Artikel ini akan membahas secara mendalam bagaimana replikasi database dan failover bekerja, trade-off dari berbagai pendekatan, serta bagaimana kamu dapat menerapkannya agar sistem kamu tetap online.

Apa Itu High Availability dalam Database?

Sederhananya, High Availability (HA) adalah kemampuan sistem untuk terus berjalan dan meminimalkan downtime (waktu mati). Dalam konteks database, HA berarti aplikasi kamu dapat terus melakukan operasi read dan write tanpa hambatan downtime yang signifikan.

High availability sering kali diukur menggunakan persentase ketersediaan (nines):

  • 99.9% (“Three Nines”): ~8.76 jam downtime per tahun.
  • 99.99% (“Four Nines”): ~52.56 menit downtime per tahun.
  • 99.999% (“Five Nines”): ~5.26 menit downtime per tahun.

Untuk mencapai tingkat ketersediaan yang tinggi, kamu memerlukan redundansi node database, deteksi kegagalan yang cepat, dan mekanisme failover otomatis.

Topologi Replikasi Database

Replikasi adalah proses menyalin data untuk memastikan konsistensi di antara beberapa node database. Berikut adalah beberapa topologi replikasi yang paling umum digunakan di lingkungan produksi:

1. Primary-Replica (Leader-Follower)

Ini adalah topologi yang paling populer. Satu node ditunjuk sebagai Primary (Leader) untuk menangani semua operasi tulis (write). Data tersebut kemudian disalin ke satu atau lebih node Replica (Follower). Operasi baca (read) dapat disebarkan ke node replika untuk membagi beban kerja database.

  • Kelebihan: Mudah diatur, mudah melakukan scale out untuk operasi read, dan kepemilikan data yang jelas.
  • Kekurangan: Throughput write terbatas pada kemampuan satu node primary saja. Jika primary mati, operasi write akan terhenti hingga ada replica yang dipromosikan menjadi primary baru.

2. Multi-Primary (Leader-Leader)

Dalam topologi ini, beberapa node berfungsi sebagai primary dan semuanya dapat menerima operasi write. Operasi write ini kemudian disinkronisasikan ke node primary lainnya.

  • Kelebihan: Ketersediaan operasi write yang tinggi, serta mengurangi latency bagi pengguna yang tersebar secara geografis karena dapat mengakses server terdekat.
  • Kekurangan: Kompleksitasnya sangat tinggi. Kamu harus menangani konflik write (misalnya ketika dua node memperbarui baris data yang sama di waktu yang bersamaan).

3. Peer-to-Peer (Desentralisasi)

Biasa digunakan pada database terdistribusi seperti Cassandra, di mana setiap node memiliki kedudukan yang setara. Operasi read dan write didistribusikan ke seluruh node berdasarkan partition key dan konfigurasi quorum.

  • Kelebihan: Sangat andal, dapat scale out secara linier, dan tidak ada single point of failure (jika satu node mati, sistem tidak langsung lumpuh).
  • Kekurangan: Konsistensi data yang kuat (strong consistency) sulit dicapai secara instan; sistem biasanya menggunakan pendekatan eventual consistency.

Replikasi Sinkron vs. Asinkron

Ketika operasi write terjadi di database primary, bagaimana perubahan tersebut disalin ke replica? Pilihan di bawah ini akan menentukan karakteristik performa dan konsistensi sistem kamu.

Replikasi Sinkron (Synchronous)

Node primary menulis transaksi secara lokal, mengirimkannya ke replica, dan menunggu konfirmasi dari replica bahwa data telah ditulis sebelum memberikan respons “sukses” kepada klien.

  • Kelebihan: Jaminan data tidak hilang. Jika primary mati, replica memiliki salinan data yang 100% sama persis.
  • Kekurangan: Latency write menjadi lebih tinggi karena prosesnya bergantung pada kecepatan jaringan antar node. Jika salah satu replica lambat atau offline, proses write pada primary bisa ikut tertunda.

Replikasi Asinkron (Asynchronous)

Node primary menulis transaksi secara lokal, langsung memberikan respons “sukses” kepada klien tanpa menunggu, lalu mengirimkan pembaruan data ke replica di latar belakang (background).

  • Kelebihan: Proses write berjalan sangat cepat. Node primary tidak terhambat oleh status replica maupun latency jaringan.
  • Kekurangan: Ada risiko kehilangan data (failover data loss). Jika primary mendadak mati sebelum replikasi background selesai, data baru yang sudah dilaporkan sukses ke klien tetapi belum sampai di replica akan hilang.

Bagaimana Proses Failover Bekerja

Failover adalah proses pemindahan operasional database dari node primary yang rusak ke node replica yang sehat—bisa secara otomatis (auto-failover) maupun manual.

graph TD
    A[Traffic Client] --> B(Load Balancer / Proxy)
    B -->|Read/Write| C[Node DB Primary]
    B -->|Read Only| D[Node DB Replica]
    C -->|Link Replika| D
    E[Health Check / Sentinel] -->|Ping Status| C
    E -->|Ping Status| D
    C -.->|CRASH/MATI| F[Offline]
    E -->|Deteksi Gagal| G[Mulai Failover]
    G -->|Promosikan Replika| D
    G -->|Update Rute| B
    B -->|Read/Write| D

Alur Failover Otomatis (Auto-Failover):

  1. Health Monitoring: Program pemantau (sering disebut sentinel atau coordinator) secara berkala melakukan ping ke database primary untuk memeriksa kondisinya.
  2. Failure Detection: Jika primary gagal merespons setelah melewati batas waktu (timeout) tertentu, pemantau akan menandai status primary sebagai tidak aktif/down.
  3. Leader Election: Sistem memilih replica yang paling sehat dan memiliki data paling mutakhir untuk dipromosikan.
  4. Promotion: Replica terpilih dinaikkan statusnya menjadi primary baru agar dapat menerima operasi write kembali.
  5. Reconfiguration: Database proxy, load balancer, dan klien aplikasi diberi tahu mengenai alamat IP primary yang baru agar traffic tidak salah arah.

Jebakan Failover: Split-Brain dan Replication Lag

Meskipun failover otomatis sangat membantu, ada beberapa risiko besar yang harus diwaspadai jika konfigurasi sistem kurang tepat.

1. Skenario Split-Brain

Kondisi ini terjadi ketika gangguan jaringan (network partition) memisahkan node-node database, membuat replica menduga primary telah mati padahal primary sebenarnya masih aktif berjalan. Akibatnya, replica mempromosikan dirinya sendiri menjadi primary. Akhirnya, sistem memiliki dua node primary aktif yang sama-sama menerima operasi write. Ketika jaringan pulih, database akan mengalami konflik data yang sangat rumit untuk digabungkan kembali tanpa kehilangan data.

  • Pencegahan: Gunakan mekanisme konsensus quorum (seperti Raft atau Paxos). Pemilihan primary baru membutuhkan persetujuan mayoritas node (misalnya minimal 2 dari 3 node), sehingga partisi jaringan yang terisolasi tidak bisa asal membuat primary baru.

2. Replication Lag

Replication lag adalah keterlambatan waktu antara penulisan data di node primary dengan pengaplikasian data tersebut di replica. Jika lag sangat tinggi pada replica asinkron saat failover dipicu, data yang belum sempat tersinkronisasi akan hilang, atau terjadi ketidakkonsistenan baca.

  • Pencegahan: Pantau metrik replication lag secara real-time. Pasang alert jika delay melewati batas toleransi, dan hindari mempromosikan replica yang tertinggal terlalu jauh.

Best Practice untuk Database High Availability

Agar proses failover berjalan dengan mulus dan database tetap andal, coba terapkan beberapa best practice berikut:

  • Gunakan Jumlah Node Ganjil: Siapkan minimal 3 node (1 Primary, 2 Replica) agar quorum voting sah dan sistem aman dari masalah split-brain.
  • Berhati-hatilah dengan Otomatisasi: Auto-failover sangat membantu, tetapi pastikan parameter deteksinya tepat agar tidak terjadi flapping (kondisi bolak-balik failover akibat gangguan jaringan sesaat).
  • Gunakan Database Proxy: Terapkan layer proxy database seperti PgBouncer (untuk PostgreSQL) atau ProxySQL (untuk MySQL) untuk mengelola koneksi klien. Saat failover terjadi, traffic akan langsung dialihkan di belakang layar tanpa perlu me-restart aplikasi kamu.
  • Simulasi Failover Secara Rutin (Chaos Engineering): Jangan menunggu sistem mati sungguhan untuk menguji script failover kamu. Lakukan simulasi mematikan node primary di lingkungan staging secara berkala agar tim kamu terbiasa.
  • Siapkan Backup Lintas Region (Multi-Region): Untuk database yang sangat kritis, pastikan file backup disimpan di region cloud yang berbeda agar tetap aman jika terjadi bencana di satu wilayah.

FAQ

Apa perbedaan antara replikasi dan backup?

Replikasi adalah proses menyalin database secara real-time ke node cadangan demi keandalan tinggi dan pembagian beban read. Sedangkan backup adalah snapshot statis database pada waktu tertentu untuk pemulihan bencana (misalnya, jika data tidak sengaja terhapus atau terkena ransomware). Kamu membutuhkan keduanya.

Apakah replikasi membuat operasi write menjadi lebih cepat?

Tidak. Replikasi sinkron justru membuat proses write menjadi lebih lambat karena harus menunggu konfirmasi dari replica. Replikasi asinkron mempertahankan performa write tetap normal tetapi tidak membuatnya lebih cepat. Jika ingin menulis data lebih cepat, kamu perlu menerapkan sharding atau menggunakan arsitektur multi-primary.

Bisakah failover database berjalan tanpa disadari oleh pengguna?

Bisa. Asalkan kamu menggunakan database proxy yang tepat dan penanganan connection retry yang baik pada kode aplikasi. Proses failover biasanya hanya memakan waktu beberapa detik dan hanya akan terasa seperti lonjakan latency singkat bagi pengguna.

Bagaimana cara tim kamu menangani failover database? Apakah kamu masih menggunakan promosi manual, menggunakan proxy database, atau langsung menggunakan layanan managed cloud seperti Amazon RDS? Bagikan pengalaman kamu di kolom komentar!