pgactive - Ekstensi replikasi active-active untuk Postgres

 (github.com/aws)
9 poin oleh GN⁺ 2025-07-18 | 1 komentar | Bagikan ke WhatsApp
  • Ekstensi replikasi active-active untuk PostgreSQL yang dibuat dan dirilis secara terbuka oleh AWS
  • Saat perlu menulis dan memperbarui data di beberapa instans PostgreSQL, alih-alih model active-standby lama yang hanya menerima perubahan di satu instans tertentu, ini memungkinkan pembangunan arsitektur yang mendukung perubahan serentak dan replikasi di beberapa instans
  • Cocok untuk skenario seperti konfigurasi database highly available di beberapa region, meminimalkan latensi tulis, pembaruan blue/green aplikasi, dan migrasi data dua arah
  • Memanfaatkan replikasi logis untuk mendukung deteksi konflik, penyelesaian konflik tulis, dan konversi format database target

Konsep replikasi active-active

  • Replikasi (Replication) adalah teknologi untuk menyinkronkan perubahan antar database
  • Arsitektur active-standby PostgreSQL yang ada selama ini hanya menerima perubahan di satu instans, sementara sisanya bersifat read-only, sehingga satu lokasi berperan sebagai sumber data tunggal
  • pgactive menyediakan topologi replikasi active-active yang memungkinkan penulisan data secara bersamaan di beberapa instans
  • Pendekatan ini cocok untuk lingkungan yang memerlukan banyak titik tulis, misalnya deployment multi-region atau migrasi dua arah
  • Dalam model active-active, konflik, latensi, dan keterbatasan sebagian fitur memerlukan pengelolaan tersendiri

Teknologi inti: replikasi logis

  • Replikasi logis (Logical Replication) mengirimkan data dalam format yang dapat diinterpretasikan oleh sistem eksternal
  • Melalui replikasi logis, berbagai fungsi tambahan dapat diimplementasikan di database tujuan, seperti deteksi konflik, penyelesaian konflik tulis, dan transformasi kueri
  • PostgreSQL memperkenalkan replikasi logis bawaan pada versi 10 di tahun 2017, tetapi replikasi active-active memerlukan kemampuan tambahan
  • Karena karakteristik desain PostgreSQL, kemampuan tersebut dapat dikembangkan dan diterapkan dalam bentuk ekstensi (extension)
  • Komunitas pengembang PostgreSQL juga secara bertahap menambahkan kemampuan terkait ke proyek inti

Bacaan terkait

1 komentar

 
GN⁺ 2025-07-18
Opini Hacker News
  • Saya merangkum sejarah perkembangan BDR, pglogical, pgactive, dan Postgres Distributed(PGD) berdasarkan yang saya dengar dari rekan tim di 2nd Quadrant dan EDB
    Yang paling awal muncul dan masih open source sampai sekarang adalah BDR1 (tautan), dan pgactive dibangun di atas ini
    BDR2 adalah penulisan ulang BDR1 menjadi closed source, dan akhirnya ditinggalkan
    pglogical v1 dan v2 (keduanya open source, tautan) dirilis, dan dari keduanya v1 dimodifikasi besar-besaran lalu digabungkan ke Postgres 10
    Berdasarkan pengalaman dengan fitur logical replication di Postgres 10, 2nd Quadrant mulai mengembangkan pglogical v2, dan dari sinilah pgEdge juga lahir
    Setelah itu 2nd Quadrant membuat pglogical v3 dan BDR v3 versi closed source, lalu keduanya digabung menjadi BDR v4
    Setelahnya nama produk BDR diubah menjadi Postgres Distributed(PGD, tautan)
    Setelah 2ndQuadrant diakuisisi oleh EDB, EDB merilis PGD v6
    • PostgresPro juga punya sistem replikasi multi-master tersendiri tautan dokumentasi
    • Bertanya apakah PGDv6 masih closed source
  • Sistem ini menggunakan logical replication milik Postgres untuk meneruskan perubahan dari satu instance ke instance lain
    Jika terjadi konflik, nilai yang terakhir ditulis berdasarkan timestamp akan menjadi yang akhirnya diterapkan
    Riwayat konflik yang terjadi disimpan di tabel khusus bernama pgactive_conflict_history, jadi riwayatnya bisa ditinjau dan diselesaikan secara manual
    Untuk detail dan dokumentasi, lihat di sini
    • Penasaran apakah ini termasuk multi-master replication
      Kalau kemampuan seperti ini bisa diterima secara resmi ke Postgres, sepertinya akan menarik
    • Dari sudut pandang pengguna, saya ingin tahu apakah write mereka langsung dianggap berhasil, atau hanya akan konvergen pada akhirnya
  • Penasaran apakah ada yang baru-baru ini benar-benar memakai database Bloomberg (comdb2) secara langsung
  • Ini masih terkait tapi agak melenceng, apakah ada cara untuk melakukan “replikasi yang bisa ditulis secara lokal (berbasis read replica)”
    Misalnya, saya ingin membaca data dari production atau staging, tetapi hanya bisa memodifikasinya secara lokal dan hasilnya tidak dipantulkan kembali ke upstream, dengan memakai database sekunder
    Saat ini kebanyakan dilakukan dengan membuat snapshot secara berkala lewat skrip (cron dan sejenisnya) menggunakan dump data atau query, menyimpannya ke S3, lalu mengunduh dan memulihkan datanya secara lokal
    Cara ini umumnya efektif, tetapi kadang pembangunan indeks memakan waktu terlalu lama
    • Sebagai catatan, karena masalah data sensitif seperti informasi pribadi, berbahaya kalau data seperti ini langsung masuk ke environment staging atau dev
      Risiko hukum dan etisnya besar, jadi kebanyakan perusahaan tidak merekomendasikan cara seperti ini
    • Jika memakai logical replication Postgres dengan filter, replikasi satu arah dimungkinkan, sehingga setelah replication slot dilepas, data lokal bisa diubah dengan bebas
      Dengan begitu Anda bisa memodifikasi tabel lokal tanpa memengaruhi primary
    • Menyimpan database lokal yang “murni” sebagai cadangan, lalu menyalinnya saat diperlukan untuk dijadikan database pengembangan, membuat penyalinan sangat cepat tanpa perlu membangun indeks lagi
      Rekomendasi perintah createdb --template
    • Penasaran bagaimana konflik antara write lokal dan update jarak jauh ditangani
      Saya tidak terpikir strategi merge yang bisa berlaku untuk semua situasi
    • Setahu saya, dalam konfigurasi logical replication Postgres, ini memang perilaku standarnya
      Bukan berarti write diblokir di replica, hanya saja hasilnya tidak menyebar ke tempat lain
  • Kita harus selalu ingat bahwa istilah “Conflict resolution” pada akhirnya berarti “membuang data yang sudah di-commit dan disetujui, sehingga merusak durability”
    Yang terbaik adalah merancang arsitektur agar tidak ada tumpang tindih area data yang akan ditulis di seluruh instance aktif
    Dalam kasus seperti itu, alat seperti pgactive cukup berguna
    Atau, lebih baik sejak awal memakai database terdistribusi (seperti Yugabyte)
    • Dokumentasi resmi juga merekomendasikan cara menghindari konflik dengan membagi schema per master, sehingga “setiap master menjadi satu-satunya writer untuk schema masing-masing”
      Semua master tetap bisa membaca semua schema, tetapi untuk write masing-masing hanya menangani bagiannya sendiri
      Penasaran apakah selain schema, partition dan sebagainya juga bisa dipakai untuk membagi tanggung jawab
  • Ini membuat saya bertanya-tanya kenapa AWS membuat ini
    Saya tidak langsung melihat fitur ini dipakai di produk mereka sendiri
    RDS memakai block replication, Aurora memakai SAN replication miliknya sendiri
    Dugaan saya, mungkin ini ditujukan untuk pemakaian di DMS
    • Mungkin karena Aurora DSQL yang baru dirilis
    • Sejujurnya saya kurang melihat manfaat besarnya
      Saya mempertanyakan kenapa ini perlu dilakukan pada database relasional ACID yang kuat
    • Setahu saya SAN replication milik Aurora tidak dipakai untuk cross region replication
    • Di readme repositorinya juga tertulis bahwa “membangun klaster database highly available Multi-Region” adalah kegunaan utamanya
    • Ternyata ini memang sudah tersedia di RDS Postgres sejak 2 tahun lalu (tautan terkait)
      Namun ada kabar bahwa 1 bulan lalu ini secara resmi dirilis sebagai open source ke komunitas (berita resmi)
  • Saya pernah mengoperasikan beberapa klaster dengan repmgr dan patroni untuk environment yang benar-benar tanpa downtime, dan plugin ini benar-benar ingin saya pasang hanya sebagai pilihan terakhir
    Demi bisa tidur nyenyak di malam hari, saya ingin sebisa mungkin menghindarinya
  • Kebetulan saya baru-baru ini sedang mencari cara mudah untuk membangun klaster Postgres highly available yang mendukung “automatic failover, pemulihan node, dan point-in-time recovery”
    Kombinasi patroni+etcd+haproxy sering direkomendasikan, dan melihat orang-orang yang benar-benar memakainya merekomendasikannya dengan antusias, tampaknya memang ada alasannya
    Namun saat melihat file contoh dengan docker compose, rasanya agak memberatkan
    pgpool terlihat sederhana karena sepertinya cukup diletakkan di depan tiap postgres
    Saya penasaran dengan rekomendasi atau pengalaman dari orang-orang yang menyukai Postgres di lingkungan kerja nyata
    Targetnya adalah membangun klaster berbasis docker compose sesederhana mungkin, dengan ketersediaan tinggi, (minimal) tanpa kehilangan data, dan point-in-time recovery
    • Bertanya apakah yang dicari adalah alat seperti Barman
    • Saya memakai cloudnativepg, dan dengan itu saja sebagian besar fitur yang dibutuhkan langsung berfungsi
  • Membagikan apakah ada materi lain seperti pgactive atau kasus terkait
    <i>Pgactive: Active-Active Replication Extension for PostgreSQL on Amazon RDS</i>
    Tulisan Hacker News (tulisan Oktober 2023, 1 komentar)
  • Sepertinya ini bersifat asynchronous, dan tampaknya akan ada masalah besar pada isolasi transaksi
    • Pada akhirnya ini soal trade-off
      Artinya, setiap orang perlu menerima kelebihan dan kekurangannya sesuai situasi masing-masing