Topik ini menjelaskan cara menggunakan Data Transmission Service (DTS) untuk memigrasikan data dari database TiDB yang dikelola sendiri ke instans ApsaraDB RDS for MySQL.
Pilih jalur migrasi Anda:
| Jalur | Langkah | Kapan digunakan |
|---|---|---|
| Hanya migrasi penuh | Prasyarat → Prosedur | Migrasi satu kali dengan jendela pemeliharaan singkat |
| Migrasi penuh + inkremental | Prasyarat → Persiapan → Prosedur | Migrasi tanpa downtime; tetap menjaga database sumber aktif selama migrasi |
Tabel tanpa primary key atau kendala UNIQUE dapat menghasilkan catatan duplikat di database tujuan. Pastikan semua tabel yang akan dimigrasikan memiliki PRIMARY KEY atau kendala UNIQUE sebelum memulai.
Prasyarat
Sebelum memulai, pastikan Anda telah:
Memiliki instans ApsaraDB RDS for MySQL dengan ruang penyimpanan yang tersedia lebih besar daripada total ukuran data di database TiDB sumber. Untuk detailnya, lihat Buat instans ApsaraDB RDS for MySQL.
(Hanya untuk migrasi penuh + inkremental) Menyelesaikan bagian Persiapan untuk menyiapkan kluster Kafka dan mengonfigurasi TiDB Binlog atau TiCDC guna menangkap data inkremental.
Persiapan (hanya untuk migrasi inkremental)
Lewati bagian ini jika Anda hanya memerlukan migrasi data penuh.
DTS membaca data inkremental dari TiDB melalui pipeline berbasis Kafka. DTS hanya membaca dari partisi 0 topik Kafka, sehingga topik tersebut harus memiliki tepat satu partisi. Sebelum membuat tugas DTS, siapkan pipeline ini menggunakan salah satu metode berikut.
Metode 1: TiDB Binlog
Terapkan server database sumber, Pump, Drainer, dan kluster Kafka pada jaringan internal yang sama untuk meminimalkan latensi jaringan.
Siapkan kluster Kafka menggunakan salah satu opsi berikut:
Kluster Kafka yang dikelola sendiri: Lihat dokumentasi Apache Kafka. Atur
message.max.bytesdanreplica.fetch.max.bytespada broker, sertafetch.message.max.bytespada konsumen ke nilai yang cukup besar untuk menangani volume log biner TiDB. Untuk detail konfigurasi, lihat CONFIGURATION.Instans ApsaraMQ for Kafka: Lihat Ikhtisar memulai. Terapkan instans dalam virtual private cloud (VPC) yang sama dengan server database sumber.
Buat topik di kluster Kafka atau instans ApsaraMQ for Kafka.
PentingTopik harus memiliki tepat satu partisi. DTS hanya membaca data inkremental dari partisi dengan ID 0.
Terapkan Pump dan Drainer. Untuk detailnya, lihat Penerapan kluster TiDB Binlog.
Edit file konfigurasi Drainer agar mengarah ke kluster Kafka Anda. Untuk detailnya, lihat Panduan pengguna klien konsumen Binlog.
Pastikan server database TiDB dapat terhubung ke kluster Kafka.
Tambahkan blok CIDR server DTS ke daftar putih database TiDB. Untuk detailnya, lihat Tambahkan blok CIDR server DTS.
Metode 2: TiCDC
Siapkan kluster Kafka menggunakan salah satu opsi berikut:
Kluster Kafka yang dikelola sendiri: Lihat dokumentasi Apache Kafka. Atur
message.max.bytesdanreplica.fetch.max.bytespada broker, sertafetch.message.max.bytespada konsumen ke nilai yang cukup besar untuk menangani volume log biner TiDB. Untuk detail konfigurasi, lihat CONFIGURATION.Instans ApsaraMQ for Kafka: Lihat Ikhtisar memulai. Terapkan instans dalam VPC yang sama dengan server database sumber.
Buat topik di kluster Kafka atau instans ApsaraMQ for Kafka.
PentingTopik harus memiliki tepat satu partisi. DTS hanya membaca data inkremental dari partisi dengan ID 0.
Instal TiCDC. Kami menyarankan Anda menggunakan TiUP untuk menambahkan node TiCDC baru atau melakukan scale out node TiCDC yang ada di kluster TiDB. Untuk detailnya, lihat Terapkan dan kelola TiCDC.
Replikasikan data inkremental di database TiDB sumber ke Kafka. Kami menyarankan Anda menggunakan
tiup cdc cli changefeed create \pada baris perintah pertama. Untuk detailnya, lihat Replikasikan data ke Kafka.Pastikan server database TiDB dapat terhubung ke kluster Kafka.
Izin yang diperlukan
| Database | Izin yang diperlukan |
|---|---|
| Database TiDB | SELECT pada objek yang akan dimigrasikan; SHOW VIEW |
| Instans ApsaraDB RDS for MySQL | Izin baca dan tulis pada database tujuan |
Untuk bantuan membuat dan mengonfigurasi akun, lihat Buat akun dan Ubah izin akun.
Penagihan
| Jenis migrasi | Biaya konfigurasi instans | Biaya lalu lintas internet |
|---|---|---|
| Migrasi skema + migrasi data penuh | Gratis | Dikenakan biaya ketika Access Method diatur ke Public IP Address. Lihat Ikhtisar penagihan. |
| Migrasi data inkremental | Dikenakan biaya. Lihat Ikhtisar penagihan. | — |
Operasi SQL yang didukung untuk migrasi inkremental
| Jenis operasi | Pernyataan SQL |
|---|---|
| DML | INSERT, UPDATE, DELETE |
| DDL | CREATE TABLE, DROP TABLE, ALTER TABLE, RENAME TABLE, TRUNCATE TABLE, CREATE VIEW, DROP VIEW, ALTER VIEW |
Catatan penggunaan
Batasan database sumber:
Server database sumber harus memiliki bandwidth outbound yang mencukupi. Bandwidth yang tidak mencukupi akan mengurangi kecepatan migrasi.
Tabel harus memiliki PRIMARY KEY atau kendala UNIQUE dengan semua bidang unik. Tabel tanpa kendala ini dapat menyebabkan catatan duplikat di tujuan.
Saat melakukan migrasi dengan penggantian nama tabel atau kolom, satu tugas mendukung hingga 1.000 tabel. Untuk lebih dari 1.000 tabel, jalankan beberapa tugas secara batch atau migrasikan pada tingkat database.
Migrasi data inkremental memerlukan kluster Kafka dengan TiDB Binlog atau TiCDC yang telah dikonfigurasi (lihat Persiapan).
Migrasi data penuh:
Jalankan migrasi selama jam sepi ketika beban CPU pada kedua database berada di bawah 30%. DTS menggunakan sumber daya baca dan tulis pada kedua database selama migrasi penuh.
Operasi INSERT bersamaan selama migrasi penuh menyebabkan fragmentasi tabel di tujuan. Ruang tabel tujuan kemungkinan akan lebih besar daripada sumber setelah migrasi selesai.
Hindari menulis data dari sumber lain ke tujuan selama migrasi untuk mencegah ketidakkonsistenan data.
Migrasi data inkremental:
Setelah membuat tugas, segera lakukan operasi pada database sumber atau masukkan data uji. Hal ini memperbarui informasi offset dan mencegah kegagalan tugas akibat latensi berlebihan.
DTS hanya membaca data inkremental dari partisi 0 topik Kafka.
Pertimbangan tipe data dan set karakter:
Data yang berisi karakter langka atau emoji (karakter 4-byte) memerlukan tabel tujuan menggunakan set karakter UTF8mb4. Jika Anda menggunakan fitur migrasi skema, atur parameter
character_set_serverdi database tujuan ke UTF8mb4.Nama kolom di MySQL tidak case-sensitive. Menulis nama kolom yang hanya berbeda kapitalisasinya ke tabel tujuan yang sama dapat menghasilkan hasil tak terduga.
DTS menggunakan
ROUND(COLUMN, PRECISION)untuk mengambil nilai FLOAT dan DOUBLE. Presisi default: FLOAT = 38 digit, DOUBLE = 308 digit. Pastikan pengaturan presisi ini sesuai kebutuhan Anda.
Setelah migrasi:
Saat Status tugas menunjukkan Completed, jalankan
ANALYZE TABLE <table_name>untuk memverifikasi data telah ditulis ke disk. Alih bencana HA di database MySQL tujuan dapat menyebabkan data hanya ada di memori, sehingga berpotensi kehilangan data.DTS mencoba melanjutkan tugas yang gagal hingga 7 hari. Sebelum mengalihkan workload ke database tujuan, hentikan atau lepas tugas yang gagal, atau jalankan REVOKE untuk mencabut izin tulis DTS di tujuan. Jika tidak, tugas yang dilanjutkan dapat menimpa data tujuan dengan data sumber.
Pernyataan DDL yang gagal di tujuan tidak menghentikan tugas DTS. Lihat pernyataan DDL yang gagal di log tugas. Untuk detailnya, lihat Lihat log tugas.
Jika tugas DTS gagal, tim dukungan DTS akan mencoba memulihkannya dalam waktu 8 jam. Tugas dapat dimulai ulang dan parameter tugas (bukan parameter database) mungkin dimodifikasi selama pemulihan. Untuk parameter yang mungkin dimodifikasi, lihat Ubah parameter instans.
Jika nama database sumber tidak sesuai dengan konvensi penamaan ApsaraDB RDS for MySQL, buat database tujuan terlebih dahulu dan gunakan fitur pemetaan nama objek untuk mengganti namanya saat konfigurasi tugas. Untuk detailnya, lihat Kelola database dan Pemetaan nama objek.
Konfigurasikan dan jalankan tugas migrasi
Langkah 1: Buka halaman Data Migration
Gunakan salah satu konsol berikut:
Konsol DTS:
Login ke Konsol DTS.
Di panel navigasi kiri, klik Data Migration.
Di pojok kiri atas, pilih wilayah tempat instans migrasi berada.
Konsol Data Management Service (DMS):
Langkah aktual dapat berbeda tergantung mode dan tata letak konsol DMS. Untuk detailnya, lihat Mode simple dan Sesuaikan tata letak dan gaya konsol DMS.
Login ke Konsol DMS.
Di bilah navigasi atas, buka Data + AI > DTS (DTS) > Data Migration.
Dari daftar drop-down di samping Data Migration Tasks, pilih wilayah tempat instans migrasi berada.
Langkah 2: Buat tugas dan konfigurasikan database sumber dan tujuan
Klik Create Task.
Konfigurasikan database sumber dan tujuan menggunakan parameter berikut:
Pengaturan tugas:
| Parameter | Deskripsi |
|---|---|
| Task Name | Nama untuk tugas DTS. DTS menghasilkan nama secara otomatis. Tentukan nama deskriptif agar mudah mengidentifikasi tugas. Nama tidak perlu unik. |
Database sumber:
| Parameter | Deskripsi |
|---|---|
| Select Existing Connection | Jika instans TiDB telah terdaftar di DTS, pilih dari daftar dan DTS akan mengisi parameter koneksi secara otomatis. Jika tidak, konfigurasikan parameter di bawah. Di konsol DMS, gunakan daftar Select a DMS database instance. |
| Database Type | Pilih TiDB. |
| Access Method | Pilih metode akses berdasarkan lokasi penempatan TiDB. Contoh ini menggunakan Self-managed Database on ECS. Untuk metode akses lain, lengkapi penyiapan lingkungan yang diperlukan terlebih dahulu. Lihat Ikhtisar persiapan. |
| Instance Region | Wilayah tempat database TiDB berada. |
| ECS Instance ID | ID instans ECS yang menjalankan database TiDB. |
| Port Number | Port layanan TiDB. Default: 4000. |
| Database Account | Akun TiDB. Lihat Izin yang diperlukan untuk izin yang dibutuhkan. |
| Database Password | Kata sandi untuk akun TiDB. |
| Migrate Incremental Data | Pilih Yes untuk mengaktifkan migrasi data inkremental, lalu masukkan informasi kluster Kafka di bagian Parameter kluster Kafka. Pilih No untuk migrasi penuh saja. |
Database tujuan:
| Parameter | Deskripsi |
|---|---|
| Select Existing Connection | Jika instance RDS telah terdaftar di DTS, pilih instance tersebut dari daftar. Jika belum, konfigurasikan parameter berikut. Di konsol DMS, gunakan daftar Select a DMS database instance. |
| Database Type | Pilih MySQL. |
| Access Method | Pilih Alibaba Cloud Instance. |
| Instance Region | Wilayah tempat instans ApsaraDB RDS for MySQL tujuan berada. |
| Replicate Data Across Alibaba Cloud Accounts | Pilih No untuk migrasi dalam akun yang sama. |
| RDS Instance ID | ID instans ApsaraDB RDS for MySQL tujuan. |
| Database Account | Akun database tujuan. Lihat Izin yang diperlukan. |
| Database Password | Kata sandi untuk akun database tujuan. |
| Encryption | Pilih Non-encrypted atau SSL-encrypted. Untuk menggunakan enkripsi SSL, aktifkan enkripsi SSL pada instans RDS sebelum mengonfigurasi tugas. Lihat Gunakan sertifikat cloud untuk mengaktifkan enkripsi SSL. |
Langkah 3: Uji konektivitas
Di bagian bawah halaman, klik Test Connectivity and Proceed, lalu klik Test Connectivity di kotak dialog CIDR Blocks of DTS Servers.
Blok CIDR server DTS harus ditambahkan (secara otomatis atau manual) ke pengaturan keamanan database sumber dan tujuan. Untuk detailnya, lihat Tambahkan blok CIDR server DTS.
Langkah 4: Konfigurasikan objek yang akan dimigrasikan
Di halaman Configure Objects, atur parameter berikut:
| Parameter | Deskripsi |
|---|---|
| Migration Types | Pilih jenis migrasi berdasarkan jalur Anda: <br>- Schema Migration + Full Data Migration: Hanya migrasi penuh.<br>- Schema Migration + Full Data Migration + Incremental Data Migration: Migrasi penuh + inkremental untuk migrasi tanpa downtime.<br><br> Catatan Jika Anda melewatkan Schema Migration, buat database dan tabel tujuan sebelum memulai tugas, dan aktifkan pemetaan nama objek di Selected Objects. Jika Anda melewatkan Incremental Data Migration, hentikan penulisan ke database sumber selama migrasi untuk menjaga konsistensi data. |
| Processing Mode of Conflicting Tables | Precheck and Report Errors (disarankan): Gagal dalam precheck jika tabel dengan nama identik ada di sumber dan tujuan. Gunakan pemetaan nama objek untuk mengganti nama tabel yang bentrok. Lihat Pemetaan nama objek. <br><br>Ignore Errors and Proceed: Lewati precheck untuk nama tabel identik. Gunakan dengan hati-hati — ini dapat menyebabkan ketidakkonsistenan data. Selama migrasi penuh, catatan yang sudah ada di tujuan dipertahankan. Selama migrasi inkremental, catatan yang sudah ada ditimpa. Jika skema berbeda, hanya kolom tertentu yang dimigrasikan atau tugas mungkin gagal. |
| Capitalization of Object Names in Destination Instance | Mengontrol kapitalisasi nama database, tabel, dan kolom di tujuan. DTS default policy dipilih secara default. Lihat Tentukan kapitalisasi nama objek. |
| Source Objects | Pilih tabel atau database dari bagian Source Objects, lalu klik  untuk menambahkannya ke Selected Objects. |
| Selected Objects | - Untuk mengganti nama satu objek, klik kanan objek tersebut di Selected Objects. Lihat Pemetaan nama satu objek.<br>- Untuk mengganti nama beberapa objek sekaligus, klik Batch Edit. Lihat Pemetaan nama beberapa objek sekaligus.<br>- Untuk memfilter baris, klik kanan tabel dan tentukan kondisi filter.<br><br> Catatan Mengganti nama objek dapat merusak objek lain yang bergantung padanya. |
Langkah 5: Konfigurasikan pengaturan lanjutan
Klik Next: Advanced Settings dan konfigurasikan parameter berikut:
| Parameter | Deskripsi |
|---|---|
| Retry Time for Failed Connections | Durasi waktu DTS mencoba kembali koneksi yang gagal setelah task dimulai. Nilai yang valid: 10–1.440 menit. Default: 720. Atur minimal 30 menit. DTS akan melanjutkan task jika koneksi berhasil dipulihkan dalam rentang waktu ini; jika tidak, task akan gagal.<br><br> Catatan Jika beberapa task menggunakan database sumber atau tujuan yang sama, retry time yang paling baru diatur akan berlaku untuk semuanya. DTS mengenakan biaya penggunaan instans selama proses retry. |
| Retry Time for Other Issues | Durasi waktu DTS mencoba kembali operasi DDL atau DML yang gagal. Nilai yang valid: 1–1.440 menit. Default: 10. Atur minimal 10 menit. Nilai ini harus lebih kecil daripada Retry Time for Failed Connections. |
| Enable Throttling for Full Data Migration | Membatasi penggunaan resource selama full migration untuk mengurangi beban pada database. Konfigurasikan Queries per second (QPS) to the source database, RPS of Full Data Migration, dan Data migration speed for full migration (MB/s). Opsi ini tersedia hanya jika Full Data Migration dipilih. |
| Enable Throttling for Incremental Data Migration | Membatasi penggunaan resource selama incremental migration. Konfigurasikan RPS of Incremental Data Migration dan Data migration speed for incremental migration (MB/s). Opsi ini tersedia hanya jika Incremental Data Migration dipilih. |
| Environment Tag | Tag opsional untuk mengidentifikasi instans DTS. |
| Configure ETL | Aktifkan fitur extract, transform, and load (ETL) untuk mentransformasi data selama migrasi. Pilih Yes dan masukkan statement pemrosesan di editor kode. Lihat What is ETL? dan Configure ETL. |
| Monitoring and Alerting | Atur peringatan untuk kegagalan task atau latensi migrasi yang melebihi ambang batas. Pilih Yes dan konfigurasikan ambang batas peringatan serta pengaturan notifikasi. Lihat Configure monitoring and alerting. |
Langkah 6: Konfigurasikan verifikasi data (opsional)
Klik Next Step: Data Verification untuk menyiapkan tugas verifikasi data. Untuk detailnya, lihat Konfigurasi tugas verifikasi data.
Langkah 7: Simpan pengaturan dan jalankan pemeriksaan awal
Untuk melihat pratinjau parameter API guna mengonfigurasi tugas ini secara terprogram, arahkan kursor ke Next: Save Task Settings and Precheck dan klik Preview OpenAPI parameters.
Untuk melanjutkan, klik Next: Save Task Settings and Precheck.
DTS menjalankan pemeriksaan awal sebelum migrasi dimulai. Tugas tidak dapat dimulai hingga pemeriksaan awal berhasil.
Jika pemeriksaan awal gagal, klik View Details di sebelah item yang gagal, selesaikan masalahnya, lalu klik Precheck Again.
Untuk peringatan pemeriksaan awal: jika peringatan tidak dapat diabaikan, perbaiki masalah dan jalankan kembali pemeriksaan awal. Jika dapat diabaikan, klik Confirm Alert Details, lalu Ignore, lalu OK, lalu Precheck Again. Mengabaikan peringatan dapat menyebabkan ketidakkonsistenan data.
Langkah 8: Beli instans dan mulai migrasi
Tunggu hingga Success Rate mencapai 100%, lalu klik Next: Purchase Instance.
Di halaman Purchase Instance, konfigurasikan hal berikut:
Parameter Deskripsi Resource Group Kelompok sumber daya untuk instans migrasi. Default: default resource group. Lihat Apa itu Resource Management? Instance Class Kecepatan migrasi tergantung pada kelas instans. Lihat Kelas instans migrasi data untuk memilih kelas sesuai beban kerja Anda. Baca dan terima Data Transmission Service (Pay-as-you-go) Service Terms dengan mencentang kotak centang.
Klik Buy and Start, lalu klik OK di dialog konfirmasi.
Monitor tugas di halaman Data Migration:
Hanya migrasi penuh: Tugas berhenti otomatis saat selesai. Status menunjukkan Completed.
Migrasi penuh + inkremental: Tugas berjalan terus-menerus. Status menunjukkan Running.
Parameter kluster Kafka
Saat Migrate Incremental Data diatur ke Yes, konfigurasikan kluster Kafka di bagian database sumber:
| Parameter | Deskripsi |
|---|---|
| Kafka Cluster Type | Lokasi penempatan kluster Kafka. Contoh ini menggunakan Self-managed Database on ECS. Jika Anda memilih Express Connect, VPN Gateway, or Smart Access Gateway, pilih juga VPC dari Connected VPC dan tentukan Domain Name or IP. |
| Kafka Data Source Component | Pilih berdasarkan metode yang digunakan di Persiapan: Use the default binlog format of the TiDB database. (TiDB Binlog) atau Use the TiCDC Canal-JSON format. (TiCDC). |
| ECS Instance ID | ID instans ECS yang menjalankan kluster Kafka. |
| Port Number | Port layanan Kafka. |
| Kafka Cluster Account | Username Kafka. Biarkan kosong jika autentikasi tidak diaktifkan. |
| Kafka Cluster Password | Kata sandi Kafka. Biarkan kosong jika autentikasi tidak diaktifkan. |
| Kafka Version | Versi Kafka. Jika versinya 1.0 atau lebih baru, pilih 1.0. |
| Encryption | Pilih Non-encrypted atau SCRAM-SHA-256 berdasarkan kebutuhan keamanan Anda. |
| Topic | Topik yang menerima data inkremental. Topik harus memiliki hanya satu partisi. |
Langkah selanjutnya
Setelah status tugas migrasi menunjukkan Completed atau latensi migrasi inkremental mencapai nol, alihkan aplikasi Anda ke database tujuan:
Hentikan penulisan ke database TiDB sumber.
Tunggu hingga latensi migrasi inkremental mencapai 0 dan tugas memproses semua perubahan yang tersisa.
Perbarui string koneksi aplikasi Anda agar mengarah ke instans ApsaraDB RDS for MySQL.
Jalankan
ANALYZE TABLE <table_name>pada tabel utama untuk memverifikasi integritas data.Hentikan atau lepas tugas migrasi DTS.