Konsep Replication

Database Toko Maju Jaya selama ini hidup di satu server: satu proses PostgreSQL, satu disk, satu mesin. Selama disk itu sehat, semuanya lancar — tetapi satu komponen berarti satu titik kegagalan tunggal: jika server itu mati di jam sibuk transaksi, kasir berhenti melayani pelanggan sampai server pulih. Replication adalah jawaban PostgreSQL untuk masalah ini: server lain dijaga tetap berisi salinan data yang terus mengikuti perubahan, sehingga kegagalan satu mesin tidak lagi menghentikan seluruh operasi. Chapter ini membangun kosakata dan kerangka berpikir replikasi — tujuan, mekanisme dasar, serta pilihan async versus sync — sebelum chapter berikutnya membuat Anda benar-benar menjalankan dua server yang saling mereplikasi.

Mengapa Server Tunggal Tidak Cukup #

Replikasi bukan fitur tunggal dengan satu tujuan; empat kebutuhan berbeda diselesaikan dengan salinan data yang selalu mutakhir:

Perhatikan bahwa replikasi bukan pengganti backup. Backup melindungi dari kesalahan logis — DELETE tanpa WHERE, tabel terdrop, korupsi aplikasi — karena salinan lama tetap ada; replikasi justru setia menyalin kesalahan itu ke semua server. Kedua mekanisme itu saling melengkapi, sebagaimana dibahas di chapter Konsep Backup .

Replikasi Menyalin Perubahan, Bukan Hasil Akhir #

Cara termurah menjaga salinan data adalah menyalin file database setiap malam — tetapi salinan semacam itu usang sepanjang hari. PostgreSQL memakai pendekatan yang jauh lebih presisi: setiap perubahan (satu INSERT, satu UPDATE, satu baris index yang ikut berubah) terlebih dahulu ditulis sebagai record ke write-ahead log (WAL) sebelum diterapkan ke file data. Chapter Write-Ahead Logging membahas peran WAL untuk durability; untuk replikasi, WAL punya peran kedua: record yang sama persis bisa dikirim ke server lain dan di-replay di sana, sehingga server kedua menempuh jalur perubahan yang identik dan berakhir dengan isi data yang sama.

Diagram berikut memperlihatkan alur dasarnya:

Semua tulisan masuk ke satu server yang disebut primary. Proses walsender di primary mengalirkan record WAL begitu record itu tercipta — inilah sebabnya model ini disebut streaming. Di sisi penerima, proses walreceiver menulis record ke WAL lokal standby, lalu proses recovery standby me-replay-nya seolah WAL itu dihasilkan oleh server sendiri. Karena standby menjalankan replay terus-menerus, standby mengetahui data yang mutakhir tanpa primary pernah menghitung “diff” antar tabel.

Fondasi yang Sudah Aktif di Server Anda #

Kabar baiknya: tanpa satu pun konfigurasi tambahan, server PostgreSQL Anda sudah berjalan dengan fondasi replikasi aktif. Dua parameter berikut menentukan kesiapan itu — mari kita baca nilainya langsung dari server:

-- Level penulisan WAL menentukan informasi replikasi yang dibawa WAL.
-- Nilai "replica" sudah cukup untuk streaming replication fisik.
SHOW wal_level;

-- Jumlah proses walsender maksimum: satu per standby/streamer yang tersambung.
SHOW max_wal_senders;

-- Parameter fondasi replikasi lainnya di server ini.
SELECT name, setting
FROM pg_settings
WHERE name IN ('max_replication_slots',
               'max_logical_replication_workers',
               'max_worker_processes')
ORDER BY name;

Output yang Dihasilkan:

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

 max_wal_senders 
-----------------
 10
(1 row)

              name               | setting 
---------------------------------+---------
 max_logical_replication_workers | 4
 max_replication_slots           | 10
 max_worker_processes            | 8
(3 rows)

Tiga temuan penting dari output tersebut. Pertama, wal_level = replica — level bawaan sejak PostgreSQL 10 — berarti WAL sudah memuat informasi yang dibutuhkan standby untuk replay; level logical (untuk replikasi per-tabel) baru dibutuhkan di chapter Logical Replication . Kedua, max_wal_senders = 10 berarti primary ini sanggup mengumpan hingga sepuluh streamer serentak (standby, pg_basebackup, atau subscriber logical) tanpa perubahan apa pun. Ketiga, max_replication_slots dan kawan-kawannya sudah menyediakan alokasi untuk slot serta worker logical replication. Singkatnya, yang belum ada hanyalah server kedua — dan itulah pekerjaan chapter berikutnya.

Asynchronous vs Synchronous #

Pertanyaan desain terpenting dalam replikasi: kapan boleh menyatakan COMMIT berhasil? PostgreSQL memisahkan dua jawaban itu menjadi mode asynchronous (bawaan) dan synchronous:

Mode synchronous diaktifkan lewat synchronous_standby_names — primary kemudian menunggu ACK dari standby yang disebutkan. Ada tingkat tunggu yang bisa dipilih lewat synchronous_commit (misalnya remote_apply menunggu sampai standby selesai me-replay), dan sejak PostgreSQL 10 kata kunci ANY memungkinkan kuorum: cukup N standby mana pun yang mengonfirmasi. Mode sync tidak gratis: setiap transaksi kini membayar latency jaringan, dan standby yang tersendat bisa membuat primary terlihat “menggantung”. Karena itu banyak sistem memakai async untuk mayoritas tulisan dan sync hanya untuk data yang benar-benar kritis.

Satu Primary atau Banyak Primary #

Dalam ekosistem PostgreSQL, arsitektur replikasi terbagi dua keluarga besar. Single-primary — yang dibahas sepanjang section ini — menunjuk satu server sebagai satu-satunya penerima tulisan; standby hanya membaca. Konsistensinya hampir gratis karena hanya ada satu sumber kebenaran, dan promosi standby menjadi pengganti adalah operasi yang relatif sederhana. Multi-primary membiarkan beberapa server menerima tulisan sekaligus untuk data yang sama; konsekuensinya adalah resolusi konflik (dua cabang menjual unit terakhir dari stok yang sama, lalu sinkron), penanganan sequence yang tidak boleh bertabrakan, dan beban desain yang jauh lebih berat. PostgreSQL bawaan tidak menyediakan multi-primary; solusi seperti ekstensi pihak ketiga berada di luar cakupan course ini. Untuk skala Toko Maju Jaya — bahkan untuk skala jauh lebih besar — pola single-primary dengan beberapa standby sudah menjadi pola industri yang dominan.

Peta Section Ini #

Dengan kosakata ini di tangan, delapan chapter berikutnya menyusun bangunan secara bertingkat: Streaming Replication membuat dua server lokal Anda benar-benar mereplikasi; Physical vs Logical Replication membandingkan dua model replikasi; Replication Slot menjaga WAL agar tidak terbuang; Logical Replication mereplikasi per tabel; Replication Lag mengukur jeda; Read Replica memanfaatkan standby untuk beban baca; Konsep Failover mempromosikan standby; dan Arsitektur High Availability merangkai semuanya menjadi sistem yang mengelola failover secara otomatis.

Referensi #

• High Availability, Load Balancing, and Replication
• Log-Shipping Standby Servers
• Replication

-- Level penulisan WAL menentukan informasi replikasi yang dibawa WAL.
-- Nilai "replica" sudah cukup untuk streaming replication fisik.
SHOW wal_level;

-- Jumlah proses walsender maksimum: satu per standby/streamer yang tersambung.
SHOW max_wal_senders;

-- Parameter fondasi replikasi lainnya di server ini.
SELECT name, setting
FROM pg_settings
WHERE name IN ('max_replication_slots',
               'max_logical_replication_workers',
               'max_worker_processes')
ORDER BY name;