Physical vs Logical Replication

Chapter sebelumnya membangun replikasi dengan satu resep: salin seluruh cluster lewat pg_basebackup, lalu streaming-kan WAL apa adanya. Resep itu — physical replication — adalah pilihan tepat untuk menjaga salinan identik, tetapi bukan satu-satunya model yang dimiliki PostgreSQL. Ada model kedua yang membongkar WAL menjadi perubahan level baris lalu mengirimkannya hanya untuk tabel-tabel yang Anda pilih — logical replication. Memilih model yang salah bukan cuma soal efisiensi: physical tidak bisa dipakai untuk naik versi major, sedangkan logical tidak cocok menjadi standby failover. Chapter ini menaruh kedua model berdampingan agar keputusan Anda berikutnya berbasis kriteria, bukan kebiasaan.

Dua Model, Satu Sumber #

Kedua model berangkat dari bahan yang sama: WAL. Bedanya ada di apa yang dikirim ke server kedua. Physical replication mengirim record WAL apa adanya — urutan byte yang menggambarkan perubahan pada block file data (“block 42 tabel ini berubah jadi begini”). Standby me-replay record itu dengan kode yang sama persis seperti primary, sehingga hasilnya identik byte demi byte. Logical replication memakai logical decoding: primary menerjemahkan WAL menjadi deskripsi perubahan logis (“baris id 7 tabel produk di-UPDATE menjadi nilai-nilai ini”), lalu mengirim deskripsi itu melalui protokol publikasi-langganan ke server lain yang mengeksekusinya sebagai INSERT/UPDATE/DELETE biasa.

Konsekuensi perbedaan itu menjalar ke mana-mana, dan tabel berikut merangkum sembilan dimensi yang paling sering menentukan keputusan:

Baris keempat dan kelima sering menjadi penentu mutlak: WAL mentah hanya bisa di-replay oleh server yang memahami format block yang identik — PostgreSQL 17 tidak bisa me-replay WAL PostgreSQL 16, dan build big-endian tidak bisa me-replay WAL little-endian. Deskripsi perubahan logis tidak punya batasan itu, sehingga logical replication menjadi jembatan antar versi dan antar platform.

wal_level Menentukan Model yang Tersedia #

Model mana yang bisa Anda jalankan ditentukan satu parameter: wal_level. Level replica (bawaan) sudah cukup untuk streaming replication fisik, sedangkan logical menuliskan info tambahan yang dibutuhkan decoder — misalnya identity tuple untuk UPDATE dan DELETE. Mari kita baca keadaan server ini beserta parameter fondasi lainnya:

-- Level WAL menentukan model replikasi yang tersedia.
-- "replica" (bawaan): cukup untuk streaming replication fisik.
-- "logical": syarat tambahan untuk logical replication.
SHOW wal_level;

-- Parameter fondasi untuk kedua model, beserta konteksnya:
-- "postmaster" artinya perubahan hanya berlaku setelah restart server.
SELECT name, setting, context
FROM pg_settings
WHERE name IN ('wal_level',
               'max_wal_senders',
               'max_replication_slots',
               'max_logical_replication_workers',
               'max_worker_processes')
ORDER BY name;

Output yang Dihasilkan:

 wal_level 
-----------
 replica
(1 row)

              name               | setting |  context   
---------------------------------+---------+------------
 max_logical_replication_workers | 4       | postmaster
 max_replication_slots           | 10      | postmaster
 max_wal_senders                 | 10      | postmaster
 max_worker_processes            | 8       | postmaster
 wal_level                       | replica | postmaster
(5 rows)

Server course ini berada di wal_level = replica, sehingga siap untuk physical replication hari ini, tetapi belum untuk logical. Kolom context memberi tahu hal penting yang sering mengejutkan: kelima parameter ini berstatus postmaster, artinya mengubahnya lewat ALTER SYSTEM baru berlaku setelah server di-restart — berbeda dari banyak parameter lain yang cukup pg_reload_conf(). Karena itu rencanakan pengaktifan wal_level = logical pada jendela restart terjadwal, bukan di tengah jam sibuk. max_replication_slots dan max_logical_replication_workers pada nilai bawaan (10 dan 4) sudah memadai untuk mulai bereksperimen di chapter Logical Replication .

Kapan Memilih Masing-masing #

Peta keputusan berikut memetakan kebutuhan ke model:

• Butuh failover otomatis ketika primary mati → physical. Standby identik adalah calon primary yang siap promosi tanpa kehilangan konsistensi internal; server logical tidak mengandung state cluster sehingga tidak bisa dipromosikan begitu saja.
• Naik versi major tanpa henti waktu → logical. Publikasikan tabel di server lama, langgani dari server baru, tunggu tersinkron, alihkan aplikasi, lalu lepas. Physical tidak pernah bisa lintas versi major.
• Kirim subset tabel ke sistem lain → logical. Misalnya hanya tabel produk yang dikirim ke server laporan cabang, tanpa menyeret tabel transaksi yang rahasianya tinggi.
• Konsolidasi beberapa database ke satu server pelaporan → logical. Satu subscriber boleh melanggan publikasi dari banyak publisher berbeda — hal yang mustahil bagi physical yang selalu satu-ke-satu cluster.
• Salinan whole-cluster untuk DR lintas lokasi → physical. Satu pasangan primary-standby menutup semua database sekaligus tanpa perlu mendefinisikan apa pun per tabel.

Membaca Perbandingan Lewat Dua Kasus #

Kasus pertama: Toko Maju Jaya ingin naik dari PostgreSQL 16 ke 17 tanpa menutup kasir semalaman. Physical replication tidak bisa dipakai karena standby 17 tidak mengerti WAL 16. Jalannya logical: pasang wal_level = logical di server 16, buat publication untuk tabel-tabel inti, langgani dari server 17 yang skemanya sudah disiapkan manual, alihkan tulisan setelah tersinkron, dan lepas langganan. Total henti waktu: hitungan menit, bukan jam.

Kasus kedua: tim analitik butuh tabel penjualan di server mereka, tetapi tidak boleh melihat tabel karyawan yang berisi gaji. Physical replication akan menyeret seluruh cluster termasuk tabel terlarang itu. Logical replication menyelesaikannya dengan publication yang memuat satu tabel saja. Kedua kasus memilih model yang berbeda bukan karena selera, tetapi karena batasan teknisnya memang berbeda.

Bagaimanapun model yang Anda pilih, keduanya bergantung pada satu komitmen yang sama dari primary: WAL yang dibutuhkan penerima tidak boleh terbuang sebelum benar-benar diterima. Mekanisme jaminannya — replication slot — adalah chapter berikutnya.

Referensi #

• Logical Replication
• Log-Shipping Standby Servers
• Replication
• Streaming Replication Protocol

-- Level WAL menentukan model replikasi yang tersedia.
-- "replica" (bawaan): cukup untuk streaming replication fisik.
-- "logical": syarat tambahan untuk logical replication.
SHOW wal_level;

-- Parameter fondasi untuk kedua model, beserta konteksnya:
-- "postmaster" artinya perubahan hanya berlaku setelah restart server.
SELECT name, setting, context
FROM pg_settings
WHERE name IN ('wal_level',
               'max_wal_senders',
               'max_replication_slots',
               'max_logical_replication_workers',
               'max_worker_processes')
ORDER BY name;