Mengonfigurasi database MySQL sumber untuk migrasi berkelanjutan

Halaman ini menjelaskan cara mengonfigurasi instance database sumber berikut untuk migrasi MySQL homogen berkelanjutan:

Mengonfigurasi sumber Cloud SQL untuk MySQL

Untuk mengonfigurasi instance sumber Cloud SQL untuk MySQL untuk proses migrasi Anda, lakukan hal berikut:

  1. Periksa apakah database sumber Anda berisi metadata yang ditentukan oleh pengguna dengan klausa DEFINER. Lihat Memverifikasi metadata dengan klausa DEFINER.

    Database Migration Service untuk migrasi MySQL homogen tidak memigrasikan akun dan login pengguna. Sumber yang berisi metadata yang ditentukan oleh akun pengguna dengan klausa DEFINER dapat memblokir migrasi Anda.

  2. Jika database sumber Anda berisi objek yang mereferensikan tabel dalam skema sistem mysql, performance_schema, information_schema, ndbinfo, atau sys, pastikan database replika juga berisi tabel skema sistem ini.

    Jika database replika tidak memiliki tabel ini, tugas migrasi Anda mungkin gagal dengan Unknown table in system schema .

  3. Aktifkan dan konfigurasi log biner di database sumber Anda.

    Di Cloud SQL untuk MySQL, logging biner diaktifkan secara otomatis saat Anda menggunakan pemulihan point-in-time (PITR). Anda dapat mengonfigurasi format log dan periode retensi data dengan flag sistem yang tersedia di Cloud SQL. Lakukan tindakan berikut:

    1. Aktifkan PITR di instance Anda. Fitur ini otomatis mengaktifkan logging biner. Logging biner tidak dapat diaktifkan tanpa PITR di Cloud SQL. Lihat Pemulihan point-in-time (PITR) dalam dokumentasi Cloud SQL.
    2. Gunakan flag Cloud SQL untuk menyesuaikan konfigurasi logging. Untuk mengetahui detail selengkapnya, lihat Mengonfigurasi flag database dalam dokumentasi Cloud SQL.
      1. Database Migration Service mengharuskan binlog_format ditetapkan ke ROW. Anda tidak perlu menyesuaikan setelan ini, Cloud SQL untuk MySQL secara otomatis menetapkan flag binlog_format ke ROW.
      2. Tetapkan periode retensi log ke jangka waktu yang cukup lama untuk mendukung migrasi database. Umumnya, satu minggu sudah cukup. Gunakan salah satu flag berikut:
        • MySQL 5.6 - 5.7: expire_logs_days
        • MySQL 8.0 dan yang lebih baru: expire_logs_days, binlog_expire_logs_seconds

  4. Buat akun pengguna migrasi khusus di instance Anda. Lihat Membuat pengguna dalam dokumentasi Cloud SQL. Pastikan bahwa:

    • Anda mengizinkan akun pengguna khusus untuk terhubung dari host mana pun (host=%).
    • Sandi untuk akun tidak melebihi 32 karakter. Untuk mengetahui informasi selengkapnya tentang batasan panjang sandi pengguna MySQL, lihat Bug MySQL #43439.

  5. Tetapkan hak istimewa yang diperlukan ke akun pengguna migrasi khusus. Untuk migrasi berkelanjutan, daftar lengkap hak istimewa yang diperlukan bergantung pada apakah Anda menyediakan file dump sendiri atau menggunakan fitur dump terkelola Database Migration Service:

    Managed dump

    Jika Anda ingin Database Migration Service mengambil dump lengkap database sumber secara otomatis, tetapkan hak istimewa berikut ke akun pengguna:

    Dump manual

    Jika Anda memberikan file dump Anda sendiri yang dibuat dengan mysqldump, Anda harus memberikan hak istimewa yang diperlukan untuk fase CDC:

Mengonfigurasi sumber MySQL yang dihosting sendiri

Untuk mengonfigurasi instance sumber MySQL yang dihosting sendiri untuk proses migrasi, lakukan hal berikut:

  1. Pastikan semua tabel Anda (kecuali tabel dalam database sistem) menggunakan mesin penyimpanan InnoDB. Jika Anda menggunakan mesin penyimpanan yang berbeda, Anda mungkin perlu mengonversi tabel Anda. Untuk mengetahui informasi selengkapnya, lihat Mengonversi Tabel dari MyISAM ke InnoDB.
  2. Periksa apakah database sumber Anda berisi metadata yang ditentukan oleh pengguna dengan klausa DEFINER. Lihat Memverifikasi metadata dengan klausa DEFINER.

    Database Migration Service untuk migrasi MySQL homogen tidak memigrasikan akun dan login pengguna. Sumber yang berisi metadata yang ditentukan oleh akun pengguna dengan klausa DEFINER dapat memblokir migrasi Anda.

  3. Jika database sumber Anda berisi objek yang mereferensikan tabel dalam skema sistem mysql, performance_schema, information_schema, ndbinfo, atau sys, pastikan database replika juga berisi tabel skema sistem ini.

    Jika database replika tidak memiliki tabel ini, tugas migrasi Anda mungkin gagal dengan Unknown table in system schema .

  4. Konfigurasi setelan server-id ke nilai 1 atau lebih besar. Untuk mengetahui informasi selengkapnya, lihat Opsi dan Variabel Replikasi dan Logging Biner.

  5. Pastikan GTID_MODE ditetapkan ke ON atau OFF, nilai lain tidak didukung.

    Database Migration Service memerlukan GTID_MODE yang ditetapkan ke ON dalam skenario berikut:

    Untuk mengetahui informasi selengkapnya tentang GTID_MODE, lihat Variabel Sistem ID Transaksi Global.

  6. Aktifkan dan konfigurasi log biner di database sumber Anda. Lakukan tindakan berikut:

      • Aktifkan log biner di database sumber Anda.
      • Tetapkan binlog_format ke 'ROW'. Lihat Logging biner berbasis baris.
      • Tetapkan periode retensi log ke jangka waktu yang cukup lama untuk mendukung migrasi database. Umumnya, satu minggu sudah cukup. Gunakan salah satu flag berikut:
        • MySQL 5.5 - 5.7: expire_logs_days
        • MySQL 8.0: expire_logs_days, binlog_expire_logs_seconds

  7. Buat akun pengguna migrasi khusus di instance Anda. Lihat Pernyataan pengelolaan akun. Pastikan bahwa:

    • Anda mengizinkan akun pengguna khusus untuk terhubung dari host mana pun (host=%).
    • Sandi untuk akun tidak melebihi 32 karakter. Untuk mengetahui informasi selengkapnya tentang batasan panjang sandi pengguna MySQL, lihat Bug MySQL #43439.

  8. Tetapkan hak istimewa yang diperlukan ke akun pengguna migrasi khusus. Untuk migrasi berkelanjutan, daftar lengkap hak istimewa yang diperlukan bergantung pada apakah Anda menyediakan file dump sendiri atau menggunakan fitur dump terkelola Database Migration Service:

    Managed dump

    Jika Anda ingin Database Migration Service otomatis mengambil dump lengkap database sumber, tetapkan hak istimewa berikut ke akun pengguna:

    Dump manual

    Jika Anda menyediakan file dump yang dibuat dengan mysqldump, Anda harus memberikan hak istimewa yang diperlukan untuk fase CDC:

Mengonfigurasi sumber Amazon RDS for MySQL

Untuk mengonfigurasi instance sumber Amazon RDS for MySQL untuk proses migrasi Anda, lakukan hal berikut:

  1. Amazon RDS for MySQL menggunakan mesin penyimpanan InnoDB secara default, tetapi memungkinkan penggunaan mesin penyimpanan lain. Pastikan semua tabel Anda (kecuali tabel dalam database sistem) menggunakan mesin penyimpanan InnoDB. Jika Anda menggunakan mesin penyimpanan yang berbeda, Anda mungkin perlu mengonversi tabel Anda. Untuk mengetahui informasi selengkapnya, lihat Mengonversi Tabel dari MyISAM ke InnoDB.
  2. Periksa apakah database sumber Anda berisi metadata yang ditentukan oleh pengguna dengan klausa DEFINER. Lihat Memverifikasi metadata dengan klausa DEFINER.

    Database Migration Service untuk migrasi MySQL homogen tidak memigrasikan akun dan login pengguna. Sumber yang berisi metadata yang ditentukan oleh akun pengguna dengan klausa DEFINER dapat memblokir migrasi Anda.

  3. Jika database sumber Anda berisi objek yang mereferensikan tabel dalam skema sistem mysql, performance_schema, information_schema, ndbinfo, atau sys, pastikan database replika juga berisi tabel skema sistem ini.

    Jika database replika tidak memiliki tabel ini, tugas migrasi Anda mungkin gagal dengan Unknown table in system schema .

  4. Pastikan GTID_MODE ditetapkan ke ON atau OFF, nilai lain tidak didukung. Amazon RDS for MySQL menggunakan GTID_MODE = OFF secara default.

    Database Migration Service memerlukan GTID_MODE yang ditetapkan ke ON dalam skenario berikut:

    Untuk mengetahui informasi selengkapnya tentang GTID_MODE, lihat Variabel Sistem ID Transaksi Global.

  5. Verifikasi dan konfigurasi log biner di database sumber Anda. Lakukan tindakan berikut:

    1. Pastikan instance Anda menggunakan pencadangan otomatis. Amazon RDS hanya membuat log biner jika pencadangan otomatis diaktifkan. Untuk mengetahui informasi selengkapnya, lihat Mengaktifkan pencadangan otomatis dalam dokumentasi Amazon RDS.

    2. Tetapkan periode retensi log ke periode yang cukup lama untuk mendukung migrasi database. Umumnya, satu minggu sudah cukup. Lihat Menetapkan dan menampilkan konfigurasi log biner dalam dokumentasi Amazon RDS.

    3. Mulai ulang server agar perubahan yang Anda buat dapat diterapkan.

  6. Buat akun pengguna migrasi khusus di instance Anda. Lihat Pernyataan pengelolaan akun. Pastikan bahwa:

    • Anda mengizinkan akun pengguna khusus untuk terhubung dari host mana pun (host=%).
    • Sandi untuk akun tidak melebihi 32 karakter. Untuk mengetahui informasi selengkapnya tentang batasan panjang sandi pengguna MySQL, lihat Bug MySQL #43439.

  7. Tetapkan hak istimewa yang diperlukan ke akun pengguna migrasi khusus. Untuk migrasi berkelanjutan, daftar lengkap hak istimewa yang diperlukan bergantung pada apakah Anda menyediakan file dump sendiri atau menggunakan fitur dump terkelola Database Migration Service:

    Managed dump

    Jika Anda ingin Database Migration Service otomatis mengambil dump lengkap database sumber, tetapkan hak istimewa berikut ke akun pengguna:

    Dump manual

    Jika Anda menyediakan file dump yang dibuat dengan mysqldump, Anda harus memberikan hak istimewa yang diperlukan untuk fase CDC:

Mengonfigurasi sumber Amazon Aurora untuk MySQL

Untuk mengonfigurasi instance sumber Amazon Aurora for MySQL untuk proses migrasi Anda, lakukan hal berikut:

  1. Periksa apakah database sumber Anda berisi metadata yang ditentukan oleh pengguna dengan klausa DEFINER. Lihat Memverifikasi metadata dengan klausa DEFINER.

    Database Migration Service untuk migrasi MySQL homogen tidak memigrasikan akun pengguna dan login. Sumber yang berisi metadata yang ditentukan oleh akun pengguna dengan klausa DEFINER dapat memblokir migrasi Anda.

  2. Jika database sumber Anda berisi objek yang mereferensikan tabel dalam skema sistem mysql, performance_schema, information_schema, ndbinfo, atau sys, pastikan database replika juga berisi tabel skema sistem ini.

    Jika database replika tidak memiliki tabel ini, tugas migrasi Anda mungkin gagal dengan Unknown table in system schema .

  3. Pastikan GTID_MODE ditetapkan ke ON atau OFF, nilai lain tidak didukung. Amazon Aurora untuk MySQL menggunakan GTID_MODE = OFF secara default.

    Database Migration Service memerlukan GTID_MODE yang ditetapkan ke ON dalam skenario berikut:

    Untuk mengetahui informasi selengkapnya tentang GTID_MODE, lihat Variabel Sistem ID Transaksi Global.

  4. Aktifkan dan konfigurasi log biner di database sumber Anda. Lakukan tindakan berikut:

    1. Aktifkan logging biner untuk database MySQL Anda.

    2. Tetapkan periode retensi log ke periode yang cukup lama untuk mendukung migrasi database. Umumnya, satu minggu sudah cukup. Lihat Menetapkan dan menampilkan konfigurasi log biner.

    3. Mulai ulang server agar perubahan yang Anda buat dapat diterapkan.

  5. Buat akun pengguna migrasi khusus di instance Anda. Lihat Pernyataan pengelolaan akun. Pastikan bahwa:

    • Anda mengizinkan akun pengguna khusus untuk terhubung dari host mana pun (host=%).
    • Sandi untuk akun tidak melebihi 32 karakter. Untuk mengetahui informasi selengkapnya tentang batasan panjang sandi pengguna MySQL, lihat Bug MySQL #43439.

  6. Tetapkan hak istimewa yang diperlukan ke akun pengguna migrasi khusus. Untuk migrasi berkelanjutan, daftar lengkap hak istimewa yang diperlukan bergantung pada apakah Anda menyediakan file dump sendiri atau menggunakan fitur dump terkelola Database Migration Service:

    Managed dump

    Jika Anda ingin Database Migration Service otomatis mengambil dump lengkap database sumber, tetapkan hak istimewa berikut ke akun pengguna:

    Dump manual

    Jika Anda menyediakan file dump yang dibuat dengan mysqldump, Anda harus memberikan hak istimewa yang diperlukan untuk fase CDC:

Mengonfigurasi sumber Microsoft Azure Database for MySQL

Untuk mengonfigurasi instance sumber Microsoft Azure Database for MySQL untuk proses migrasi, lakukan hal berikut:

  1. Periksa apakah database sumber Anda berisi metadata yang ditentukan oleh pengguna dengan klausa DEFINER. Lihat Memverifikasi metadata dengan klausa DEFINER.

    Database Migration Service untuk migrasi MySQL homogen tidak memigrasikan akun dan login pengguna. Sumber yang berisi metadata yang ditentukan oleh akun pengguna dengan klausa DEFINER dapat memblokir migrasi Anda.

  2. Jika database sumber Anda berisi objek yang mereferensikan tabel dalam skema sistem mysql, performance_schema, information_schema, ndbinfo, atau sys, pastikan database replika juga berisi tabel skema sistem ini.

    Jika database replika tidak memiliki tabel ini, tugas migrasi Anda mungkin gagal dengan Unknown table in system schema .

  3. Pastikan GTID_MODE ditetapkan ke ON atau OFF, nilai lain tidak didukung. Microsoft Azure Database for MySQL menggunakan GTID_MODE = OFF secara default.

    Database Migration Service memerlukan GTID_MODE yang ditetapkan ke ON dalam skenario berikut:

    Untuk mengetahui informasi selengkapnya tentang GTID_MODE, lihat Variabel Sistem ID Transaksi Global.

  4. Verifikasi dan konfigurasi setelan logging biner di database sumber Anda. Lakukan tindakan berikut:

    1. Logging biner diaktifkan secara default di Microsoft Azure Database for MySQL. Anda tidak perlu mengaktifkannya, tetapi pastikan fitur ini diaktifkan. Untuk mengetahui informasi selengkapnya, lihat dokumentasi Microsoft.

    2. Tetapkan binlog_expire_logs_seconds ke periode yang cukup lama untuk mendukung migrasi database. Umumnya, satu minggu sudah cukup.

      Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi parameter server di Azure Database for MySQL dan parameter binlog_expire_logs_seconds dalam dokumentasi Microsoft.

    3. Mulai ulang server agar perubahan yang Anda buat dapat diterapkan.

  5. Periksa nilai setelan require_secure_transport Anda.

    Secara default, database Microsoft Azure memerlukan enkripsi SSL/TLS untuk semua koneksi masuk. Bergantung pada nilai require_secure_transport, gunakan salah satu setelan enkripsi berikut saat Anda membuat profil koneksi sumber:

    • Jika require_secure_transport disetel ke on, pilih Basic, TLS, atau mTLS.
    • Jika require_secure_transport ditetapkan ke off, pilih None.

  6. Buat akun pengguna migrasi khusus di instance Anda. Lihat Pernyataan pengelolaan akun. Pastikan bahwa:

    • Anda mengizinkan akun pengguna khusus untuk terhubung dari host mana pun (host=%).
    • Sandi untuk akun tidak melebihi 32 karakter. Untuk mengetahui informasi selengkapnya tentang batasan panjang sandi pengguna MySQL, lihat Bug MySQL #43439.

  7. Tetapkan hak istimewa yang diperlukan ke akun pengguna migrasi khusus. Untuk migrasi berkelanjutan, daftar lengkap hak istimewa yang diperlukan bergantung pada apakah Anda menyediakan file dump sendiri atau menggunakan fitur dump terkelola Database Migration Service:

    Managed dump

    Jika Anda ingin Database Migration Service mengambil dump lengkap database sumber secara otomatis, tetapkan hak istimewa berikut ke akun pengguna:

    Dump manual

    Jika Anda menyediakan file dump yang dibuat dengan mysqldump, Anda harus memberikan hak istimewa yang diperlukan untuk fase CDC:

Langkah berikutnya

Untuk mendapatkan panduan migrasi langkah demi langkah yang lengkap untuk migrasi Cloud SQL untuk MySQL yang homogen, lihat Memulai migrasi Cloud SQL untuk MySQL.