Replikasi PostgreSQL Streaming, Cara Kerja dan Pemasangannya

Bayangkan disk server database tiba-tiba rusak pukul dua siang. Backup semalam memang ada, tapi transaksi pagi sampai siang ikut hilang, dan memulihkan dump besar butuh waktu. Di titik inilah replikasi streaming PostgreSQL berguna: ada server kedua yang isinya hampir sama persis dengan server utama, detik demi detik.

Replikasi streaming adalah fitur bawaan PostgreSQL. Tidak perlu ekstensi atau lisensi tambahan. Server utama (primary) mengirim perubahan ke satu atau beberapa server cadangan (standby), yang bisa melayani query baca dan siap diangkat menjadi primary bila dibutuhkan.

Bagaimana replikasi streaming bekerja?

Setiap perubahan di PostgreSQL ditulis dulu ke Write-Ahead Log (WAL) sebelum masuk ke file data. WAL inilah yang membuat database bisa pulih setelah mati mendadak. Replikasi streaming memanfaatkan mekanisme yang sama.

Di primary, proses walsender mengirim rekaman WAL lewat koneksi khusus. Di standby, proses walreceiver menerimanya dan proses startup memutar ulang perubahan itu ke data lokal. Hasilnya standby menjadi salinan fisik primary: tabel, indeks, user, dan semua database dalam satu cluster ikut tersalin.

Secara bawaan replikasinya asinkron. Primary tidak menunggu standby sebelum menjawab COMMIT, sehingga performa tetap cepat, tapi transaksi yang belum terkirim saat primary hancur bisa hilang. Mode sinkron mengatasi itu dengan risiko lain: kalau standby sinkron tidak bisa dijangkau, COMMIT di primary akan menunggu.

Perlu diingat, replikasi fisik ini menyalin seluruh cluster dan mensyaratkan versi mayor PostgreSQL yang sama di kedua sisi. Kalau kamu hanya ingin menyalin sebagian tabel atau antar versi berbeda, yang dicari adalah logical replication, topik lain lagi.

Menyiapkan server primary

Contoh berikut memakai dua server di jaringan privat: primary 10.0.0.21 dan standby 10.0.0.22, keduanya dengan versi PostgreSQL yang sama dari paket resmi. Langkah instalasinya bisa mengikuti cara pasang PostgreSQL 17 di Ubuntu 24.04.

Buat user khusus replikasi di primary:

CREATE ROLE replikator WITH REPLICATION LOGIN PASSWORD 'ganti-dengan-sandi-panjang';

Pastikan PostgreSQL mendengarkan di IP privat, lewat postgresql.conf:

listen_addresses = 'localhost,10.0.0.21'
wal_level = replica
max_wal_senders = 10

wal_level = replica dan max_wal_senders = 10 sebenarnya sudah menjadi nilai bawaan di versi modern, tapi menuliskannya membuat maksud konfigurasi jelas.

Izinkan standby masuk untuk replikasi lewat pg_hba.conf:

host  replication  replikator  10.0.0.22/32  scram-sha-256

Kata replication di kolom database bukan nama database, melainkan izin khusus untuk koneksi replikasi. Restart PostgreSQL di primary setelah mengubah listen_addresses, dan buka port 5432 di firewall hanya untuk IP standby.

Menyiapkan server standby

Di standby, hentikan PostgreSQL lalu kosongkan folder datanya. Hati-hati, langkah ini menghapus isi database di server standby. Pada Ubuntu dengan PostgreSQL 17, foldernya /var/lib/postgresql/17/main.

sudo systemctl stop postgresql
sudo -u postgres bash -c 'rm -rf /var/lib/postgresql/17/main/*'
sudo -u postgres pg_basebackup -h 10.0.0.21 -U replikator \
  -D /var/lib/postgresql/17/main -R -X stream -C -S standby1 -P
sudo systemctl start postgresql

Arti opsinya:

• -R menulis primary_conninfo ke postgresql.auto.conf dan membuat file standby.signal, sehingga server langsung berjalan sebagai standby.
• -X stream ikut mengalirkan WAL selama proses salin agar hasilnya konsisten.
• -C -S standby1 membuat replication slot bernama standby1 di primary. Slot mencegah primary membuang WAL yang belum diterima standby.
• -P menampilkan progres.

Sejak PostgreSQL 12, file recovery.conf tidak dipakai lagi. Banyak tutorial lama masih menyebutnya, jadi abaikan bagian itu dan gunakan standby.signal yang dibuat otomatis oleh -R.

Satu peringatan soal slot: kalau standby mati lama, slot membuat WAL menumpuk di primary sampai disk penuh. Pantau ukurannya, atau batasi dengan max_slot_wal_keep_size.

Memantau lag dan memastikan semuanya sehat

Di primary, view pg_stat_replication menunjukkan setiap standby yang tersambung:

SELECT client_addr, state, sync_state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_byte,
       replay_lag
FROM pg_stat_replication;

state yang sehat bernilai streaming. Di standby, SELECT pg_is_in_recovery(); harus mengembalikan true, dan view pg_stat_wal_receiver menunjukkan status koneksi ke primary.

Cara paling jujur untuk menguji tetap praktik langsung: buat tabel kecil di primary, isi beberapa baris, lalu baca dari standby. Mencoba menulis di standby akan ditolak dengan error read-only, dan itu tanda konfigurasinya benar.

Masukkan query lag ini ke sistem pemantauan. Lag yang terus naik biasanya berarti jaringan terlalu sempit, disk standby lambat, atau ada query panjang di standby yang menahan pemutaran ulang WAL.

Saat primary benar-benar rusak

Promosi standby menjadi primary cukup satu perintah di standby:

SELECT pg_promote();

Setelah itu standby menerima tulisan. Arahkan aplikasi ke alamat baru, atau gunakan IP virtual agar aplikasi tidak perlu diubah. Primary lama tidak boleh dinyalakan lagi sebagai primary, karena dua server yang sama-sama menerima tulisan akan membuat data bercabang. Jadikan ia standby baru, bisa dengan pg_rewind (syaratnya wal_log_hints atau data checksums aktif) atau salin ulang dengan pg_basebackup.

PostgreSQL sendiri tidak melakukan failover otomatis. Untuk itu orang memakai alat tambahan seperti Patroni atau repmgr, yang mengawasi kesehatan primary dan memutuskan kapan promosi dilakukan.

Satu hal lagi yang sering disalahpahami: replika bukan backup. Perintah DROP TABLE yang salah ketik akan ikut tereplikasi dalam hitungan detik. Tetap jalankan backup database otomatis dengan retensi, idealnya ditambah arsip WAL untuk pemulihan ke titik waktu tertentu.

Kesimpulannya, replikasi streaming adalah cara paling sederhana untuk punya salinan PostgreSQL yang selalu segar, cukup dengan user replikasi, satu baris pg_hba, dan pg_basebackup -R. Pilih mode asinkron untuk kebanyakan kebutuhan, pantau lag dan slot, dan siapkan prosedur promosi sebelum benar-benar dibutuhkan.