Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Pemecahan Masalah PostgreSQL Endpoint
Bagian ini berisi skenario replikasi khusus untuk PostgreSQL.
**Topics**
+ [Transaksi jangka panjang pada sumber](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Longrunning)
+ [Beban kerja yang tinggi pada sumbernya](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highworkload)
+ [Throughput jaringan tinggi](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highnetwork)
+ [Menumpahkan file di Aurora PostgreSQL](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill)
## 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\$1replication\$1slots](https://www.postgresql.org/docs/15/view-pg-replication-slots.html) di Dokumentasi PostgreSQL 15.4.](https://www.postgresql.org/docs/15/)
+ 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 != ''
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, lihat[Mengonfigurasi plugin pglogical](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security.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](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM) PostgreSQL 13.13.](https://www.postgresql.org/docs/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 database`logical_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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.html#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem) di Panduan Pengembang Layanan *Amazon Relational Database Service*.