Apa itu PostgreSQL Streaming Replication (WAL) dan bagaimana cara mengaturnya

• Streaming Replication di PostgreSQL adalah cara yang efisien untuk mempertahankan satu atau lebih replika yang nyaris real-time dari DB primer di server standby
• Server primer terus-menerus mengirimkan record Write-Ahead Log (WAL) ke server standby segera setelah dibuat, sehingga meminimalkan latensi dalam proses replikasi
• Dirancang untuk meningkatkan high availability dan skalabilitas, dengan memungkinkan query baca dialihkan ke server standby sehingga mengurangi beban pada server primer
• Mendukung mode sinkron maupun asinkron, sehingga keseimbangan antara konsistensi data dan performa dapat diatur secara fleksibel
• Mencakup proses ketika server standby terhubung ke server primer untuk meminta streaming WAL, lalu menerapkan record yang diterima ke salinan DB miliknya sendiri
• Dibandingkan pengiriman log berbasis file, metode ini memberikan failover yang lebih cepat dan mengurangi risiko kehilangan data, sehingga ideal untuk lingkungan yang tersebar secara geografis

Bagaimana cara kerja Streaming Replication?

• Data WAL dikirim terus-menerus secara real-time dari server primer ke server standby, sehingga DB di standby tetap hampir identik dengan primer
• Dengan demikian, replika dapat digunakan untuk failover master atau menangani beban baca, sehingga sistem dapat diskalakan beberapa kali lipat

File konfigurasi PostgreSQL dan lokasinya

• File konfigurasi PostgreSQL berperan penting dalam mengelola pengaturan dan perilaku server database.
  • postgresql.conf: file konfigurasi utama yang berisi sebagian besar pengaturan server. Lokasinya dapat berbeda-beda bergantung pada sistem operasi, misalnya /etc/postgresql/<version>/main/postgresql.conf (Debian/Ubuntu) atau /var/lib/pgsql/<version>/data/postgresql.conf (Red Hat/CentOS)
  • pg_hba.conf: mengontrol autentikasi klien dengan mendefinisikan bagaimana klien terhubung ke server. Biasanya berada di direktori yang sama dengan postgresql.conf
  • pg_ident.conf: digunakan untuk pemetaan nama pengguna, tetapi lebih jarang dipakai
  • recovery.conf: digunakan untuk konfigurasi server standby pada PostgreSQL versi sebelum 12, tetapi pada versi setelahnya isinya dipindahkan ke postgresql.conf dan postgresql.auto.conf
• Lokasi yang tepat dapat berbeda tergantung sistem operasi, metode instalasi, dan versi PostgreSQL
  • Anda dapat menggunakan perintah SQL SHOW config_file; untuk menemukan lokasi file-file ini dari dalam instance PostgreSQL

Contoh dan struktur WAL (Write Ahead Logs)

• WAL dapat dilihat dengan perintah pg_waldump
• Setiap baris merepresentasikan record WAL yang berisi informasi tentang operasi DB
• Komponen tiap record:
  • rmgr: resource manager (misalnya Heap, Btree, Transaction)
  • len: panjang record
  • tx: ID transaksi
  • lsn: log sequence number
  • prev: LSN sebelumnya
  • desc: deskripsi operasi
• Jenis operasi yang terlihat:
  • Operasi INSERT (Heap dan Btree)
  • Operasi MULTI_INSERT (Heap2)
  • Transaksi COMMIT
  • Operasi file (CREATE)
  • Full Page Writes (FPW)
• Output WAL menunjukkan alur transaksi, modifikasi data, dan aktivitas sistem secara terperinci, sehingga berguna untuk analisis perilaku DB, troubleshooting, dan point-in-time recovery

Cara bekerja dengan Docker

• Pengaturan penting terkait Streaming Replication di postgresql.conf:
  • wal_level, max_wal_senders, max_replication_slots, hot_standby, dll.
• Yang dibutuhkan untuk contoh Docker Compose:
  • init-master.sh: mengatur PostgreSQL master untuk replikasi. Membuat user replikasi dan slot, serta memperbarui pengaturan terkait WAL
  • init-replica.sh: menyiapkan replika PostgreSQL agar terhubung ke master dan memulai replikasi. Menunggu sampai master siap, lalu melakukan backup dasar dan mengonfigurasi replika
  • start-replica.sh: memulai replika PostgreSQL di dalam container Docker. Menjalankan skrip init-replica.sh lalu memulai PostgreSQL
  • docker-compose.yml: mendefinisikan layanan master dan replika serta mengatur environment variable, volume, command, dan hal-hal lain yang diperlukan
• Setelah memberikan izin eksekusi pada skrip, jalankan docker-compose up -d untuk memulai master dan replika
• Anda dapat terhubung ke master dan memeriksa status replikasi dengan pg_stat_replication
• Anda dapat terhubung ke replika dan memeriksa apakah berada dalam mode recovery dengan pg_is_in_recovery()

Opini GN⁺

• Streaming Replication dapat sangat meningkatkan performa dan ketahanan infrastruktur database. Baik untuk skenario failover maupun distribusi beban baca ke replika, fitur ini memungkinkan DB diskalakan sambil tetap menjaga performa yang stabil
• Menunjukkan keseluruhan proses konfigurasi dan output sangat penting. Ini memberikan pandangan yang menyeluruh atas banyak komponen yang bergerak dan membantu memahami dengan lebih baik apa yang sedang terjadi
• Memahami cara kerja Streaming Replication dan mengonfigurasinya dengan benar sangatlah penting. Semoga artikel ini membantu memperjelas proses tersebut dan memberikan wawasan tentang cara kerja replikasi
• Produk atau proyek lain dengan fungsi serupa antara lain Replication milik MySQL atau Data Guard milik Oracle. Solusi-solusi ini juga bekerja dengan mengirimkan perubahan dari master ke replika, meskipun detail implementasinya bisa berbeda
• Saat menggunakan Streaming Replication, bandwidth jaringan dan latensi perlu dipertimbangkan. Transfer data antara master dan replika dapat mengonsumsi sumber daya jaringan dalam jumlah besar. Skalabilitas jumlah replika juga merupakan pertimbangan penting
• Persyaratan konsistensi data juga perlu dievaluasi. Replikasi sinkron dapat memengaruhi performa tulis tetapi memberikan konsistensi yang lebih kuat. Replikasi asinkron memberikan performa yang lebih baik tetapi memiliki sedikit kemungkinan kehilangan data

[GN⁺]

Komentar Hacker News

• Ada pendapat bahwa artikel ini bagus, tetapi dari sudut pandang seorang full-stack developer yang ingin mengelola database, terasa kurang contoh penerapan di dunia nyata

  • Ada pertanyaan tentang cara memeriksa seberapa jauh keterlambatan replika dibandingkan master
  • Disarankan cara memantau replika dengan pekerjaan cron sederhana untuk memeriksa status
  • Untuk masalah yang lebih kompleks, ada pertanyaan tentang cara beralih ke replika jika server utama mati
  • Ada pertimbangan apakah peralihan sebaiknya dilakukan otomatis atau manual
  • Ada keraguan apakah diperlukan dua replika untuk menghindari skenario split-brain
  • Ada pertanyaan tentang cara memulihkan kembali ke keadaan semula setelah peralihan

• Ada yang berpendapat bahwa solusi paling mudah untuk replikasi PostgreSQL adalah operator Kubernetes

  • CloudnativePG disebut sebagai contoh
  • Dijelaskan bahwa yang dibutuhkan bukan hanya replikasi, tetapi juga failover, pemulihan, pemantauan, self-healing, backup, dan lain-lain
  • Ada pertanyaan apakah ada implementasi gratis/open source lain di luar Kubernetes

• Salah satu alasan menggunakan Kubernetes dan Helm adalah karena masalah ini bisa diselesaikan

  • Dijelaskan bahwa melalui paket Bitnami PostgreSQL, hampir semuanya bisa dikonfigurasi tanpa pengaturan tambahan
  • Dijelaskan bahwa Postgres-ha membuat proxy untuk menangani kegagalan secara khusus sehingga memungkinkan failover tanpa downtime

• StackGres direkomendasikan untuk pengguna Kubernetes

• Terakhir, ada komentar skeptis bahwa artikel ini tampaknya ditulis oleh AI