Belajar Database Administrator - High Availability & Replication

#Pendahuluan

Di episode 7 kita bisa melihat database — sekarang kita membuatnya tidak pernah berhenti. High availability (HA) adalah kemampuan layanan tetap berjalan saat satu node mati. Ingat prinsip di episode 5: pg_basebackup tidak hanya untuk backup — ia juga bahan baku pembuatan replica. Kali ini kedua konsep itu bertemu.

Gambaran yang benar: HA bukan "menghilangkan kegagalan" (mustahil), melainkan memperpendek waktu pemulihan hingga pengguna tidak merasakan apa-apa. Alat ukurnya nanti: RTO (waktu pulih) dan RPO (data yang hilang) — dua angka yang kita bahas serius di episode 15.

#Streaming Replication: Konsep

Pada mode streaming replication, primary mengalirkan WAL-nya secara live ke satu atau lebih replica (standby):

Replica terus-menerus menerapkan WAL dari primary, sehingga datanya hampir selalu sinkron (tertinggal paling banyak beberapa detik — tergantung synchronous_commit). Karakteristik penting:

• Replica dibuka read-only: aplikasi hanya bisa SELECT di sana (bagus untuk beban baca).
• Failover = mempromosikan replica menjadi primary baru saat primary mati.
• Replikasi asynchronous (default): replica bisa tertinggal; tidak kehilangan performa primary.
• Replikasi synchronous: menjamin tidak ada data hilang (RPO = 0) dengan biaya latency tiap commit — cocok untuk transaksi kritis.

#Setup Replica dengan pg_basebackup

Di lab (host kedua, atau dua instance), persiapkan primary lalu buat replica:

1. Pastikan user replikasi ada di primary:

CREATE ROLE repl_user LOGIN REPLICATION PASSWORD 'ReplRahasia';

2. Atur primary untuk menerima replikasi di pg_hba.conf:

host replication repl_user 10.0.0.0/8 scram-sha-256

3. Di server replica, klon data dari primary:

sudo -u postgres pg_basebackup -h primary-host -U repl_user \
    -D /var/lib/postgresql/16/main -R -P
sudo systemctl start postgresql

Flag -R otomatis menulis file konfigurasi standby.signal + koneksi ke primary. Verifikasi:

psql -c "SELECT * FROM pg_stat_replication;"
psql -c "SELECT pg_is_in_recovery();"  # true = ini replica

Jika pg_is_in_recovery() mengembalikan true, replica aktif. Uji nyata: buat tabel di primary, lihat tabel itu muncul di replica beberapa detik kemudian.

#Failover: Manual dan Otomatis

Failover manual (paling dasar — wajib dikuasai dulu): saat primary mati, promosikan replica:

# di server replica
sudo -u postgres /usr/lib/postgresql/16/bin/pg_ctl promote -D /var/lib/postgresql/16/main
# atau sederhananya: hapus standby.signal lalu restart
sudo -u postgres rm /var/lib/postgresql/16/main/standby.signal
sudo systemctl restart postgresql

Replica yang dipromosikan mulai menerima write. Aplikasi harus diarahkan ke alamat barunya — itulah mengapa DBA selalu menaruh primary di balik virtuIP / DNS, bukan alamat IP mentah, supaya failover cukup menggeser alamat.

Failover otomatis dengan repmgr (atau Patroni untuk skala besar). repmgr menambah deteksi & promosi otomatis:

sudo repmgr -f /etc/repmgr.conf primary register
sudo repmgr -f /etc/repmgr.conf standby clone -h primary-host
sudo systemctl enable repmgr
# pada failover, salah satu standby dipromosikan otomatis
sudo repmgr -f /etc/repmgr.conf standby promote -f

Patroni menambahkan distributed consensus (etcd/consul) sehingga keputusan siapa yang jadi primary tidak ragu. Untuk series ini repmgr sudah cukup; Patroni masuk di episode 22 sebagai bagian dari arsitektur yang lebih besar.

#Load Balancing Baca

Setelah ada replica, bagi beban baca. pgbouncer yang kita pasang di episode 3 bisa memetakan koneksi ke beberapa host:

[databases]
appdb = host=10.0.0.11,10.0.0.12 port=5432 dbname=appdb
 
[pgbouncer]
listen_port = 6432
pool_mode = transaction

Mekanisme yang lebih halus: read/write splitting di lapisan aplikasi/ORM — tulis ke primary, baca ke replica. Pilihan lain: HAProxy di depan primary + replicas dengan health check pg_isready. Untuk rute paling sederhana: gunakan dua alamat terpisah (primary untuk write, replica untuk report) — mudah, jelas, dan cukup untuk kebanyakan kasus.

#Pitfall Umum

1. Replica tertinggal tanpa disadari: replikasi async bisa lag puluhan detik di bawah beban. Pantau pg_stat_replication (replay_lag) — masukkan ke dashboard episode 7.
2. wal_keep_size / slot terlalu kecil: replika yang tertinggal jauh bisa "putus" dan harus di-clone ulang. Pertimbangkan replication slot (max_replication_slots) untuk menjamin WAL tidak dibuang.
3. Failover tanpa menguji aplikasi: aplikasi yang memegang koneksi lama tidak otomatis pindah. Uji skenario nyata termasuk koneksi aktif saat primary mati.
4. Semua beban ke primary: HA yang tidak dipakai membagi beban = membayar dua server untuk satu. Arahkan reporting/read ke replica.
5. Satu mesin, dua instance: replication antar instance di VM yang sama tidak memberi HA apa pun — satu mati listrik membunuh keduanya.

#Penutup

Inti yang harus dibawa pulang:

• Streaming replication mengalirkan WAL dari primary ke replica; pg_basebackup -R adalah jalur setuanya.
• Failover manual dulu (pg_ctl promote), lalu otomatis (repmgr/Patroni); selalu di balik alamat/DNS yang bisa digeser.
• Load balancing baca: pgbouncer multi-host, HAProxy, atau splitting di aplikasi.
• HA adalah janji yang harus diuji: matikan primary secara berkala dan ukur RTO/RPO.

Di episode 9 selanjutnya kita mengamankan database: security & access control — least privilege dan manajemen roles/grants, autentikasi scram-SHA-256, TLS untuk lalu lintas data, enkripsi data-at-rest, serta audit trail. Kalian sudah bisa membuat database hidup; sekarang buat ia tidak mudah dijebol. Sampai jumpa di episode 9!