Replication #

Dalam sistem backend modern, database sering menjadi single point of failure sekaligus bottleneck performa. Ketika trafik meningkat, query read semakin berat, atau availability menjadi requirement utama, satu database server saja biasanya tidak cukup. Di sinilah database replication berperan.

Artikel ini membahas secara mendalam:

Apa itu database replication
Kenapa replication sangat penting
Jenis-jenis database replication
Masalah umum pada replication
Best practice dalam mengimplementasikan database replication

Apa Itu Database Replication #

Database replication adalah proses menyalin dan menyinkronkan data dari satu database (biasanya disebut primary / master) ke satu atau lebih database lain (disebut replica / standby / slave).

Tujuan utamanya:

Menyediakan high availability
Meningkatkan read scalability
Mengurangi beban database utama
Menyediakan backup dan disaster recovery

Secara umum, alur sederhananya:

Client -> Write -> Primary DB
                |
                v
            Replica DB(s) -> Read

Kenapa Database Replication Itu Penting #

High Availability (HA) #

Jika primary database down (hardware failure, OOM, disk full, dll), replica bisa dipromosikan menjadi primary.

Tanpa replication:

Downtime = aplikasi mati

Dengan replication:

Failover lebih cepat
Downtime jauh lebih kecil

Read Scalability #

Sebagian besar aplikasi:

Read-heavy (dashboard, list data, report, admin)
Write relatif lebih sedikit

Dengan replication:

Write → primary
Read → replica

Hasilnya:

Beban primary berkurang drastis
Query read berat tidak mengganggu write

Isolasi Beban Query Berat #

Query seperti:

Reporting
Export data
Analytic query
Full table scan

Sangat berbahaya jika dijalankan di primary.

Dengan replication:

Query berat diarahkan ke replica
Primary tetap responsif

Disaster Recovery #

Replica bisa:

Berada di availability zone berbeda
Bahkan region berbeda

Jika terjadi:

Data center failure
Human error di primary

Replica menjadi penyelamat terakhir.

Jenis-Jenis Database Replication #

Synchronous Replication #

Karakteristik:

Write dianggap sukses jika primary dan replica sudah menerima data

Kelebihan:

Data konsisten (strong consistency)
Hampir tidak ada replication lag

Kekurangan:

Latency write meningkat
Jika replica lambat → primary ikut lambat

Cocok untuk:

Sistem finansial
Data yang sangat kritikal

Asynchronous Replication #

Karakteristik:

Primary langsung menganggap write sukses
Replica menerima data belakangan

Kelebihan:

Write sangat cepat
Primary tidak tergantung replica

Kekurangan:

Ada replication lag
Risiko data belum tersalin saat primary crash

Cocok untuk:

Sebagian besar aplikasi web
Sistem dengan read-heavy traffic

Semi-Synchronous Replication #

Karakteristik:

Primary menunggu minimal satu replica menerima data

Trade-off:

Lebih aman dari async
Lebih cepat dari sync penuh

Masalah Umum pada Database Replication #

Replication Lag #

Replica tertinggal dari primary.

Penyebab umum:

Query write terlalu berat
Index belum optimal
Replica hardware lebih lemah

Dampak:

User melihat data lama
Inconsistent user experience

Read After Write Problem #

User melakukan:

Update data
Langsung read

Jika read diarahkan ke replica:

Data belum tersinkron
User melihat data lama

Query Tidak Aman di Replica #

Beberapa query berbahaya:

SELECT ... FOR UPDATE
Transaction panjang
Locking query

Replica bukan tempat locking.

Skema dan Migrasi #

Perubahan schema:

DDL berat
Index creation

Bisa:

Mengganggu replication
Membuat lag ekstrem

Best Practice Database Replication #

Pisahkan Koneksi Write dan Read #

Gunakan:

Write connection → primary
Read connection → replica

Biasanya lewat:

Database proxy
Application-level routing

Jangan Gunakan Replica untuk Data Kritis Real-Time #

Untuk kasus:

Login
Update saldo
State machine

Gunakan primary.

Replica cocok untuk:

List
History
Report

Tangani Read After Write dengan Benar #

Beberapa pendekatan:

Sticky session (read ke primary beberapa detik)
Explicit read from primary
Cache write result

Monitor Replication Lag #

Wajib monitor:

Seconds behind primary
Replication IO / SQL thread

Jika lag tinggi:

Kurangi query berat
Optimasi index
Scale replica

Hindari Query Berat di Primary #

Pastikan:

Reporting
Export
Cron analytic

Dijalankan di replica.

Gunakan Replica Khusus untuk Beban Tertentu #

Contoh:

Replica A → API read
Replica B → reporting
Replica C → backup

Isolasi beban = stabilitas.

Migrasi Schema dengan Hati-Hati #

Best practice:

Online schema migration
Add index secara bertahap
Hindari DDL di jam sibuk

Jangan Asumsikan Replica Selalu Konsisten #

Desain aplikasi dengan asumsi:

Replica bisa delay
Replica bisa sementara unavailable

Failover logic harus jelas.

Kesimpulan #

Database replication bukan sekadar duplikasi data, tapi fondasi penting untuk:

Skalabilitas
Availability
Stabilitas sistem

Namun replication juga membawa kompleksitas:

Data consistency
Routing read/write
Lag dan failover

Dengan desain yang tepat dan best practice yang disiplin, database replication bisa menjadi penyelamat sistem, bukan sumber masalah baru.

“Replication tidak membuat database lebih sederhana, tapi membuat sistem lebih tahan banting.”