Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan masalah latensi di AWS Database Migration Service
Bagian ini memberikan gambaran umum tentang penyebab umum latensi AWS DMS tugas selama fase replikasi yang sedang berlangsung (CDC). AWS DMS mereplikasi data secara asinkron. Latensi adalah penundaan antara saat perubahan dilakukan pada sumber dan ketika perubahan direplikasi ke target. Latensi dapat disebabkan karena salah konfigurasi komponen replikasi, seperti berikut ini:
+ Titik akhir sumber atau sumber data
+ Titik akhir target atau sumber data
+ Instans replikasi
+ Jaringan antara komponen-komponen ini
Sebaiknya gunakan migrasi uji sebagai bukti konsep untuk mengumpulkan informasi tentang replikasi Anda. Anda kemudian dapat menggunakan informasi ini untuk menyetel konfigurasi replikasi Anda untuk meminimalkan latensi. Untuk informasi tentang menjalankan bukti migrasi konsep, lihat[Menjalankan bukti konsep](CHAP_BestPractices.md#CHAP_BestPractices.RunPOC).
**Topics**
+ [Jenis latensi CDC](#CHAP_Troubleshooting_Latency_Types)
+ [Penyebab umum latensi CDC](#CHAP_Troubleshooting_Latency_Causes)
+ [Memecahkan masalah latensi](CHAP_Troubleshooting_Latency_Troubleshooting.md)
## Jenis latensi CDC
Bagian ini berisi jenis latensi replikasi yang mungkin terjadi selama CDC.
### Latensi sumber
Penundaan, dalam detik, antara waktu komit peristiwa terakhir yang diambil dari titik akhir sumber, dan stempel waktu sistem saat ini dari instance replikasi. Anda dapat memantau latensi antara sumber data dan instance replikasi menggunakan `CDCLatencySource` CloudWatch metrik. `CDCLatencySource`Metrik tinggi menunjukkan bahwa proses menangkap perubahan dari sumber tertunda. Misalnya, jika aplikasi Anda melakukan penyisipan ke sumber pada pukul 10:00, dan AWS DMS mengkonsumsi perubahan pada 10:02, `CDCLatencySource` metriknya adalah 120 detik.
Untuk informasi tentang CloudWatch metrik untuk AWS DMS, lihat[Metrik tugas replikasi](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task).
### Target latensi
Penundaan, dalam detik, antara waktu komit pada sumber peristiwa pertama yang menunggu untuk berkomitmen ke target, dan stempel waktu instans replikasi DMS saat ini. Anda dapat memantau latensi antara commit pada sumber data dan target data Anda menggunakan `CDCLatencyTarget` CloudWatch metrik. Ini berarti itu `CDCLatencyTarget` termasuk keterlambatan dalam membaca dari sumbernya. Akibatnya, selalu `CDCLatencyTarget` lebih besar dari atau sama dengan`CDCLatencySource`.
Misalnya, jika aplikasi Anda memasukkan sisipan ke sumber pada pukul 10:00, dan AWS DMS mengkonsumsinya pada 10:02 dan menulisnya ke target pada 10:05, metriknya adalah 300 detik. `CDCLatencyTarget`
## Penyebab umum latensi CDC
Bagian ini berisi penyebab latensi yang mungkin dialami replikasi Anda selama CDC.
**Topics**
+ [Sumber daya titik akhir](#CHAP_Troubleshooting_Latency_Causes_Endpoint)
+ [Sumber daya instance replikasi](#CHAP_Troubleshooting_Latency_Causes_Replication_Instance)
+ [Kecepatan jaringan dan bandwidth](#CHAP_Troubleshooting_Latency_Causes_Replication_Network)
+ [Konfigurasi DMS](#CHAP_Troubleshooting_Latency_Causes_Replication_DMS_Config)
+ [Skenario replikasi](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios)
### Sumber daya titik akhir
Faktor-faktor berikut secara signifikan mempengaruhi kinerja replikasi dan latensi:
+ Konfigurasi database sumber dan target
+ Ukuran instans
+ Under-provisioned atau penyimpanan data sumber atau target yang salah konfigurasi
Untuk mengidentifikasi penyebab latensi yang disebabkan oleh masalah titik akhir untuk sumber dan target yang AWS di-host, pantau CloudWatch metrik berikut:
+ `FreeMemory`
+ `CPUUtilization`
+ Throughput dan I/O metrik, seperti`WriteIOPS`,`WriteThroughput`, atau `ReadLatency`
+ Metrik volume transaksi seperti`CDCIncomingChanges`.
Untuk informasi tentang CloudWatch metrik pemantauan, lihat[AWS Database Migration Service metrik](CHAP_Monitoring.md#CHAP_Monitoring.Metrics).
### Sumber daya instance replikasi
Sumber daya instans replikasi sangat penting untuk replikasi, dan Anda harus memastikan bahwa tidak ada hambatan sumber daya, karena dapat menyebabkan latensi sumber dan target.
Untuk mengidentifikasi hambatan sumber daya untuk instance replikasi Anda, verifikasi hal berikut:
+ CloudWatch Metrik penting seperti CPU, Memori, I/O per detik, dan penyimpanan tidak mengalami lonjakan atau nilai tinggi secara konsisten.
+ Ukuran instans replikasi Anda sesuai dengan beban kerja Anda. Untuk informasi tentang menentukan ukuran instans replikasi yang benar, lihat[Memilih ukuran terbaik untuk contoh replikasi](CHAP_BestPractices.SizingReplicationInstance.md).
### Kecepatan jaringan dan bandwidth
Bandwith jaringan adalah faktor yang mempengaruhi transmisi data. Untuk menganalisis kinerja jaringan replikasi Anda, lakukan salah satu hal berikut:
+ Periksa `WriteThroughput` metrik `ReadThroughput` dan di tingkat instance. Untuk informasi tentang CloudWatch metrik pemantauan, lihat[AWS Database Migration Service metrik](CHAP_Monitoring.md#CHAP_Monitoring.Metrics).
+ Gunakan AMI AWS DMS Dukungan Diagnostik. Jika AMI Dukungan Diagnostik tidak tersedia di wilayah Anda, Anda dapat mengunduhnya dari wilayah yang didukung dan menyalinnya ke wilayah Anda untuk melakukan analisis jaringan. Untuk informasi tentang AMI Dukungan Diagnostik, lihat[Bekerja dengan AWS DMS dukungan diagnostik AMI](CHAP_SupportAmi.md).
CDC in AWS DMS adalah single-thread untuk memastikan konsistensi data. Hasilnya, Anda dapat menentukan volume data yang dapat didukung jaringan Anda dengan menghitung kecepatan transfer data single-thread Anda. Misalnya, jika tugas Anda terhubung ke sumbernya menggunakan jaringan 100 Mbps (megabit per detik), replikasi Anda memiliki alokasi bandwidth maksimum teoretis sebesar 12,5 MBps (megabyte per detik). Ini sama dengan 45 gigabit per jam. Jika tingkat pembuatan log transaksi pada sumber lebih besar dari 45 gigabit per jam, ini berarti tugas tersebut memiliki latensi CDC. Untuk jaringan 100 MBps, tarif ini adalah maksimum teoritis; faktor lain seperti lalu lintas jaringan dan overhead sumber daya pada sumber dan target mengurangi bandwidth yang tersedia aktual.
### Konfigurasi DMS
Bagian ini berisi konfigurasi replikasi yang direkomendasikan yang dapat membantu mengurangi latensi.
+ **Pengaturan titik akhir**: Pengaturan titik akhir sumber dan target Anda dapat menyebabkan instans replikasi mengalami kinerja yang buruk. Pengaturan titik akhir yang mengaktifkan fitur padat sumber daya akan memengaruhi kinerja. Misalnya, untuk titik akhir Oracle, menonaktifkan LogMiner dan menggunakan Binary Reader meningkatkan kinerja, karena membutuhkan sumber daya LogMiner yang padat. Pengaturan endpoing berikut meningkatkan kinerja untuk titik akhir Oracle:
```
useLogminerReader=N;useBfile=Y
```
Untuk informasi selengkapnya tentang pengaturan titik akhir, lihat dokumentasi untuk mesin titik akhir sumber dan target Anda dalam [Bekerja dengan AWS Titik akhir DMS](CHAP_Endpoints.md) topik.
+ **Pengaturan tugas**: Beberapa pengaturan tugas untuk skenario replikasi tertentu dapat menyebabkan instans replikasi mengalami kinerja yang buruk. Misalnya, AWS DMS menggunakan mode penerapan transaksional secara default (`BatchApplyEnabled=false`) untuk CDC untuk semua titik akhir kecuali untuk Amazon Redshift. Namun, untuk sumber dengan sejumlah besar perubahan, pengaturan `BatchApplyEnabled` ke `true` dapat meningkatkan kinerja.
Untuk informasi selengkapnya tentang pengaturan tugas, lihat [Menentukan pengaturan tugas untuk AWS Tugas Layanan Migrasi Database](CHAP_Tasks.CustomizingTasks.TaskSettings.md).
+ **Posisi Mulai dari tugas khusus CDC**: Memulai CDC-only tugas dari posisi atau stempel waktu di masa lalu akan memulai tugas dengan peningkatan latensi sumber CDC. Tergantung pada volume perubahan pada sumber, latensi tugas akan membutuhkan waktu untuk mereda.
+ **Pengaturan LOB**: Jenis data Objek Besar dapat menghambat kinerja replikasi karena cara mer AWS DMS eplikasi data biner besar. Untuk informasi selengkapnya, lihat topik berikut:
+ [Menyetel dukungan LOB untuk database sumber di AWS DMS tugas](CHAP_Tasks.LOBSupport.md)
+ [Melakukan migrasi objek biner large (LOB)](CHAP_BestPractices.md#CHAP_BestPractices.LOBS).
### Skenario replikasi
Bagian ini menjelaskan skenario replikasi tertentu dan bagaimana skenario tersebut dapat mempengaruhi latensi.
**Topics**
+ [Menghentikan tugas untuk jangka waktu yang lama](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Stoptask)
+ [Perubahan yang di-cache](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Cachedchanges)
+ [Cross-region replikasi](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Crossregion)
#### Menghentikan tugas untuk jangka waktu yang lama
Saat Anda menghentikan tugas, AWS DMS menyimpan posisi log transaksi terakhir yang dibaca dari sumbernya. Saat Anda melanjutkan tugas, DMS mencoba melanjutkan membaca dari posisi log transaksi yang sama. Melanjutkan tugas setelah beberapa jam atau hari menyebabkan latensi sumber CDC meningkat hingga DMS selesai menggunakan backlog transaksi.
#### Perubahan yang di-cache
**Perubahan cache ** adalah perubahan yang ditulis aplikasi Anda ke sumber data saat AWS DMS menjalankan fase replikasi beban penuh. DMS tidak menerapkan perubahan ini sampai fase beban penuh selesai dan fase CDC dimulai. Untuk sumber dengan jumlah transaksi yang besar, perubahan yang di-cache membutuhkan waktu lebih lama untuk diterapkan, sehingga latensi sumber meningkat saat fase CDC dimulai. Sebaiknya jalankan fase beban penuh saat volume transaksi rendah untuk meminimalkan jumlah perubahan yang di-cache.
#### Cross-region replikasi
Menemukan titik akhir DMS atau instans replikasi Anda di AWS wilayah yang berbeda meningkatkan latensi jaringan. Ini meningkatkan latensi replikasi. Untuk performa terbaik, cari titik akhir sumber, titik akhir target, dan instans replikasi di AWS wilayah yang sama.