Jika database sumber Anda adalah MySQL—seperti Database MySQL yang dikelola sendiri atau ApsaraDB RDS for MySQL—tinjau pertimbangan dan batasan berikut sebelum mengonfigurasi tugas migrasi data untuk memastikan keberhasilan eksekusinya.
Solusi migrasi untuk sumber MySQL
Tinjau pertimbangan dan batasan untuk setiap solusi migrasi:
Migrasi antar database MySQL
Jika database tujuan Anda adalah MySQL—seperti ApsaraDB RDS for MySQL atau Database MySQL yang dikelola sendiri—tinjau pertimbangan dan batasan berikut:
|
Type
|
Description
|
|
Source database limits
|
-
Batasan bandwidth: Server yang menghosting database sumber harus memiliki bandwidth outbound yang mencukupi. Jika tidak, kecepatan migrasi akan menurun.
-
Setiap tabel yang akan dimigrasikan harus memiliki primary key atau kendala UNIQUE, dan kolom kunci tersebut harus berisi nilai unik. Jika tidak, catatan duplikat dapat 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 selama tiga hari (disarankan tujuh hari). Untuk database MySQL yang dikelola sendiri, simpan log biner lokal minimal selama 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 tidak, 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.
-
Jika Anda hanya menjalankan migrasi penuh, jangan menulis data baru ke instans sumber. Jika tidak, 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.
|
|
Other limits
|
-
Kami menyarankan menggunakan versi MySQL yang sama untuk database sumber dan tujuan guna memastikan kompatibilitas.
-
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 pada database tujuan.
-
DTS tidak mendukung migrasi parser yang didefinisikan menggunakan sintaks komentar.
-
Jika terjadi konflik primary key atau unique key selama migrasi:
-
Jika skema tabel konsisten dan sebuah 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.
-
Jika database tujuan MySQL Anda versi 8.0.23 atau lebih baru dan kolom target adalah kolom tersembunyi tak terlihat, DTS tidak dapat menulis data ke kolom tersebut. Hal ini dapat menyebabkan kegagalan tugas atau 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.
-
Jika Anda tidak menggunakan DTS untuk memigrasikan skema, verifikasi sendiri kompatibilitas bidang. Jika tidak, tugas dapat gagal atau data hilang. Misalnya, jika tipe kolom sumber adalah text dan tipe kolom tujuan adalah varchar(255), bidang besar di sumber mungkin terpotong.
-
Jika data Anda mencakup karakter empat-byte—seperti karakter Tionghoa langka atau emoji—database dan tabel tujuan harus menggunakan charset utf8mb4.
Catatan
Jika Anda menggunakan DTS untuk memigrasikan skema, atur parameter tingkat instans character_set_server ke utf8mb4 di database tujuan.
-
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 pada 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.
-
Pastikan presisi migrasi DTS untuk kolom FLOAT atau DOUBLE sesuai kebutuhan bisnis Anda. DTS membaca kolom-kolom ini menggunakan ROUND(COLUMN,PRECISION). Jika presisi tidak 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 lepas 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 petunjuk, lihat Lihat log tugas.
-
Jika Anda menulis kolom dengan nama identik namun berbeda kapitalisasi ke tabel yang sama di database tujuan MySQL, hasil yang tidak terduga dapat terjadi. Nama kolom MySQL bersifat case-insensitive.
-
Setelah migrasi selesai—status tugas adalah Status dan berubah menjadi Completed—jalankan analyze table <table_name> untuk memastikan semua data telah ditulis ke tabel tujuan. Misalnya, setelah alih bencana high-availability (HA) di database tujuan MySQL, data mungkin tetap berada di memori dan tidak pernah mencapai disk, menyebabkan kehilangan data.
-
Jika instans RDS for MySQL Anda memiliki Always-Encrypted diaktifkan, migrasi penuh tidak didukung.
Catatan
Instans RDS for MySQL dengan Enkripsi Data Transparan (TDE) yang diaktifkan mendukung migrasi skema, migrasi penuh, dan migrasi inkremental.
-
Untuk memigrasikan akun database dari sumber, penuhi prasyarat yang diperlukan dan tinjau pertimbangan terkait. Untuk informasi lebih lanjut, lihat Migrasi akun database.
-
Jika 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.
|
|
Special cases
|
-
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 terkluster 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 dapat 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.
-
Untuk tujuan RDS for MySQL:
DTS secara otomatis membuat database di RDS for MySQL. Jika nama database tidak memenuhi aturan penamaan RDS for MySQL, buat database tersebut secara manual sebelum mengonfigurasi tugas migrasi. Untuk petunjuk, lihat Kelola database.
|
Migrasi dari MySQL ke PolarDB for MySQL
Jika database tujuan Anda adalah PolarDB for MySQL, tinjau pertimbangan dan batasan berikut:
|
Type
|
Description
|
|
Source database limits
|
-
Batasan bandwidth: Server yang menghosting database sumber harus memiliki bandwidth outbound yang mencukupi. Jika tidak, kecepatan migrasi akan menurun.
-
Setiap tabel yang akan dimigrasikan harus memiliki primary key atau kendala UNIQUE, dan kolom kunci tersebut harus berisi nilai unik. Jika tidak, catatan duplikat dapat 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 selama tiga hari (disarankan tujuh hari). Untuk database MySQL yang dikelola sendiri, simpan log biner lokal minimal selama 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 tidak, 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.
-
Jika Anda hanya menjalankan migrasi penuh, jangan menulis data baru ke instans sumber. Jika tidak, 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.
|
|
Other limits
|
-
Kami menyarankan menggunakan versi MySQL yang sama untuk database sumber dan tujuan guna memastikan kompatibilitas.
-
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 pada database tujuan.
-
DTS tidak mendukung migrasi parser yang didefinisikan menggunakan sintaks komentar.
-
Jika terjadi konflik primary key atau unique key selama migrasi:
-
Jika skema tabel konsisten dan sebuah 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.
-
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 pada 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.
-
Jika data Anda mencakup karakter empat-byte—seperti karakter Tionghoa langka atau emoji—database dan tabel tujuan harus menggunakan charset utf8mb4.
Catatan
Jika Anda menggunakan DTS untuk memigrasikan skema, atur parameter tingkat instans character_set_server ke utf8mb4 di database tujuan.
-
Pastikan presisi migrasi DTS untuk kolom FLOAT atau DOUBLE sesuai kebutuhan bisnis Anda. DTS membaca kolom-kolom ini menggunakan ROUND(COLUMN,PRECISION). Jika presisi tidak 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 lepas 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.
-
DTS tidak mendukung konversi data datetime ke varchar.
-
Jika penulisan DDL gagal di database tujuan, tugas DTS tetap berjalan. Periksa pernyataan DDL yang gagal di log tugas. Untuk petunjuk, lihat Lihat log tugas.
-
Jika instans RDS for MySQL Anda memiliki Always-Encrypted diaktifkan, migrasi penuh tidak didukung.
Catatan
Instans RDS for MySQL dengan Enkripsi Data Transparan (TDE) yang diaktifkan mendukung migrasi skema, migrasi penuh, dan migrasi inkremental.
-
Untuk memigrasikan akun database dari sumber, penuhi prasyarat yang diperlukan dan tinjau pertimbangan terkait. Untuk informasi lebih lanjut, lihat Migrasi akun database.
-
Jika 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.
|
|
Special cases
|
|
Migrasi dari MySQL ke PolarDB-X 2.0
Tinjau pertimbangan dan batasan berikut:
|
Type
|
Description
|
|
Source database limits
|
-
Batasan bandwidth: Server yang menghosting database sumber harus memiliki bandwidth outbound yang mencukupi. Jika tidak, kecepatan migrasi akan menurun.
-
Setiap tabel yang akan dimigrasikan harus memiliki primary key atau kendala UNIQUE, dan kolom kunci tersebut harus berisi nilai unik. Jika tidak, catatan duplikat dapat 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 selama tiga hari (disarankan tujuh hari). Untuk database MySQL yang dikelola sendiri, simpan log biner lokal minimal selama 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 penuh. Jika tidak, 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.
-
Jika Anda hanya menjalankan migrasi penuh, jangan menulis data baru ke instans sumber. Jika tidak, data sumber dan tujuan menjadi tidak konsisten. Untuk menjaga konsistensi data secara real-time, pilih 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.
|
|
Other limits
|
-
Jika terjadi konflik primary key atau unique key selama migrasi:
-
Jika skema tabel konsisten dan sebuah 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.
-
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 pada database tujuan.
-
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 pada 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.
-
Pastikan presisi migrasi DTS untuk kolom FLOAT atau DOUBLE sesuai kebutuhan bisnis Anda. DTS membaca kolom-kolom ini menggunakan ROUND(COLUMN,PRECISION). Jika presisi tidak 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 lepas 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 instans RDS for MySQL Anda memiliki Always-Encrypted diaktifkan, migrasi penuh tidak didukung.
Catatan
Instans RDS for MySQL dengan Enkripsi Data Transparan (TDE) yang diaktifkan mendukung migrasi skema, migrasi penuh, dan migrasi inkremental.
-
Jika 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.
|
|
Special cases
|
-
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 terkluster 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 dapat 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.
|
Migrasi dari MySQL ke AnalyticDB for MySQL
Tinjau pertimbangan dan batasan berikut:
|
Type
|
Description
|
|
Source database limits
|
-
Batasan bandwidth: Server yang menghosting database sumber harus memiliki bandwidth outbound yang mencukupi. Jika tidak, kecepatan migrasi akan menurun.
-
Setiap tabel yang akan dimigrasikan harus memiliki primary key atau kendala UNIQUE, dan kolom kunci tersebut harus berisi nilai unik. Jika tidak, catatan duplikat dapat 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 selama tiga hari (disarankan tujuh hari). Untuk database MySQL yang dikelola sendiri, simpan log biner lokal minimal selama 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 tidak, 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 tidak, tugas migrasi akan gagal.
-
Jika Anda hanya menjalankan migrasi penuh, jangan menulis data baru ke instans sumber. Jika tidak, 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.
|
|
Other limits
|
-
Indeks awalan tidak didukung. Jika database sumber Anda berisi indeks awalan, migrasi dapat 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 pada database tujuan.
-
Jika terjadi konflik primary key atau unique key selama migrasi:
-
Jika skema tabel konsisten dan sebuah 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 dapat 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 dibutuhkan 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 tersebut 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 pada 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.
-
Pastikan presisi migrasi DTS untuk kolom FLOAT atau DOUBLE sesuai kebutuhan bisnis Anda. DTS membaca kolom-kolom ini menggunakan ROUND(COLUMN,PRECISION). Jika presisi tidak 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 lepas 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 petunjuk, lihat Lihat log tugas.
-
Jika instans RDS for MySQL Anda memiliki Always-Encrypted diaktifkan, migrasi penuh tidak didukung.
Catatan
Instans RDS for MySQL dengan Enkripsi Data Transparan (TDE) yang diaktifkan mendukung migrasi skema, migrasi penuh, dan migrasi inkremental.
-
Jika 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.
|
|
Special cases
|
-
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 terkluster 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 dapat 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.
|
Migrasi dari MySQL ke kluster Kafka yang dikelola sendiri
Tinjau pertimbangan dan batasan berikut:
|
Type
|
Description
|
|
Source database limits
|
-
Batasan bandwidth: Server yang menghosting database sumber harus memiliki bandwidth outbound yang mencukupi. Jika tidak, kecepatan migrasi akan menurun.
-
Setiap tabel yang akan dimigrasikan harus memiliki primary key atau kendala UNIQUE, dan kolom kunci tersebut harus berisi nilai unik. Jika tidak, catatan duplikat dapat 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 selama tiga hari (disarankan tujuh hari). Untuk database MySQL yang dikelola sendiri, simpan log biner lokal minimal selama 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 tidak, 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.
-
Jika Anda hanya menjalankan migrasi penuh, jangan menulis data baru ke instans sumber. Jika tidak, 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.
|
|
Other limits
|
-
Hanya tabel data yang didukung sebagai objek migrasi.
-
DTS tidak mendukung migrasi objek INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER, atau FK.
-
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 pada 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.
-
Pastikan presisi migrasi DTS untuk kolom FLOAT atau DOUBLE sesuai kebutuhan bisnis Anda. DTS membaca kolom-kolom ini menggunakan ROUND(COLUMN,PRECISION). Jika presisi tidak 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 lepas 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.
-
Jangan menulis data ke database tujuan kecuali melalui DTS, karena hal ini dapat menyebabkan ketidakkonsistenan data antara database sumber dan tujuan.
-
Jika kluster Kafka tujuan Anda melakukan scale out atau scale in selama migrasi, restart tugas DTS.
-
Jika instans RDS for MySQL Anda memiliki Always-Encrypted diaktifkan, migrasi penuh tidak didukung.
Catatan
Instans RDS for MySQL dengan Enkripsi Data Transparan (TDE) yang diaktifkan mendukung migrasi skema, migrasi penuh, dan migrasi inkremental.
-
Jika 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.
|
|
Special cases
|
-
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 terkluster 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 dapat 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.
|
Migrasi dari MySQL ke DataHub
Tinjau pertimbangan dan batasan berikut:
|
Type
|
Description
|
|
Source database limits
|
-
Batasan bandwidth: Server yang menghosting database sumber harus memiliki bandwidth outbound yang mencukupi. Jika tidak, kecepatan migrasi akan menurun.
-
Setiap tabel yang akan dimigrasikan harus memiliki primary key atau kendala UNIQUE, dan kolom kunci tersebut harus berisi nilai unik. Jika tidak, catatan duplikat dapat 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 selama tiga hari (disarankan tujuh hari). Untuk database MySQL yang dikelola sendiri, simpan log biner lokal minimal selama 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.
Menjalankan operasi DDL yang memodifikasi skema database atau tabel selama fase migrasi skema akan menyebabkan tugas migrasi data gagal. -
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.
|
|
Other limits
|
-
Hanya migrasi tingkat tabel yang didukung.
-
DTS tidak mendukung migrasi objek INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER, atau FK.
-
Satu bidang String di proyek DataHub tujuan mendukung hingga 2 MB.
-
Jangan gunakan alat seperti pt-online-schema-change untuk menjalankan operasi DDL online pada objek migrasi di database sumber. Jika tidak, migrasi gagal.
-
Anda dapat menggunakan Data Management (DMS) untuk menjalankan operasi DDL online. Untuk petunjuk, lihat Perubahan skema online tanpa mengunci tabel.
Peringatan
Jika data selain dari DTS menulis ke database tujuan, jangan gunakan DMS untuk menjalankan operasi DDL online. Jika tidak, data tujuan dapat hilang.
-
Pastikan presisi migrasi DTS untuk kolom FLOAT atau DOUBLE sesuai kebutuhan bisnis Anda. DTS membaca kolom-kolom ini menggunakan ROUND(COLUMN,PRECISION). Jika presisi tidak 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 lepas 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 instans RDS for MySQL Anda memiliki Always-Encrypted diaktifkan, migrasi penuh tidak didukung.
Catatan
Instans RDS for MySQL dengan Enkripsi Data Transparan (TDE) yang diaktifkan mendukung migrasi skema, migrasi penuh, dan migrasi inkremental.
-
Jika 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.
|
|
Special cases
|
-
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 terkluster 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 dapat 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.
|