Migrasi database MySQL yang dikelola sendiri ke RDS untuk MySQL - ApsaraDB RDS

Anda dapat menggunakan Data Transmission Service (DTS) untuk memigrasikan database MySQL yang dikelola sendiri dari pusat data lokal, instance Elastic Compute Service (ECS), atau cloud lainnya ke ApsaraDB RDS untuk MySQL dengan downtime minimal hingga nol.

Prasyarat

Database MySQL yang dikelola sendiri harus menjalankan MySQL versi 5.1, 5.5, 5.6, 5.7, atau 8.0.
Instance RDS untuk MySQL tujuan harus memiliki ruang penyimpanan yang tersedia lebih banyak daripada database sumber yang dikelola sendiri.

Ikhtisar solusi migrasi

DTS menyediakan tiga jenis migrasi berikut:

Migrasi Skema: Memigrasikan skema database, tabel, view, trigger, prosedur tersimpan, dan fungsi.
Migrasi Data Penuh: Memigrasikan semua data yang ada dari database sumber.
Migrasi Data Inkremental: Memigrasikan data inkremental dari database sumber ke instance RDS tujuan, menangkap perubahan yang terjadi setelah migrasi data penuh dimulai.

Untuk mencapai migrasi yang lancar tanpa downtime untuk aplikasi Anda, kami merekomendasikan menggabungkan migrasi skema, migrasi data penuh, dan migrasi data inkremental dalam solusi Anda.

Solusi migrasi umum

Solusi migrasi	Downtime	Konsistensi data	Biaya	Kasus Penggunaan
Migrasi skema + data penuh + data inkremental (Direkomendasikan)	Tanpa downtime	Konsisten setelah migrasi selesai terlepas dari apakah data ditulis ke sumber selama migrasi.	Berbayar	Bisnis yang memerlukan downtime migrasi nol atau minimal. Lingkungan produksi.
Migrasi skema + data penuh	Tergantung pada waktu yang diperlukan untuk migrasi data penuh	Tidak konsisten jika data ditulis ke sumber selama migrasi. Konsisten jika tidak ada data yang ditulis ke sumber selama migrasi.	Gratis	Bisnis yang dapat mentolerir downtime migrasi. Lingkungan uji.

Penagihan

Saat menggunakan DTS untuk memigrasikan data dari database sumber ke instance RDS untuk MySQL, migrasi skema, migrasi data penuh, dan lalu lintas jaringan publik gratis. Anda hanya akan dikenakan biaya untuk item-item berikut:

Migrasi Data Inkremental: Anda akan dikenakan biaya saat migrasi inkremental sedang berjalan. Tidak ada biaya jika migrasi dijeda atau gagal.
Verifikasi Data: Anda akan dikenakan biaya verifikasi data.

Keterbatasan

Kunci Utama: Semua tabel yang akan dimigrasikan harus memiliki kunci utama atau kendala unik dengan nilai unik. Jika tidak, instance RDS tujuan mungkin berisi data duplikat.
DDL: Jangan melakukan operasi DDL, seperti mengubah skema database atau tabel, selama migrasi skema dan migrasi data penuh. Jika tidak, tugas migrasi data akan gagal.
DML: Jika Anda hanya melakukan migrasi data penuh, jangan gunakan DML untuk menulis data baru ke instance sumber selama migrasi. Untuk mempertahankan konsistensi data secara real-time, pilih migrasi skema, migrasi data penuh, dan migrasi data inkremental.
Jumlah Tabel: Jika Anda perlu mengedit pemetaan nama kolom, Anda dapat memigrasikan hingga 1.000 tabel dalam satu tugas migrasi. Untuk memigrasikan lebih banyak tabel, buat beberapa tugas migrasi.
Set Karakter: Jika data yang akan dimigrasikan berisi karakter empat-byte, seperti karakter langka atau emoji, instance RDS tujuan dan tabelnya harus menggunakan set karakter utf8mb4. Untuk migrasi skema, atur parameter character_set_server menjadi utf8mb4 untuk instance RDS tujuan.
Akun Database: Untuk memigrasikan akun dari database sumber, pastikan akun yang digunakan untuk migrasi memenuhi persyaratan yang dijelaskan dalam Migrasi Akun Database.
Switchover Primer/Sekunder: Jika database sumber melakukan switchover selama migrasi, migrasi akan gagal.
Kolom Tak Terlihat di MySQL 8.0: Jika database sumber menjalankan MySQL 8.0.23 atau versi lebih baru dan berisi kolom tak terlihat, termasuk yang dihasilkan secara otomatis untuk tabel tanpa kunci utama, Anda harus terlebih dahulu membuatnya terlihat dengan menjalankan ALTER TABLE ... ALTER COLUMN ... SET VISIBLE;. Jika tidak, data akan hilang selama migrasi.
Konten yang Tidak Dapat Dimigrasikan:
- Pengurai yang didefinisikan menggunakan sintaks komentar.
- Data yang dihasilkan oleh operasi yang tidak dicatat dalam log biner, seperti pemulihan cadangan fisik atau operasi kaskade kunci asing.

Klik untuk memperluas lebih banyak batasan spesifik

Jenis	Deskripsi
Batasan database sumber	Persyaratan bandwidth: Server yang menampung database sumber harus memiliki bandwidth keluar yang cukup. Jika tidak, kecepatan migrasi data akan terpengaruh. Tabel yang akan dimigrasikan harus memiliki kunci utama atau kendala UNIK, dan bidangnya harus unik. Jika tidak, data duplikat mungkin muncul di database tujuan. Jika Anda memigrasikan tabel dan perlu mengeditnya (misalnya, memetakan nama kolom), satu tugas migrasi data mendukung maksimal 1.000 tabel. Jika Anda melebihi batas ini, kesalahan akan dilaporkan saat Anda mengirimkan tugas. Dalam hal ini, pisahkan tabel menjadi beberapa tugas migrasi atau konfigurasikan tugas untuk memigrasikan seluruh database. Jika Anda melakukan migrasi inkremental, log biner: Harus diaktifkan, dengan `binlog_format` disetel ke `ROW` dan `binlog_row_image` disetel ke `FULL`. Jika tidak, kesalahan akan dilaporkan selama pra-pemeriksaan, dan tugas migrasi data tidak dapat dimulai. Penting Jika database MySQL yang dikelola sendiri adalah kluster dual-primer di mana setiap instansinya adalah primer untuk yang lain, Anda harus mengaktifkan parameter `log_slave_updates`. Ini memastikan bahwa DTS dapat memperoleh semua log biner. Log biner lokal untuk instance RDS untuk MySQL harus disimpan setidaknya selama 3 hari (7 hari direkomendasikan). Log biner lokal untuk database MySQL yang dikelola sendiri harus disimpan setidaknya selama 7 hari. Jika tidak, tugas DTS mungkin gagal karena tidak dapat memperoleh log biner. Dalam kasus ekstrem, ini dapat menyebabkan ketidaksesuaian data atau kehilangan data. Masalah yang disebabkan oleh pengaturan periode retensi log biner lebih pendek dari persyaratan DTS tidak dicakup oleh Perjanjian Tingkat Layanan (SLA) DTS. Catatan Untuk informasi tentang cara mengatur Retention Period untuk log biner lokal instans RDS for MySQL, lihat Hapus log lokal secara otomatis. Batasan operasi database sumber: Selama migrasi skema dan migrasi data penuh, jangan melakukan operasi DDL yang mengubah database atau skema tabel. Jika tidak, tugas migrasi data akan gagal. Jika Anda hanya melakukan migrasi data penuh, jangan tuliskan data baru ke instans sumber untuk menghindari inkonsistensi data antara database sumber dan tujuan. Untuk menjaga konsistensi data secara real-time, pilih migrasi skema, migrasi data penuh, dan migrasi data inkremental. Selama migrasi, data yang dihasilkan oleh operasi yang tidak dicatat dalam log biner, seperti data dari pemulihan cadangan fisik atau operasi kaskade, tidak dimigrasikan ke database tujuan. Catatan Jika hal ini terjadi, Anda dapat memigrasikan seluruh data lagi ketika bisnis Anda mengizinkan. Jika database sumber adalah MySQL 8.0.23 atau yang lebih baru dan data yang akan dimigrasikan mencakup kolom tidak terlihat, kehilangan data dapat terjadi karena data dalam kolom-kolom tersebut tidak dapat diambil. Catatan Anda dapat menjalankan perintah `ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;` untuk membuat kolom yang tidak terlihat menjadi terlihat. Untuk informasi lebih lanjut, lihat Invisible Columns. Tabel tanpa kunci utama secara otomatis menghasilkan kunci utama yang tidak terlihat. Anda juga harus membuat kunci utama yang tidak terlihat ini menjadi terlihat. Untuk informasi lebih lanjut, lihat Generated Invisible Primary Keys.
Batasan lainnya	Pastikan versi MySQL dari database sumber dan tujuan sama untuk memastikan kompatibilitas. Jika operasi DDL online yang menggunakan tabel sementara, seperti penggabungan beberapa tabel, dilakukan pada database sumber, kehilangan data mungkin terjadi di database tujuan, atau instans migrasi mungkin gagal. Migrasi parser yang didefinisikan dengan sintaks komentar tidak didukung. Jika terjadi konflik kunci utama atau kunci unik saat instans migrasi sedang berjalan: Jika database sumber dan tujuan memiliki skema yang sama, dan catatan data memiliki kunci utama yang sama dengan catatan data yang ada di database tujuan, skenario berikut mungkin terjadi: Selama migrasi data penuh, DTS tidak memigrasikan catatan data ke database tujuan. Catatan data yang ada di database tujuan dipertahankan. Selama migrasi data inkremental, DTS memigrasikan catatan data ke database tujuan. Catatan data yang ada di database tujuan ditimpa. Jika database sumber dan tujuan memiliki skema yang berbeda, hanya kolom tertentu yang dimigrasikan atau tugas migrasi data gagal. Lanjutkan dengan hati-hati. Jika database tujuan adalah MySQL 8.0.23 atau lebih baru dan kolom target adalah kolom tak terlihat, instans DTS mungkin gagal atau kehilangan data mungkin terjadi 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 Kolom Tak Terlihat. Tabel tanpa kunci utama secara otomatis menghasilkan kunci utama tak terlihat. Anda juga harus membuat kunci utama tak terlihat ini menjadi terlihat. Untuk informasi lebih lanjut, lihat Kunci Utama Tak Terlihat yang Dihasilkan. Jika Anda tidak menggunakan fitur migrasi skema DTS, Anda harus memastikan kompatibilitas bidang sendiri. Jika tidak, instans mungkin gagal atau kehilangan data mungkin terjadi. Sebagai contoh, jika bidang tabel sumber bertipe `text` dan bidang tujuan yang sesuai adalah `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 harus menggunakan set karakter `utf8mb4`. Catatan Jika Anda menggunakan DTS untuk migrasi skema, atur parameter tingkat instans `character_set_server` di database tujuan ke `utf8mb4`. Sebelum migrasi data, evaluasi performa database sumber dan tujuan. Lakukan migrasi data selama jam sepi. Selama migrasi data penuh, DTS mengonsumsi sebagian sumber daya baca/tulis database sumber dan tujuan, yang dapat meningkatkan beban database. Migrasi data penuh melibatkan operasi INSERT bersamaan, yang dapat menyebabkan fragmentasi tabel di database tujuan. Setelah migrasi penuh, ruang penyimpanan tabel di database tujuan lebih besar daripada di instans sumber. Konfirmasikan bahwa presisi migrasi untuk kolom bertipe FLOAT atau DOUBLE memenuhi persyaratan bisnis Anda. DTS membaca nilai kolom ini menggunakan `ROUND(COLUMN,PRECISION)`. Jika presisi tidak didefinisikan secara eksplisit, DTS menggunakan presisi 38 untuk FLOAT dan 308 untuk DOUBLE. DTS mencoba melanjutkan tugas migrasi yang gagal dalam waktu tujuh hari. Sebelum Anda memindahkan bisnis ke instans tujuan, akhiri atau lepaskan tugas tersebut. Atau, jalankan perintah `revoke` untuk mencabut izin tulis akun database yang digunakan oleh DTS untuk mengakses instans tujuan. Ini mencegah data sumber menimpa data di instans tujuan jika tugas dilanjutkan secara otomatis. Jika pernyataan DDL gagal ditulis ke database tujuan, tugas DTS tetap berjalan. Anda harus memeriksa log tugas untuk pernyataan DDL yang gagal. Untuk informasi lebih lanjut tentang cara melihat log tugas, lihat Kueri log tugas. Jika Anda menulis bidang yang namanya hanya berbeda dalam huruf besar/kecil ke tabel yang sama di database MySQL tujuan, hasil migrasi mungkin tidak sesuai harapan karena nama kolom MySQL tidak peka huruf besar/kecil. Setelah migrasi data selesai (Status instans adalah Status dan Completed), jalankan perintah `analyze table <table_name>` untuk mengonfirmasi bahwa semua data telah ditulis ke tabel tujuan. Sebagai contoh, jika failover primer/sekunder dipicu pada database MySQL tujuan, data mungkin hanya ditulis ke memori, yang dapat menyebabkan kehilangan data. Jika fitur kerahasiaan penuh 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 dari database sumber, Anda harus memenuhi prasyarat dan memahami catatan terkait. Untuk informasi lebih lanjut, lihat Migrasi akun database. Jika instans gagal, helpdesk DTS akan mencoba memulihkan instans dalam waktu 8 jam. Selama proses pemulihan, instans mungkin di-restart dan parameternya mungkin disesuaikan. Catatan Saat parameter disesuaikan, hanya parameter instans DTS yang dimodifikasi, bukan parameter database. Parameter yang dapat dimodifikasi termasuk tetapi tidak terbatas pada yang dijelaskan di Ubah parameter instans.
Kasus khusus	Jika sumbernya adalah database MySQL yang dikelola sendiri: Switchover primer/sekunder pada database sumber selama migrasi menyebabkan tugas migrasi gagal. Latensi di DTS dihitung dengan membandingkan cap waktu UNIX dari catatan data terakhir yang dimigrasikan dengan cap waktu UNIX saat ini. Jika tidak ada operasi DML yang dilakukan pada database sumber untuk waktu yang 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 memigrasikan seluruh database, Anda juga dapat membuat tabel detak jantung yang 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 instance Amazon Aurora MySQL atau instance MySQL kluster lainnya, pastikan nama domain atau alamat IP yang dikonfigurasi untuk tugas dan hasil resolusinya selalu menunjuk ke node baca/tulis (RW). Jika tidak, tugas migrasi mungkin tidak berjalan sesuai harapan. Jika sumbernya adalah instance RDS untuk MySQL: Untuk migrasi data inkremental, instance RDS untuk MySQL yang tidak mencatat log transaksi, seperti instance RDS untuk MySQL 5.6 yang hanya-baca, tidak dapat digunakan sebagai sumber. DTS secara berkala menjalankan perintah CREATE DATABASE IF NOT EXISTS `test` pada database sumber untuk memajukan offset log biner. Jika tujuannya adalah instance RDS untuk MySQL: DTS secara otomatis membuat database di Instans RDS for MySQL. Jika nama database yang akan dimigrasikan tidak sesuai dengan konvensi penamaan RDS for MySQL, Anda harus membuat database tersebut di Instans RDS for MySQL sebelum Anda mengonfigurasi Tugas migrasi. Untuk informasi selengkapnya, lihat Mengelola database.

Fase 1: Persiapkan untuk migrasi

Langkah 1: Otorisasi DTS untuk mengakses sumber daya cloud

Navigasikan ke halaman otorisasi cepat dengan Akun Alibaba Cloud Anda dan klik Authorize.
Jika Anda melihat pesan EntityAlreadyExists.Role dan EntityAlreadyExists.Role.Policy, otorisasi selesai. Lanjutkan dengan langkah-langkah berikutnya.

Langkah 2: Buat dan otorisasi akun database

Akun untuk database sumber

Eksekusi pernyataan berikut pada database sumber untuk membuat akun:

-- Buat akun untuk database sumber. Ganti dts_user dan Your_Password123 dengan nilai aktual.
CREATE USER 'dts_user'@'%' IDENTIFIED BY 'Your_Password123';

-- Berikan hak akses akun untuk migrasi skema dan data penuh.
GRANT SELECT ON *.* TO 'dts_user'@'%';

-- Berikan hak akses akun untuk migrasi data inkremental.
GRANT REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW ON *.* TO 'dts_user'@'%';

-- Berikan hak akses akun untuk membuat tabel detak jantung untuk memajukan posisi file log biner.
GRANT CREATE ON *.* TO 'dts_user'@'%'; 

FLUSH PRIVILEGES;

Akun istimewa untuk instance RDS tujuan

Navigasikan ke halaman Instance konsol RDS, pilih wilayah di bagian atas, dan kemudian klik ID instance RDS tujuan.
Di panel navigasi kiri, klik Accounts, lalu klik Create Account.
Pilih Privileged Account untuk Account Type dan konfigurasikan parameter lainnya sesuai petunjuk.

Anda juga dapat menggunakan akun database yang ada dengan hak istimewa yang tercantum dalam tabel berikut untuk migrasi:

Akun database	Migrasi skema	Migrasi data penuh	Migrasi data inkremental
Akun untuk database sumber	Hak istimewa SELECT		Hak istimewa SELECT pada objek yang akan dimigrasikan. Hak istimewa REPLICATION CLIENT, REPLICATION SLAVE, dan SHOW VIEW. Hak istimewa untuk membuat database dan tabel di database sumber. Hak istimewa ini memungkinkan DTS membuat database `test` untuk memajukan posisi log biner.
Akun untuk instance RDS tujuan	Hak akses baca dan tulis

Langkah 3: Konfigurasikan akses ke database sumber

Pilih metode akses untuk database sumber dan lengkapi konfigurasi yang sesuai.

Database Sumber	Metode Akses yang Direkomendasikan	Konfigurasi
Database Lokal dengan Alamat IP Publik	Public IP	Tambahkan blok CIDR server DTS ke daftar putih IP database sumber.
Database Lokal Tanpa Alamat IP Publik	Cloud Enterprise Network (CEN) Database Gateway VPN Gateway/Express Connect/Smart Access Gateway (SAG)	Tambahkan blok CIDR server DTS ke daftar putih IP database sumber. Lengkapi konfigurasi untuk metode akses yang dipilih.
Database yang Di-hosting pada Instance ECS	ECS instance	Tidak diperlukan konfigurasi manual.

Langkah 4: Konfigurasikan Binary logging untuk database sumber (hanya untuk migrasi data inkremental)

Untuk melakukan migrasi inkremental, Anda harus mengonfigurasi Binary logging untuk database sumber sebagai berikut lalu mulai ulang MySQL agar konfigurasi tersebut berlaku:

Aktifkan binary logging untuk database sumber dan simpan log setidaknya selama 7 hari.
Atur parameter binlog_format dari database sumber ke row dan parameter binlog_row_image ke full.
Jika database sumber adalah klaster dual-master, aktifkan parameter log_slave_updates untuk memastikan DTS dapat memperoleh semua binary logs.

Untuk mengonfigurasi Binary logging untuk database sumber, ikuti langkah-langkah berikut:

Linux

Gunakan vim untuk memodifikasi parameter berikut dalam file my.cnf:

log_bin=mysql_bin
binlog_format=row

# Untuk versi MySQL sebelum 8.0, konfigurasikan expire_logs_days untuk menetapkan periode retensi log biner. Nilai default: 0 (tidak pernah kedaluwarsa).
# Untuk versi MySQL 8.0 dan yang lebih baru, konfigurasikan binlog_expire_logs_seconds untuk menetapkan periode retensi log biner. Defaultnya adalah 2.592.000 detik (30 hari).
# Jika periode retensi log biner saat ini kurang dari 7 hari, Anda dapat mengatur ulang menjadi 7 hari atau lebih dengan mengonfigurasi parameter berikut:
# expire_logs_days=7
# binlog_expire_logs_seconds=604800

# Atur parameter ini ke bilangan bulat lebih besar dari 1.
server_id=2

# Parameter ini harus diatur jika database sumber menjalankan versi MySQL lebih baru dari 5.6.
binlog_row_image=full

# Atur parameter ini ke ON jika database sumber merupakan kluster dual-master.
# log_slave_updates=ON

Mulai ulang proses MySQL:
```
/etc/init.d/mysqld restart
```

Windows

Modifikasi parameter berikut dalam file my.ini:

log_bin=mysql_bin
binlog_format=row

# Untuk versi MySQL sebelum 8.0, konfigurasikan expire_logs_days untuk menetapkan periode retensi log biner. Nilai default: 0 (tidak pernah kedaluwarsa).
# Untuk versi MySQL 8.0 dan yang lebih baru, konfigurasikan binlog_expire_logs_seconds untuk menetapkan periode retensi log biner. Defaultnya adalah 2.592.000 detik (30 hari).
# Jika periode retensi log biner saat ini kurang dari 7 hari, Anda dapat mengatur ulang menjadi 7 hari atau lebih dengan mengonfigurasi parameter berikut:
# expire_logs_days=7
# binlog_expire_logs_seconds=604800

# Atur parameter ini ke bilangan bulat lebih besar dari 1.
server_id=2

# Parameter ini harus diatur jika database sumber menjalankan versi MySQL lebih baru dari 5.6.
binlog_row_image=full

# Atur parameter ini ke ON jika database sumber merupakan kluster dual-master.
# log_slave_updates=ON

Mulai ulang layanan MySQL dari Windows Service Manager atau jalankan perintah berikut:
```
net stop mysql
net start mysql
```

Fase 2: Konfigurasikan tugas migrasi

Masuk ke Konsol DTS, pilih Data Migration di panel navigasi kiri, lalu klik Create Task.

Konfigurasikan Database Sumber dan Instance RDS Tujuan.

Database sumber

Parameter	Deskripsi
Database Type	Pilih MySQL.
Access Method	Pilih metode akses untuk database sumber. Contoh: Public IP.
Instance Region	Pilih wilayah tempat database sumber berada.
Domain Name or IP	Masukkan endpoint publik atau alamat IP dari database sumber.
Port	Masukkan port layanan dari database sumber. Nilai default: 3306.
Database Account	Masukkan akun yang dibuat untuk database sumber.
Database Password	Masukkan kata sandi untuk akun tersebut.
Encryption	Menentukan apakah akan mengenkripsi koneksi ke database sumber. Jika enkripsi SSL tidak diaktifkan untuk database sumber, pilih Non-encrypted. Jika enkripsi SSL diaktifkan untuk database sumber, pilih SSL-encrypted. Dalam hal ini, Anda harus mengunggah CA Certificate dan mengonfigurasi parameter CA Key.

Instance RDS tujuan

Parameter	Deskripsi
Database Type	Pilih MySQL.
Access Method	Pilih Alibaba Cloud Instance.
Instance Region	Pilih wilayah instans RDS.
Replicate Data Across Alibaba Cloud Accounts	Pilih No.
RDS Instance ID	Pilih ID instans RDS.
Database Account	Masukkan akun istimewa yang dibuat untuk instans RDS.
Database Password	Masukkan kata sandi untuk akun tersebut.
Encryption	Menentukan apakah koneksi ke instans basis data sumber akan dienkripsi. Pilih Non-encrypted atau SSL-encrypted. Jika Anda memilih SSL-encrypted, Anda harus mengaktifkan enkripsi SSL untuk instans RDS tujuan.

Uji Koneksi Database.
Klik Test Connectivity and Proceed di bagian bawah halaman. Di kotak dialog yang muncul, klik Test Connectivity. Jika tes gagal, perbaiki masalah berdasarkan pesan kesalahan.

Konfigurasikan objek yang akan dimigrasikan.

Konfigurasikan pengaturan pada tab Configure Objects, Advanced Configurations, dan Data Verification.

Konfigurasikan Objek

Konfigurasikan parameter dalam tabel berikut. Lalu, klik Next: Advanced Settings.

Parameter	Deskripsi
Migration Types	Untuk hanya melakukan migrasi data penuh, pilih Schema Migration dan Full Data Migration. Untuk memastikan kontinuitas layanan selama migrasi data, pilih Schema Migration, Full Data Migration, dan Incremental Data Migration. Catatan Jika Anda tidak memilih Schema Migration, pastikan database dan tabel telah dibuat di database tujuan untuk menerima data dan fitur pemetaan nama objek diaktifkan di Selected Objects. Jika Anda tidak memilih Incremental Data Migration, kami sarankan Anda tidak menulis data ke database sumber selama migrasi data. Ini memastikan konsistensi data antara database sumber dan tujuan.
Method to Migrate Triggers in Source Database	Metode yang digunakan untuk memigrasikan trigger dari database sumber. Anda dapat memilih metode migrasi berdasarkan kebutuhan bisnis Anda. Jika tidak ada trigger yang akan dimigrasikan, Anda tidak perlu mengonfigurasi parameter ini. Untuk informasi lebih lanjut, lihat Sinkronkan atau migrasikan trigger dari database sumber. Catatan Parameter ini tersedia hanya jika Anda memilih Schema Migration dan Incremental Data Migration untuk parameter Migration Types.
Enable Migration Assessment	Menentukan apakah akan mengaktifkan penilaian migrasi. Penilaian migrasi bertujuan untuk memeriksa apakah skema database sumber dan tujuan, seperti panjang indeks, prosedur tersimpan, dan tabel dependen, memenuhi persyaratan. Anda dapat memilih Yes atau No berdasarkan kebutuhan bisnis Anda. Catatan Anda dapat mengonfigurasi parameter ini hanya jika Anda memilih Schema Migration untuk parameter Migration Types. Jika Anda memilih Yes, pra-pemeriksaan mungkin memakan waktu lebih lama. Anda dapat melihat Assessment Result selama pra-pemeriksaan. Hasil penilaian tidak mempengaruhi hasil pra-pemeriksaan.
Processing Mode of Conflicting Tables	Precheck and Report Errors: Memeriksa apakah database tujuan berisi tabel yang menggunakan nama yang sama dengan tabel di database sumber. Jika database sumber dan tujuan tidak berisi tabel dengan nama identik, pra-pemeriksaan berhasil. Jika tidak, kesalahan akan dikembalikan selama pra-pemeriksaan dan tugas migrasi data tidak dapat dimulai. Catatan Jika database sumber dan tujuan berisi tabel dengan nama yang identik dan tabel di database tujuan tidak dapat dihapus atau diganti namanya, Anda dapat menggunakan fitur pemetaan nama objek untuk mengganti nama tabel yang dimigrasikan ke database tujuan. Untuk informasi selengkapnya, lihat Memetakan nama objek. Ignore Errors and Proceed: Melewati pra-pemeriksaan untuk nama tabel identik di database sumber dan tujuan. Peringatan Jika Anda memilih Ignore Errors and Proceed, ketidaksesuaian data mungkin terjadi dan bisnis Anda mungkin terpapar risiko potensial berikut: Jika database sumber dan tujuan memiliki skema yang sama, dan catatan data memiliki kunci utama yang sama dengan catatan data yang ada di database tujuan, skenario berikut mungkin terjadi: Selama migrasi data penuh, DTS tidak memigrasikan catatan data ke database tujuan. Catatan data yang ada di database tujuan dipertahankan. Selama migrasi data inkremental, DTS memigrasikan catatan data ke database tujuan. Catatan data yang ada di database tujuan ditimpa. Jika database sumber dan tujuan memiliki skema yang berbeda, hanya kolom tertentu yang akan dimigrasikan atau Tugas migrasi data akan gagal. Lanjutkan dengan hati-hati.
Whether to migrate Event	Menentukan apakah akan memigrasikan event dari database sumber. Jika Anda memilih Yes, Anda harus menyelesaikan operasi berikutnya. Untuk informasi lebih lanjut, lihat Synchronize or migrate events.
Capitalization of Object Names in Destination Instance	Pengaturan kapitalisasi nama database, nama tabel, dan nama kolom di instans tujuan. Secara default, DTS default policy dipilih. Anda dapat memilih opsi lain untuk memastikan bahwa kapitalisasi nama objek konsisten dengan yang ada di database sumber atau tujuan. Untuk informasi lebih lanjut, lihat Tentukan kapitalisasi nama objek di instans tujuan.
Source Objects	Pilih satu atau beberapa objek dari bagian Source Objects. Klik ikon dan tambahkan objek ke bagian Selected Objects. Catatan Anda dapat memilih kolom, tabel, atau database sebagai objek yang akan dimigrasikan. Jika Anda memilih tabel atau kolom sebagai objek yang akan dimigrasikan, DTS tidak akan memigrasikan objek lainnya, seperti tampilan, pemicu, atau prosedur tersimpan, ke database tujuan.
Selected Objects	Untuk mengganti nama objek yang ingin Anda migrasikan ke instans tujuan, klik kanan objek di bagian Selected Objects. Untuk informasi lebih lanjut, lihat Pemetaan nama untuk satu objek. Untuk mengganti nama beberapa objek sekaligus, klik Batch Edit di pojok kanan atas bagian Selected Objects. Untuk informasi lebih lanjut, lihat Pemetaan beberapa nama objek sekaligus. Catatan Jika Anda menggunakan fitur pemetaan nama objek untuk mengganti nama objek, objek lain yang bergantung pada objek tersebut mungkin gagal dimigrasikan. Untuk memfilter data menggunakan kondisi WHERE, klik kanan tabel yang akan dimigrasikan di bagian Selected Objects dan konfigurasikan kondisi filter di kotak dialog yang muncul. Untuk informasi lebih lanjut, lihat Filter data yang akan dimigrasikan. Untuk memilih operasi SQL yang akan dimigrasikan di tingkat database atau tabel, klik kanan objek yang akan dimigrasikan di bagian Selected Objects dan pilih operasi SQL di kotak dialog yang muncul. Untuk informasi lebih lanjut tentang operasi yang didukung, lihat Operasi SQL yang mendukung migrasi data inkremental.

(Opsional) Konfigurasi Lanjutan

Konfigurasikan pengaturan lanjutan untuk menyesuaikan tugas migrasi. Jika Anda tidak perlu mengonfigurasi pengaturan ini, pertahankan nilai default dan klik Next: Data verification.

Parameter	Deskripsi
Dedicated Cluster for Task Scheduling	Secara default, DTS menjadwalkan tugas migrasi data ke klaster bersama jika Anda tidak menentukan klaster khusus. Jika Anda ingin meningkatkan stabilitas tugas migrasi data, beli klaster khusus. Untuk informasi lebih lanjut, lihat Apa itu klaster khusus DTS.
Copy the temporary table of the Online DDL tool that is generated in the source table to the destination database.	Jika Anda menggunakan DMS atau alat gh-ost untuk melakukan operasi DDL online pada database sumber, Anda dapat menentukan apakah akan memigrasi data tabel sementara yang dihasilkan oleh operasi DDL online. Nilai valid: Penting Anda tidak dapat menggunakan alat seperti pt-online-schema-change untuk melakukan operasi DDL online pada database sumber. Jika tidak, tugas DTS gagal. Yes: DTS memigrasi data tabel sementara yang dihasilkan oleh operasi DDL online. Catatan Jika operasi DDL online menghasilkan sejumlah besar data, latensi mungkin terjadi untuk tugas migrasi data. No, Adapt to DMS Online DDL: DTS tidak memigrasi data tabel sementara yang dihasilkan oleh operasi DDL online. Hanya operasi DDL asli yang dilakukan menggunakan DMS yang dimigrasi. Catatan Jika Anda memilih opsi ini, tabel di database tujuan mungkin terkunci. No, Adapt to gh-ost: DTS tidak memigrasi data tabel sementara yang dihasilkan oleh operasi DDL online. Hanya operasi DDL asli yang dilakukan menggunakan alat gh-ost yang dimigrasi. Anda dapat menggunakan ekspresi reguler default atau kustom untuk menyaring tabel bayangan alat gh-ost dan tabel yang tidak diperlukan. Catatan Jika Anda memilih opsi ini, tabel di database tujuan mungkin terkunci.
Whether to Migrate Accounts	Menentukan apakah akan memigrasikan informasi akun dari database sumber. Anda dapat mengonfigurasi parameter ini berdasarkan kebutuhan bisnis Anda. Jika Anda memilih Yes, Anda harus memilih akun yang ingin dimigrasikan dan memeriksa izin akun database sumber dan tujuan yang digunakan dalam tugas migrasi data.
Retry Time for Failed Connections	Rentang waktu ulang untuk koneksi gagal. Jika database sumber atau tujuan gagal terhubung setelah tugas migrasi data dimulai, DTS segera mencoba kembali koneksi dalam rentang waktu ulang. Nilai valid: 10 hingga 1.440. Unit: menit. Nilai default: 720. Kami merekomendasikan Anda mengatur parameter ini ke nilai lebih dari 30. Jika DTS tersambung kembali ke database sumber dan tujuan dalam rentang waktu ulang yang ditentukan, DTS melanjutkan tugas migrasi data. Jika tidak, tugas migrasi data gagal. Catatan Jika Anda menentukan rentang waktu ulang berbeda untuk beberapa tugas migrasi data yang berbagi database sumber atau tujuan yang sama, nilai yang ditentukan terakhir akan diutamakan. Saat DTS mencoba kembali koneksi, Anda akan dikenakan biaya untuk instans DTS. Kami merekomendasikan Anda menentukan rentang waktu ulang berdasarkan kebutuhan bisnis Anda. Anda juga dapat melepaskan instans DTS sesegera mungkin setelah database sumber dan instans tujuan dilepaskan.
Retry Time for Other Issues	Rentang waktu ulang untuk masalah lainnya. Sebagai contoh, jika operasi DDL atau DML gagal dilakukan setelah tugas migrasi data dimulai, DTS segera mencoba kembali operasi dalam rentang waktu ulang. Nilai valid: 1 hingga 1440. Unit: menit. Nilai default: 10. Kami merekomendasikan Anda mengatur parameter ini ke nilai lebih dari 10. Jika operasi gagal berhasil dilakukan dalam rentang waktu ulang yang ditentukan, DTS melanjutkan tugas migrasi data. Jika tidak, tugas migrasi data gagal. Penting Nilai parameter Retry Time for Other Issues harus lebih kecil dari nilai parameter Retry Time for Failed Connections.
Enable Throttling for Full Data Migration	Menentukan apakah akan mengaktifkan pembatasan kecepatan untuk migrasi data penuh. Selama migrasi data penuh, DTS menggunakan sumber daya baca dan tulis dari database sumber dan tujuan. Ini dapat meningkatkan beban server database. Anda dapat mengaktifkan pembatasan kecepatan untuk migrasi data penuh berdasarkan kebutuhan bisnis Anda. Untuk mengonfigurasi pembatasan kecepatan, Anda harus mengonfigurasi parameter Queries per second (QPS) to the source database, RPS of Full Data Migration, dan Data migration speed for full migration (MB/s). Ini mengurangi beban server database tujuan. Catatan Anda hanya dapat mengonfigurasi parameter ini jika Anda memilih Full Data Migration untuk parameter Migration Types.
Enable Throttling for Incremental Data Migration	Menentukan apakah akan mengaktifkan pembatasan kecepatan untuk migrasi data inkremental. Untuk mengonfigurasi pembatasan kecepatan, Anda harus mengonfigurasi parameter RPS of Incremental Data Migration dan Data migration speed for incremental migration (MB/s). Ini mengurangi beban server database tujuan. Catatan Anda hanya dapat mengonfigurasi parameter ini jika Anda memilih Incremental Data Migration untuk parameter Migration Types.
Environment Tag	Tag lingkungan yang digunakan untuk mengidentifikasi instans DTS. Anda dapat memilih tag lingkungan berdasarkan kebutuhan bisnis Anda. Dalam contoh ini, Anda tidak perlu mengonfigurasi parameter ini.
Whether to delete SQL operations on heartbeat tables of forward and reverse tasks	Menentukan apakah akan menulis operasi SQL pada tabel denyut nadi ke database sumber saat instans DTS sedang berjalan. Nilai valid: Yes: tidak menulis operasi SQL pada tabel denyut nadi. Dalam hal ini, latensi instans DTS mungkin ditampilkan. No: menulis operasi SQL pada tabel denyut nadi. Dalam hal ini, fitur seperti pencadangan fisik dan kloning database sumber mungkin terpengaruh.
Configure ETL	Menentukan apakah akan mengaktifkan fitur extract, transform, dan load (ETL). Untuk informasi lebih lanjut, lihat Apa itu ETL? Nilai valid: Yes: mengonfigurasi fitur ETL. Anda dapat memasukkan pernyataan pemrosesan data di editor kode. Untuk informasi lebih lanjut, lihat Konfigurasikan ETL dalam tugas migrasi data atau sinkronisasi data. No: tidak mengonfigurasi fitur ETL.
Monitoring and Alerting	Menentukan apakah akan mengonfigurasi peringatan untuk tugas migrasi data. Jika tugas gagal atau latensi migrasi melebihi ambang batas yang ditentukan, kontak peringatan menerima notifikasi. Nilai valid: No: tidak mengonfigurasi peringatan. Yes: mengonfigurasi peringatan. Dalam hal ini, Anda juga harus mengonfigurasi ambang batas peringatan dan pengaturan notifikasi peringatan. Untuk informasi lebih lanjut, lihat bagian Konfigurasikan pemantauan dan peringatan saat Anda membuat tugas DTS dari topik Konfigurasikan pemantauan dan peringatan.

(Opsional) Verifikasi Data

Verifikasi data memantau dan membandingkan data antara database sumber dan tujuan untuk mengidentifikasi ketidaksesuaian. Jika Anda tidak memerlukan verifikasi data, lanjutkan ke langkah berikutnya.

Metode verifikasi data	Biaya	Deskripsi
Full Data Verification	Dikenakan biaya	Memverifikasi data dalam migrasi data penuh.
Incremental Data Verification	Dikenakan biaya	Memverifikasi data dalam migrasi data inkremental.
Schema Verification	Gratis	Melakukan verifikasi skema pada objek yang akan dimigrasikan.

Anda dapat mengonfigurasi fitur verifikasi data saat mengonfigurasi tugas migrasi. Anda juga dapat mengonfigurasi tugas verifikasi data individual setelah migrasi selesai. Anda dapat melewati langkah ini sesuai kebutuhan.

Klik untuk memperluas detail konfigurasi verifikasi data

Data Verification Mode: Pilih satu atau lebih metode verifikasi data berdasarkan kebutuhan bisnis Anda.

Verifikasi Data Penuh

Konfigurasikan parameter berikut jika Anda memilih Full Data Verification.

Parameter	Deskripsi
Full Data Verification	Full field validation by row sampling: Konfigurasikan persentase pengambilan sampel (bilangan bulat dari 10 hingga 100) untuk melakukan validasi penuh pada data yang diambil sampelnya. Verify based on the number of table rows: Memverifikasi jumlah baris data migrasi penuh tanpa memverifikasi data. Catatan Mode Verify based on the number of table rows gratis. Mode Full field validation by row sampling dikenakan biaya berdasarkan jumlah data yang diverifikasi secara aktual.
Full Data Verification Time Rule	Hanya Start Now yang didukung.
Timeout Settings for Full Data Verification	No: Tugas verifikasi penuh tidak akan diakhiri secara paksa jika timeout. Yes: Tetapkan durasi timeout untuk tugas verifikasi penuh. Timer dimulai saat tugas validasi dimulai, dan jika tugas tidak selesai dalam waktu yang ditentukan, tugas tersebut diakhiri secara paksa. Nilainya adalah bilangan bulat dari 1 hingga 72.
Full calibration reference	Default: Menggunakan gabungan database sumber dan tujuan sebagai dasar untuk memverifikasi konsistensi data. Source Database: Menggunakan database sumber sebagai dasar untuk memverifikasi bahwa database tujuan konsisten dengan sumber (tidak memeriksa data tambahan di instance RDS tujuan). Destination Database: Menggunakan instance RDS tujuan sebagai dasar untuk memverifikasi bahwa database sumber konsisten dengan instance RDS tujuan (tidak memeriksa data tambahan di database sumber).
Maximum number of rows of data read per second by full verification (RPS)	Verifikasi data penuh mengonsumsi beberapa sumber daya baca dari database. Anda dapat menetapkan batasan kecepatan untuk tugas verifikasi (baris per detik dan byte per detik) untuk mengurangi beban pada server database. Catatan Nilai 0 berarti tidak ada batasan yang ditetapkan. Jika baik Maximum number of rows of data read per second by full verification (RPS) maupun The maximum number of bytes read per second by full verification Byte/s. adalah 0, kecepatan tidak dibatasi.
The maximum number of bytes read per second by full verification Byte/s.

Verifikasi Data Inkremental

Jika Anda memilih Incremental Data Verification, Anda juga harus mengonfigurasi parameter berikut:

Parameter	Deskripsi
Incremental Verification Benchmark	Anda dapat memfilter operasi DML yang akan diverifikasi berdasarkan kebutuhan Anda.

Tentukan Verification Objects.
Di bagian Selected Objects, Anda dapat memilih objek yang tidak memerlukan verifikasi data dan klik untuk menghapusnya.
Catatan
Secara default, objek yang akan disinkronkan atau dimigrasikan ditambahkan ke bagian Selected Objects.

Konfigurasikan peringatan untuk verifikasi data.

Konfigurasikan peringatan untuk verifikasi data berdasarkan kebutuhan bisnis Anda. Tabel berikut menjelaskan parameter-parameter tersebut.

Parameter	Deskripsi
Full Data Verification Alert	No: menonaktifkan peringatan. Yes: mengaktifkan peringatan. Dalam hal ini, Anda juga harus memilih dan mengonfigurasi aturan peringatan. Informasi berikut menjelaskan aturan peringatan: Peringatan dipicu jika verifikasi data penuh gagal. Peringatan dipicu jika volume data yang tidak konsisten yang terdeteksi oleh verifikasi data penuh lebih besar dari atau sama dengan ambang batas yang ditentukan.
Incremental Data Verification Alert	No: menonaktifkan peringatan. Yes: mengaktifkan peringatan. Dalam hal ini, Anda juga harus memilih dan mengonfigurasi aturanperingatan. Informasi berikut menjelaskan aturan peringatan: Peringatan dipicu jika verifikasi data inkremental gagal. Peringatan dipicu jika volume data yang tidak konsisten yang terdeteksi oleh verifikasi data inkremental dalam periode berturut-turut yang ditentukan lebih besar dari atau sama dengan ambang batas yang ditentukan. Anda dapat menentukan jumlah periode berturut-turut, periode statistik, dan ambang batas volume data yang tidak konsisten. Peringatan dipicu jika latensi migrasi atau sinkronisasi data yang terdeteksi oleh verifikasi data inkremental dalam periode berturut-turut yang ditentukan lebih besar dari atau sama dengan ambang batas yang ditentukan. Anda dapat menentukan jumlah periode berturut-turut, periode statistik, dan latensi migrasi atau sinkronisasi data.

Penting

Jika Anda mengaktifkan peringatan untuk verifikasi data dan ingin menerima notifikasi saat peringatan dipicu, Anda harus berlangganan pesan peringatan di CloudMonitor. Untuk informasi lebih lanjut, lihat Konfigurasikan aturan peringatan untuk tugas DTS di konsol CloudMonitor.

Fase 3: Pra-pemeriksaan dan mulai migrasi

Setelah Anda menyelesaikan konfigurasi, klik Next: Save Task Settings and Precheck. DTS memvalidasi lingkungan dan konfigurasi Anda.
Tunggu pra-pemeriksaan selesai.
- Jika Success Rate mencapai 100%, lingkungan siap untuk migrasi.
- Jika pra-pemeriksaan gagal, klik View Details, perbaiki masalah, dan jalankan pra-pemeriksaan lagi.
- Tinjau peringatan yang dapat diabaikan untuk memastikan bahwa mereka tidak menimbulkan risiko, lalu abaikan dan lanjutkan.
Setelah pra-pemeriksaan berhasil, klik Next: Purchase Instance.
Pilih Resource Group (default: default resource group) dan spesifikasi instans DTS yang sesuai.
Baca dan pilih Data Transmission Service (Pay-As-You-Go) Terms of Service, klik Purchase and Start, lalu klik Confirm. Tugas dimulai secara otomatis.

Fase 4: Verifikasi data dan switchover bisnis

Tunggu kemajuan tugas migrasi.
1. Tugas tanpa migrasi data inkremental memiliki Status bernilai Completed ketika selesai.
2. Tugas dengan migrasi data inkremental memiliki Status bernilai Running dan tidak berakhir secara otomatis.

Verifikasi konsistensi data.

Setelah migrasi penuh selesai dan latensi migrasi data inkremental mendekati nol, verifikasi konsistensi data antara database sumber dan tujuan.

Verifikasi otomatis: Konfigurasikan tugas verifikasi data di DTS untuk secara otomatis membandingkan data di database sumber dan tujuan.

Verifikasi manual: Bandingkan jumlah baris tabel dan data bisnis inti antara database sumber dan instance RDS tujuan. Contoh kode:

-- Contoh 1: Eksekusi pernyataan berikut pada database sumber dan instance RDS tujuan masing-masing untuk membandingkan jumlah baris tabel.
SELECT COUNT(*) FROM your_table;

-- Contoh 2: Eksekusi pernyataan berikut pada database sumber dan instance RDS tujuan masing-masing untuk membandingkan indikator bisnis utama, seperti total jumlah pesanan dalam periode tertentu.
SELECT SUM(amount) FROM orders WHERE create_time >= '2024-01-01';

Alihkan bisnis Anda.
Selama jam-jam sepi, hentikan aplikasi Anda, pastikan latensi migrasi data inkremental adalah nol, lalu ubah string koneksi database aplikasi Anda ke endpoint instance RDS tujuan. Setelah alih bencana selesai, lepaskan tugas migrasi.

Lampiran 1: Jenis migrasi

Jenis migrasi	Deskripsi
Migrasi skema	Memigrasikan definisi struktur objek seperti tabel, view, dan prosedur tersimpan. DTS mengonversi `DEFINER` dalam view dan prosedur tersimpan menjadi `INVOKER` di database tujuan.
Migrasi data penuh	Memigrasikan semua data yang ada dari database sumber ke instance RDS tujuan.
Migrasi data inkremental	Setelah migrasi penuh, jenis ini secara terus-menerus memigrasikan perubahan data baru dari sumber ke tujuan, memungkinkan migrasi tanpa downtime.

Lampiran 2: Operasi SQL yang didukung selama migrasi data inkremental

Jenis operasi	Pernyataan SQL
DML	INSERT, UPDATE, dan DELETE
DDL	ALTER TABLE dan ALTER VIEW CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, dan CREATE VIEW DROP INDEX dan DROP TABLE RENAME TABLE Penting Operasi RENAME TABLE dapat menyebabkan ketidaksesuaian data antara database sumber dan tujuan. Sebagai contoh, jika Anda memilih tabel sebagai objek yang akan dimigrasikan dan mengubah nama tabel selama migrasi data, data dari tabel tersebut tidak akan dimigrasikan ke database tujuan. Untuk mencegah situasi ini, Anda dapat memilih database tempat tabel tersebut berada sebagai objek yang akan dimigrasikan saat mengonfigurasi tugas migrasi data. Pastikan bahwa database tempat tabel tersebut berada sebelum dan sesudah operasi RENAME TABLE ditambahkan ke objek yang akan dimigrasikan. TRUNCATE TABLE

FAQ

P1: Apa yang harus saya lakukan jika kesalahan "JDBC: [conn_error, cause: null, message from server: "Host 'XXX' is not allowed to connect to this MySQL server"]; PING: []; TELNET: []; requestId=[XXX]" terjadi?
Kesalahan ini menunjukkan pengecualian Java Database Connectivity (JDBC). Verifikasi akun, kata sandi, dan izin untuk JDBC, atau gunakan akun istimewa untuk menguji koneksi.
P2: Mengapa saya tidak dapat memilih instance RDS di wilayah China (Fuzhou) saat membuat tugas migrasi?
DTS tidak mendukung instance di wilayah China (Fuzhou). Sebagai alternatif, Anda dapat mencadangkan database MySQL 5.7 atau 8.0 yang dikelola sendiri ke cloud.