Type | Description |
Source database limits | Batasan bandwidth: Server yang menghosting database sumber harus memiliki bandwidth outbound yang mencukupi. Jika tidak, kecepatan migrasi akan terpengaruh. Tabel yang akan dimigrasikan harus memiliki primary key atau kendala UNIQUE, dan field-field tersebut harus unik. Jika tidak, data duplikat mungkin ada di database tujuan. Jika Anda melakukan migrasi data pada level tabel dan perlu mengedit tabel, seperti memetakan nama kolom, satu tugas migrasi data mendukung maksimal 1.000 tabel. Jika melebihi batas ini, kesalahan akan dilaporkan setelah Anda mengirimkan tugas. Dalam kasus ini, pisahkan tabel menjadi beberapa tugas migrasi atau konfigurasikan tugas untuk memigrasikan seluruh database. Jika Anda melakukan migrasi inkremental, perhatikan hal berikut terkait log biner: Pencatatan log biner harus diaktifkan. Parameter binlog_format harus diatur ke row, dan parameter binlog_row_image harus diatur ke full. Jika tidak, pemeriksaan awal gagal, dan tugas migrasi data tidak dapat dimulai.
Penting Jika database MySQL yang dikelola sendiri berada dalam kluster dual-primary di mana setiap instans merupakan primary dan secondary satu sama lain, Anda harus mengaktifkan parameter log_slave_updates. Hal ini memastikan bahwa DTS dapat memperoleh semua log biner. Log biner instans RDS for MySQL harus dipertahankan minimal selama 3 hari. Kami menyarankan agar Anda menyimpannya selama 7 hari. Log biner database MySQL yang dikelola sendiri harus dipertahankan minimal selama 7 hari. Jika tidak, DTS mungkin gagal karena tidak dapat memperoleh log biner. Dalam kasus ekstrem, hal ini dapat menyebabkan ketidakkonsistenan data atau kehilangan data. Masalah yang disebabkan oleh periode retensi log biner yang lebih pendek dari periode yang disyaratkan tidak dicakup oleh Perjanjian Tingkat Layanan (SLA) DTS.
Batasan operasi database sumber: Selama migrasi skema dan migrasi data penuh, jangan lakukan operasi DDL untuk mengubah skema database atau tabel. Jika tidak, tugas migrasi data akan gagal.
Catatan Selama migrasi data penuh, DTS melakukan kueri ke database sumber. Hal ini membuat metadata lock, yang dapat memblokir operasi DDL pada database sumber. Jika Anda hanya melakukan migrasi data penuh, jangan menulis data baru ke instans sumber. Jika tidak, ketidakkonsistenan data akan terjadi antara sumber dan tujuan. Untuk memastikan konsistensi data secara real-time, pilih migrasi skema, migrasi data penuh, dan migrasi data inkremental.
Perubahan data dari operasi yang tidak dicatat dalam log biner selama migrasi tidak akan dimigrasikan ke database tujuan. Contoh operasi tersebut termasuk pemulihan data menggunakan backup fisik dan operasi kaskade.
Catatan Jika hal ini terjadi, Anda dapat melakukan migrasi data penuh lagi saat bisnis Anda mengizinkan. Jika database sumber adalah MySQL 8.0.23 atau versi yang lebih baru dan data yang akan dimigrasikan berisi kolom tak terlihat (invisible columns), kehilangan data mungkin terjadi karena data dalam kolom tersebut tidak dapat diperoleh.
Catatan Anda dapat menjalankan perintah ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; untuk membuat kolom tak terlihat menjadi terlihat. Untuk informasi lebih lanjut, lihat Invisible Columns.
|
Other limits | Kami menyarankan agar Anda menggunakan versi MySQL yang sama untuk database sumber dan tujuan guna memastikan kompatibilitas. Jika operasi DDL online yang menggunakan tabel temporary, seperti penggabungan beberapa tabel, dilakukan pada database sumber, kehilangan data mungkin terjadi di database tujuan atau instans migrasi dapat gagal. Migrasi parser yang didefinisikan dengan sintaks komentar tidak didukung. Jika terjadi konflik primary key atau unique key selama migrasi: Jika database sumber dan tujuan memiliki skema yang sama, dan sebuah record data memiliki primary key yang sama dengan record data yang sudah ada di database tujuan, skenario berikut mungkin terjadi: Selama migrasi data penuh, DTS tidak memigrasikan record data tersebut ke database tujuan. Record data yang sudah ada di database tujuan tetap dipertahankan. Selama migrasi data inkremental, DTS memigrasikan record data tersebut ke database tujuan. Record data yang sudah ada di database tujuan akan ditimpa.
Jika database sumber dan tujuan memiliki skema yang berbeda, hanya kolom tertentu yang dimigrasikan atau tugas migrasi data gagal. Lakukan dengan hati-hati.
Jika database tujuan adalah MySQL 8.0.23 atau versi yang lebih baru dan kolom target untuk menerima data berisi kolom tak terlihat, instans DTS mungkin gagal atau terjadi kehilangan data. Hal ini karena kolom target untuk menulis data tidak dapat ditemukan.
Catatan Anda dapat menjalankan perintah ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; untuk membuat kolom tak terlihat menjadi terlihat. Untuk informasi lebih lanjut, lihat Invisible Columns. Jika Anda tidak menggunakan fitur migrasi skema DTS, Anda harus memastikan kompatibilitas field sendiri. Jika tidak, instans mungkin gagal atau terjadi kehilangan data. Misalnya, jika field tabel sumber bertipe text dan field tujuan bertipe varchar(255), pemotongan data mungkin terjadi jika tabel sumber berisi objek besar. Jika data yang akan dimigrasikan berisi konten yang memerlukan penyimpanan empat byte, seperti karakter langka atau emoji, database dan tabel tujuan yang menerima data tersebut harus menggunakan charset utf8mb4.
Catatan Jika Anda menggunakan DTS untuk migrasi skema, Anda harus mengatur parameter tingkat instans character_set_server database tujuan ke utf8mb4. Sebelum migrasi data, evaluasi performa database sumber dan tujuan. Kami menyarankan agar Anda melakukan migrasi data selama jam sepi. Selama migrasi data penuh, DTS mengonsumsi sebagian sumber daya baca dan tulis database sumber dan tujuan, yang dapat meningkatkan beban database. Migrasi data penuh melibatkan operasi INSERT konkuren, yang menyebabkan fragmentasi tabel di database tujuan. Setelah migrasi penuh selesai, ruang penyimpanan tabel di database tujuan lebih besar daripada di instans sumber. Konfirmasi apakah presisi migrasi DTS untuk kolom bertipe data FLOAT atau DOUBLE memenuhi kebutuhan bisnis Anda. DTS membaca nilai kolom-kolom tersebut menggunakan ROUND(COLUMN,PRECISION). Jika presisi tidak didefinisikan secara eksplisit, DTS memigrasikan nilai FLOAT dengan presisi 38 digit dan nilai DOUBLE dengan presisi 308 digit. DTS mencoba melanjutkan tugas migrasi data yang gagal dalam tujuh hari terakhir. Oleh karena itu, sebelum Anda mengalihkan layanan ke instans tujuan, Anda harus mengakhiri atau merilis tugas tersebut, atau menggunakan perintah revoke untuk mencabut izin tulis akun DTS pada instans tujuan. Jika tidak, data di instans sumber akan menimpa data di instans tujuan setelah tugas dilanjutkan secara otomatis. Jika pernyataan DDL gagal ditulis ke database tujuan, tugas DTS tetap berjalan. Anda perlu memeriksa log tugas untuk menemukan pernyataan DDL yang gagal. Untuk informasi lebih lanjut tentang cara melihat log tugas, lihat Query task logs. Jika Anda menulis field yang nama kolomnya hanya berbeda dalam huruf besar/kecil ke tabel yang sama di database MySQL tujuan, hasil migrasi mungkin tidak sesuai harapan. Hal ini karena nama kolom di database MySQL bersifat case-insensitive. Setelah migrasi data selesai (status instans adalah Status Completed), kami menyarankan agar Anda menjalankan perintah analyze table <table_name> untuk memastikan bahwa semua data telah ditulis ke tabel tujuan. Misalnya, jika alih bencana HA dipicu di database MySQL tujuan, data mungkin hanya ditulis ke memori, menyebabkan kehilangan data. Jika fitur always-encrypted (EncDB) diaktifkan untuk instans RDS for MySQL, migrasi data penuh tidak didukung.
Catatan Instans RDS for MySQL dengan Enkripsi Data Transparan (TDE) yang diaktifkan mendukung migrasi skema, migrasi data penuh, dan migrasi data inkremental. Untuk memigrasikan akun database dari database sumber, Anda harus memenuhi prasyarat dan memahami catatan terkait. Untuk informasi lebih lanjut, lihat Migrate database accounts. Jika suatu instans gagal, helpdesk DTS akan mencoba memulihkan instans tersebut dalam waktu 8 jam. Selama proses pemulihan, operasi seperti restart instans atau penyesuaian parameternya mungkin dilakukan.
Catatan Saat parameter disesuaikan, hanya parameter instans DTS yang dimodifikasi. Parameter dalam database tidak dimodifikasi. Parameter yang mungkin dimodifikasi mencakup, namun tidak terbatas pada, yang dijelaskan dalam Modify instance parameters.
|
Special cases | Saat database sumber adalah database MySQL yang dikelola sendiri: Alih bencana primary/secondary di database sumber selama migrasi menyebabkan tugas migrasi gagal. Latensi DTS dihitung dengan membandingkan timestamp record data terakhir yang dimigrasikan dengan timestamp saat ini. Jika tidak ada operasi DML yang dilakukan pada database sumber dalam waktu lama, informasi latensi mungkin tidak akurat. Jika latensi yang ditampilkan terlalu tinggi, Anda dapat melakukan operasi DML pada database sumber untuk memperbarui informasi latensi.
Catatan Jika Anda memilih untuk memigrasikan seluruh database, Anda juga dapat membuat tabel heartbeat. Tabel heartbeat diperbarui atau ditulis setiap detik. DTS secara berkala menjalankan perintah CREATE DATABASE IF NOT EXISTS `test` pada database sumber untuk memajukan offset log biner. Jika database sumber adalah instans Amazon Aurora MySQL atau instans MySQL terklaster lainnya, pastikan nama domain atau alamat IP yang dikonfigurasi untuk tugas dan hasil resolusinya selalu mengarah ke node read/write (RW). Jika tidak, tugas migrasi mungkin tidak berjalan sesuai harapan.
Saat database sumber adalah instans RDS for MySQL: Untuk memigrasikan data inkremental, instans RDS for MySQL yang tidak mencatat log transaksi, seperti instans hanya baca RDS for MySQL 5.6, tidak dapat digunakan sebagai database sumber. DTS secara berkala menjalankan perintah CREATE DATABASE IF NOT EXISTS `test` pada database sumber untuk memajukan offset log biner.
Saat database tujuan adalah instans RDS for MySQL: DTS secara otomatis membuat database di instans RDS for MySQL. Jika nama database yang akan dimigrasikan tidak memenuhi konvensi penamaan RDS for MySQL, Anda harus membuat database tersebut di instans RDS for MySQL sebelum mengonfigurasi tugas migrasi. Untuk informasi lebih lanjut, lihat Manage databases.
|