--- title: "Replikasi PostgreSQL Streaming, Cara Kerja dan Pemasangannya" description: "Cara kerja streaming replication PostgreSQL lewat WAL, langkah memasang primary dan standby dengan pg_basebackup, memantau lag, dan kapan promote." url: "https://nivelva.com/insight/replikasi-postgresql-streaming-cara-kerja-pemasangan" category: "Server \u0026 Infrastruktur" tags: ["postgresql","replikasi","database","high availability","wal"] author: "Lucas Tan" published: "2026-11-11T13:30:00+07:00" updated: "2026-11-11T13:30:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Replikasi PostgreSQL Streaming, Cara Kerja dan Pemasangannya > **Jawaban singkat:** Streaming replication mengirim catatan WAL dari server primary ke standby secara terus-menerus, sehingga standby menjadi salinan yang hampir real time dan bisa dipakai untuk baca atau dipromosikan saat primary rusak. Pemasangannya cukup dengan user replikasi, aturan pg_hba, dan pg_basebackup -R. 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. | Aspek | Asinkron (bawaan) | Sinkron | |:--|:--|:--| | Kecepatan COMMIT di primary | Tidak terpengaruh standby | Menunggu konfirmasi standby | | Risiko kehilangan data saat primary rusak | Ada, sebesar lag saat itu | Sangat kecil untuk standby sinkron | | Bila standby mati | Primary tetap jalan | Transaksi tertahan, kecuali ada standby sinkron lain | | Pengaturan | Tidak perlu tambahan | `synchronous_standby_names` di primary | | Cocok untuk | Read replica, cadangan umum | Data transaksi yang tidak boleh hilang | 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](https://nivelva.com/insight/cara-pasang-postgresql-17-ubuntu-24-04). Buat user khusus replikasi di primary: ```sql CREATE ROLE replikator WITH REPLICATION LOGIN PASSWORD 'ganti-dengan-sandi-panjang'; ``` Pastikan PostgreSQL mendengarkan di IP privat, lewat `postgresql.conf`: ```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`: ```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`. ```bash 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: ```sql 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: ```sql 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](https://nivelva.com/insight/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. ## Sumber - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/replikasi-postgresql-streaming-cara-kerja-pemasangan Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com