All Products
Search

This Product

    Data Transmission Service:Migrasi RDS for MySQL ke PolarDB for MySQL

    Document Center

    Data Transmission Service:Migrasi RDS for MySQL ke PolarDB for MySQL

    Last Updated:Jul 18, 2026

    Gunakan Data Transmission Service (DTS) untuk memigrasikan data dari database MySQL ke kluster PolarDB for MySQL.

    Database sumber yang didukung

    Database MySQL sumber dapat berupa salah satu jenis berikut. Topik ini menggunakan instans ApsaraDB RDS for MySQL sebagai contoh. Proses konfigurasi untuk jenis database sumber lainnya serupa.

    • Instans ApsaraDB RDS for MySQL.

    • Database yang dikelola sendiri:

      • Database yang dikelola sendiri dengan alamat IP publik
      • Database yang dikelola sendiri yang dihosting di Elastic Compute Service (ECS)
      • Database yang dikelola sendiri yang terhubung melalui Express Connect, VPN Gateway, atau Smart Access Gateway
      • Database yang dikelola sendiri yang terhubung melalui Database Gateway

    Prasyarat

    Batasan

    Catatan

    Jenis

    Deskripsi

    Batasan database sumber

    • Persyaratan bandwidth: Server yang menghosting database sumber harus memiliki bandwidth outbound yang cukup. Jika tidak, laju migrasi data akan terpengaruh.

    • Tabel yang akan dimigrasikan harus memiliki primary key atau unique constraint dengan nilai kolom unik. Jika tidak, data duplikat mungkin dihasilkan di database tujuan.

    • Jika objek migrasi berada pada level tabel dan Anda perlu mengeditnya (misalnya, untuk memetakan nama kolom), satu tugas migrasi mendukung maksimal 1.000 tabel. Jika jumlahnya melebihi batas, kesalahan akan dikembalikan saat Anda mengirimkan tugas. Dalam kasus ini, bagi tabel yang akan dimigrasikan dan konfigurasikan migrasi dalam beberapa tugas, atau konfigurasikan tugas migrasi level database.

    • Jika Anda melakukan migrasi inkremental, log biner harus memenuhi persyaratan berikut:

      • Pencatatan log biner harus diaktifkan, dengan binlog_format diatur ke row dan binlog_row_image diatur ke full. Jika tidak, pemeriksaan awal akan melaporkan kesalahan dan tugas migrasi data tidak dapat dimulai.

        Penting

        Jika instans sumber MySQL yang dikelola sendiri merupakan klaster dual-primary (kedua server saling menjadi primary dan replica satu sama lain), aktifkan parameter log_slave_updates untuk memastikan DTS menangkap semua log biner.

      • Instans ApsaraDB RDS for MySQL harus menyimpan log biner lokal minimal selama tiga hari (tujuh hari direkomendasikan). Database MySQL yang dikelola sendiri harus menyimpan log biner lokal minimal selama tujuh hari. Jika tidak, DTS mungkin gagal mengambil log biner dan tugas bisa gagal. Dalam kasus ekstrem, ketidakkonsistenan data atau kehilangan data dapat terjadi. Masalah yang disebabkan oleh pengaturan periode retensi log biner lebih pendek dari persyaratan DTS tidak dicakup oleh SLA DTS.

        Catatan

        Untuk cara mengonfigurasi retention period log biner lokal pada instans ApsaraDB RDS for MySQL, lihat Konfigurasi penghapusan otomatis (kebijakan retensi log lokal).

    • Batasan operasi database sumber:

      • Selama fase migrasi skema dan migrasi data penuh, jangan lakukan operasi DDL yang mengubah skema database atau tabel. Jika dilakukan, tugas migrasi data akan gagal.

        Catatan

        Selama fase migrasi data penuh, DTS melakukan query ke database sumber, yang menghasilkan metadata lock yang dapat memblokir operasi DDL pada database sumber.

      • Jika Anda hanya melakukan migrasi data penuh, jangan menulis data baru ke instans sumber. Jika tidak, akan terjadi ketidakkonsistenan data antara sumber dan tujuan. Untuk menjaga konsistensi data secara real time, kami merekomendasikan Anda memilih Migrasi skema, Migrasi data penuh, dan Migrasi data inkremental.

    • Saat instans migrasi sedang berjalan, data yang dihasilkan oleh operasi yang tidak ditulis ke log biner (seperti data yang dipulihkan melalui backup fisik atau dihasilkan oleh operasi kaskade) tidak dimigrasikan ke database tujuan.

      Catatan

      Jika hal ini terjadi dan bisnis Anda mengizinkan, jalankan kembali migrasi data penuh.

    • Jika database sumber adalah MySQL 8.0.23 atau versi lebih baru dan data yang akan dimigrasikan berisi kolom tak terlihat (invisible columns), kehilangan data dapat terjadi karena DTS tidak dapat mengambil data dari kolom tersebut.

      Catatan

      Anda dapat menggunakan pernyataan ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; untuk membuat kolom tak terlihat menjadi terlihat. Untuk informasi selengkapnya, lihat Invisible Columns.

    • Kompatibilitas MySQL: Saat DTS memigrasikan data dari database sumber keluarga MySQL, DTS mengandalkan protokol standar MySQL dan format log biner. Perilaku yang tidak kompatibel dengan standar MySQL tidak didukung. Jika database sumber Anda mengklaim kompatibel dengan MySQL tetapi berperilaku berbeda dari MySQL (misalnya, saat OceanBase bertindak sebagai database sumber kompatibel MySQL, timestamp event rotate di akhir log biner bernilai 0, yang tidak sesuai dengan MySQL), tugas migrasi DTS dapat gagal secara tak terduga.

    Batasan lainnya

    • Kami merekomendasikan agar database sumber dan tujuan menggunakan versi MySQL yang sama demi kompatibilitas.

    • Jika database sumber Anda menggunakan operasi DDL Online berbasis temporary-table-mode—termasuk skenario penggabungan multi-tabel—atau menambahkan function-based indexes ke kolom unique key, kehilangan data atau kegagalan tugas dapat terjadi di database tujuan.

    • Parser yang didefinisikan menggunakan sintaks komentar tidak dapat dimigrasikan.

    • Jika terjadi konflik primary key atau unique key selama migrasi:

      • Jika skema tabel konsisten dan sebuah record di database tujuan memiliki nilai primary key yang sama dengan record di database sumber:

        • Selama migrasi penuh, DTS menyimpan record di database tujuan. Record dari database sumber tidak dimigrasikan.

        • Selama migrasi inkremental, DTS tidak menyimpan record di database tujuan. Record dari database sumber menimpa record di database tujuan.

      • Jika skema tabel tidak konsisten, hanya sebagian kolom data yang mungkin dimigrasikan, atau migrasi dapat gagal. Harap berhati-hati.

    • Sebelum migrasi, evaluasi kinerja database sumber dan tujuan. Kami merekomendasikan Anda memigrasikan data selama jam sepi, karena DTS mengonsumsi sumber daya baca dan tulis pada kedua database selama migrasi data penuh, yang dapat meningkatkan beban database.

    • Karena migrasi data penuh menjalankan operasi INSERT secara konkuren, fragmentasi tabel terjadi di database tujuan. Setelah migrasi data penuh, ruang penyimpanan tabel di database tujuan lebih besar daripada instans sumber.

    • Jika data yang akan dimigrasikan berisi konten yang memerlukan penyimpanan empat byte (seperti karakter langka atau emoji), database dan tabel tujuan yang menerima data tersebut harus menggunakan set karakter utf8mb4.

      Catatan

      Jika Anda menggunakan DTS untuk memigrasikan skema, atur parameter tingkat instans character_set_server ke utf8mb4 pada database tujuan.

    • Verifikasi apakah presisi migrasi yang diterapkan DTS pada kolom FLOAT dan DOUBLE memenuhi kebutuhan bisnis Anda. DTS membaca nilai kolom tersebut dengan memanggil ROUND(COLUMN,PRECISION). Jika presisi tidak didefinisikan secara eksplisit, DTS memigrasikan FLOAT dengan presisi 38 digit dan DOUBLE dengan presisi 308 digit.

    • DTS mencoba melanjutkan tugas migrasi yang gagal dalam waktu tujuh hari. Oleh karena itu, sebelum mengalihkan bisnis Anda ke instans tujuan, selesaikan atau rilis tugas tersebut, atau jalankan perintah revoke untuk mencabut izin tulis akun yang digunakan DTS untuk mengakses instans tujuan. Hal ini mencegah tugas dilanjutkan secara otomatis dan menimpa data di instans tujuan dengan data dari sumber.

    • DTS tidak mendukung konversi data datetime ke varchar.

    • Jika pernyataan DDL gagal ditulis ke database tujuan, tugas DTS tetap berjalan. Anda harus melihat pernyataan DDL yang gagal di log tugas. Untuk cara melihat log tugas, lihat Lihat log tugas.

    • Jika Fully Encrypted Database (EncDB) diaktifkan pada instans RDS MySQL, migrasi data penuh tidak didukung.

      Catatan

      Instans RDS MySQL yang telah mengaktifkan Transparent Data Encryption (TDE) mendukung migrasi skema, migrasi data penuh, dan migrasi data inkremental.

    • Untuk memigrasikan akun dari database sumber, Anda harus memenuhi prasyarat yang berlaku dan memahami pertimbangan terkait. Untuk informasi selengkapnya, lihat Migrasi akun database.

    • Jika tugas gagal, staf dukungan DTS akan mencoba memulihkannya dalam waktu delapan jam. Selama pemulihan, mereka mungkin merestart tugas atau menyesuaikan parameternya.

      Catatan

      Hanya parameter tugas DTS yang dimodifikasi—bukan parameter database. Parameter yang mungkin disesuaikan termasuk yang tercantum di Modifikasi parameter instans.

    Kasus khusus

    • Saat database sumber adalah database MySQL yang dikelola sendiri:

      • Jika database sumber melakukan alih bencana primary/secondary selama migrasi, tugas migrasi akan gagal.

      • Latensi migrasi yang dilaporkan oleh DTS adalah selisih antara timestamp data terbaru yang dimigrasikan ke database tujuan dan timestamp saat ini. Jika database sumber tidak melakukan operasi DML dalam waktu lama, latensi yang dilaporkan mungkin tidak akurat. Jika latensi yang ditampilkan tampak terlalu tinggi, jalankan operasi DML pada database sumber untuk memperbarui latensi.

        Catatan

        Jika Anda memigrasikan seluruh database, Anda juga dapat membuat tabel heartbeat yang diperbarui atau ditulis secara berkala (misalnya, setiap detik).

      • DTS secara berkala menjalankan pernyataan CREATE DATABASE IF NOT EXISTS `test` pada database sumber untuk memajukan posisi log biner.

      • Jika database sumber adalah Amazon Aurora MySQL atau mode klaster MySQL lainnya, pastikan nama domain atau alamat IP yang dikonfigurasi untuk tugas—dan resolusi DNS-nya—selalu mengarah ke node read/write (RW). Jika tidak, tugas migrasi mungkin tidak berjalan dengan baik.

    • Saat database sumber adalah RDS MySQL:

      • Untuk memigrasikan data inkremental, instans RDS MySQL yang tidak mencatat log transaksi (seperti instans hanya baca RDS MySQL 5.6) tidak dapat digunakan sebagai database sumber.

      • DTS secara berkala menjalankan pernyataan CREATE DATABASE IF NOT EXISTS `test` pada database sumber untuk memajukan posisi log biner.

    • Saat database tujuan adalah PolarDB MySQL Edition:

      • DTS secara otomatis membuat database di PolarDB for MySQL. Jika nama database yang akan dimigrasikan tidak memenuhi konvensi penamaan PolarDB for MySQL, Anda harus membuat database tersebut di PolarDB for MySQL sebelum mengonfigurasi tugas migrasi. Untuk operasi terkait, lihat Kelola database.

      • Anda tidak dapat menyesuaikan laju migrasi penuh.

    Penagihan

    Jenis migrasi

    Biaya konfigurasi instans

    Biaya lalu lintas internet

    Migrasi skema dan migrasi data penuh

    Gratis.

    Anda dikenai biaya lalu lintas internet ketika Access Method database tujuan diatur ke Public IP Address. Untuk informasi selengkapnya, lihat Ikhtisar Penagihan.

    Migrasi data inkremental

    Dikenai biaya. Untuk informasi selengkapnya, lihat Ikhtisar penagihan.

    Jenis migrasi

    • Migrasi skema

      DTS memigrasikan definisi skema objek yang dipilih dari database sumber ke database tujuan.

      • DTS mendukung migrasi skema untuk tabel, view, trigger, prosedur tersimpan, dan fungsi.

        Catatan

        routine_body prosedur tersimpan, routine_body fungsi, dan select_statement view tidak dimodifikasi.

      • Selama migrasi skema, DTS mengubah `DEFINER` menjadi `INVOKER` untuk view, prosedur tersimpan, dan fungsi yang akan dimigrasikan. Tindakan ini mengubah nilai `SQL SECURITY` menjadi `INVOKER`. DTS juga mengatur `DEFINER` ke akun database tujuan yang digunakan untuk tugas migrasi.

        Catatan

        Metode otentikasi keamanan dan definer database sumber tidak dimodifikasi.

      • Karena DTS tidak memigrasikan informasi pengguna, Anda harus memberikan izin baca dan tulis kepada invoker untuk memanggil view, prosedur tersimpan, dan fungsi di database tujuan.

    • Migrasi penuh

      DTS memigrasikan semua data historis objek yang dipilih dari database sumber ke database tujuan.

    • Migrasi inkremental

      Setelah migrasi penuh selesai, DTS memigrasikan perubahan data inkremental dari sumber ke database tujuan, sehingga Anda dapat memigrasikan data tanpa mengganggu aplikasi yang dikelola sendiri.

    Operasi SQL untuk migrasi inkremental

    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

      Penting

      Operasi RENAME TABLE dapat menyebabkan ketidakkonsistenan data. Misalnya, jika Anda hanya memilih satu tabel sebagai objek migrasi dan mengganti nama tabel tersebut di instans sumber selama migrasi, data tabel ini tidak dimigrasikan ke database tujuan. Untuk mencegah masalah ini, pilih seluruh database tempat tabel tersebut berada sebagai objek migrasi saat mengonfigurasi tugas migrasi data. Pastikan database tempat tabel berada sebelum dan sesudah operasi RENAME TABLE termasuk dalam objek migrasi.

    • TRUNCATE TABLE

    Izin yang diperlukan untuk akun database

    Database

    Migrasi skema

    Migrasi data penuh

    Migrasi data inkremental

    Instans ApsaraDB RDS for MySQL

    Izin SELECT

    Izin SELECT

    Izin REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW, dan SELECT

    Kluster PolarDB for MySQL

    Izin baca dan tulis

    Untuk petunjuk membuat akun database dan memberikan izin, lihat:

    Prosedur

    1. Buka halaman daftar tugas migrasi untuk wilayah tujuan menggunakan salah satu metode berikut.

      Dari Konsol DTS

      1. Login ke Konsol Data Transmission Service (DTS).

      2. Di panel navigasi kiri, klik Data Migration.

      3. Di pojok kiri atas halaman, pilih wilayah tempat instans migrasi berada.

      Dari Konsol DMS

      Catatan

      Operasi aktual dapat berbeda tergantung pada mode dan tata letak Konsol DMS. Untuk informasi selengkapnya, lihat Konsol mode sederhana dan Sesuaikan tata letak dan gaya Konsol DMS.

      1. Login ke Konsol Data Management (DMS).

      2. Di bilah menu atas, pilih Data + AI > Data Transmission (DTS) > Data Migration.

      3. Di sebelah kanan Data Migration Tasks, pilih wilayah tempat instans migrasi berada.

    2. Klik Create Task untuk membuka halaman konfigurasi tugas.

    3. Opsi: Di pojok kanan atas halaman, klik New Configuration Page.

      Catatan

      • Jika Anda sudah berada di halaman konfigurasi baru (tombol di pojok kanan atas adalah Back to Previous Version), Anda dapat melewati langkah ini.

      • Parameter pada halaman konfigurasi baru dan lama berbeda. Kami merekomendasikan Anda menggunakan halaman konfigurasi baru.

    4. Konfigurasikan database sumber dan tujuan.

      Peringatan

      Setelah memilih instans sumber dan tujuan, baca Limits di bagian atas halaman untuk memastikan tugas migrasi dapat dibuat dan dijalankan dengan sukses.

      Bagian

      Parameter

      Deskripsi

      N/A

      Task Name

      DTS menghasilkan nama tugas secara otomatis. Tentukan nama deskriptif untuk memudahkan identifikasi. Nama tidak perlu unik.

      Source Database

      Select a DMS database instance.

      Pilih instans yang ada sesuai kebutuhan.

      • Jika Anda menggunakan instans yang ada, informasi database akan diisi otomatis. Anda tidak perlu memasukkannya lagi.

      • Jika Anda tidak menggunakan instans yang ada, konfigurasikan informasi database berikut.

      Catatan

      Database Type

      Pilih MySQL.

      Connection Type

      Pilih Alibaba Cloud Instance.

      Instance Region

      Pilih wilayah instans sumber ApsaraDB RDS for MySQL.

      Cross-account

      Contoh ini memigrasikan data dalam satu Akun Alibaba Cloud yang sama. Pilih No.

      RDS Instance ID

      Pilih ID instans sumber ApsaraDB RDS for MySQL.

      Database Account

      Masukkan akun database instans sumber ApsaraDB RDS for MySQL. Untuk informasi tentang izin yang diperlukan, lihat Izin yang diperlukan untuk akun database.

      Database Password

      Masukkan password untuk akun database.

      Connection Method

      Pilih Non-encrypted atau SSL-encrypted sesuai kebutuhan database Anda. Jika Anda mengatur parameter ini ke SSL-encrypted, Anda harus mengaktifkan enkripsi SSL untuk instans RDS for MySQL terlebih dahulu. Untuk informasi selengkapnya, lihat Aktifkan enkripsi SSL dengan cepat menggunakan sertifikat cloud.

      Destination Database

      Select a DMS database instance.

      Pilih instans yang ada sesuai kebutuhan.

      • Jika Anda menggunakan instans yang ada, informasi database akan diisi otomatis. Anda tidak perlu memasukkannya lagi.

      • Jika Anda tidak menggunakan instans yang ada, konfigurasikan informasi database berikut.

      Catatan

      Database Type

      Pilih PolarDB for MySQL.

      Connection Type

      Pilih Alibaba Cloud Instance.

      Instance Region

      Pilih wilayah kluster tujuan PolarDB for MySQL.

      PolarDB Cluster ID

      Pilih ID kluster tujuan PolarDB for MySQL.

      Database Account

      Masukkan akun database untuk kluster tujuan PolarDB for MySQL. Untuk informasi tentang izin yang diperlukan, lihat Izin yang diperlukan untuk akun database.

      Database Password

      Masukkan password untuk akun database.

      Encryption

      Pilih jenis koneksi sesuai kebutuhan. Untuk informasi selengkapnya tentang fitur enkripsi SSL, lihat Aktifkan enkripsi SSL.

    5. Setelah menyelesaikan konfigurasi, klik Test Connectivity and Proceed di bagian bawah halaman.

      Jika database sumber atau tujuan adalah instans database Alibaba Cloud, seperti instans RDS for MySQL atau ApsaraDB for MongoDB, DTS secara otomatis menambahkan blok CIDR server DTS ke daftar putih alamat IP instans tersebut. Jika database sumber atau tujuan adalah database yang dikelola sendiri yang dihosting di instans ECS, DTS secara otomatis menambahkan blok CIDR server DTS ke aturan grup keamanan instans ECS. Anda juga harus memastikan database dapat diakses dari instans ECS. Jika database yang dikelola sendiri dihosting di beberapa instans ECS, Anda harus secara manual menambahkan blok CIDR server DTS ke aturan grup keamanan setiap instans ECS. Jika database sumber atau tujuan adalah database yang dikelola sendiri yang ditempatkan di pusat data lokal atau disediakan oleh penyedia layanan cloud pihak ketiga, Anda harus secara manual menambahkan blok CIDR server DTS ke daftar putih alamat IP database untuk mengizinkan akses dari server DTS. Untuk informasi selengkapnya tentang alamat IP server DTS, lihat Blok CIDR server DTS.

      Peringatan

      Menambahkan blok alamat IP publik server DTS, baik secara otomatis maupun manual, dapat menimbulkan risiko keamanan. Dengan menggunakan produk ini, Anda mengakui dan menerima risiko potensial tersebut. Anda harus menerapkan langkah-langkah keamanan dasar, seperti menggunakan password kuat, membatasi port terbuka untuk setiap blok CIDR, menggunakan autentikasi untuk panggilan API internal, serta secara berkala memeriksa dan membatasi blok CIDR yang tidak diperlukan. Anda juga dapat terhubung menggunakan jaringan internal, seperti jalur sewa, VPN Gateway, atau Smart Access Gateway.

    6. Konfigurasikan objek tugas.

      1. Di halaman Configure Objects, konfigurasikan objek yang ingin dimigrasikan.

        Parameter

        Deskripsi

        Migration Types

        • Jika Anda hanya perlu melakukan migrasi penuh, pilih Schema Migration dan Full Data Migration.

        • Untuk melakukan migrasi tanpa downtime, pilih Schema Migration, Full Data Migration, dan Incremental Data Migration.

        Catatan

        • Jika Anda tidak memilih Schema Migration, Anda harus memastikan database dan tabel untuk menerima data sudah ada di database tujuan. Anda juga dapat menggunakan fitur pemetaan nama objek di kotak Selected Objects sesuai kebutuhan.

        • Jika Anda tidak memilih Incremental Data Migration, jangan menulis data baru ke instans sumber selama migrasi data untuk memastikan konsistensi data.

        Method to Migrate Triggers in Source Database

        Pilih metode untuk memigrasikan trigger berdasarkan kebutuhan bisnis Anda. Jika objek yang akan dimigrasikan tidak melibatkan trigger, Anda dapat melewati pengaturan ini. Untuk informasi selengkapnya, lihat Konfigurasi cara menyinkronkan atau memigrasikan trigger.

        Catatan

        Pengaturan ini tersedia hanya jika Migration Types dan Schema Migration dipilih untuk Incremental Data Migration.

        Processing Mode of Conflicting Tables

        • Precheck and Report Errors: Memeriksa apakah tabel dengan nama yang sama ada di database tujuan. Jika tidak ada tabel dengan nama yang sama, pemeriksaan awal lolos. Jika ada tabel dengan nama yang sama, kesalahan dilaporkan selama pemeriksaan awal, dan tugas migrasi data tidak dimulai.

          Catatan

          Jika tabel di database tujuan memiliki nama yang sama tetapi tidak dapat dengan mudah dihapus atau diganti namanya, Anda dapat mengubah nama tabel di database tujuan. Untuk informasi selengkapnya, lihat Pemetaan nama objek.

        • Ignore Errors and Proceed: Melewati pemeriksaan untuk tabel dengan nama yang sama.

          Peringatan

          Memilih Ignore Errors and Proceed dapat menyebabkan ketidakkonsistenan data dan risiko bisnis. Misalnya:

          • Jika skema tabel konsisten dan sebuah record di database tujuan memiliki nilai primary key yang sama dengan record di database sumber:

            • Selama migrasi penuh, DTS menyimpan record di database tujuan. Record dari database sumber tidak dimigrasikan.

            • Selama migrasi inkremental, DTS tidak menyimpan record di database tujuan. Record dari database sumber menimpa record di database tujuan.

          • Jika skema tabel tidak konsisten, hanya sebagian kolom data yang mungkin dimigrasikan, atau migrasi dapat gagal. Harap berhati-hati.

        Whether to migrate Event

        Pilih apakah akan memigrasikan event database sumber. Jika Anda memilih Yes, langkah tambahan diperlukan. Sinkronkan atau migrasikan event.

        Capitalization of Object Names in Destination Instance

        Anda dapat mengonfigurasi kebijakan case sensitivity untuk nama objek yang dimigrasikan, seperti database, tabel, dan kolom, di instans tujuan. Secara default, DTS default policy dipilih. Anda juga dapat memilih untuk menjaga case sensitivity konsisten dengan kebijakan default database sumber atau tujuan. Untuk informasi selengkapnya, lihat Case sensitivity nama objek di database tujuan.

        Source Objects

        Pilih satu atau beberapa objek dari bagian Source Objects. Klik ikon Rightwards arrow dan tambahkan objek ke bagian Selected Objects.

        Catatan

        Granularitas pemilihan objek migrasi adalah skema, tabel, dan kolom. Jika Anda hanya memilih tabel atau kolom sebagai objek migrasi, objek lain seperti view, trigger, dan prosedur tersimpan tidak dimigrasikan ke database tujuan.

        Selected Objects
        Catatan

        • Jika Anda menggunakan fitur pemetaan nama objek, migrasi objek lain yang bergantung pada objek yang diganti namanya mungkin gagal.

        • Untuk memfilter data menggunakan klausa WHERE, klik kanan tabel yang akan dimigrasikan di kotak Selected Objects dan tentukan kondisi filter di kotak dialog yang muncul. Untuk petunjuknya, lihat Atur kondisi filter.

        • Untuk memilih operasi SQL yang akan dimigrasikan pada level database atau tabel, klik kanan objek di kotak Selected Objects dan pilih operasi SQL yang diinginkan di kotak dialog yang muncul. Untuk daftar operasi yang didukung, lihat Operasi SQL yang didukung untuk migrasi inkremental.

      2. Klik Next: Advanced Settings untuk mengonfigurasi parameter lanjutan.

        Parameter

        Deskripsi

        Dedicated Cluster for Task Scheduling

        Secara default, DTS menjadwalkan tugas pada klaster bersama, dan tidak perlu pemilihan. Anda dapat membeli klaster khusus dengan spesifikasi tertentu untuk menjalankan tugas migrasi DTS. Untuk informasi selengkapnya, lihat Apa itu klaster khusus DTS?.

        Select the engine type of the destination database

        Pilih jenis mesin untuk database tujuan berdasarkan kebutuhan bisnis Anda.

        • InnoDB: Mesin penyimpanan default.

        • X-Engine: Mesin penyimpanan database untuk pemrosesan transaksi online (OLTP).

        Copy the temporary table of the Online DDL tool that is generated in the source table to the destination database.

        Jika Anda menggunakan Data Management (DMS) atau gh-ost untuk melakukan perubahan DDL online di database sumber, Anda dapat memilih apakah akan memigrasikan data dari tabel sementara yang dihasilkan oleh perubahan DDL online tersebut.

        Penting

        • Tugas DTS tidak mendukung penggunaan alat seperti pt-online-schema-change untuk melakukan perubahan DDL online. Jika dilakukan, tugas DTS akan gagal.

        • Metode pemrosesan untuk setiap fase adalah sebagai berikut: Fase Schema Migration dan Full Data Migration tidak mengizinkan operasi DDL yang mengubah struktur database atau tabel. Oleh karena itu, tidak dikendalikan oleh kebijakan DDL online.

          • Schema Migration: Tidak dikendalikan oleh kebijakan DDL online. Tabel sementara terkait dibuat.

          • Full Data Migration: Tidak dikendalikan oleh kebijakan DDL online. Migrasi tabel sementara tidak termasuk dalam objek migrasi penuh. Semua tabel yang namanya cocok dengan ekspresi reguler (^_(.+)_(?:gho|new)$ atau ^_(.+)_(?:ghc|del|old)$) difilter.

          • Incremental Data Migration: Dikendalikan oleh kebijakan DDL online.

            • Yes: Memigrasikan perubahan data dari tabel sementara (misalnya, _table_name_gho) yang dihasilkan oleh operasi DDL online.

            • No, Adapt to DMS Online DDL dan No, Adapt to gh-ost: Memfilter perubahan data dari tabel sementara (misalnya, _table_name_gho) yang dihasilkan oleh alat seperti gh-ost berdasarkan aturan ekspresi reguler.

        • Yes: Memigrasikan data dari tabel sementara yang dihasilkan oleh perubahan DDL online.

          Catatan

          Jika perubahan DDL online menghasilkan banyak data di tabel sementara, hal ini dapat menyebabkan latensi tugas.

        • No, Adapt to DMS Online DDL: Tidak memigrasikan data dari tabel sementara yang dihasilkan oleh perubahan DDL online. Hanya memigrasikan pernyataan DDL asli yang dieksekusi menggunakan Data Management (DMS).

          Catatan

          Opsi ini menyebabkan tabel di database tujuan terkunci.

        • No, Adapt to gh-ost: Tidak memigrasikan data dari tabel sementara yang dihasilkan oleh perubahan DDL online. Mendukung aturan filtering kustom. DTS memfilter perubahan data dari tabel sementara (misalnya, _table_name_gho) yang dihasilkan oleh alat seperti gh-ost berdasarkan aturan ekspresi reguler. Anda dapat memodifikasi ekspresi reguler default yang digunakan untuk mencocokkan tabel shadow dan tabel tidak berguna sesuai kebutuhan:

          • Tabel shadow: ^_(.+)_(?:gho|new)$

          • Tabel tidak berguna: ^_(.+)_(?:ghc|del|old)$

          Catatan

          Opsi ini menyebabkan tabel di database tujuan terkunci.

        Whether to Migrate Accounts

        Pilih apakah akan memigrasikan informasi akun dari database sumber. Jika Anda memilih Yes, Anda juga perlu memilih akun yang akan dimigrasikan dan mengonfirmasi izinnya. Untuk informasi selengkapnya, termasuk metode otorisasi, lihat Migrasi akun database.

        Retry Time for Failed Connections

        Setelah tugas migrasi dimulai, jika koneksi ke database sumber atau tujuan gagal, DTS melaporkan kesalahan dan segera mulai mencoba menghubungkan kembali. Durasi percobaan ulang default adalah 720 menit. Anda dapat menyesuaikan waktu percobaan ulang ke nilai antara 10 hingga 1440 menit. Kami merekomendasikan Anda mengatur durasi lebih dari 30 menit. Jika DTS berhasil terhubung kembali ke database sumber dan tujuan dalam durasi yang ditentukan, tugas migrasi akan dilanjutkan secara otomatis. Jika tidak, tugas gagal.

        Catatan

        • Untuk beberapa instans DTS yang berbagi sumber atau tujuan yang sama, waktu percobaan ulang jaringan ditentukan oleh pengaturan tugas yang terakhir dibuat.

        • Karena Anda dikenai biaya untuk tugas selama periode percobaan ulang koneksi, kami merekomendasikan Anda menyesuaikan waktu percobaan ulang berdasarkan kebutuhan bisnis, atau segera rilis instans DTS setelah instans database sumber dan tujuan dirilis.

        Retry Time for Other Issues

        Setelah tugas migrasi dimulai, jika terjadi masalah non-konektivitas, seperti pengecualian eksekusi DDL atau DML, di database sumber atau tujuan, DTS melaporkan kesalahan dan segera mulai mencoba mengulang operasi tersebut. Durasi percobaan ulang default adalah 10 menit. Anda dapat menyesuaikan waktu percobaan ulang ke nilai antara 1 hingga 1440 menit. Kami merekomendasikan Anda mengatur durasi lebih dari 10 menit. Jika operasi terkait berhasil dalam durasi percobaan ulang yang ditentukan, tugas migrasi akan dilanjutkan secara otomatis. Jika tidak, tugas gagal.

        Penting

        Nilai Retry Time for Other Issues harus lebih kecil dari nilai Retry Time for Failed Connections.

        Enable Throttling for Full Data Migration

        Selama migrasi penuh, DTS mengonsumsi sumber daya baca dan tulis pada database sumber dan tujuan, yang dapat meningkatkan beban database. Jika diperlukan, Anda dapat mengaktifkan pembatasan kecepatan untuk tugas migrasi penuh. Anda dapat mengatur Queries per second (QPS) to the source database, RPS of Full Data Migration, dan Data migration speed for full migration (MB/s) untuk mengurangi beban pada database tujuan.

        Catatan

        • Item konfigurasi ini tersedia hanya jika Anda memilih Full Data Migration untuk Migration Types.

        • Anda juga dapat menyesuaikan kecepatan migrasi penuh setelah instans migrasi sedang berjalan.

        Enable Throttling for Incremental Data Migration

        Jika diperlukan, Anda juga dapat memilih untuk mengatur batas kecepatan untuk tugas migrasi inkremental. Anda dapat mengatur RPS of Incremental Data Migration dan Data migration speed for incremental migration (MB/s) untuk mengurangi beban pada database tujuan.

        Catatan

        Environment Tag

        Pilih tag lingkungan untuk mengidentifikasi instans berdasarkan kebutuhan bisnis Anda. Tidak perlu pemilihan untuk contoh ini.

        Whether to delete SQL operations on heartbeat tables of forward and reverse tasks

        Pilih apakah akan menulis informasi SQL heartbeat ke database sumber saat instans DTS sedang berjalan.

        • Yes: Informasi SQL heartbeat tidak ditulis ke database sumber. Hal ini dapat menyebabkan instans DTS melaporkan delay.

        • No: Menulis informasi SQL heartbeat ke database sumber. Hal ini dapat mengganggu fitur seperti backup fisik dan cloning database sumber.

        Configure ETL

        Pilih apakah akan mengaktifkan fitur ekstrak, transformasi, muat (ETL). Untuk informasi selengkapnya, lihat Apa itu ETL? Nilai yang valid:

        Monitoring and Alerting

        Pilih apakah akan mengatur peringatan dan menerima notifikasi peringatan berdasarkan kebutuhan bisnis Anda.

        • No: Tidak mengatur peringatan.

        • Yes: Konfigurasi peringatan dengan mengatur ambang batas peringatan dan pemberitahuan peringatan. Jika migrasi gagal atau latensi melebihi ambang batas, sistem akan mengirimkan notifikasi peringatan.

      3. Klik Next: Data Validation untuk mengonfigurasi tugas validasi data.

        Jika Anda ingin menggunakan fitur validasi data, lihat Konfigurasi validasi data untuk petunjuk konfigurasi.

    7. Simpan tugas dan jalankan pemeriksaan awal.

      • Untuk melihat parameter konfigurasi instans ini saat memanggil operasi API, arahkan pointer ke tombol Next: Save Task Settings and Precheck dan klik Preview OpenAPI parameters di balon yang muncul.

      • Jika Anda tidak perlu melihat atau telah selesai melihat parameter API, klik Next: Save Task Settings and Precheck di bagian bawah halaman.

      Catatan

      • Sebelum tugas migrasi dimulai, DTS melakukan pemeriksaan awal. Tugas hanya dimulai setelah lolos pemeriksaan awal.

      • Jika pemeriksaan awal gagal, klik View Details di sebelah item pemeriksaan yang gagal, perbaiki masalah berdasarkan petunjuk, lalu jalankan kembali pemeriksaan awal.

      • Jika peringatan dilaporkan selama pemeriksaan awal:

        • Untuk item pemeriksaan yang tidak dapat diabaikan, klik View Details di sebelah item yang gagal, perbaiki masalah berdasarkan petunjuk, lalu jalankan kembali pemeriksaan awal.

        • Untuk item pemeriksaan yang dapat diabaikan, Anda dapat mengklik Confirm Alert Details, Ignore, OK, dan Precheck Again untuk melewati item peringatan dan menjalankan kembali pemeriksaan awal. Jika Anda memilih untuk mengabaikan peringatan, hal ini dapat menyebabkan masalah seperti ketidakkonsistenan data dan menimbulkan risiko bagi bisnis Anda.

    8. Saat Success Rate mencapai 100%, klik Next: Purchase Instance.

    9. Beli instans.

      1. Di halaman Purchase, pilih spesifikasi link untuk instans migrasi data. Untuk informasi selengkapnya, lihat tabel berikut.

        Kategori

        Parameter

        Deskripsi

        New Instance Class

        Resource Group Settings

        Pilih kelompok sumber daya tempat instans tersebut berada. Nilai default adalah kelompok sumber daya default. Untuk informasi selengkapnya, lihat Apa itu Resource Management?

        Instance Class

        DTS menyediakan spesifikasi migrasi dengan tingkat kinerja berbeda. Spesifikasi link memengaruhi kecepatan migrasi. Anda dapat memilih spesifikasi berdasarkan skenario bisnis Anda. Untuk informasi selengkapnya, lihat Spesifikasi link migrasi data.

      2. Setelah konfigurasi selesai, baca dan pilih Data Transmission Service (Pay-as-you-go) Service Terms.

      3. Klik Buy and Start. Di kotak dialog OK yang muncul, klik OK.

        Anda dapat melihat progres tugas migrasi di halaman daftar Data Migration Tasks.

        Catatan

        • Jika tugas migrasi tidak mencakup migrasi inkremental, tugas akan berhenti secara otomatis setelah migrasi penuh selesai. Setelah tugas berhenti, Status-nya berubah menjadi Completed.

        • Jika tugas migrasi mencakup migrasi inkremental, tugas tidak berhenti secara otomatis. Tugas migrasi inkremental terus berjalan. Selama tugas migrasi inkremental berjalan, Status tugas adalah Running.