Pilih preferensi cookie Anda

Kami menggunakan cookie penting serta alat serupa yang diperlukan untuk menyediakan situs dan layanan. Kami menggunakan cookie performa untuk mengumpulkan statistik anonim sehingga kami dapat memahami cara pelanggan menggunakan situs dan melakukan perbaikan. Cookie penting tidak dapat dinonaktifkan, tetapi Anda dapat mengklik “Kustom” atau “Tolak” untuk menolak cookie performa.

Jika Anda setuju, AWS dan pihak ketiga yang disetujui juga akan menggunakan cookie untuk menyediakan fitur situs yang berguna, mengingat preferensi Anda, dan menampilkan konten yang relevan, termasuk iklan yang relevan. Untuk menerima atau menolak semua cookie yang tidak penting, klik “Terima” atau “Tolak”. Untuk membuat pilihan yang lebih detail, klik “Kustomisasi”.

Preferensi
Hubungi Kami
Umpan Balik
AWS Documentation
Buat Akun AWS

Pemecahan Masalah PostgreSQL Endpoint

PDF
RSS
Mode fokus
Pemecahan Masalah PostgreSQL Endpoint - AWS Layanan Migrasi Database
Transaksi jangka panjang pada sumberBeban kerja yang tinggi pada sumbernyaThroughput jaringan tinggiMenumpahkan file di Aurora PostgreSQL

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

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

Bagian ini berisi skenario replikasi khusus untuk PostgreSQL.

Transaksi jangka panjang pada sumber

Ketika ada transaksi jangka panjang dalam database sumber, seperti beberapa ribu sisipan dalam satu transaksi, peristiwa DMS CDC dan penghitung transaksi tidak meningkat sampai transaksi selesai. Penundaan ini dapat menyebabkan masalah latensi yang dapat Anda ukur menggunakan CDCLatencyTarget metrik.

Untuk meninjau transaksi jangka panjang, lakukan salah satu hal berikut:

  • Gunakan pg_replication_slots tampilan. Jika restart_lsn nilai tidak diperbarui, kemungkinan PostgreSQL tidak dapat merilis Write Ahead Logs WALs () karena transaksi aktif yang berjalan lama. Untuk informasi tentang pg_replication_slots tampilan, lihat pg_replication_slots di Dokumentasi PostgreSQL 15.4.

  • Gunakan kueri berikut untuk mengembalikan daftar semua kueri aktif dalam database, bersama dengan informasi terkait: 

    SELECT pid, age(clock_timestamp(), query_start), usename, query 
FROM pg_stat_activity WHERE query != '<IDLE>' 
AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;

    Dalam hasil kueri, age bidang menunjukkan durasi aktif setiap kueri, yang dapat Anda gunakan untuk mengidentifikasi kueri yang berjalan lama.

Beban kerja yang tinggi pada sumbernya

Jika PostgreSQL sumber Anda memiliki beban kerja yang tinggi, periksa hal berikut untuk mengurangi latensi:

  • Anda mungkin mengalami latensi tinggi saat menggunakan test_decoding plugin saat memigrasikan subset tabel dari database sumber dengan nilai transaksi per detik (TPS) tinggi. Ini karena test_decoding plugin mengirimkan semua perubahan database ke contoh replikasi yang kemudian difilter DMS, berdasarkan pemetaan tabel tugas. Peristiwa untuk tabel yang bukan bagian dari pemetaan tabel tugas dapat meningkatkan latensi sumber.

  • Periksa throughput TPS menggunakan salah satu metode berikut.

    • Untuk sumber Aurora PostgreSQL, gunakan metrik. CommitThroughput CloudWatch

    • Untuk PostgreSQL yang berjalan di Amazon RDS atau lokal, gunakan kueri berikut menggunakan klien PSQL versi 11 atau yang lebih tinggi enter (Tekan selama kueri untuk memajukan hasil):

      SELECT SUM(xact_commit)::numeric as temp_num_tx_ini FROM pg_stat_database; \gset
select pg_sleep(60);
SELECT SUM(xact_commit)::numeric as temp_num_tx_final FROM pg_stat_database; \gset
select (:temp_num_tx_final - :temp_num_tx_ini)/ 60.0 as "Transactions Per Second";

  • Untuk mengurangi latensi saat menggunakan test_decoding plugin, pertimbangkan untuk menggunakan pglogical plugin sebagai gantinya. Berbeda dengan test_decoding plugin, filter pglogical plugin write ahead log (WAL) berubah di sumbernya, dan hanya mengirimkan perubahan yang relevan ke instance replikasi. Untuk informasi tentang menggunakan pglogical plugin dengan AWS DMS, lihatMengonfigurasi plugin pglogical.

Throughput jaringan tinggi

Replikasi Anda mungkin memiliki penggunaan bandwidth jaringan yang tinggi saat menggunakan test_decoding plugin, terutama selama transaksi volume tinggi. Ini karena test_decoding plugin memproses perubahan, dan mengubahnya menjadi format yang dapat dibaca manusia yang lebih besar dari format biner asli.

Untuk meningkatkan kinerja, pertimbangkan untuk menggunakan pglogical plugin sebagai gantinya, yang merupakan plugin biner. Berbeda dengan test_decoding plugin, pglogical plugin menghasilkan output format biner, menghasilkan perubahan aliran write ahead log (WAL) terkompresi.

Menumpahkan file di Aurora PostgreSQL

Dalam PostgreSQL versi 13 dan lebih tinggi, parameter menentukan alokasi memori logical_decoding_work_mem untuk decoding dan streaming. Untuk informasi selengkapnya tentang logical_decoding_work_mem parameter, lihat Konsumsi Sumber Daya di PostgreSQL di Dokumentasi PostgreSQL 13.13.

Replikasi logis mengakumulasi perubahan untuk semua transaksi dalam memori sampai transaksi tersebut dilakukan. Jika jumlah data yang disimpan di semua transaksi melebihi jumlah yang ditentukan oleh parameter databaselogical_decoding_work_mem, maka DMS menumpahkan data transaksi ke disk untuk melepaskan memori untuk data decoding baru.

Transaksi yang berjalan lama, atau banyak subtransaksi, dapat mengakibatkan DMS mengkonsumsi memori decoding logis yang meningkat. Peningkatan penggunaan memori ini menghasilkan DMS membuat file tumpahan pada disk, yang menyebabkan latensi sumber tinggi selama replikasi.

Untuk mengurangi dampak peningkatan beban kerja sumber, lakukan hal berikut:

  • Kurangi transaksi yang berjalan lama.

  • Mengurangi jumlah sub-transaksi.

  • Hindari melakukan operasi yang menghasilkan ledakan besar catatan log, seperti menghapus atau memperbarui seluruh tabel dalam satu transaksi. Lakukan operasi dalam batch yang lebih kecil sebagai gantinya.

Anda dapat menggunakan CloudWatch metrik berikut untuk memantau beban kerja pada sumbernya:

  • TransactionLogsDiskUsage: Jumlah byte yang saat ini ditempati oleh WAL logis. Nilai ini meningkat secara monoton jika slot replikasi logis tidak dapat mengikuti laju penulisan baru, atau jika ada transaksi yang berjalan lama mencegah pengumpulan sampah file lama.

  • ReplicationSlotDiskUsage: Jumlah ruang disk yang digunakan slot replikasi logis saat ini.

Anda dapat mengurangi latensi sumber dengan menyetel parameter. logical_decoding_work_mem Nilai default untuk parameter ini adalah 64 MB. Parameter ini membatasi jumlah memori yang digunakan oleh setiap koneksi replikasi streaming logis. Kami merekomendasikan pengaturan logical_decoding_work_mem nilai secara signifikan lebih tinggi daripada work_mem nilai untuk mengurangi jumlah perubahan yang diterjemahkan yang ditulis DMS ke disk.

Kami menyarankan Anda memeriksa file tumpahan secara berkala, terutama selama periode aktivitas migrasi berat atau latensi. Jika DMS membuat sejumlah besar file tumpahan, ini berarti bahwa decoding logis tidak beroperasi secara efisien, yang dapat meningkatkan latensi. Untuk mengurangi ini, tingkatkan nilai logical_decoding_work_mem parameter.

Anda dapat memeriksa overflow transaksi saat ini dengan aurora_stat_file fungsi tersebut. Untuk informasi selengkapnya, lihat Menyesuaikan memori kerja untuk decoding logis di Panduan Pengembang Layanan Amazon Relational Database Service.

Di halaman ini

PrivasiSyarat situsPreferensi cookie
© 2025, Amazon Web Services, Inc. atau afiliasinya. Semua hak dilindungi undang-undang.