Backup menyelamatkan data saat bencana, tetapi pemulihan dari backup memakan waktu — dan selama pemulihan berlangsung, toko online kita tutup. Masalah kedua muncul di sisi beban: query ETL yang memindai jutaan baris pesanan akan membuat checkout pelanggan ikut lambat bila keduanya berbagi satu database. Replikasi database menjawab keduanya dengan menjaga salinan database hampir-waktu-nyata di server lain: primary menerima semua tulisan, replica menyalin perubahan tersebut, dan beban baca dibagi ke banyak mesin. Bab ini membahas arsitekturnya, mode sinkron vs asinkron, streaming replication PostgreSQL, dan replication lag yang wajib dipantau.
Arsitektur Master-Replica #
Bentuk replikasi paling umum membagi peran secara tegas. Satu server bertindak sebagai master (PostgreSQL menyebutnya primary): seluruh INSERT, UPDATE, dan DELETE hanya ditujukan ke server tersebut. Server lain menjadi replica: menerima aliran perubahan dari master, menerapkannya di salinannya sendiri, lalu melayani query baca.
Pemisahan jalur tulis dan jalur baca memberi dua manfaat: performa (query laporan berat dan transaksi checkout tidak lagi berebut mesin yang sama) dan ketahanan (bila primary rusak, salah satu replica dapat dipromosikan menjadi primary baru dalam hitungan menit — jauh lebih cepat daripada restore dari backup).
Sinkron vs Asinkron #
Pertanyaan krusialnya: kapan master boleh menjawab “transaksi sudah aman”? Dua mode memberi jawaban berlawanan.
| Aspek | Replikasi sinkron | Replikasi asinkron |
|---|---|---|
| Konfirmasi commit | setelah replica menuliskan perubahan | segera setelah master menulis lokal |
| Risiko kehilangan data saat failover | nyaris nol | ada — perubahan yang belum terkirim hilang bersama master |
| Latensi tulis | lebih tinggi (menunggu perjalanan pulang ke replica) | setinggi tulisan lokal |
| Ketahanan saat replica mati | tulisan tertahan atau gagal | tulisan tetap lancar, replica mengejar belakangan |
Mode sinkron cocok untuk data yang tidak boleh hilang sedikit pun — pembayaran dan ledger. Mode asinkron unggul untuk skala baca besar dengan toleransi kecil terhadap jeda data, misalnya katalog produk dan laporan. PostgreSQL bahkan mengizinkan kombinasi: satu replica sinkron untuk jaminan, sisanya asinkron untuk skala.
Streaming Replication di PostgreSQL #
PostgreSQL mengirim perubahan melalui WAL (write-ahead log) — catatan aktivitas yang memang sudah ditulis master sebelum menerapkan perubahan ke berkas datanya. Streaming replication memanfaatkan catatan tersebut: replica membuka koneksi ke primary, menerima potongan WAL secara berkelanjutan, dan memutarnya pada salinannya sendiri. Konfigurasi intinya ringkas (tidak dieksekusi di lingkungan bab ini karena tidak ada server PostgreSQL berjalan):
# postgresql.conf di server primary
wal_level = replica # aktifkan pencatatan WAL untuk replikasi
max_wal_senders = 10 # jumlah maksimum koneksi replica# pg_hba.conf di server primary: izinkan replica menarik WAL
host replication pengguna_replikasi 10.0.0.0/8 scram-sha-256# di server replica: clone pertama dari primary;
# -R menuliskan konfigurasi agar replica langsung ikut streaming WAL
pg_basebackup -h db-primary.example.com -U pengguna_replikasi \
-D /var/lib/postgresql/data -R -X streamSetelah replica berjalan, kesehatannya dipantau dari primary lewat view pg_stat_replication:
-- berjalan di server primary; hasilnya dijelaskan, tidak dieksekusi di sini
SELECT application_name, state, sync_state, write_lag
FROM pg_stat_replication;Satu baris hasil mewakili satu replica yang terhubung: state bernilai streaming berarti replikasi sehat, sync_state membedakan replica sinkron dari asinkron, dan write_lag mengukur seberapa jauh replica tertinggal. Panduan lengkapnya ada di Warm Standby / Streaming Replication
dan High Availability PostgreSQL
.
Read Replica untuk Beban Analytics #
Bagi data engineer, read replica adalah pemisah lalu lintas paling praktis. Pola “satu replica per kelompok beban” menjadikan dampak query rakus mudah diprediksi:
- Pipeline ETL yang mengekstrak jutaan baris pesanan setiap malam diarahkan penuh ke satu replica khusus — table scan besar tidak pernah menyentuh primary.
- Dashboard dan query ad-hoc analis mendapat replica kedua.
- BI tools yang suka menjalankan query tak terdapat diisolasi di replica ketiga.
Replication Lag: Jarak antar Server #
Replica asinkron selalu tertinggal sedikit — selisih waktu antara perubahan di primary dan perubahan yang sama diterapkan di replica disebut replication lag. Lag sehat berukuran milidetik hingga beberapa detik, tetapi beberapa keadaan membuatnya membengkak:
| Penyebab lag membengkak | Penanganan |
|---|---|
satu transaksi raksasa (mis. UPDATE puluhan juta baris) | pecah pekerjaan besar menjadi batch kecil |
| jaringan lambat antar pusat data | pindahkan replica lebih dekat ke primary |
| replica kekurangan sumber daya untuk menerapkan WAL | naikkan spesifikasi replica, cek query berat di replica |
Lag besar berdampak nyata pada kebenaran baca: laporan penjualan dari replica yang tertinggal 20 menit kehilangan pesanan 20 menit terakhir — tidak masalah untuk tren mingguan, tetapi menyesatkan untuk operasi jam-an. Praktik yang sehat: pantau write_lag sebagai metrik berkelanjutan, pasang ambang peringatan, dan rutekan hanya query yang toleran terhadap jeda ke replica yang sedang tertinggal.
Dengan replikasi, satu database relasional dapat melayani baca dan tulis dalam skala besar. Namun seiring pertumbuhan kebutuhan — analitik kolom raksasa, cache mikrodetik, pencarian teks lengkap, deret waktu sensor — pertanyaannya bergeser menjadi “sistem penyimpanan mana yang tepat untuk tiap jenis beban”. Chapter penutup section ini, Pemilihan Sistem Penyimpanan, memetakan keputusan tersebut.