Menguasai Slot Replikasi Postgres: Mencegah Pembengkakan WAL dan Masalah Produksi Lainnya

Selama beberapa tahun terakhir, saya telah membantu puluhan pengguna dan organisasi untuk membangun pipeline Change Data Capture (CDC) untuk database Postgres mereka. Kekhawatiran utama dalam proses tersebut adalah menyiapkan dan mengelola slot replikasi, yang merupakan mekanisme Postgres untuk memastikan bahwa segmen write-ahead log (WAL) database tetap ada sampai diproses oleh konsumen replikasi yang terdaftar.

Jika tidak hati-hati, slot replikasi dapat menyebabkan jumlah segmen WAL yang tidak semestinya besar tertahan oleh database. Postingan ini menjelaskan praktik terbaik untuk membantu mencegah ini dan masalah lainnya, membahas aspek seperti detak jantung, failover slot replikasi, pemantauan, pengelolaan publikasi Postgres, dan lainnya. Meskipun ini terutama berdasarkan pengalaman menggunakan slot replikasi melalui konektor Postgres Debezium, prinsip-prinsip ini berlaku secara umum dan layak dipertimbangkan juga saat menggunakan alat CDC lain untuk Postgres yang berbasis replikasi logis.

Gunakan Plugin Output Decoding Logis pgoutput

Postgres menggunakan plugin output decoding logis untuk menserialisasi data yang dikirim ke klien replikasi logis. Saat membuat slot replikasi, Anda harus menentukan plugin mana yang akan digunakan. Meskipun ada beberapa opsi, saya merekomendasikan menggunakan plugin pgoutput, yang merupakan plugin decoding standar yang juga digunakan untuk replikasi logis antar server Postgres. Ini memiliki beberapa keuntungan:

• pgoutput tersedia langsung di Postgres 10+ (termasuk layanan terkelola AWS, GCP, dan Azure), tanpa memerlukan instalasi tambahan
• Dibandingkan dengan plugin lain yang menggunakan JSON sebagai format serialisasi, pgoutput menggunakan format biner efisien dari pesan replikasi Postgres.
• Ini memberikan kontrol yang terperinci atas tabel, kolom, dan baris yang direplikasi (lihat informasi lebih lanjut di bawah)

Saat menggunakan alat CDC seperti Debezium, mereka biasanya akan membuat slot replikasi secara otomatis. Untuk membuat slot secara manual menggunakan plugin pgoutput, panggil fungsi pg_create_logical_replication_slot() seperti ini:

SELECT * FROM pg_create_logical_replication_slot('my_slot', 'pgoutput');
+-----------+-----------+
| slot_name | lsn |
|-----------+-----------|
| my_slot | 0/15AF761 |
+-----------+-----------+

LSN yang dikembalikan adalah pointer 64-bit yang secara unik mengidentifikasi lokasi di WAL, dengan bagian pertama mengidentifikasi segmen WAL dan bagian kedua mengidentifikasi offset di dalam segmen tersebut. Konsumen yang berlangganan slot ini akan menerima event perubahan mulai dari LSN ini.

Tidak seperti plugin decoding berbasis teks seperti test_decoding, pgoutput mengeluarkan format biner, yang berarti Anda tidak dapat memeriksa pesan untuk slot replikasi menggunakan fungsi Postgres seperti pg_logical_slot_peek_changes(). Untuk melihat sekilas pesan yang dihasilkan oleh pgoutput di baris perintah, tanpa menjalankan solusi CDC lengkap seperti Debezium, Anda dapat menggunakan alat pgoutput-cli:

docker run -it --rm --network my-network pgoutput-cli --host=postgres --port=5432 --database=inventorydb --user=dbz_user --password=kusnyf-maczuz-7qabnA --publication=dbz_publication --slot=my_slot

Output JSON:

{
"op": "I",
"message_id": "b14952a5-4033-4252-a33c-6039f700e9db",
"lsn": 26691112,
"transaction": { "tx_id": 755, "begin_lsn": 26691432, "commit_ts": "2025-07-02T12:09:05.854104Z" },
"table_schema": { "column_definitions": [ { "name": "id", "part_of_pkey": true, "type_id": 23, "type_name": "integer", "optional": false }, ... ], "db": "inventorydb", "schema_name": "inventory", "table": "customers", "relation_id": 16391 },
"before": null,
"after": { "id": 1028, "first_name": "Sarah", "last_name": "O'Brian", "email": "sarah@example", "is_test_account": "f" }
}

Tentukan Ukuran Maksimum Slot Replikasi

Protokol replikasi seperti Postgres perlu menyeimbangkan antara menyimpan log transaksi cukup lama agar konsumen dapat mengejar setelah downtime—misalnya selama upgrade—dan memastikan log transaksi tidak menghabiskan ruang disk yang tidak wajar di mesin database.

Sistem yang berbeda membuat trade-off yang berbeda di area ini. Sebagai contoh, MySQL memungkinkan Anda mengonfigurasi waktu retensi maksimum untuk binlog-nya; konsumen bertanggung jawab untuk memproses semua event dari binlog tepat waktu. Sebaliknya, slot replikasi Postgres memerlukan pengakuan aktif dari konsumen untuk melepaskan segmen WAL yang telah diproses. Database akan menahan semua segmen WAL selama yang diperlukan bagi semua konsumen replikasi untuk memproses data. Secara historis, ini berarti bahwa slot replikasi dapat menyebabkan jumlah backlog WAL yang tidak terbatas jika konsumen berhenti memproses slot tersebut, berpotensi menghabiskan ruang disk mesin database jika tidak ada tindakan.

Untungnya, situasi ini berubah dengan Postgres versi 13, yang memungkinkan Anda membatasi ukuran WAL maksimum yang dapat ditahan oleh slot replikasi. Untuk melakukannya, tentukan parameter max_slot_wal_keep_size di file postgresql Anda:

max_slot_wal_keep_size=50GB

Jika perbedaan antara restart LSN slot dan LSN saat ini lebih besar dari batas ini, database akan membatalkan slot replikasi dan menjatuhkan segmen WAL yang lebih lama. Ini membuat slot tidak dapat digunakan, yang berarti slot baru perlu dibuat, biasanya juga mengambil snapshot awal data yang baru saat menggunakan Debezium. Meskipun itu tidak nyaman bagi konsumen event, itu pasti lebih baik daripada database operasional Anda kehabisan ruang disk pada akhirnya.

Aktifkan Detak Jantung

Situasi yang sangat rentan terhadap pertumbuhan WAL yang tidak disengaja adalah kombinasi beberapa database logis dengan pola lalu lintas yang berbeda di satu host Postgres. Ini karena ada satu WAL bersama untuk seluruh instance, sedangkan slot replikasi dibatasi untuk database individu. Sekarang, bayangkan situasi di mana ada banyak transaksi yang dijalankan terhadap satu database—sehingga menambah banyak entri ke WAL—sementara ada database lain yang idle. Slot replikasi untuk database kedua tidak dapat membuat kemajuan, karena tidak pernah menerima event perubahan, dan oleh karena itu akan menyebabkan semakin banyak segmen WAL yang dipertahankan.

Solusi untuk ini adalah menghasilkan beberapa lalu lintas "palsu" di database kedua, memungkinkan slot replikasinya untuk maju. Secara historis, tabel detak jantung khusus sering digunakan untuk tujuan ini. Namun, Postgres 14+ menawarkan alternatif tanpa tabel yang elegan: melalui fungsi pg_logical_emit_message(), konten arbitrer dapat ditulis ke WAL, tanpa bermanifestasi di tabel mana pun. Ada sejumlah aplikasi menarik untuk pesan decoding logis ini, termasuk memajukan slot replikasi di database dengan lalu lintas rendah. Untuk mengaktifkan pesan detak jantung dengan Debezium, tambahkan konfigurasi berikut ke konfigurasi konektor Anda:

{ "interval" : "60000", "action" : "SELECT pg_logical_emit_message(false, 'heartbeat', now()::varchar)" }

Konektor menjalankan query ini setiap 60 detik, menulis pesan decoding logis dengan timestamp saat ini ke WAL. Selanjutnya, ia akan mengambil pesan melalui replikasi logis dan dengan demikian memungkinkan slot untuk maju. Perhatikan bahwa izin EXECUTE untuk fungsi ini harus diberikan kepada pengguna database Debezium:

GRANT EXECUTE ON FUNCTION pg_logical_emit_message(transactional boolean, prefix text, content text) TO <debezium_user>;

Gunakan Publikasi Tingkat Tabel

Jika Anda menggunakan plugin decoding logis pgoutput, Anda memiliki kontrol yang terperinci atas konten aliran replikasi. Jika Anda hanya tertarik pada perubahan pada sepuluh tabel dari 100 tabel di database Anda, mengalirkan perubahan untuk tepat sepuluh tabel itu tidak hanya membantu menghemat sumber daya (CPU, I/O jaringan) di sisi database, tetapi juga dapat secara drastis mengurangi biaya egress, ketika mengalirkan event perubahan ke zona ketersediaan lain dari penyedia cloud Anda.

Plugin pgoutput bergantung pada publikasi Postgres untuk mendefinisikan jenis perubahan apa yang harus dipublikasikan melalui replikasi logis. Untuk membuat publikasi tingkat tabel, tentukan semua tabel yang event perubahannya harus dipublikasikan:

CREATE PUBLICATION mypublication FOR TABLE customers, purchase_orders;

Jika database Anda memiliki beberapa skema tetapi Anda hanya ingin menangkap perubahan ke tabel dalam skema tertentu, Anda dapat melakukannya dengan membuat publikasi sebagai berikut:

CREATE PUBLICATION mypublication FOR TABLES IN SCHEMA inventory;

Saat menggunakan Debezium, secara default akan membuat publikasi FOR ALL TABLES. Namun, ini memerlukan izin superuser dan mungkin secara tidak perlu mengalirkan event tabel yang akan Anda filter di konektor. Alternatifnya, Anda dapat meminta Debezium membuat publikasi tingkat tabel dengan mengatur opsi konektor autocreate ke filtered. Debezium kemudian akan membuat publikasi yang mencerminkan set tabel yang ditangkap sebagaimana didefinisikan oleh filter include/exclude tabel dan skema konektor. Perhatikan bahwa ini memerlukan izin kepemilikan untuk semua tabel yang terpengaruh bagi pengguna konektor.

Untuk mengikuti prinsip hak istimewa minimal, sebaiknya pertimbangkan untuk membuat publikasi untuk konektor sendiri, sehingga meminimalkan set izin yang perlu Anda berikan kepada pengguna konektor. Secara default, publikasi diharapkan bernama "dbz_publication", tetapi Anda dapat mengganti nama melalui properti konektor publication. Saat menyiapkan beberapa konektor untuk menangkap set tabel yang berbeda di database yang sama, publikasi khusus harus dibuat untuk setiap konektor.

Gunakan Filter Kolom dan Baris

Mulai Postgres 15 dan seterusnya, publikasi memungkinkan Anda untuk lebih memangkas konten aliran replikasi. Melalui daftar kolom, Anda dapat menentukan kolom mana dari tabel yang harus dipublikasikan. Ini bisa sangat berguna untuk mengecualikan kolom besar, misalnya data biner, yang tidak diperlukan untuk kasus penggunaan tertentu. Sayangnya, tidak ada cara untuk mengecualikan kolom tertentu; sebaliknya, nama semua kolom yang akan ditangkap perlu ditentukan saat membuat publikasi:

CREATE PUBLICATION mypublication FOR TABLE customers (id, first_name, last_name);

Jika publikasi ini digunakan melalui Debezium, pastikan daftar kolom konektor (sebagaimana ditentukan melalui opsi konektor include dan exclude) cocok dengan daftar kolom publikasi.

Daftar kolom mewakili bentuk proyeksi, yaitu mirip dengan klausa SELECT dari query SQL. Selain itu, publikasi juga menyediakan kontrol atas baris mana yang akan disertakan dalam aliran replikasi melalui filter baris. Ini sesuai dengan klausa WHERE dari query, dan terlihat sangat mirip saat membuat publikasi:

CREATE PUBLICATION mypublication FOR TABLE customers WHERE (is_test_account IS FALSE);

Filter baris bisa sangat berguna untuk mengecualikan bagian dari kumpulan data operasional dari replikasi, misalnya data uji atau data yang dihapus secara logis. Saat menggunakan fitur snapshot Debezium—yang mengambil baris bukan melalui replikasi logis tetapi dengan memindai tabel yang sebenarnya di database—Anda harus menentukan ekspresi filter yang sama melalui opsi statementdes untuk memastikan konsistensi antara snapshot dan event streaming.

Aktifkan Slot Failover

Kekurangan lama dari replikasi logis di Postgres adalah kurangnya dukungan failover. Sampai relatif baru, slot replikasi hanya dapat dibuat di instance primer. Jika Anda telah menyiapkan cluster Postgres yang terdiri dari server primer dan replika baca, replikasi logis tidak dapat dilanjutkan dari replika setelah mempromosikannya menjadi primer jika terjadi kegagalan. Sebaliknya, biasanya Anda harus membuat slot replikasi baru, yang juga berarti memulai dengan snapshot awal baru jika penulisan dapat terjadi pada primer baru sebelum membuat slot replikasi baru.

Untungnya, selama beberapa versi Postgres terakhir, masalah ini akhirnya diatasi. Di Postgres 16, dukungan untuk membuat slot replikasi di replika ditambahkan. Meskipun tidak menyelesaikan masalah failover secara langsung, ini adalah peningkatan substansial, karena memungkinkan Anda memiliki slot di server primer dan standby serta secara manual menjaganya tetap sinkron. Postgres 17 akhirnya menambahkan dukungan penuh untuk slot failover. Ini sekarang dapat secara otomatis menyinkronkan status slot replikasi di server standby dengan slot di primer, tanpa memerlukan intervensi manual sama sekali. Setelah failover, konsumen dapat terus membaca dari slot di primer yang baru dipromosikan, tanpa kehilangan event, atau menghadapi sejumlah besar event duplikat (beberapa duplikat diharapkan terjadi). Untuk mengaktifkan slot failover, diperlukan sedikit konfigurasi.

Di primer: Berikan failover=true saat memanggil pg_create_logical_replication_slot() untuk membuat slot replikasi di primer; dengan Debezium 3.0.5 atau lebih baru, Anda dapat meminta Debezium membuat slot failover dengan mengatur opsi konektor sloter ke true. Atur opsi synchronized_standby_slots ke nama slot fisik yang menghubungkan server primer dan standby.

Di server standby: Atur opsi sync_replication_slots ke on; ini akan memulai proses worker yang secara otomatis menyinkronkan status slot replikasi logis dari server primer ke server standby. Tambahkan nama database slot ke string koneksi yang digunakan untuk terhubung ke server primer (primary_conninfo). Jika Anda menggunakan Postgres di Amazon RDS, tentukan nama database menggunakan opsi rdsl_slot_sync_dbname. Atur opsi hot_standby_feedback ke true.

Jika Anda terhubung ke Postgres melalui proxy, misalnya pgbouncer, mempromosikan replika menjadi primer dapat dibuat sepenuhnya transparan bagi konsumen replikasi Anda seperti Debezium, melanjutkan pemrosesan event perubahan dengan mulus setelah failover.

Pertimbangkan Menggunakan Replica Identity FULL

Di Postgres, identitas replika tabel menentukan bidang mana dari baris yang akan ditulis ke WAL untuk gambar baris lama untuk event update dan delete. Secara default, nilai lama hanya akan dicatat untuk kolom primer. Selain itu, nilai kolom TOAST hanya akan terkandung dalam gambar baris baru jika nilainya berubah.

Keanehan ini dapat membuat event perubahan agak sulit dan kompleks untuk diproses oleh konsumen. Saat melakukan pemrosesan aliran inkremental pada aliran event perubahan, gambar baris lama yang hilang memerlukan operasi materialisasi status yang mahal. Karena nilai untuk kolom TOAST yang tidak berubah tidak ada dari event update, konsumen tidak dapat menerapkan event perubahan seperti itu dengan semantik upsert sederhana.

Untuk menghindari masalah ini, pertimbangkan untuk mengubah identitas replika tabel Anda dari DEFAULT menjadi FULL:

ALTER TABLE inventoryers REPLICA IDENTITY FULL;

Ini akan menyebabkan gambar baris lama dan baru lengkap, termasuk kolom TOAST, ditulis ke WAL dan dengan demikian tersedia dalam event perubahan data. Beberapa DBA Postgres khawatir tentang potensi dampak pada penggunaan disk dan konsumsi CPU. Namun, overhead sebenarnya dapat dikelola dalam banyak kasus. Detailnya tergantung pada beban kerja spesifik Anda, jadi Anda harus melakukan benchmarking sendiri untuk mengukur dampak yang tepat. Sebagai contoh, sebuah post menyebutkan peningkatan moderat konsumsi CPU puncak dari 30% menjadi 35% saat mengaktifkan identitas replika FULL. Ini seharusnya dapat diterima dalam banyak kasus, dan melakukannya dapat membantu secara substansial untuk menyederhanakan konsumsi dan pemrosesan aliran event perubahan.

Pantau, Pantau, Pantau!

Observabilitas yang mendalam adalah kunci untuk mengoperasikan sistem data dengan sukses di produksi. Saat menjalankan Postgres, Anda harus memasang pemantauan dan peringatan untuk slot replikasi Anda untuk memastikan bahwa mereka tidak akan pernah mengkonsumsi jumlah WAL yang tidak wajar. Metrik berikut harus terus dilacak menggunakan alat observabilitas seperti Prometheus dan Grafana, Datadog, Elastic, atau sejenisnya:

• Ukuran WAL total
• Ukuran WAL yang dipertahankan per slot replikasi
• Ruang WAL yang tersisa per slot replikasi
• Status (aktif/tidak aktif/tidak valid) per slot replikasi

Untuk mendapatkan ukuran WAL total, Anda dapat menjumlahkan ukuran semua file yang dikembalikan oleh fungsi pg_ls_waldir(). Metrik spesifik slot dapat diambil dari tampilan pg_replication_slots, misalnya seperti ini:

SELECT slot_name, plugin, database, restart_lsn, CASE WHEN invalidation_reason IS NOT NULL THEN 'invalid' ELSE CASE WHEN active IS TRUE THEN 'active' ELSE 'inactive' END END as "status", pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS "retained_wal", pg_size_pretty(safe_wal_size) AS "safe_wal_size" FROM pg_replication_slots ORDER BY slot_name;

Ukuran WAL yang dipertahankan dapat dihitung dengan menentukan perbedaan antara restart LSN slot dan LSN saat ini dari database. Kolom safe_wal_size di tampilan mewakili jumlah byte yang dapat ditahan slot sebagai tambahan sampai mencapai batas yang dikonfigurasi melalui max_slot_wal_keep_size.

Semua metrik ini dapat diperoleh dari instance Postgres dengan sangat mudah menggunakan proyek postgres_exporter, yang mengekspos endpoint yang kompatibel dengan Prometheus. Selain itu, juga masuk akal untuk melacak ruang kosong yang tersisa dari disk atau volume yang menampung WAL. Postgres sendiri tidak mengekspos nilai ini, sebaliknya Anda harus mendapatkannya dari sistem operasi, job orchestrator (seperti Kubernetes), atau penyedia cloud (saat menjalankan Postgres di layanan seperti Amazon RDS). Terakhir, disarankan untuk memonitor metrik MilliSecondsBehindSource yang disediakan Debezium untuk setiap instance konektor. Ini mewakili waktu yang dibutuhkan dari titik waktu perubahan dibuat di database hingga event tersebut diproses oleh Debezium. Debezium menyediakan metriknya melalui JMX; melalui komponen jmx_exporter Prometheus, mereka dapat diekspos melalui HTTP dalam format yang kompatibel dengan Prometheus.

Contoh menunjukkan hasil dari menjalankan pgbench selama 30 menit (20 koneksi, empat thread masing-masing). Ada tiga konektor Debezium dengan slot replikasi logis yang sesuai. Slot replikasi 1 menunjukkan tingkat retensi WAL yang konstan, karena konektor ini berjalan terus menerus dan mengeluarkan event. Konektor yang memiliki slot 2 dihentikan selama beberapa menit di tengah proses, seperti yang ditunjukkan oleh kolom merah di panel status aktivitas. Selama waktu itu, backlog WAL slot itu naik, tetapi kemudian menyusut lagi saat konektor mengejar setelah dimulai ulang. Slot 3 akhirnya terus menerus menahan lebih banyak WAL, alasannya adalah bahwa slot ini dikonfigurasi terhadap database lain di host Postgres ini, dan tidak ada perubahan yang terjadi di database itu. Dengan demikian, Debezium tidak pernah mendapatkan pengakuan kemajuan pada slot ini. Event detak jantung, seperti yang dibahas di atas, dapat digunakan untuk mengatasi situasi ini.

Apa yang harus dilakukan jika konsumen replikasi aktif tidak dapat mengimbangi perubahan di database sumber dan kelambatan replikasinya terus meningkat? Sementara saya berencana untuk menulis posting blog terpisah tentang penyesuaian kinerja konektor Debezium Postgres, salah satu solusinya adalah bekerja dengan beberapa slot replikasi, masing-masing mengekspor perubahan ke subset tabel yang berbeda, sehingga memungkinkan Anda untuk membagi beban konsumen ke beberapa proses yang berjalan di mesin terpisah. Untuk melakukannya, Anda dapat menyalin slot replikasi yang ada dengan pg_copy_logical_replication_slot(). Dengan begitu, konektor kedua dapat melanjutkan pemrosesan dari LSN yang sama dengan slot asli.

Selain memvisualisasikan nilai dalam dasbor, Anda juga harus memiliki peringatan yang dipicu ketika ambang batas tertentu terlampaui. Nilai spesifik tergantung pada ukuran database Anda dan karakteristik beban kerja Anda. Pertimbangkan untuk memulai dengan nilai berikut dan sesuaikan ambang batas dari sana untuk menemukan keseimbangan yang tepat antara memicu cukup awal dan menghindari kebisingan yang tidak perlu:

• Penggunaan disk melewati 60-70%
• Slot replikasi tidak aktif selama lebih dari 30 menit
• Slot replikasi menahan lebih dari 10-20 GB data WAL

Seringkali, lebih dari nilai absolut itu sendiri, turunan pertama—yaitu perubahan pada nilai—menarik, dan harus menjadi subjek peringatan, misalnya jika penggunaan disk meningkat dengan cepat, atau jika WAL yang dipertahankan oleh slot replikasi tumbuh perlahan namun stabil selama periode waktu yang lebih lama.

Jika Anda menerapkan transaksi besar yang berjalan lama terhadap database Postgres Anda, ini dapat menyebabkan replikasi logis menumpahkan status ke disk selama decoding konten WAL, meningkatkan beban I/O mesin dan memperlambat proses replikasi. Di Postgres 14 dan lebih baru, Anda dapat memeriksa tumpahan disk slot replikasi dengan menanyakan tampilan pg_stat_replication_slots:

SELECT slot_name, total_txns, spill_txns, pg_size_pretty(spill_bytes) as spilled, pg_size_pretty(total_bytes) as total FROM pg_stat_replication_slots;

Jika Anda mengamati jumlah tumpahan disk yang tidak semestinya besar, pertimbangkan untuk meningkatkan pengaturan logical_decoding_work_mem (default 64 MB).

Hapus Slot Replikasi yang Tidak Digunakan

Terakhir, tip perawatan: jangan lupa untuk menghapus slot replikasi yang tidak digunakan! Secara khusus, saat menghentikan dan menghapus konektor Debezium, slot replikasinya di Postgres tidak akan secara otomatis dihapus. Jika slot tidak lagi diperlukan untuk konektor lain atau jenis konsumen replikasi lainnya, Anda harus menjatuhkan slot untuk mencegahnya memblokir penghapusan segmen WAL. Untuk melakukannya, panggil fungsi pg_drop_replication_slot() seperti ini:

SELECT pg_drop_replication_slot('my_replication slot');

Setelah Postgres 18 dirilis (direncanakan untuk September 2025), opsi baru idle_replication_slot_timeout akan berguna untuk itu. Rekan berbasis waktu dari opsi max_slot_wal_keep_size yang disebutkan sebelumnya, ini memungkinkan Anda untuk membatalkan slot replikasi setelah periode tidak aktif yang dapat dikonfigurasi. Mengaturnya ke nilai yang cukup besar seperti 48 jam atau 72 jam akan membantu memastikan bahwa slot yang tidak aktif dibatalkan tepat waktu, mencegah mereka menahan lebih banyak segmen WAL.

Ringkasan

Slot replikasi logis adalah blok bangunan penting untuk membangun pipeline CDC dengan Postgres. Meskipun kekhawatiran tentang potensi pertumbuhan WAL kadang-kadang menyebabkan ketidakpastian dan kecemasan di antara pengguna, ketakutan ini sebagian besar tidak perlu ketika slot replikasi diatur dan dikonfigurasi dengan benar.

Dengan mengonfigurasi aspek seperti ukuran slot maksimum, publikasi yang terperinci, dan detak jantung secara hati-hati, Anda dapat memastikan stabilitas dan kinerja database Postgres dan pipeline CDC Anda. Slot failover, seperti yang didukung sejak Postgres 17, memungkinkan Anda melanjutkan replikasi dengan mulus setelah mempromosikan server standby menjadi primer. Terakhir, lakukan pemantauan dan peringatan yang komprehensif untuk memastikan slot replikasi Anda berperilaku seperti yang diharapkan.