Data Transmission Service (DTS) memungkinkan Anda melakukan migrasi data antara berbagai sumber data—termasuk migrasi ke Alibaba Cloud, migrasi antar instans dalam Alibaba Cloud, serta skenario pemisahan database dan skala keluar. Topik ini menjelaskan cara mengonfigurasi tugas migrasi data di klaster khusus DTS dengan menggunakan instans ApsaraDB RDS for MySQL sebagai sumber dan tujuan.
Prasyarat
Sebelum memulai, pastikan Anda telah memiliki:
Klaster khusus DTS. Lihat Buat klaster khusus DTS.
Instans ApsaraDB RDS for MySQL sebagai sumber dan tujuan. Lihat Buat instans ApsaraDB RDS for MySQL.
Ruang penyimpanan tersedia pada instans tujuan lebih besar daripada ukuran total data pada instans sumber.
(Jika instans sumber/tujuan dan klaster khusus DTS berada di wilayah berbeda) Akses Internet diaktifkan untuk instans sumber atau tujuan.
Penagihan
Anda hanya dikenakan biaya untuk sumber daya klaster khusus DTS. Membuat tugas migrasi di klaster khusus tidak dikenakan biaya tambahan. Jika Anda melakukan migrasi data dari database Alibaba Cloud ke cloud lain, Anda akan dikenakan biaya atas lalu lintas Internet yang dihasilkan. Lihat Penagihan klaster khusus DTS.
Jenis migrasi
DTS mendukung tiga jenis migrasi yang dapat dikombinasikan sesuai kebutuhan Anda:
| Jenis migrasi | Apa yang dilakukan | Kapan menggunakannya |
|---|---|---|
| Schema migration | Menyalin skema objek (tabel, view, trigger, stored procedure, fungsi) dari sumber ke tujuan. Mengubah atribut SECURITY dari DEFINER menjadi INVOKER untuk view, stored procedure, dan fungsi. Tidak melakukan migrasi akun pengguna—berikan izin baca dan tulis yang diperlukan kepada INVOKER secara terpisah. | Selalu sertakan ini kecuali skema tujuan sudah ada. |
| Full data migration | Menyalin seluruh data yang ada dari sumber ke tujuan. | Sertakan ini untuk seeding data awal. Jangan menulis ke sumber selama migrasi full-only. |
| Incremental data migration | Setelah migrasi penuh selesai, terus-menerus menerapkan perubahan dari sumber ke tujuan menggunakan binary log. Menjaga sinkronisasi antara sumber dan tujuan tanpa gangguan layanan. | Sertakan ini untuk meminimalkan downtime dan menjaga layanan tetap berjalan selama migrasi. |
Kombinasi yang direkomendasikan: Pilih ketiga jenis (schema migration + full data migration + incremental data migration) untuk melakukan migrasi data tanpa mengganggu aplikasi Anda. Gunakan migrasi full-only (schema migration + full data migration) hanya untuk migrasi satu kali di mana downtime dapat diterima.
Operasi SQL yang didukung untuk migrasi data inkremental
| Jenis operasi | Operasi 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 |
Izin yang diperlukan
Berikan izin berikut kepada akun database yang digunakan oleh DTS sebelum memulai tugas:
| Database | Schema migration | Full data migration | Incremental data migration |
|---|---|---|---|
| Sumber ApsaraDB RDS untuk MySQL | SELECT | SELECT | Izin baca dan tulis |
| ApsaraDB RDS for MySQL tujuan | Izin baca dan tulis | Izin baca dan tulis | Izin baca dan tulis |
Jika Anda berencana melakukan migrasi akun, akun sumber juga memerlukan SELECT pada mysql.user, mysql.db, mysql.columns_priv, dan mysql.tables_priv. Akun tujuan memerlukan CREATE USER dan GRANT OPTION. Akun sistem (root, mysql.infoschema, mysql.session, mysql.sys) dan akun yang sudah ada di tujuan tidak dapat dimigrasikan.
Untuk petunjuk membuat akun dan memberikan izin, lihat Buat akun pada instans ApsaraDB RDS for MySQL dan Ubah izin akun standar pada instans ApsaraDB RDS for MySQL.
Batasan
Selama schema migration, DTS melakukan migrasi foreign key dari database sumber ke database tujuan. Selama full data migration dan incremental data migration, DTS secara sementara menonaktifkan pemeriksaan kendala kunci asing dan operasi kaskade pada tingkat session. Jika Anda melakukan operasi kaskade atau delete pada database sumber selama migrasi, ketidakkonsistenan data dapat terjadi.
| Kategori | Batas |
|---|---|
| Source database | Server sumber harus memiliki bandwidth outbound yang mencukupi, atau kecepatan migrasi akan menurun. |
| Tabel harus memiliki primary key atau kendala UNIQUE dengan semua field unik. Tanpa ini, database tujuan mungkin berisi catatan duplikat. | |
| Jika Anda memilih tabel sebagai objek migrasi dan perlu mengganti nama tabel atau kolom di tujuan, satu tugas mendukung hingga 1.000 tabel. Melebihi batas ini menyebabkan error permintaan—bagi tabel ke beberapa tugas, atau migrasikan seluruh database sebagai gantinya. | |
Untuk migrasi data inkremental: atur binlog_format ke row, atur binlog_row_image ke full, dan aktifkan binary logging. Jika database MySQL yang dikelola sendiri berjalan di klaster dual-primary, atur log_slave_updates ke ON agar DTS dapat membaca semua binary log. | |
| Untuk migrasi inkremental saja: simpan binary log selama lebih dari 24 jam. Untuk migrasi data penuh + migrasi data inkremental: simpan binary log minimal 7 hari. Setelah migrasi penuh selesai, Anda dapat mengurangi periode retensi menjadi lebih dari 24 jam. Retensi yang tidak mencukupi menyebabkan DTS gagal mendapatkan binary log, yang dapat mengakibatkan kegagalan tugas atau kehilangan data. | |
| Jangan lakukan operasi DDL selama schema migration atau full data migration. Jangan menulis ke database sumber selama migrasi full-only—melakukannya menyebabkan ketidakkonsistenan data. | |
| Lainnya | Gunakan versi engine yang sama untuk database MySQL sumber dan tujuan. |
| Jalankan migrasi selama jam sepi. Full data migration menggunakan sumber daya baca dan tulis pada kedua instans dan meningkatkan beban server. | |
| Full data migration menyebabkan fragmentasi pada tabel tujuan karena operasi INSERT konkuren. Setelah migrasi, ruang tabel tujuan lebih besar daripada ruang tabel sumber. | |
DTS menggunakan ROUND(COLUMN,PRECISION) untuk membaca kolom FLOAT dan DOUBLE. Presisi default adalah 38 digit untuk FLOAT dan 308 digit untuk DOUBLE. Verifikasi bahwa pengaturan presisi ini memenuhi kebutuhan Anda. | |
DTS secara otomatis mencoba ulang tugas yang gagal hingga 7 hari. Sebelum mengalihkan beban kerja ke database tujuan, hentikan atau lepas tugas migrasi—atau jalankan REVOKE untuk menghapus izin tulis DTS pada tujuan. Jika tidak, tugas yang dilanjutkan akan menimpa data tujuan dengan data sumber. | |
| Kasus khusus | Untuk MySQL yang dikelola sendiri: failover primary/secondary selama tugas migrasi aktif menyebabkan tugas gagal. |
| Untuk MySQL yang dikelola sendiri: jika tidak ada operasi DML yang dijalankan pada sumber dalam jangka waktu lama, pelaporan latensi migrasi mungkin tidak akurat. Jalankan operasi DML untuk merefresh latensi. Jika Anda melakukan migrasi seluruh database, buat tabel heartbeat yang menulis data setiap detik. | |
DTS secara berkala mengeksekusi CREATE DATABASE IF NOT EXISTS \test\`` pada database sumber untuk memajukan posisi binary log. | |
| Untuk tujuan ApsaraDB RDS for MySQL: DTS secara otomatis membuat database tujuan kecuali nama database sumber tidak valid. Jika nama tidak valid, buat database secara manual sebelum mengonfigurasi tugas. |
Konfigurasikan tugas migrasi
Konfigurasi mencakup empat tahap: menghubungkan database sumber dan tujuan, memilih objek migrasi, mengonfigurasi pengaturan lanjutan, dan memulai tugas.
Langkah 1: Hubungkan database sumber dan tujuan
Buka halaman Dedicated Cluster.
Di bilah navigasi atas, pilih wilayah tempat klaster khusus DTS Anda berada.
Temukan klaster tersebut, lalu di kolom Actions, pilih Configure Task > Configure Data Migration Task.
Di halaman konfigurasi, baca pemberitahuan Limits di bagian atas sebelum melanjutkan.
Konfigurasikan parameter Source Database:
Parameter Deskripsi Task Name Dihasilkan otomatis. Tentukan nama deskriptif untuk mengidentifikasi tugas. Tidak perlu unik. Select an existing database connection (opsional) Pilih koneksi yang sudah ada untuk mengisi otomatis parameter sumber. Lewati langkah ini jika mengonfigurasi secara manual. Database Type Pilih MySQL. Connection Type Pilih Alibaba Cloud Instance. Instance Region Diatur oleh klaster khusus DTS. Tidak dapat diubah. Replicate Data Across Alibaba Cloud Accounts Pilih No untuk migrasi dalam akun yang sama. RDS Instance ID ID instans ApsaraDB RDS for MySQL sumber. Instans sumber dan tujuan dapat merupakan instans yang sama. Database Account Akun dengan izin yang tercantum di Izin yang diperlukan. Database Password Password untuk akun database. Connection Method Pilih Non-encrypted atau SSL-encrypted. Untuk enkripsi SSL, konfigurasikan SSL pada instans sebelum memulai tugas ini. Konfigurasikan parameter Destination Database:
Parameter Deskripsi Select an existing DMS database instance (opsional) Pilih koneksi yang sudah ada untuk mengisi otomatis parameter tujuan. Lewati langkah ini jika mengonfigurasi secara manual. Database Type Pilih MySQL. Connection Type Pilih Alibaba Cloud Instance. Instance Region Diatur oleh klaster khusus DTS. Tidak dapat diubah. RDS Instance ID ID instans ApsaraDB RDS for MySQL tujuan. Database Account Akun dengan izin yang tercantum di Izin yang diperlukan. Database Password Password untuk akun database. Connection Method Pilih Non-encrypted atau SSL-encrypted. Untuk enkripsi SSL, konfigurasikan SSL pada instans sebelum memulai tugas ini. Klik Test Connectivity and Proceed. DTS secara otomatis menambahkan blok CIDR servernya ke daftar putih IP instans database Alibaba Cloud, atau ke aturan security group instans Elastic Compute Service (ECS) yang meng-host database yang dikelola sendiri. Untuk database yang dikelola sendiri di pusat data lokal atau cloud pihak ketiga, tambahkan secara manual blok CIDR server DTS ke daftar putih IP database. Lihat Tambahkan blok CIDR server DTS ke pengaturan keamanan database lokal.
PeringatanMenambahkan blok CIDR server DTS ke daftar putih IP atau aturan security group menimbulkan risiko keamanan. Sebelum melanjutkan, ambil tindakan pencegahan: perkuat keamanan akun dan password, batasi port yang terbuka, autentikasi panggilan API, audit daftar putih IP dan aturan security group secara berkala untuk menghapus blok CIDR yang tidak sah, dan pertimbangkan menggunakan Express Connect, VPN Gateway, atau Smart Access Gateway untuk menghubungkan database ke DTS.
Langkah 2: Pilih objek migrasi
Konfigurasikan jenis migrasi, penanganan konflik, dan objek yang akan dimigrasikan:
| Parameter | Deskripsi |
|---|---|
| Migration Type | Pilih kombinasi yang sesuai dengan tujuan Anda. Untuk migrasi penuh saja: pilih Schema Migration dan Full Data Migration. Untuk menjaga layanan tetap berjalan selama migrasi: pilih Schema Migration, Full Data Migration, dan Incremental Data Migration. |
| Processing Mode of Conflicting Tables | Precheck and Report Errors: memeriksa apakah tujuan berisi tabel dengan nama yang sama seperti sumber. Pemeriksaan awal hanya lolos jika tidak ada konflik nama. Gunakan pemetaan nama objek untuk mengganti nama tabel yang bertabrakan di tujuan. Ignore Errors and Proceed: melewati pemeriksaan konflik nama. Jika skema cocok, DTS melewati catatan dengan primary key duplikat. Jika skema berbeda, hanya kolom tertentu yang dimigrasikan atau tugas gagal. Gunakan dengan hati-hati—ketidakkonsistenan data dapat terjadi. |
| Method to Migrate Triggers in Source Database | Hanya berlaku saat Schema Migration dipilih. Pilih metode sesuai kebutuhan Anda. Lihat Sinkronkan atau migrasikan trigger dari database sumber. |
| Enable Migration Assessment | Hanya berlaku saat Schema Migration dipilih. Pilih Yes untuk memeriksa apakah skema sumber dan tujuan (panjang indeks, stored procedure, tabel dependen) memenuhi persyaratan migrasi. Hasil penilaian terlihat selama pemeriksaan awal dan tidak memengaruhi kelulusan pemeriksaan awal. |
| Capitalization of Object Names in Destination Instance | Mengontrol kapitalisasi nama database, tabel, dan kolom di tujuan. Default-nya adalah DTS default policy. Lihat Tentukan kapitalisasi nama objek di instans tujuan. |
| Source Objects | Pilih objek dari daftar Source Objects dan klik ikon  untuk menambahkannya ke Selected Objects. Granularitas yang dapat dipilih: kolom, tabel, atau database. Memilih tabel atau kolom mengecualikan view, trigger, dan stored procedure dari migrasi. |
| Selected Objects | Klik kanan objek untuk mengganti namanya atau mengatur kondisi WHERE untuk memfilter baris. Klik Batch Edit (kanan atas) untuk mengganti nama beberapa objek sekaligus. Lihat Pemetaan nama objek dan Gunakan kondisi SQL untuk memfilter data. Mengganti nama objek dapat menyebabkan objek dependen gagal dimigrasikan. |
Langkah 3: Konfigurasikan pengaturan lanjutan
Klik Next: Advanced Settings dan konfigurasikan hal berikut:
Verifikasi data
Untuk memverifikasi konsistensi data setelah migrasi, lihat Aktifkan verifikasi data.
Pengaturan lanjutan
| Parameter | Deskripsi |
|---|---|
| Select the dedicated cluster used to schedule the task | Klaster khusus DTS Anda dipilih secara default. |
| Set Alerts | Pilih Yes untuk menerima notifikasi ketika tugas gagal atau latensi migrasi melebihi ambang batas. Tentukan ambang batas peringatan dan kontak. Lihat Konfigurasikan pemantauan dan peringatan saat membuat tugas DTS. |
| Copy the temporary table of the Online DDL tool that is generated in the source table to the destination database | Berlaku saat menggunakan Data Management (DMS) atau gh-ost untuk operasi DDL Online pada sumber. Yes: memigrasikan data tabel temporary yang dihasilkan oleh DDL Online (dapat memperpanjang waktu migrasi untuk dataset besar). No, Adapt to DMS Online DDL: melewati data tabel temporary; hanya memigrasikan DDL asli. Tabel di tujuan mungkin terkunci. No, Adapt to gh-ost: melewati data tabel temporary; hanya memigrasikan DDL asli. Gunakan ekspresi reguler default atau kustom untuk memfilter tabel shadow gh-ost. Tabel di tujuan mungkin terkunci. Penting pt-online-schema-change tidak didukung. Menggunakannya menyebabkan tugas gagal. |
| Whether to Migrate Accounts | Pilih Yes untuk memigrasikan akun database sumber. Lihat persyaratan izin di Izin yang diperlukan. |
| Method to Migrate Triggers in Source Database | Pilih metode migrasi trigger. Lihat Sinkronkan atau migrasikan trigger dari database sumber. |
| Retry Time for Failed Connections | Berapa lama DTS mencoba ulang setelah kegagalan koneksi. Nilai valid: 10–1.440 menit. Default: 720. Atur minimal 30 menit. Jika koneksi berhasil dalam jendela ini, DTS melanjutkan tugas. Jika instans sumber atau tujuan bersama digunakan oleh beberapa tugas, nilai yang paling baru ditetapkan berlaku untuk semua tugas. Catatan Saat DTS mencoba ulang koneksi, Anda dikenakan biaya untuk instans DTS. Tentukan nilai ini berdasarkan kebutuhan bisnis Anda. Anda juga dapat melepas instans DTS sesegera mungkin setelah instans sumber dan tujuan dilepas. |
| The wait time before a retry when other issues occur in the source and destination databases | Berapa lama DTS mencoba ulang setelah kegagalan operasi DDL atau DML. Nilai valid: 1–1.440 menit. Default: 10. Atur minimal 10 menit. Nilai ini harus lebih kecil daripada Retry Time for Failed Connections. |
Langkah 4: Jalankan pemeriksaan awal dan mulai tugas
Klik Next: Save Task Settings and Precheck. Untuk melihat pratinjau parameter API yang digunakan untuk mengonfigurasi tugas ini, arahkan kursor ke tombol tersebut dan klik Preview OpenAPI parameters.
Tunggu hingga pemeriksaan awal selesai. Jika pemeriksaan awal gagal:
Untuk item yang gagal: klik View Details, perbaiki masalahnya, lalu klik Precheck Again.
Untuk item peringatan yang tidak dapat diabaikan: klik View Details, perbaiki masalahnya, lalu klik Precheck Again.
Untuk item peringatan yang dapat diabaikan: klik Confirm Alert Details > Ignore > OK > Precheck Again. Mengabaikan peringatan dapat menyebabkan ketidakkonsistenan data.
Saat tingkat keberhasilan mencapai 100%, klik Next: Select DTS Instance Type.
Di bagian New Instance Class, atur Instance Class untuk tugas tersebut. Minimum adalah 1 unit DTS (DU) dan maksimum adalah jumlah DU tersedia yang tersisa di klaster.
Baca dan centang kotak Data Transmission Service (Pay-as-you-go) Service Terms.
Klik Start Task > OK.
Untuk memantau kemajuan, buka halaman detail klaster dan klik Cluster Task List di panel navigasi kiri.
Langkah berikutnya
Setelah tugas dimulai dan migrasi inkremental sedang berjalan:
Pantau latensi migrasi di Cluster Task List. Jika latensi tinggi karena tidak ada aktivitas di sumber, jalankan operasi DML untuk merefresh-nya.
Sebelum mengalihkan trafik aplikasi ke database tujuan, verifikasi konsistensi data menggunakan verifikasi data.
Hentikan atau lepas tugas migrasi sebelum mengalihkan beban kerja, atau jalankan
REVOKEuntuk menghapus izin tulis DTS pada tujuan. Hal ini mencegah tugas yang dilanjutkan menimpa data tujuan.