All Products
Search
Document Center

:Migrasi data dari instance ApsaraDB RDS for MySQL Enterprise Edition ke instance PolarDB-X 2.0 Standard Edition

Last Updated:Nov 09, 2025

Topik ini memberikan gambaran tentang migrasi data dari instance ApsaraDB RDS for MySQL Enterprise Edition ke instance PolarDB-X 2.0 Standard Edition.

Pendahuluan

Untuk memigrasikan data dari instance ApsaraDB RDS for MySQL Enterprise Edition ke instance PolarDB-X 2.0 Standard Edition, buat instance tujuan PolarDB-X 2.0 Standard Edition dan sinkronkan data dari instance sumber ApsaraDB RDS for MySQL Enterprise Edition. Setelah migrasi, instance tujuan PolarDB-X 2.0 Standard Edition akan mencakup informasi akun, database, daftar putih alamat IP, serta pengaturan parameter yang identik dengan instance sumber.

Catatan

Migrasi data dari instance ApsaraDB RDS for MySQL Enterprise Edition ke instance PolarDB-X 2.0 Standard Edition dilakukan melalui tugas sinkronisasi data menggunakan Data Transmission Service (DTS).

Untuk menyinkronkan data melalui DTS, buat tugas sinkronisasi untuk mentransfer skema database, tabel, dan data penuh dari instance sumber ApsaraDB RDS for MySQL Enterprise Edition ke instance tujuan PolarDB-X 2.0 Standard Edition. Kemudian, lanjutkan dengan menyinkronkan data tambahan. Untuk detail lebih lanjut, lihat Apa itu Data Transmission Service?.

Untuk memigrasikan data dari instance ApsaraDB RDS for MySQL Enterprise Edition, pastikan instance tersebut memenuhi persyaratan berikut untuk mesin database dan jenis penyimpanan.

Versi mesin database

Jenis penyimpanan

MySQL 5.6, MySQL 5.7, dan MySQL 8.0

SSD Lokal

Manfaat

Fitur migrasi ini menawarkan manfaat sebagai berikut:

  • Titik akhir dapat beralih antara instance sumber dan tujuan, memungkinkan Anda memindahkan bisnis dari instance sumber ke instance tujuan PolarDB-X 2.0 Standard Edition tanpa perlu mengubah konfigurasi koneksi aplikasi.

  • Tidak ada biaya untuk fitur migrasi data.

  • Tidak ada kehilangan data selama proses migrasi.

  • Mendukung migrasi data tambahan.

  • Mendukung migrasi panas dengan hanya satu koneksi transien saat memindahkan bisnis dari instance sumber ApsaraDB RDS for MySQL Enterprise Edition ke instance tujuan PolarDB-X 2.0 Standard Edition.

  • Anda dapat secara manual beralih titik akhir antara instance sumber dan tujuan. Hindari operasi penulisan selama pergantian titik akhir. Durasi pergantian dapat dikontrol sesuai kebutuhan bisnis, biasanya selesai dalam waktu 10 menit.

  • Jika migrasi gagal, Anda dapat membatalkannya. Pembatalan biasanya selesai dalam waktu 10 menit.

Prasyarat

  • Instance sumber ApsaraDB RDS for MySQL Enterprise Edition harus menggunakan mesin penyimpanan InnoDB atau X-Engine.

  • Akun istimewa dibuat jika Database Proxy (Mode Aman) diaktifkan untuk instance sumber ApsaraDB RDS for MySQL Enterprise Edition. Untuk informasi tentang cara membuat akun istimewa, lihat Buat Akun. Anda juga dapat beralih instance sumber ke mode performa tinggi. Untuk informasi lebih lanjut, lihat [Perubahan Produk/Perubahan Fitur] Mode koneksi jaringan instance ApsaraDB RDS ditingkatkan.

Batasan

  • Anda hanya dapat memigrasikan data dari instance ApsaraDB RDS for MySQL Enterprise Edition ke instance PolarDB-X 2.0 Standard Edition dengan versi mesin database yang sama atau lebih tinggi.

  • Alamat IPv6 tidak didukung dalam pergantian titik akhir.

  • Saat menyinkronkan data menggunakan tugas sinkronisasi DTS, perhatikan batasan berikut:

    • Sinkronisasi data lintas wilayah tidak didukung.

    • Jangan modifikasi parameter instance sumber ApsaraDB RDS for MySQL Enterprise Edition selama migrasi.

    • Hanya database, tabel, tampilan, prosedur tersimpan, dan fungsi yang dapat dimigrasikan.

      Catatan

      Informasi akun, daftar putih alamat IP, dan parameter dari instance sumber ApsaraDB RDS for MySQL Enterprise Edition dimigrasikan di konsol PolarDB-X alih-alih menggunakan DTS.

    • Tabel berikut menjelaskan batasan pada instance sumber ApsaraDB RDS for MySQL Enterprise Edition.

      Kategori

      Deskripsi

      Batasan pada database sumber

      • Tabel yang akan disinkronkan harus memiliki PRIMARY KEY atau batasan UNIQUE, dan semua bidang harus unik. Jika tidak, database tujuan mungkin berisi catatan data duplikat.

        • Jika Anda memilih tabel sebagai objek yang akan disinkronkan dan Anda perlu mengedit tabel (seperti mengganti nama tabel atau kolom) di database tujuan, hingga 1.000 tabel dapat disinkronkan dalam satu tugas sinkronisasi data. Jika Anda menjalankan tugas untuk menyinkronkan lebih dari 1.000 tabel, kesalahan akan dikembalikan. Dalam hal ini, kami sarankan Anda membagi tabel dan mengonfigurasi beberapa tugas untuk menyinkronkan tabel, atau mengonfigurasi tugas untuk menyinkronkan seluruh database.

        • Persyaratan berikut untuk log biner harus dipenuhi:

          • Fitur pencatatan biner diaktifkan dan parameter binlog_row_image diatur ke full. Untuk informasi lebih lanjut tentang cara mengaktifkan fitur pencatatan biner, lihat Ubah parameter instance ApsaraDB RDS for MySQL. Jika tidak, kesalahan akan dilaporkan selama pra-pemeriksaan dan tugas sinkronisasi data tidak dapat dimulai.

          • Untuk tugas sinkronisasi data tambahan, log biner dari database sumber harus disimpan setidaknya selama 24 jam. Untuk tugas sinkronisasi data penuh dan tambahan, log biner dari database sumber harus disimpan setidaknya selama tujuh hari. Setelah sinkronisasi data penuh selesai, Anda dapat mengatur periode retensi menjadi lebih dari 24 jam. Jika tidak, DTS mungkin gagal mendapatkan log biner dan tugas mungkin gagal. Dalam keadaan ekstrem, inkonsistensi data atau kehilangan data mungkin terjadi. Pastikan periode retensi log biner dikonfigurasi berdasarkan persyaratan yang ditentukan. Masalah yang terjadi karena ketidakpatuhan terhadap persyaratan tidak dicakup oleh jaminan SLA DTS. Untuk informasi lebih lanjut tentang cara mengelola log biner dari instance sumber ApsaraDB RDS for MySQL Enterprise Edition, lihat Kelola file log biner.

    • Tabel berikut menjelaskan batasan pada pernyataan SQL.

      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

      • TRUNCATE TABLE

    • Tabel berikut menjelaskan batasan lainnya.

      Kategori

      Deskripsi

      Batasan lainnya

      • Sebelum Anda menyinkronkan data, evaluasi dampak sinkronisasi data pada kinerja database sumber dan tujuan. Kami sarankan Anda menyinkronkan data selama jam-jam sepi. Selama sinkronisasi data penuh awal, DTS menggunakan sumber daya baca dan tulis dari database sumber dan tujuan. Ini dapat meningkatkan beban pada server database.

      • Selama sinkronisasi data penuh, operasi INSERT konkuren menyebabkan fragmentasi dalam tabel database tujuan. Setelah sinkronisasi data penuh selesai, ukuran tablespace yang digunakan oleh database tujuan lebih besar daripada yang digunakan oleh database sumber.

      • Selama sinkronisasi data, ketidaksesuaian data antara database sumber dan tujuan terjadi jika data dari sumber lain ditulis ke database tujuan. Misalnya, jika Anda menggunakan Data Management (DMS) untuk mengeksekusi pernyataan DDL online selama sinkronisasi data, kehilangan data mungkin terjadi di database tujuan.

      • Secara default, DTS menonaktifkan batasan FOREIGN KEY untuk database tujuan dalam tugas sinkronisasi data. Dalam hal ini, operasi tertentu seperti operasi kaskade dan hapus dari database sumber tidak disinkronkan ke database tujuan.

Catatan penggunaan

Konfigurasi SSL titik akhir instance sumber ApsaraDB RDS for MySQL Enterprise Edition dan instance tujuan PolarDB-X 2.0 Standard Edition harus sama.

  • Jika opsi Pergantian Titik Akhir dipilih dan SSL diaktifkan untuk titik akhir instance sumber ApsaraDB RDS for MySQL Enterprise Edition, pastikan bahwa SSL diaktifkan untuk titik akhir instance tujuan PolarDB-X 2.0 Standard Edition.

  • Jika SSL dinonaktifkan untuk titik akhir instance sumber ApsaraDB RDS for MySQL Enterprise Edition, pastikan bahwa SSL dinonaktifkan untuk titik akhir instance PolarDB-X 2.0 Standard Edition.

Aturan penagihan

Sinkronisasi data selama migrasi gratis. Biaya hanya dikenakan untuk instance tujuan PolarDB-X 2.0 Standard Edition.

Kebijakan cadangan

Jadwal cadangan instance tujuan PolarDB-X 2.0 Standard Edition sama dengan instance sumber ApsaraDB RDS for MySQL Enterprise Edition.

Setelah migrasi selesai, Anda dapat memodifikasi kebijakan cadangan instance PolarDB-X 2.0 Standard Edition.

Pergantian titik akhir

Jika Anda memilih opsi Pergantian Titik Akhir, titik akhir instance sumber ApsaraDB RDS for MySQL Enterprise Edition dan instance tujuan PolarDB-X 2.0 Standard Edition akan berganti secara otomatis selama migrasi. Setelah pergantian, Anda dapat terhubung ke instance tujuan PolarDB-X 2.0 Standard Edition tanpa perlu mengubah konfigurasi aplikasi. Gambar berikut mengilustrasikan pertukaran titik akhir antara instance sumber ApsaraDB RDS for MySQL Enterprise Edition dan instance tujuan PolarDB-X 2.0 Standard Edition setelah opsi Pergantian Titik Akhir dipilih.

Untuk menggunakan fitur pergantian titik akhir, perhatikan poin-poin berikut:

  • Fitur pergantian titik akhir hanya mengganti titik akhir antara instance sumber ApsaraDB RDS for MySQL Enterprise Edition dan instance tujuan PolarDB-X 2.0 Standard Edition. vSwitch dan VIP tidak diganti.

  • Titik akhir hanya dapat diganti jika instance sumber ApsaraDB RDS for MySQL Enterprise Edition dan instance tujuan PolarDB-X 2.0 Standard Edition memiliki titik akhir. Secara default, hanya titik akhir privat utama yang diganti.

  • Titik akhir yang menggunakan alamat IPv6 tidak diganti.

  • Port tidak diganti antara instance sumber ApsaraDB RDS for MySQL Enterprise Edition dan instance tujuan PolarDB-X 2.0 Standard Edition. Pastikan kedua instance menggunakan port yang sama, yaitu 3306 secara default. Untuk informasi tentang cara mengubah port, lihat Lihat dan kelola titik akhir dan port instance.

  • Setelah titik akhir diganti, entri DNS asli mungkin tetap ada di cache hingga kedaluwarsa. Selama periode ini, Anda mungkin gagal terhubung ke instance PolarDB-X 2.0 Standard Edition, atau instance tersebut mungkin hanya mengizinkan operasi baca. Untuk menyelesaikan masalah ini, segarkan cache DNS.

    Catatan

    Segarkan cache DNS berdasarkan sistem operasi dan versi server Anda. Contoh berikut menggunakan Alibaba Cloud Linux 2/3.

    1. Periksa apakah layanan systemd-resolved sedang berjalan. Jika layanan aktif, Active: active (running) akan ditampilkan.

      sudo systemctl status systemd-resolved
    2. Segarkan cache DNS layanan systemd-resolved.

      sudo systemd-resolve --flush-caches
  • Jika ingin mengakses instance PolarDB-X 2.0 Standard Edition menggunakan DMS setelah pergantian titik akhir, masuk menggunakan versi terbaru DMS dan ID instance PolarDB-X 2.0 Standard Edition.