Cara mengatasi latensi tinggi pada tugas inkremental DTS - Data Transmission Service

Latensi di atas 1.000 milidetik selama migrasi data inkremental atau sinkronisasi umumnya menunjukkan adanya bottleneck sumber daya pada instans DTS, database sumber, atau database tujuan. Telusuri penyebab berikut secara berurutan. Setiap bagian menjelaskan cara mengonfirmasi penyebab dan langkah penanganannya.

Pemeriksaan cepat terlebih dahulu: Jika latensi muncul secara tiba-tiba dan tidak ada perubahan lain, periksa Penyebab 11 terlebih dahulu — tampilan konsol DTS bisa tertinggal dari status replikasi aktual.

Penyebab 1: Batas RPS instans DTS tercapai

Instans migrasi data dan instans sinkronisasi data masing-masing memiliki batas records per second (RPS). Jika volume tulis dari database sumber mencapai batas tersebut, latensi akan meningkat. Transaksi besar merupakan pemicu umum.

Cara mengonfirmasi: Di Konsol DTS, periksa volume data yang terlibat dalam tugas, atau klik Quick Diagnostics untuk melihat apakah batas RPS instans saat ini telah tercapai. Lihat Pantau kinerja tugas, Spesifikasi instans sinkronisasi data, dan Spesifikasi instans migrasi data.

Perbaikan: Upgrade instans migrasi data atau instans sinkronisasi data. Lihat Upgrade instans DTS.

Penyebab 2: Bottleneck tulis pada database tujuan

Jika instans database tujuan tidak memiliki kapasitas memadai, kinerja tulisnya menjadi bottleneck.

Cara mengonfirmasi: Untuk tujuan ApsaraDB RDS for MySQL, periksa utilisasi CPU, penggunaan memori, dan beban I/O pada halaman Monitoring and Alerts di Konsol ApsaraDB RDS. Lihat Lihat informasi pemantauan dan Jenis instans untuk instans ApsaraDB RDS for MySQL primary standar (arsitektur x86 asli).

Perbaikan: Upgrade instans database tujuan. Untuk ApsaraDB RDS for MySQL, lihat Ubah spesifikasi instans.

Penyebab 3: Bottleneck baca pada database sumber atau bandwidth habis

Jika database sumber tidak dapat menyediakan data cukup cepat — karena batas IOPS atau bandwidth jaringan yang jenuh — DTS tertinggal.

Cara mengonfirmasi: Untuk sumber ApsaraDB RDS for MySQL, periksa IOPS dan metrik lainnya pada halaman Monitoring and Alerts di Konsol ApsaraDB RDS. Lihat Lihat informasi pemantauan dan Jenis instans untuk instans ApsaraDB RDS for MySQL primary standar (arsitektur x86 asli).

Perbaikan: Upgrade spesifikasi instans database sumber atau tingkatkan bandwidth jaringannya. Untuk ApsaraDB RDS for MySQL, lihat Ubah spesifikasi instans.

Penyebab 4: Pembaruan hotspot

Tabel tanpa primary key atau pembaruan berulang yang terkonsentrasi pada satu tabel atau baris dapat menciptakan pembaruan hotspot yang memperlambat replikasi.

Cara mengonfirmasi: Untuk sumber ApsaraDB RDS for MySQL, periksa halaman SQL Explorer and Audit di Konsol ApsaraDB RDS untuk melihat apakah transaksi terkonsentrasi pada tabel tertentu. Lihat Gunakan fitur SQL Explorer and Audit.

Perbaikan: Tunggu hingga pembaruan hotspot selesai. Disarankan agar Anda menghindari pembaruan hotspot demi pertimbangan bisnis.

Penyebab 5: DTS mencoba ulang karena kegagalan tulis di tujuan

Jika DTS tidak dapat terhubung ke database tujuan atau mengalami exception saat menulis, DTS akan mencoba ulang berulang kali. Setiap siklus percobaan ulang menambah latensi.

Cara mengonfirmasi: Periksa apakah status tugas adalah Retrying di Konsol DTS, lalu klik Troubleshoot untuk melihat error spesifik.

Contoh skenario: Jika tujuannya adalah instans AnalyticDB for MySQL dan operasi DDL mengubah tipe field di sumber, tujuan tidak dapat menerapkan perubahan tersebut. DTS mencoba ulang berulang kali tanpa keberhasilan, sehingga latensi terus meningkat.

Perbaikan untuk contoh DDL:

Hapus tabel yang terpengaruh oleh operasi DDL dari objek yang akan disinkronkan.
Tunggu hingga latensi sinkronisasi turun menjadi 0 milidetik.
Hapus tabel tersebut dari database tujuan.
Tambahkan kembali tabel tersebut ke objek yang akan disinkronkan.

Lihat FAQ sinkronisasi data dan Modifikasi objek yang akan disinkronkan.

Penyebab 6: Trigger di database tujuan

Trigger pada database tujuan menjalankan logika tambahan untuk setiap baris yang ditulis oleh DTS, sehingga meningkatkan latensi tulis.

Cara mengonfirmasi: Jalankan kueri berikut untuk memeriksa trigger di database tujuan MySQL:

SELECT * FROM information_schema.triggers WHERE trigger_schema='<Database name>';

Perbaikan: Hapus atau nonaktifkan trigger di database tujuan. Untuk menghapus trigger dari database MySQL:

DROP TRIGGER [IF EXISTS] [Database name].<Trigger name>;

Jika database sumber berisi trigger dan Anda perlu mempertahankannya, lihat Konfigurasikan tugas sinkronisasi data untuk database sumber yang berisi trigger.

Penyebab 7: Skema tabel kompleks menyebabkan lock di database tujuan

Jika tabel tujuan memiliki primary key dan unique key sekaligus, serta sistem lain juga menulis ke tabel tersebut secara konkuren dengan DTS, dapat terjadi lock tabel dan kueri SQL lambat.

Cara mengonfirmasi dan memperbaiki (jalankan perintah ini terhadap database tujuan):

Periksa lock dan kueri lambat: Jalankan SHOW PROCESSLIST; untuk mengidentifikasi tabel terkunci atau proses lambat, lalu jalankan KILL [CONNECTION | QUERY] <thread_id> untuk menghentikan proses tersebut.
Periksa skema tabel: Jalankan SHOW CREATE TABLE <Database name>.<Table name>; untuk memeriksa skema. Jika unique key tidak diperlukan, hapuslah:
```
ALTER TABLE <Database name>.<Table name> DROP INDEX <Unique key name>;
```

Penyebab 8: Operasi DDL berlebihan pada database sumber

Menjalankan banyak operasi DDL saat tugas DTS sedang aktif dapat menyebabkan latensi karena DTS harus mereplikasi setiap pernyataan DDL ke tujuan.

Cara mengonfirmasi: Untuk sumber ApsaraDB RDS for MySQL, periksa halaman SQL Explorer and Audit di Konsol ApsaraDB RDS untuk aktivitas DDL. Lihat Gunakan fitur SQL Explorer and Audit.

Perbaikan: Hindari menjalankan banyak operasi DDL pada database sumber saat tugas DTS sedang berjalan. Jika operasi DDL diperlukan, lakukan selama jam sepi.

Saat mengonfigurasi tugas, pilih hanya jenis operasi DDL yang benar-benar perlu disinkronkan oleh tugas tersebut.

Penyebab 9: Latensi jaringan akibat transmisi jarak jauh

Replikasi cross-region memperkenalkan latensi jaringan yang tidak dapat dihilangkan.

Cara mengonfirmasi: Periksa wilayah instans sumber dan tujuan pada halaman Data Migration dan Data Synchronization di Konsol DTS.

Perbaikan: Hubungkan instans sumber dan tujuan melalui Express Connect untuk mengurangi latensi jaringan cross-region.

Penyebab 10: Perbedaan skema antara tabel sumber dan tujuan

Jika tabel sumber dan tujuan memiliki skema berbeda, DTS mungkin perlu mentransformasi data selama replikasi, yang menambah overhead.

Perbaikan: Samakan skema tabel di database sumber dan tujuan sesuai kebutuhan bisnis Anda.

Penyebab 11: Latensi tampilan di Konsol DTS

Nilai latensi yang ditampilkan di Konsol DTS memiliki interval pembaruan singkat. Nilai tinggi yang ditampilkan tidak selalu menunjukkan keterlambatan replikasi data aktual.

Perbaikan: Tunggu beberapa menit dan refresh halaman untuk mendapatkan pembacaan terbaru.

Referensi

Apa yang harus saya lakukan jika tugas migrasi data penuh berhenti atau melambat?