Type | Description |
Batasan database sumber | Kebutuhan bandwidth: Server yang menghosting database sumber harus memiliki bandwidth outbound yang mencukupi. Jika tidak, kecepatan migrasi akan turun. Setiap tabel yang akan dimigrasikan harus memiliki primary key atau UNIQUE constraint, dan kolom kuncinya harus berisi nilai unik. Jika tidak, catatan duplikat mungkin muncul di database tujuan. Jika Anda memilih tabel sebagai objek migrasi dan mengeditnya—misalnya dengan memetakan nama kolom—satu tugas migrasi mendukung hingga 1.000 tabel. Jika melebihi batas ini, tugas akan gagal dengan error saat dikirimkan. Untuk mengatasinya, bagi tabel tersebut ke beberapa tugas atau konfigurasikan tugas migrasi seluruh database. Jika Anda memerlukan migrasi inkremental, aktifkan binary logging: Atur binlog_format ke ROW dan binlog_row_image ke FULL. Jika tidak, pemeriksaan awal gagal dan tugas tidak dapat dimulai.
Penting Jika sumber MySQL yang dikelola sendiri Anda adalah kluster dual-master—di mana setiap instans bertindak sebagai master dan slave—aktifkan parameter log_slave_updates. Ini memastikan DTS dapat membaca semua log biner. Untuk instans RDS for MySQL, simpan log biner lokal minimal tiga hari (tujuh hari direkomendasikan). Untuk database MySQL yang dikelola sendiri, simpan log biner lokal minimal tujuh hari. Jika DTS tidak dapat mengakses log biner, tugas akan gagal. Dalam kasus ekstrem, ketidakkonsistenan data atau kehilangan data dapat terjadi. Masalah yang disebabkan oleh periode retensi log biner lebih pendek dari yang dipersyaratkan DTS tidak dicakup dalam SLA DTS.
Operasi yang tidak diizinkan pada database sumber: Jangan menjalankan operasi DDL yang mengubah skema database atau tabel selama migrasi skema atau migrasi penuh. Jika dilakukan, tugas migrasi akan gagal.
Catatan Selama migrasi penuh, DTS melakukan query ke database sumber. Hal ini membuat metadata lock yang dapat memblokir operasi DDL pada database sumber. Jangan menjalankan operasi DDL yang menambahkan komentar—seperti ALTER TABLE table_name COMMENT='Table comment';. Jika dilakukan, tugas migrasi akan gagal. Jika Anda hanya menjalankan migrasi penuh, jangan menulis data baru ke instans sumber. Jika dilakukan, data sumber dan tujuan menjadi tidak konsisten. Untuk menjaga konsistensi data secara real time, pilih migrasi skema, migrasi penuh, dan migrasi inkremental.
DTS tidak memigrasikan data yang dihasilkan oleh perubahan yang tidak ditulis ke log biner. Contohnya termasuk data yang dipulihkan dari backup fisik atau dibuat oleh operasi kaskade.
Catatan Jika hal ini terjadi, jalankan ulang migrasi penuh setelah bisnis Anda mengizinkannya. Jika database sumber MySQL Anda versi 8.0.23 atau lebih baru dan berisi kolom tersembunyi tak terlihat, DTS tidak dapat membaca kolom tersebut. Hal ini dapat menyebabkan kehilangan data.
Catatan Jalankan ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; untuk membuat kolom tersembunyi menjadi terlihat. Untuk informasi lebih lanjut, lihat Invisible Columns. Kompatibilitas MySQL: Saat DTS memigrasikan data dari database sumber keluarga MySQL, DTS mengandalkan protokol MySQL standar dan format Binlog, serta tidak mendukung perilaku yang tidak kompatibel dengan MySQL standar. Jika database sumber Anda mengklaim kompatibel dengan MySQL tetapi berperilaku berbeda dari MySQL (misalnya, saat OceanBase dihubungkan sebagai sumber dalam mode MySQL, timestamp event rotate trailing di Binlog bernilai 0, yang berbeda dari MySQL), tugas migrasi DTS mungkin gagal.
|
Batasan lainnya | Indeks awalan tidak didukung. Jika database sumber Anda berisi indeks awalan, migrasi mungkin gagal. DTS tidak mendukung migrasi objek INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER, atau FK. Jika database sumber Anda menggunakan operasi DDL Online dalam mode temporary-table—termasuk skenario penggabungan multi-tabel—atau menambahkan indeks berbasis fungsi ke kolom kunci unik, kehilangan data atau kegagalan tugas dapat terjadi di database tujuan. Jika terjadi konflik primary key atau unique key selama migrasi: Jika skema tabel konsisten dan catatan di database tujuan memiliki nilai primary key yang sama dengan catatan di database sumber: Selama migrasi penuh, DTS menyimpan catatan di database tujuan. Catatan dari database sumber tidak dimigrasikan. Selama migrasi inkremental, DTS tidak menyimpan catatan di database tujuan. Catatan dari database sumber menimpa catatan di database tujuan.
Jika skema tabel tidak konsisten, hanya sebagian kolom data yang mungkin dimigrasikan, atau migrasi dapat gagal. Lakukan dengan hati-hati.
Database tujuan harus memiliki primary key kustom. Atau, pada langkah Configurations for Databases, Tables, and Columns, atur Primary Key Column. Jika tidak, migrasi mungkin gagal. Karena batasan bawaan AnalyticDB for MySQL, jika penggunaan ruang disk pada node melebihi 80%, tugas DTS menjadi abnormal dan mengalami penundaan. Perkirakan ruang yang diperlukan terlebih dahulu berdasarkan objek yang akan dimigrasikan, dan pastikan kluster tujuan memiliki ruang penyimpanan yang cukup. -
Jika kluster AnalyticDB for MySQL 3.0 tujuan sedang melakukan backup saat tugas DTS berjalan, tugas akan gagal.
Sebelum migrasi, evaluasi performa database sumber dan tujuan. Jalankan migrasi di luar jam sibuk bisnis. Jika tidak, migrasi penuh akan mengonsumsi sumber daya baca dan tulis di kedua database serta meningkatkan beban database. Migrasi penuh menjalankan operasi INSERT secara konkuren. Hal ini menyebabkan fragmentasi tabel tujuan. Setelah migrasi penuh, tabel tujuan memerlukan ruang penyimpanan lebih besar daripada tabel sumber. Konfirmasi bahwa presisi migrasi DTS untuk kolom FLOAT atau DOUBLE memenuhi kebutuhan bisnis Anda. DTS membaca kolom-kolom ini menggunakan ROUND(COLUMN,PRECISION). Jika tidak ada presisi yang didefinisikan, DTS menggunakan 38 digit untuk FLOAT dan 308 digit untuk DOUBLE. DTS mencoba memulihkan tugas yang gagal dalam waktu tujuh hari. Sebelum mengalihkan traffic ke instans tujuan, akhiri atau rilis tugas tersebut. Atau jalankan perintah revoke untuk mencabut izin tulis DTS pada akun instans tujuan. Hal ini mencegah pemulihan otomatis menimpa data tujuan dengan data sumber. Jika penulisan DDL gagal di database tujuan, tugas DTS tetap berjalan. Periksa pernyataan DDL yang gagal di log tugas. Untuk petunjuknya, lihat Lihat log tugas. Jika instans RDS for MySQL Anda memiliki Always-Encrypted diaktifkan, migrasi penuh tidak didukung.
Catatan Instans RDS for MySQL dengan Transparent Data Encryption (TDE) yang diaktifkan mendukung migrasi skema, migrasi penuh, dan migrasi inkremental. -
Jika suatu tugas gagal, staf dukungan DTS akan mencoba memulihkannya dalam waktu delapan jam. Selama pemulihan, mereka mungkin merestart tugas atau menyesuaikan parameternya.
Catatan
Hanya parameter tugas DTS yang dimodifikasi—bukan parameter database. Parameter yang mungkin disesuaikan termasuk yang tercantum dalam Modifikasi parameter instans.
|
Kasus khusus | Untuk sumber MySQL yang dikelola sendiri: Alih bencana master–standby pada database sumber menyebabkan tugas migrasi gagal. DTS menghitung latensi dengan membandingkan timestamp catatan terakhir yang dimigrasikan ke database tujuan dengan waktu saat ini. Jika tidak ada operasi DML yang dijalankan di sumber dalam waktu lama, pelaporan latensi menjadi tidak akurat. Jika latensi tampak terlalu tinggi, jalankan operasi DML di sumber untuk memperbarui nilai latensi.
Catatan Jika Anda memilih migrasi seluruh database, buat tabel heartbeat. Perbarui atau tulis ke tabel tersebut setiap detik. DTS secara berkala menjalankan CREATE DATABASE IF NOT EXISTS `test` pada database sumber untuk memajukan offset log biner. Jika sumber Anda adalah Amazon Aurora MySQL atau instans MySQL berkluster lainnya, pastikan nama domain atau alamat IP yang dikonfigurasi untuk tugas—dan resolusi DNS-nya—selalu mengarah ke node read–write (RW). Jika tidak, tugas migrasi mungkin gagal.
Untuk sumber RDS for MySQL: Jika Anda memerlukan migrasi inkremental, instans RDS for MySQL yang tidak mencatat log transaksi—seperti instans hanya baca RDS for MySQL 5.6—tidak didukung sebagai sumber. DTS secara berkala menjalankan CREATE DATABASE IF NOT EXISTS `test` pada database sumber untuk memajukan offset log biner.
|