Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Menghindari masalah kinerja dengan REPLICA IDENTITY FULL di PostgreSQL RDS untuk PostgreSQL

Replikasi logis PostgreSQL mengharuskan setiap tabel yang diterbitkan memiliki identitas replika sehingga pelanggan dapat menemukan baris yang benar untuk diperbarui atau dihapus. Secara default, kunci utama berfungsi sebagai identitas replika. Ketika tabel tidak memiliki kunci primer atau indeks unik yang sesuai, Anda dapat mengatur identitas replikaFULL, yang menyebabkan PostgreSQL menggunakan seluruh baris sebagai kunci.

Sementara REPLICA IDENTITY FULL memecahkan masalah langsung mereplikasi tabel tanpa kunci utama, itu dapat memperkenalkan masalah kinerja yang serius pada penerbit dan pelanggan. Memahami dampak ini penting bagi siapa saja yang menggunakan replikasi logis dengan PostgreSQL RDS untuk PostgreSQL, termasuk fitur yang mengandalkan replikasi logis secara internal, seperti penerapan. blue/green

Mengapa REPLICA IDENTITY FULL menyebabkan masalah

Peningkatan volume WAL pada penerbit

REPLICA IDENTITYPengaturan mengontrol informasi apa yang ditulis PostgreSQL ke log write-ahead (WAL) untuk mengidentifikasi baris yang diperbarui atau dihapus. Dengan identitas replika default (kunci utama), hanya kolom kunci yang dicatat sebagai identitas baris lama. DenganFULL, PostgreSQL mencatat nilai-nilai lama dari setiap kolom untuk masing-masing dan. UPDATE DELETE Ini memiliki beberapa konsekuensi:

Pencarian baris lambat pada pelanggan

Ketika pelanggan menerima catatan UPDATE atau DELETE log, ia harus menemukan baris yang cocok dalam salinan tabel lokalnya. DenganREPLICA IDENTITY FULL, pelanggan mencari baris yang cocok dengan semua nilai kolom dari gambar baris lama.

Bagaimana PostgreSQL melakukan pencarian ini berbeda dengan versi utama PostgreSQL:

Bagaimana REPLICA IDENTITY FULL menyebabkan kelambatan replikasi

Dua masalah yang dijelaskan di atas — WAL yang lebih besar pada penerbit dan pencarian baris yang lebih lambat pada pelanggan — bergabung untuk menyebabkan kelambatan replikasi.

Secara default, replikasi logis PostgreSQL menggunakan proses apply worker tunggal per langganan untuk menerima perubahan dari penerbit dan menerapkannya ke tabel pelanggan. Proses apply worker berubah secara serial, satu baris pada satu waktu, dalam urutan komit. Ini berarti throughput pelanggan dibatasi oleh seberapa cepat ia dapat menerapkan setiap perubahan individu.

Ketika REPLICA IDENTITY FULL diatur di atas meja tanpa indeks yang sesuai, setiap UPDATE dan DELETE membutuhkan pemindaian sekuensial dari seluruh tabel untuk menemukan baris yang cocok. Jika tabel memiliki jutaan baris, masing-masing operasi ini dapat memakan waktu beberapa detik atau lebih lama. Hasilnya adalah masalah cascading:

Masalah ini sangat parah untuk tabel yang sering menerima UPDATE atau DELETE operasi. INSERToperasi tidak terpengaruh karena tidak memerlukan pencarian baris pada pelanggan.

Dampak pada blue/green penerapan

Blue/green penerapan di Amazon Amazon RDS menggunakan replikasi logis secara internal untuk menjaga lingkungan hijau disinkronkan dengan lingkungan biru dengan menyiapkan satu langganan per database. Proses penerapan replikasi logis di lingkungan hijau adalah single-threaded. Proses pekerja terapkan tunggal menerima semua perubahan dari lingkungan biru dan menerapkannya satu per satu, dalam urutan komit. Tidak ada penerapan paralel di jalur blue/green replikasi.

Desain ulir tunggal ini berarti kemampuan lingkungan hijau untuk mengikuti lingkungan biru sepenuhnya bergantung pada seberapa cepat seseorang pekerja terapkan dapat memproses setiap perubahan individu. Ketika tabel digunakan REPLICA IDENTITY FULL tanpa kunci utama atau indeks yang sesuai, dampaknya pada pekerja terapan bergantung pada versi PostgreSQL. Dalam versi sebelum 16, setiap UPDATE dan DELETE pada tabel tersebut memaksa pekerja apply untuk melakukan pemindaian sekuensial dari seluruh tabel untuk menemukan baris yang cocok. Di versi 16 dan yang lebih baru, PostgreSQL akan menggunakan indeks yang sesuai jika tersedia, tetapi jika tidak ada indeks yang memenuhi syarat, pekerja terapkan masih kembali ke pemindaian berurutan. Sementara pekerja terapkan memindai tabel besar untuk satu baris, semua perubahan tertunda lainnya di semua tabel mengantri dan menunggu.

Konsekuensi untuk blue/green penyebaran sangat signifikan:

Untuk menghindari masalah ini, pastikan bahwa semua tabel memiliki kunci utama atau indeks unik yang sesuai yang secara eksplisit dikonfigurasi sebagai identitas replika yang digunakan ALTER TABLE ... REPLICA IDENTITY USING INDEX sebelum membuat penerapan. blue/green Jangan mengandalkan REPLICA IDENTITY FULL pemilihan indeks implisit di PostgreSQL 16+, karena pelanggan mungkin memilih indeks selektif yang buruk atau kembali ke pemindaian berurutan. Uji penerapan dengan beban kerja tulis yang representatif untuk mengonfirmasi bahwa lingkungan hijau dapat mengikuti.

Untuk informasi selengkapnya tentang batasan blue/green penerapan, lihatKeterbatasan dan pertimbangan untuk penerapan Amazon RDS Amazon blue/green. Untuk praktik terbaik, lihat RDS untuk PostgreSQL praktik terbaik untuk penerapan blue/green.

Cara mengidentifikasi tabel menggunakan REPLICA IDENTITY FULL

Jalankan kueri berikut untuk menemukan semua tabel denganREPLICA IDENTITY FULL:

SELECT n.nspname AS schema, c.relname AS table_name, c.relreplident
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
  AND c.relreplident = 'f'
  AND n.nspname NOT IN ('pg_catalog', 'information_schema')
ORDER BY n.nspname, c.relname;

Nilai relreplident kolom adalah:

Solusi dan praktik terbaik

Tambahkan kunci utama sedapat mungkin

Solusi paling efektif adalah menambahkan kunci utama ke tabel yang tidak memiliki satu. Ketika kunci utama ada, PostgreSQL menggunakannya sebagai identitas replika default, yang menyediakan pencarian baris yang efisien pada pelanggan dan meminimalkan overhead WAL pada penerbit.

ALTER TABLE my_table ADD COLUMN id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY;

Jika menambahkan kunci primer tidak layak karena kendala aplikasi, pertimbangkan untuk menambahkan indeks unik pada sekumpulan NOT NULL kolom dan mengaturnya sebagai identitas replika:

CREATE UNIQUE INDEX my_table_replica_idx ON my_table (col1, col2);
ALTER TABLE my_table REPLICA IDENTITY USING INDEX my_table_replica_idx;

Jangan mengandalkan pemilihan indeks implisit (PostgreSQL 16+)

Dimulai dengan PostgreSQL 16, pekerja aplikasi pelanggan dapat menggunakan btree atau indeks hash untuk pencarian baris ketika identitas replika disetel FULL ke, bahkan jika indeks tersebut tidak secara eksplisit dikonfigurasi sebagai identitas replika. Meskipun ini mencegah pemindaian berurutan dalam beberapa kasus, mengandalkan perilaku implisit ini adalah anti-pola karena alasan berikut:

Sebagai gantinya, konfigurasikan identitas replika secara eksplisit untuk setiap tabel yang direplikasi:

Cadangan REPLICA IDENTITY FULL hanya untuk tabel di mana tidak ada opsi yang layak, dan pahami bahwa kinerja bergantung pada faktor-faktor di luar kendali langsung Anda.

Memantau kelambatan replikasi

Saat menggunakanREPLICA IDENTITY FULL, pantau kelambatan replikasi dengan cermat untuk mendeteksi pelambatan penerapan pelanggan sebelum menjadi kritis.

Pada penerbit, periksa jeda antara posisi WAL saat ini dan apa yang telah dikonfirmasi pelanggan:

SELECT slot_name, confirmed_flush_lsn, pg_current_wal_lsn(),
       (pg_current_wal_lsn() - confirmed_flush_lsn) AS lag_bytes
FROM pg_replication_slots
WHERE slot_type = 'logical';

lag_bytesNilai yang terus meningkat menunjukkan pelanggan tertinggal. pg_stat_replication_slotsTampilan memberikan statistik tambahan tentang penggunaan setiap slot replikasi.

Pada pelanggan, pg_stat_subscription tampilan menunjukkan status setiap pekerja yang mendaftar, termasuk lokasi WAL terakhir yang diterima dan dilaporkan:

SELECT subname, received_lsn, latest_end_lsn,
       last_msg_send_time, last_msg_receipt_time
FROM pg_stat_subscription;

Kesenjangan besar antara received_lsn danlatest_end_lsn, atau stempel waktu basilast_msg_send_time, dapat mengindikasikan pekerja lamaran sedang berjuang untuk mengikutinya. pg_stat_subscription_statsTampilan juga melacak kesalahan dan konflik terapan yang mungkin menyebabkan kelambatan.

Untuk , Anda juga dapat memantau metrik, yang melacak lag dalam byte dari slot replikasi paling OldestReplicationSlotLag CloudWatch belakang. Nilai yang meningkat adalah tanda peringatan dini kelambatan replikasi.

Memeriksa tabel mana yang mungkin menggunakan indeks sub-optimal selama penerapan

Pada pelanggan, Anda dapat mengidentifikasi tabel tempat pekerja terapkan melakukan pembacaan heap yang berlebihan, yang dapat menunjukkan bahwa tabel tidak memiliki indeks yang efisien untuk pencarian baris selama penerapan. Jalankan kueri berikut pada pelanggan:

SELECT relname, heap_blks_read, heap_blks_hit,
       idx_blks_read, idx_blks_hit,
       heap_blks_read + heap_blks_hit AS total_heap_access
FROM pg_statio_user_tables
WHERE heap_blks_read > 0
ORDER BY heap_blks_read DESC
LIMIT 10;

Tabel dengan heap_blks_read nilai relatif tinggi idx_blks_read dapat menunjukkan bahwa pekerja terapan tidak menggunakan indeks yang efisien untuk menemukan baris UPDATE dan DELETE operasi. Ini adalah sumber umum kelambatan replikasi saat REPLICA IDENTITY FULL digunakan.

Evaluasi apakah REPLICA IDENTITY FULL diperlukan

Sebelum mengaturREPLICA IDENTITY FULL, pertimbangkan apakah Anda benar-benar membutuhkannya. Alasan umum untuk menggunakannya meliputi:

Jika satu-satunya alasan Anda adalah kurangnya kunci utama, menambahkannya hampir selalu merupakan jalan yang lebih baik. Jika Anda memerlukan gambar sebelumnya lengkap untuk CDC, pertimbangkan apakah konsumen CDC Anda dapat merekonstruksi baris penuh dengan mempertahankan status secara eksternal, yang menghindari WAL dan overhead pelanggan. REPLICA IDENTITY FULL

Ringkasan rekomendasi