Cara menangani latensi pada tugas inkremental DTS - Data Transmission Service

Topik ini menjelaskan penyebab umum latensi tinggi pada tugas migrasi atau sinkronisasi data inkremental Layanan Transmisi Data (Data Transmission Service/DTS) dan menyediakan solusinya. Anda dapat menyelidiki penyebab tersebut untuk mengidentifikasi dan mengatasi masalah latensi.

Masalah

Tugas migrasi atau sinkronisasi inkremental DTS mengalami latensi lebih dari 1.000 milidetik.

Kemungkinan penyebab

Penyebab 1: Spesifikasi instans tidak mencukupi untuk beban kerja. Setiap instans DTS untuk migrasi atau sinkronisasi data inkremental memiliki batas RPS (records per second) tertentu. Jika beban tulis pada database sumber terlalu tinggi—misalnya karena transaksi besar—tugas tersebut mungkin mengalami throttle, sehingga menyebabkan latensi.

Anda dapat memeriksa alur data tugas atau menggunakan fitur Quick Diagnostics untuk menentukan apakah instans telah mencapai batas spesifikasinya. Untuk informasi selengkapnya, lihat Monitor task performance, Specifications of data synchronization instances, dan Specifications of data migration instances.
Penyebab 2: Spesifikasi instans tujuan tidak mencukupi. Performa tulis instans database tujuan telah mencapai bottleneck.

Sebagai contoh, jika tujuannya adalah instans ApsaraDB RDS for MySQL, Anda dapat memeriksa metrik pemanfaatan sumber daya seperti CPU, memori, dan I/O pada halaman Monitoring and Alerts di Konsol ApsaraDB RDS. Bandingkan metrik tersebut dengan spesifikasi instans untuk melihat apakah performanya telah mencapai batas. Untuk informasi selengkapnya, lihat View monitoring information dan ApsaraDB RDS for MySQL instance types.
Penyebab 3: Pembaruan hotspot memengaruhi performa. Pembaruan pada tabel tanpa primary key atau pembaruan berulang pada satu tabel atau baris tertentu di database sumber dapat menyebabkan pembaruan hotspot.

Sebagai contoh, jika sumbernya adalah instans ApsaraDB RDS for MySQL, Anda dapat menggunakan fitur SQL Explorer and Audit untuk memeriksa transaksi dan mengidentifikasi apakah terjadi pembaruan hotspot, seperti transaksi yang terkonsentrasi pada tabel tertentu. Untuk informasi selengkapnya, lihat SQL Explorer and Audit.
Penyebab 4: Performa baca database sumber telah mencapai bottleneck, atau lebar pita jaringannya telah jenuh.

Sebagai contoh, jika sumbernya adalah instans ApsaraDB RDS for MySQL, Anda dapat memeriksa metrik seperti IOPS pada halaman Monitoring and Alerts di Konsol ApsaraDB RDS. Bandingkan metrik tersebut dengan spesifikasi instans untuk melihat apakah performanya telah mencapai batas. Untuk informasi selengkapnya, lihat View monitoring information dan ApsaraDB RDS for MySQL instance types.
Penyebab 5: Ketika DTS tidak dapat terhubung ke database atau gagal menulis data ke database tujuan karena error lain, DTS melakukan beberapa kali retry, sehingga menyebabkan latensi sinkronisasi. Anda dapat memeriksa apakah status tugas di konsol adalah Retrying. Klik Troubleshoot untuk melihat penyebab dan menyelesaikan masalah tersebut.

Sebagai contoh, jika database tujuan adalah instans AnalyticDB for MySQL dan Anda menjalankan operasi DDL untuk mengubah tipe kolom di database sumber, tugas sinkronisasi DTS mengalami latensi dan masuk ke status Retrying. Hal ini terjadi karena instans tujuan AnalyticDB for MySQL tidak mendukung perubahan tipe kolom. DTS berulang kali mencoba menerapkan operasi DDL tersebut, tetapi upaya tersebut gagal, sehingga menyebabkan latensi.
Penyebab 6: Database tujuan memiliki trigger, yang dapat menyebabkan latensi signifikan.
Untuk database MySQL, Anda dapat menggunakan perintah berikut untuk memeriksa adanya trigger:
```
select * from information_schema.triggers where trigger_schema='<database_name>';
```
Penyebab 7: Jika tabel yang disinkronkan ke database tujuan memiliki skema kompleks—seperti memiliki primary key dan unique key sekaligus—dan layanan selain DTS juga menulis ke database tujuan, maka lock tabel dan kueri SQL lambat dapat terjadi di database tujuan.
Penyebab 8: Sejumlah besar operasi DDL sedang berjalan di database sumber.

Sebagai contoh, jika sumbernya adalah instans ApsaraDB RDS for MySQL, Anda dapat menggunakan SQL Explorer and Audit untuk memeriksa eksekusi pernyataan DDL dan menentukan apakah volume operasi DDL sangat tinggi. Untuk informasi selengkapnya, lihat SQL Explorer and Audit.
Penyebab 9: Transmisi data jarak jauh menyebabkan latensi jaringan.

Anda dapat memeriksa wilayah database sumber dan tujuan pada halaman daftar tugas.
Penyebab 10: Skema tabel di database sumber dan tujuan tidak sesuai.
Penyebab 11: Nilai latensi yang ditampilkan di konsol mungkin mengalami keterlambatan.

Solusi

Solusi 1: Tingkatkan spesifikasi instans untuk tugas migrasi atau sinkronisasi data inkremental guna meningkatkan performa. Untuk informasi selengkapnya, lihat Upgrade a DTS instance.
Solusi 2: Tingkatkan spesifikasi instans database tujuan untuk meningkatkan performa tulisnya.

Untuk instans ApsaraDB RDS for MySQL, lihat Change instance specifications untuk meng-upgrade konfigurasinya.
Solusi 3: Jika terjadi pembaruan hotspot, tunggu hingga selesai. Atau, pertimbangkan untuk mendesain ulang logika aplikasi agar menghindari pembaruan hotspot.
Solusi 4: Tingkatkan performa instans database sumber atau upgrade lebar pita jaringannya.

Untuk instans ApsaraDB RDS for MySQL, lihat Change instance specifications untuk meng-upgrade konfigurasinya.
Solusi 5: Periksa pesan error spesifik di konsol dan selesaikan masalah tersebut sesuai petunjuk.

Jika DTS gagal menerapkan operasi DDL pada tujuan AnalyticDB for MySQL, selesaikan masalah tersebut dengan terlebih dahulu menghapus tabel yang mengalami kegagalan operasi DDL dari objek sinkronisasi. Setelah latensi turun menjadi nol, hapus tabel yang sesuai di database tujuan. Terakhir, tambahkan kembali tabel tersebut ke objek sinkronisasi. Untuk informasi selengkapnya, lihat Data synchronization FAQ dan Modify synchronization objects.
Solusi 6: Hapus atau nonaktifkan trigger di database tujuan.

Untuk database MySQL, gunakan perintah DROP TRIGGER [ IF EXISTS ] [database_name] <trigger_name>; untuk menghapus trigger.

Catatan
Jika database sumber memiliki Pemicu, lihat Mengonfigurasi Tugas DTS jika database sumber memiliki Pemicu untuk mengonfigurasi Tugas DTS.
Solusi 7: Periksa status lock, kueri SQL lambat, dan skema tabel di database tujuan. Sesuaikan operasi tulis atau skema untuk mengatasi lock tulis dan kueri SQL lambat.
Contoh berikut untuk database MySQL menunjukkan cara memeriksa status lock, kueri SQL lambat, dan skema tabel, lalu cara menyelesaikan masalahnya.
- Status lock dan kueri SQL lambat: Jalankan SHOW PROCESSLIST; untuk menemukan proses yang menyebabkan lock atau kueri lambat. Kemudian, jalankan KILL [CONNECTION | QUERY] thread_id untuk menghentikan proses tersebut.
- Skema tabel: Jalankan show create table <database_name>.<table_name>; untuk melihat skema tabel. Jika terdapat unique key, evaluasi apakah unique key tersebut diperlukan untuk bisnis Anda. Jika tidak, jalankan alter table <database_name>.<table_name> drop index <unique_key_name>; di database tujuan untuk menghapusnya.
Solusi 8: Jika tugas DTS berjalan dengan sukses, hindari menjalankan operasi DDL secara massal di database sumber. Jika operasi DDL diperlukan, jalankan pada jam sepi.

Catatan
Saat mengonfigurasi tugas, jangan pilih operasi DDL yang tidak perlu disinkronkan.
Solusi 9: Untuk mengurangi latensi jaringan akibat transmisi jarak jauh yang tidak dapat dihindari, gunakan Express Connect untuk menghubungkan instans database sumber dan tujuan.
Solusi 10: Sesuaikan skema tabel agar konsisten antara database sumber dan tujuan.
Solusi 11: Tunggu beberapa menit dan refresh konsol.

Referensi

Untuk solusi tugas data penuh yang lambat, lihat Troubleshoot slow or stuck full data migration.