Migrasikan database MySQL yang dikelola sendiri ke RDS for MySQL - ApsaraDB RDS

Gunakan Data Transmission Service (DTS) untuk memigrasikan database MySQL yang dikelola sendiri—baik yang berada di lingkungan on-premises, pada instans Elastic Compute Service (ECS), maupun di cloud lainnya—ke ApsaraDB RDS for MySQL dengan downtime minimal hingga nol.

Panduan ini mencakup:

Memilih solusi migrasi
Menyiapkan database sumber dan instans RDS tujuan
Mengonfigurasi dan menjalankan tugas migrasi
Memverifikasi data dan mengalihkan aplikasi Anda

Pilih solusi migrasi

DTS mendukung tiga jenis migrasi yang dapat Anda kombinasikan untuk membangun solusi:

Jenis migrasi	Fungsinya
Schema migration	Menyalin struktur database, tabel, view, trigger, prosedur tersimpan, dan fungsi. DTS mengonversi `DEFINER` menjadi `INVOKER` dalam view dan prosedur tersimpan.
Full data migration	Menyalin seluruh data yang ada dari database sumber ke instans RDS tujuan.
Incremental data migration	Setelah full data migration dimulai, terus-menerus menyalin perubahan baru dari database sumber—memungkinkan migrasi dengan downtime mendekati nol.

Kombinasikan jenis-jenis tersebut berdasarkan toleransi Anda terhadap downtime:

Solusi	Downtime	Konsistensi data	Batasan	Biaya	Paling cocok untuk
Schema + full + incremental (direkomendasikan)	Nol	Konsisten setelah migrasi selesai, bahkan jika terjadi penulisan selama migrasi	Migrasi inkremental berjalan hingga Anda menghentikannya secara manual	Berbayar (inkremental)	Lingkungan produksi, persyaratan zero-downtime
Schema + full	Durasi full migration	Konsisten hanya jika sumber bersifat read-only selama migrasi; tidak konsisten jika terjadi penulisan	Sumber harus dihentikan sementara untuk memastikan konsistensi data	Gratis	Lingkungan pengujian, downtime dapat diterima

Penagihan

Schema migration, full data migration, dan lalu lintas jaringan publik gratis. Item berikut dikenai biaya:

Incremental Data Migration: Dikenai biaya selama berjalan. Tidak dikenai biaya saat dijeda atau gagal.
Data Verification: Dikenai biaya berdasarkan jumlah data yang diverifikasi. Lihat biaya verifikasi data.

Prasyarat

Sebelum memulai, pastikan Anda telah memiliki:

Database MySQL sumber yang menjalankan versi 5.1, 5.5, 5.6, 5.7, atau 8.0
Instans RDS for MySQL tujuan dengan ruang penyimpanan yang tersedia lebih besar daripada database sumber

Batasan

Tinjau batasan berikut sebelum mengonfigurasi tugas migrasi.

Persyaratan database sumber:

Semua tabel yang akan dimigrasikan harus memiliki primary key atau unique constraint dengan nilai unik. Jika tidak, instans RDS tujuan mungkin berisi data duplikat.
Hindari operasi DDL (perubahan skema) selama schema migration dan full data migration. Tugas migrasi gagal jika operasi DDL terdeteksi.
Jika hanya menjalankan schema + full migration (tanpa inkremental), hindari menulis ke database sumber selama migrasi untuk menjaga konsistensi data.
Server database sumber harus memiliki bandwidth outbound yang mencukupi. Bandwidth yang tidak mencukupi mengurangi kecepatan migrasi.
Untuk incremental data migration, binary logging harus diaktifkan dan dikonfigurasi dengan benar (lihat Konfigurasi binary logging).
Jika database sumber merupakan kluster dual-primary, hindari melakukan Alih bencana primer/sekunder selama Tugas migrasi berlangsung. Tugas tersebut akan gagal jika terjadi Alih bencana.
Jika database sumber menjalankan MySQL 8.0.23 atau lebih baru dan berisi kolom invisible (termasuk primary key invisible yang dibuat otomatis untuk tabel tanpa primary key), buat kolom tersebut visible sebelum migrasi:
```
ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;
```
Lihat Invisible Columns dan Generated Invisible Primary Keys untuk detailnya.

Konten yang tidak dapat dimigrasikan:

Parser yang didefinisikan menggunakan sintaks komentar
Data dari operasi backup dan pemulihan fisik atau operasi cascade foreign key (tidak terekam dalam log biner)
Indeks dan partisi

Batasan lainnya:

Versi MySQL sumber dan tujuan harus sama.
Jika data yang akan dimigrasikan berisi karakter empat-byte (karakter langka atau emoji), instans RDS tujuan dan tabelnya harus menggunakan set karakter utf8mb4. Untuk schema migration, atur character_set_server menjadi utf8mb4 pada instans RDS tujuan.
Jika pemetaan nama kolom dikonfigurasi, satu tugas migrasi mendukung hingga 1.000 tabel. Buat beberapa tugas untuk migrasi yang lebih besar.
DTS menggunakan ROUND(COLUMN, PRECISION) untuk mengambil nilai dari kolom FLOAT dan DOUBLE. Jika presisi tidak ditentukan, FLOAT default ke 38 digit dan DOUBLE default ke 308 digit. Verifikasi bahwa pengaturan presisi ini memenuhi kebutuhan Anda.
DTS mencoba mengulang tugas yang gagal hingga 7 hari. Sebelum mengalihkan beban kerja ke tujuan, hentikan atau lepas tugas yang gagal—atau cabut izin tulis DTS pada tujuan—untuk mencegah data lama menimpa data baru.
Jika tugas DTS gagal dijalankan, dukungan teknis DTS akan mencoba memulihkan tugas dalam waktu 8 jam. Selama pemulihan, tugas mungkin dimulai ulang dan parameternya mungkin diubah.
DTS secara otomatis membuat database tujuan jika nama database sumber mengikuti konvensi penamaan ApsaraDB RDS for MySQL. Jika tidak, buat database secara manual sebelum mengonfigurasi tugas migrasi.
Operasi Online DDL pada database sumber menggunakan pt-online-schema-change tidak didukung dan akan menyebabkan tugas gagal. Gunakan DMS atau gh-ost sebagai gantinya.
DTS secara berkala mengeksekusi CREATE DATABASE IF NOT EXISTS pada database sumber (membuat database test) untuk memajukan posisi log biner.
Setelah alih bencana HA pada instans RDS tujuan, jalankan ANALYZE TABLE <table_name> untuk memastikan data ditulis ke disk dan tidak hanya di memori.
Jika database sumber memiliki Transparent Data Encryption (TDE) diaktifkan, ketiga jenis migrasi didukung. Jika fitur EncDB diaktifkan, full data migration tidak didukung.
Dalam incremental data migration, instans ApsaraDB RDS for MySQL V5.6 yang bersifat read-only tidak dapat digunakan sebagai database sumber karena tidak mencatat log transaksi.

Fase 1: Persiapan migrasi

Langkah 1: Otorisasi DTS untuk mengakses sumber daya cloud

Buka halaman otorisasi cepat dengan Akun Alibaba Cloud Anda dan klik Authorize.
Jika Anda melihat pesan EntityAlreadyExists.Role dan EntityAlreadyExists.Role.Policy, otorisasi telah selesai.

Langkah 2: Buat akun database

Akun untuk database sumber

Jalankan pernyataan berikut pada database sumber:

-- Ganti dts_user dan Your_Password123 dengan nilai aktual.
CREATE USER 'dts_user'@'%' IDENTIFIED BY 'Your_Password123';

-- Diperlukan untuk schema migration dan full data migration.
GRANT SELECT ON *.* TO 'dts_user'@'%';

-- Diperlukan untuk incremental data migration.
GRANT REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW ON *.* TO 'dts_user'@'%';

-- Diperlukan agar DTS dapat membuat tabel heartbeat untuk memajukan posisi log biner.
GRANT CREATE ON *.* TO 'dts_user'@'%';

FLUSH PRIVILEGES;

Tabel berikut merangkum izin minimum yang diperlukan untuk setiap jenis migrasi:

Jenis migrasi	Izin yang diperlukan
Schema migration	SELECT
Full data migration	SELECT
Incremental data migration	SELECT; REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW; CREATE (untuk tabel heartbeat)

Akun untuk instans RDS tujuan

Di Konsol RDS, pilih wilayah dan klik ID instans RDS tujuan.
Di panel navigasi kiri, klik Accounts, lalu klik Create Account.
Atur Account Type menjadi Privileged Account dan lengkapi parameter lainnya.

Akun tujuan memerlukan izin baca dan tulis pada instans RDS tujuan.

Langkah 3: Konfigurasi akses ke database sumber

Pilih metode akses yang sesuai dengan penerapan database sumber Anda:

Database sumber	Metode akses	Konfigurasi
On-premises dengan Alamat IP publik	Public IP	Tambahkan blok CIDR server DTS ke daftar putih IP database sumber
On-premises tanpa Alamat IP publik	Cloud Enterprise Network (CEN), Database Gateway, atau VPN Gateway/Express Connect/Smart Access Gateway (SAG)	Tambahkan blok CIDR server DTS ke daftar putih IP dan lengkapi konfigurasi akses jaringan untuk metode yang Anda pilih
Database pada instans ECS	ECS instance	Tidak perlu konfigurasi

Konfigurasi binary logging untuk incremental data migration

Lewati langkah ini jika Anda tidak melakukan incremental data migration.

Binary logging harus diaktifkan pada database sumber untuk incremental data migration. Konfigurasikan parameter berikut, lalu restart MySQL agar perubahan berlaku.

Parameter binary logging

Parameter	Nilai yang diperlukan	Catatan
`log_bin`	`mysql_bin` (atau path apa pun)	Mengaktifkan binary logging
`binlog_format`	`row`	Diperlukan agar DTS dapat menangkap perubahan tingkat baris
`binlog_row_image`	`full`	Diperlukan untuk MySQL 5.6 dan versi lebih baru
`server_id`	Bilangan bulat apa pun yang lebih besar dari 1	Harus unik dalam topologi replikasi
`expire_logs_days`	7 atau lebih besar	Versi MySQL sebelum 8.0. Default: 0 (tidak pernah kedaluwarsa)
`binlog_expire_logs_seconds`	604800 atau lebih besar (7 hari)	MySQL 8.0 dan versi lebih baru. Default: 2592000 (30 hari)
`log_slave_updates`	`ON`	Hanya untuk kluster dual-primary

Pertahankan log biner setidaknya selama 7 hari. Jika periode retensi terlalu singkat, DTS mungkin gagal memperoleh log biner yang diperlukan, sehingga menyebabkan inkonsistensi atau kehilangan data.

Konfigurasi di Linux

Edit /etc/my.cnf:

log_bin=mysql_bin
binlog_format=row

# MySQL sebelum 8.0:
# expire_logs_days=7

# MySQL 8.0 dan versi lebih baru:
# binlog_expire_logs_seconds=604800

server_id=2
binlog_row_image=full

# Hanya untuk kluster dual-primary:
# log_slave_updates=ON

Restart MySQL:
```
/etc/init.d/mysqld restart
```

Konfigurasi di Windows

Edit my.ini:

log_bin=mysql_bin
binlog_format=row

# MySQL sebelum 8.0:
# expire_logs_days=7

# MySQL 8.0 dan versi lebih baru:
# binlog_expire_logs_seconds=604800

server_id=2
binlog_row_image=full

# Hanya untuk kluster dual-primary:
# log_slave_updates=ON

Restart MySQL:
```
net stop mysql
net start mysql
```

Fase 2: Konfigurasi tugas migrasi

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

Konfigurasi database sumber dan instans RDS tujuan.

Database sumber

Parameter	Nilai
Database Type	MySQL
Access Method	Pilih metode yang dikonfigurasi di Langkah 3 (misalnya, Public IP)
Instance Region	Wilayah tempat database sumber berada
Domain Name or IP	Titik akhir publik atau Alamat IP database sumber
Port	Port layanan database sumber. Default: 3306
Database Account	Akun yang dibuat di Langkah 2
Database Password	Kata sandi untuk akun tersebut
Encryption	Non-encrypted jika SSL tidak diaktifkan; SSL-encrypted jika SSL diaktifkan (unggah CA Certificate dan atur CA Key)

Instans RDS tujuan

Parameter	Nilai
Database Type	MySQL
Access Method	Alibaba Cloud Instance
Instance Region	Wilayah instans RDS tujuan
Replicate Data Across Alibaba Cloud Accounts	No
RDS Instance ID	ID instans RDS tujuan
Database Account	Akun istimewa yang dibuat di Langkah 2
Database Password	Kata sandi untuk akun tersebut
Encryption	Non-encrypted atau SSL-encrypted. Jika SSL-encrypted, aktifkan enkripsi SSL pada instans RDS tujuan terlebih dahulu

Klik Test Connectivity and Proceed. Di kotak dialog, klik Test Connectivity. Jika pengujian gagal, perbaiki masalah berdasarkan pesan error sebelum melanjutkan.

Konfigurasi objek yang akan dimigrasikan.

Konfigurasi Objek

Di tab Configure Objects, atur jenis migrasi dan pilih objek yang akan dimigrasikan: Klik Next: Advanced Settings.

Parameter	Deskripsi
Migration Types	Pilih Schema Migration dan Full Data Migration untuk migrasi penuh. Tambahkan Incremental Data Migration untuk meminimalkan downtime.
Source Objects	Pilih database, tabel, atau kolom yang akan dimigrasikan, lalu klik untuk menambahkannya ke Selected Objects.
Selected Objects	Klik kanan objek untuk mengganti namanya atau mengonfigurasi filter WHERE. Klik Batch Edit untuk mengganti nama beberapa objek sekaligus.
Processing Mode of Conflicting Tables	Precheck and Report Errors (default): gagal dalam pemeriksaan awal jika tujuan sudah berisi tabel dengan nama yang sama. Ignore Errors and Proceed: melewati pemeriksaan ini—selama full migration, catatan yang ada dipertahankan; selama incremental migration, catatan yang ada ditimpa.
Method to Migrate Triggers in Source Database	Tersedia saat Schema Migration dan Incremental Data Migration dipilih. Lihat Synchronize or migrate triggers.
Whether to migrate Event	Menentukan apakah event dari database sumber akan dimigrasikan. Jika Anda memilih Yes, Anda harus menyelesaikan operasi berikutnya. Untuk informasi lebih lanjut, lihat Synchronize or migrate events.
Enable Migration Assessment	Tersedia saat Schema Migration dipilih. Memeriksa apakah skema sumber dan tujuan (panjang indeks, prosedur tersimpan, tabel dependen) kompatibel. Hasil ditampilkan selama pemeriksaan awal tetapi tidak memengaruhi hasil pemeriksaan awal.
Capitalization of Object Names in Destination Instance	Mengontrol kapitalisasi nama database, tabel, dan kolom di tujuan. Default ke DTS default policy. Lihat Specify capitalization of object names.

(Opsional) Konfigurasi Lanjutan

(Opsional) Di tab Advanced Configurations, sesuaikan pengaturan sesuai kebutuhan: Klik Next: Data verification.

Parameter	Deskripsi
Dedicated Cluster for Task Scheduling	Secara default, tugas dijalankan pada shared cluster. Beli dedicated cluster untuk stabilitas yang lebih baik.
Copy the temporary table of the Online DDL tool	Jika menggunakan DMS atau gh-ost untuk Online DDL pada sumber: Yes melakukan migrasi data tabel temporary (dapat meningkatkan latensi); No, Adapt to DMS Online DDL hanya memigrasikan operasi DDL asli; No, Adapt to gh-ost hanya memigrasikan DDL asli dari gh-ost.
Whether to Migrate Accounts	Memigrasikan informasi akun dari sumber. Jika diaktifkan, pilih akun yang akan dimigrasikan dan verifikasi izin akun tersebut.
Retry Time for Failed Connections	Lama waktu DTS mencoba ulang setelah koneksi gagal. Rentang: 10–1.440 menit. Default: 720 menit. Atur minimal 30 menit.
Retry Time for Other Issues	Lama waktu DTS mencoba ulang setelah kegagalan DDL atau DML. Rentang: 1–1.440 menit. Default: 10 menit. Harus lebih kecil dari Retry Time for Failed Connections.
Enable Throttling for Full Data Migration	Membatasi QPS ke database sumber, RPS untuk migrasi penuh, dan kecepatan migrasi (MB/s). Gunakan untuk mengurangi beban pada server database.
Enable Throttling for Incremental Data Migration	Membatasi RPS dan kecepatan migrasi (MB/s) untuk migrasi inkremental.
Configure ETL	Mengaktifkan pemrosesan extract, transform, and load (ETL). Lihat Configure ETL.
Monitoring and Alerting	Mengirim peringatan ketika tugas gagal atau latensi melebihi ambang batas. Lihat Configure monitoring and alerting.
Whether to delete SQL operations on heartbeat tables	Yes: tidak menulis SQL heartbeat ke sumber (latensi migrasi mungkin ditampilkan). No: menulis SQL heartbeat ke sumber (dapat memengaruhi backup fisik dan cloning).

(Opsional) Verifikasi Data

(Opsional) Pada tab Data Verification, konfigurasikan verifikasi data: Jika Anda mengonfigurasi Full Data Verification, atur parameter berikut: Jika Anda mengonfigurasi Incremental Data Verification, atur Incremental Verification Benchmark untuk memfilter operasi DML yang akan diverifikasi. Untuk mengonfigurasi peringatan untuk verifikasi data, atur Full Data Verification Alert atau Incremental Data Verification Alert ke Yes, lalu pilih dan konfigurasikan aturan peringatan. Untuk menerima pemberitahuan peringatan, berlangganan pesan peringatan di CloudMonitor. Lihat Konfigurasikan aturan peringatan untuk tugas DTS.

Metode verifikasi	Biaya	Deskripsi
Full Data Verification	Berbayar	Membandingkan data antara sumber dan tujuan setelah migration penuh
Incremental Data Verification	Berbayar	Membandingkan data selama migrasi inkremental
Schema Verification	Gratis	Memeriksa kompatibilitas schema antara sumber dan tujuan

Pilih satu atau beberapa metode verifikasi data berdasarkan kebutuhan bisnis Anda.

Full Data Verification

Konfigurasi parameter berikut jika Anda memilih Full Data Verification.

Parameter	Deskripsi
Full Data Verification	Full field validation by row sampling: mengambil sampel persentase baris (10–100%) untuk perbandingan seluruh bidang. Verify based on the number of table rows: hanya membandingkan jumlah baris (gratis).
Full Data Verification Time Rule	Hanya Start Now yang didukung.
Timeout Settings for Full Data Verification	Atur timeout (1–72 jam) untuk mengakhiri tugas verifikasi secara otomatis jika berjalan terlalu lama.
Full calibration reference	Default: menggunakan gabungan sumber dan tujuan sebagai garis dasar. Source Database: memverifikasi bahwa tujuan sesuai dengan sumber. Destination Database: memverifikasi bahwa sumber sesuai dengan tujuan.

Incremental Data Verification

Fase 3: Jalankan pemeriksaan awal dan mulai migrasi

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

Fase 4: Verifikasi data dan alih bencana

Monitor status tugas migrasi:
- Tugas tanpa incremental data migration menampilkan Status: Completed saat selesai.
- Tugas dengan incremental data migration menampilkan Status: Running dan tidak berakhir secara otomatis.
Setelah full migration selesai dan latensi migrasi inkremental mendekati nol, verifikasi konsistensi data: Opsi 1 — Verifikasi otomatis: Konfigurasi tugas verifikasi data di DTS. Opsi 2 — Verifikasi manual: Jalankan kueri berikut pada database sumber dan instans RDS tujuan, lalu bandingkan hasilnya:
```
-- Bandingkan jumlah baris
SELECT COUNT(*) FROM <your_table>;

-- Bandingkan metrik bisnis utama
SELECT SUM(amount) FROM orders WHERE create_time >= '2024-01-01';
```
Alihkan aplikasi Anda di luar jam sibuk.
1. Hentikan aplikasi Anda.
2. Pastikan latensi migrasi inkremental telah mencapai nol.
3. Perbarui string koneksi database aplikasi Anda ke titik akhir instans RDS tujuan.
4. Lepaskan tugas migrasi setelah alih bencana selesai.

Operasi SQL yang didukung untuk incremental data migration

Jenis operasi	Pernyataan SQL
DML	INSERT, UPDATE, DELETE
DDL	ALTER TABLE, ALTER VIEW, CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, CREATE VIEW, DROP INDEX, DROP TABLE, RENAME TABLE, TRUNCATE TABLE

Penting

Operasi RENAME TABLE dapat menyebabkan inkonsistensi data. Jika Anda mengganti nama tabel selama migrasi dan memilih tabel tersebut (bukan database induknya) sebagai objek migrasi, data tabel yang diganti namanya tidak akan dimigrasikan. Untuk menghindarinya, pilih database sebagai objek migrasi dan pastikan nama database sebelum dan sesudah penggantian nama termasuk dalam cakupan migrasi.

FAQ

T: Mengapa DTS gagal terhubung dengan galat "Host 'XXX' is not allowed to connect to this MySQL server"?

Ini adalah error koneksi Java Database Connectivity (JDBC). Verifikasi bahwa kredensial akun benar dan akun memiliki izin yang diperlukan. Menggunakan akun istimewa untuk menguji koneksi dapat membantu mengisolasi masalah.

T: Mengapa saya tidak dapat memilih instans RDS di wilayah China (Fuzhou) saat membuat tugas migrasi?

DTS tidak mendukung instans di wilayah China (Fuzhou). Sebagai alternatif, backup database MySQL 5.7 atau 8.0 yang dikelola sendiri ke cloud.