Pemecahan Masalah Postgre SQL Endpoint - AWS Layanan Migrasi Database
Transaksi jangka panjang pada sumberBeban kerja yang tinggi pada sumbernyaThroughput jaringan tinggiMemainkan file di Aurora Postgre SQL

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

Pemecahan Masalah Postgre SQL Endpoint

Bagian ini berisi skenario replikasi khusus untuk SQL Postgre.

Transaksi jangka panjang pada sumber

Ketika ada transaksi jangka panjang dalam database sumber, seperti beberapa ribu sisipan dalam satu transaksi, DMS CDC event dan counter 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 Postgre SQL 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 Postgre 15.4. SQL

  • 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 Postgre sumber Anda SQL 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 yang tinggi. Ini karena test_decoding plugin mengirimkan semua perubahan database ke contoh replikasi yang DMS kemudian menyaring, berdasarkan pemetaan tabel tugas. Peristiwa untuk tabel yang bukan bagian dari pemetaan tabel tugas dapat meningkatkan latensi sumber.

  • Periksa TPS throughput menggunakan salah satu metode berikut.

    • Untuk SQL sumber Aurora Postgre, gunakan metrik. CommitThroughput CloudWatch

    • Untuk Postgre yang SQL berjalan di Amazon RDS atau lokal, gunakan kueri berikut menggunakan PSQL klien versi 11 atau lebih tinggi (Tekan enter 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 menulis perubahan log (WAL) 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.

Memainkan file di Aurora Postgre SQL

Dalam Postgre SQL versi 13 dan lebih tinggi, logical_decoding_work_mem parameter menentukan alokasi memori untuk decoding dan streaming. Untuk informasi selengkapnya tentang logical_decoding_work_mem parameter, lihat Konsumsi Sumber Daya di Postgre SQL di Dokumentasi SQLPostgre 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 tumpahkan data transaksi ke disk untuk melepaskan memori untuk data decoding baru.

Transaksi yang berjalan lama, atau banyak subtransaksi, dapat mengakibatkan DMS konsumsi memori decoding logis yang meningkat. Peningkatan penggunaan memori ini menghasilkan DMS pembuatan 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 logikaWAL. 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 DMS menulis 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.