Data Transmission Service:Migrasi data dari RDS for MySQL ke AnalyticDB for PostgreSQL

Persyaratan database sumber

Binary logging (diperlukan untuk migrasi inkremental)

Konfigurasikan parameter log biner berikut pada database sumber sebelum menjalankan tugas migrasi inkremental.

Untuk pengaturan MySQL yang dikelola sendiri, lihat Buat akun dan konfigurasikan binary logging.

Untuk mengelola file log biner pada RDS MySQL, lihat Kelola file log biner.

Kendala tabel

• Tabel harus memiliki kendala PRIMARY KEY atau UNIQUE, dengan semua bidang unik. Jika tidak, catatan duplikat mungkin muncul di tujuan.

• Saat memigrasikan tabel tertentu (bukan seluruh database), satu tugas mendukung hingga 1.000 tabel. Untuk lebih dari 1.000 tabel, konfigurasikan beberapa tugas atau migrasikan seluruh database.

Pembatasan operasi selama migrasi

• Jangan mengeksekusi pernyataan DDL yang memodifikasi kunci primer atau menambahkan komentar (misalnya, ALTER TABLE table_name COMMENT='Table comment';).

• Jangan mengeksekusi pernyataan DDL yang mengubah skema database atau tabel selama migrasi skema dan migrasi data penuh.

• Jika hanya menjalankan migrasi data penuh, jangan menulis data ke database sumber. Untuk menghindari pembatasan ini, jalankan migrasi skema, migrasi data penuh, dan migrasi data inkremental bersamaan.

Batasan lain untuk database sumber

• MySQL 8.0.23 atau lebih baru — kolom tak terlihat: Jika tabel sumber berisi kolom tak terlihat, kolom tersebut tidak dapat dimigrasikan dan terjadi kehilangan data. Untuk membuat kolom terlihat, jalankan: ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;. Tabel tanpa kunci primer secara otomatis menghasilkan kunci primer tak terlihat — buat juga kunci tersebut terlihat. Lihat Invisible Columns dan Generated Invisible Primary Keys.

• Nilai DATETIME `0000-00-00 00:00:00`: DTS mengonversi nilai ini menjadi null di tujuan. Untuk menghindarinya, ubah sementara nilainya menjadi 0001-01-01 00:00:00 atau biarkan kolom tujuan kosong sebelum migrasi.

• Operasi perubahan log biner: Data yang dihasilkan oleh operasi perubahan log biner — seperti data yang dipulihkan dari backup fisik atau operasi kaskade — tidak dimigrasikan. Jika data ini tidak ada di tujuan, jalankan migrasi penuh lagi saat bisnis Anda memungkinkan.

• Fitur EncDB: Untuk instans ApsaraDB RDS for MySQL dengan fitur EncDB diaktifkan, migrasi data penuh tidak didukung.

• Transparent Data Encryption (TDE): Untuk instans ApsaraDB RDS for MySQL dengan TDE diaktifkan, migrasi skema, migrasi data penuh, dan migrasi data inkremental semuanya didukung.

Persyaratan database tujuan

• Hanya tabel yang dapat dipilih sebagai objek migrasi. View, trigger, dan prosedur tersimpan tidak dimigrasikan.

• Tipe data berikut tidak dapat dimigrasikan: VARBIT, GEOMETRY, ARRAY, UUID, TSQUERY, TSVECTOR, TXID_SNAPSHOT, dan POINT.

• Indeks awalan tidak dapat dimigrasikan. Jika database sumber berisi indeks awalan, tugas mungkin gagal.

• Jika tabel sumber memiliki kunci primer, kolom kunci primer di tujuan harus sesuai dengan sumber. Jika tabel sumber tidak memiliki kunci primer, kolom kunci primer dan kunci distribusi di tujuan harus sama.

• Kunci unik (yang berisi kolom kunci primer) di tujuan harus mencakup semua kolom dari kunci distribusinya.

• Tabel tujuan tidak boleh merupakan tabel append-optimized (AO).

• Jika pemetaan kolom digunakan atau skema sumber dan tujuan berbeda, kolom yang tidak ada di tujuan tidak akan dimigrasikan dan terjadi kehilangan data.

Pertimbangan kinerja dan operasional

• Evaluasi dampak migrasi terhadap kinerja database sumber dan tujuan sebelum memulai. Jalankan tugas migrasi selama jam sepi bila memungkinkan.

• Selama migrasi data penuh awal, operasi INSERT konkuren menyebabkan fragmentasi pada tabel tujuan. Setelah migrasi penuh selesai, ruang tabel tujuan mungkin lebih besar daripada sumber.

• Jika memigrasikan tabel tertentu (bukan seluruh database), jangan gunakan alat seperti pt-online-schema-change untuk operasi DDL Online pada objek yang sedang dimigrasikan. Gunakan Data Management (DMS) sebagai gantinya. Lihat Lakukan operasi DDL tanpa lock.

• Jangan menulis data dari sumber lain ke tujuan selama migrasi. Menulis dari beberapa sumber secara bersamaan dapat menyebabkan kehilangan data.

Kasus khusus untuk MySQL yang dikelola sendiri

• Alih bencana primary/secondary pada database sumber saat tugas migrasi sedang berjalan menyebabkan tugas gagal.

• Latensi migrasi dihitung berdasarkan Waktu data migrasi terbaru dan waktu sumber saat ini. Jika tidak ada operasi DML yang dijalankan di sumber dalam periode panjang, pembacaan latensi mungkin tidak akurat. Untuk memperbarui latensi, eksekusi operasi DML di sumber. Jika seluruh database dipilih sebagai objek migrasi, buat tabel heartbeat yang menerima pembaruan data setiap detik.

• DTS secara berkala mengeksekusi CREATE DATABASE IF NOT EXISTS \test\`` pada database sumber untuk memajukan Posisi file log biner.

Kasus khusus untuk ApsaraDB RDS for MySQL

• Dalam migrasi data inkremental, instans ApsaraDB RDS for MySQL yang tidak mencatat log transaksi — seperti instans RDS MySQL V5.6 read-only — tidak dapat digunakan sebagai sumber.

• DTS secara berkala mengeksekusi CREATE DATABASE IF NOT EXISTS \test\`` pada database sumber untuk memajukan Posisi file log biner.

• Selama migrasi skema, DTS memigrasikan kunci asing dari database sumber ke database tujuan. Selama migrasi data penuh dan migrasi data inkremental, DTS sementara menonaktifkan pemeriksaan kendala kunci asing dan operasi kaskade pada tingkat sesi. Operasi cascade update dan delete pada sumber selama migrasi dapat menyebabkan ketidakkonsistenan data.

Langkah 1: Buka halaman Data Migration

Langkah 2: Konfigurasikan database sumber dan tujuan

Klik Create Task dan konfigurasikan parameter berikut.

Pengaturan tugas:

Source Database

Destination Database

Klik Test Connectivity and Proceed.

Blok CIDR server DTS harus ditambahkan ke pengaturan keamanan database sumber dan tujuan. DTS menambahkannya secara otomatis untuk instans Alibaba Cloud. Untuk database yang dikelola sendiri, klik Test Connectivity di kotak dialog CIDR Blocks of DTS Servers. Lihat Tambahkan blok CIDR server DTS.

Langkah 3: Pilih jenis dan objek migrasi

Di halaman Configure Objects, konfigurasikan parameter berikut.

Klik Next: Advanced Settings.

Langkah 4: Konfigurasikan pengaturan lanjutan

Klik Next Step: Data Verification untuk mengonfigurasi tugas verifikasi data. Untuk informasi selengkapnya, lihat Mengonfigurasi tugas verifikasi data.

(Opsional) Konfigurasikan kolom kunci primer dan kunci distribusi untuk tabel AnalyticDB for PostgreSQL tujuan. Lihat CREATE TABLE.

Opsi ini tersedia hanya jika Schema Migration dipilih.

Langkah 5: Jalankan Pemeriksaan Awal dan beli instans migrasi

1. Klik Next: Save Task Settings and Precheck.

   Untuk melihat parameter API untuk konfigurasi tugas ini, arahkan kursor ke Next: Save Task Settings and Precheck dan klik Preview OpenAPI parameters.

2. Tunggu hingga Pemeriksaan Awal selesai.

   • Jika item pemeriksaan gagal, klik View Details di samping item yang gagal, perbaiki masalahnya, lalu klik Precheck Again.

   • Jika item pemeriksaan menghasilkan peringatan yang ingin Anda abaikan, klik Confirm Alert Details, lalu Ignore, lalu OK, lalu Precheck Again. Mengabaikan peringatan dapat menyebabkan ketidakkonsistenan data.

3. Setelah Success Rate mencapai 100%, klik Next: Purchase Instance.

4. Di halaman Purchase Instance, konfigurasikan parameter instans.

   Parameter	Deskripsi
   Resource Group	Kelompok sumber daya untuk instans migrasi. Default: default resource group. Lihat Apa itu Resource Management?
   Instance Class	Pilih kelas instans berdasarkan kecepatan migrasi yang diperlukan. Lihat Kelas instans migrasi data.

5. Baca dan terima Data Transmission Service (Pay-as-you-go) Service Terms, lalu klik Buy and Start. Di dialog konfirmasi, klik OK.