Mengonfigurasi sumber

MySQL   |  PostgreSQL   |  PostgreSQL ke AlloyDB

Ringkasan

Database Migration Service mendukung migrasi satu kali dan berkelanjutan dari database sumber ke database tujuan Cloud SQL.

Database sumber yang didukung untuk MySQL meliputi:

• Amazon RDS 5.6, 5.7, 8.0
• MySQL yang dikelola sendiri (di lokasi atau di VM cloud apa pun yang Anda kontrol sepenuhnya) 5.5, 5.6, 5.7, 8.0
• Cloud SQL untuk MySQL 5.6, 5.7, 8.0, 8.4
• Amazon Aurora 5.6, 5.7, 8.0
• Microsoft Azure Database untuk MySQL 5.7, 8.0

Untuk sumber MySQL 8.0, Layanan Migrasi Database juga mendukung versi minor berikut: 8.0.18, 8.0.26, 8.0.27, 8.0.28, 8.0.30, 8.0.31, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40.

Untuk mengonfigurasi database sumber, selesaikan langkah-langkah berikut:

1. Untuk sumber Cloud SQL: Jika Anda bermigrasi dari instance Cloud SQL yang menggunakan koneksi IP Pribadi ke instance Cloud SQL yang menggunakan rentang IP alamat non-RFC 1918, tambahkan rentang non-RFC 1918 ke konfigurasi jaringan instance Cloud SQL sumber Anda. Lihat Mengonfigurasi jaringan yang diizinkan dalam dokumentasi Cloud SQL.
2. Sebelum memigrasikan data dari database sumber ke database tujuan, pastikan Anda menghentikan semua operasi tulis Data Definition Language (DDL) selama fase dump penuh. Anda dapat menggunakan skrip untuk memverifikasi bahwa operasi DDL dihentikan. Setelah migrasi berada dalam fase CDC, Anda dapat melanjutkan operasi DDL.
3. Pastikan database sumber Anda tidak berisi metadata yang ditentukan oleh pengguna dengan klausa DEFINER. Lihat Membuat dan menjalankan tugas migrasi MySQL yang berisi metadata dengan klausa DEFINER.
4. 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 error Unknown table in system schema .

5. Anda harus menetapkan opsi server-id ke nilai 1 atau yang lebih besar. Untuk mengetahui informasi selengkapnya, lihat Opsi dan Variabel Replikasi serta Logging Biner.
6. Konfigurasikan logging ID transaksi global (GTID) dengan menetapkan GTID_MODE ke ON atau OFF. Nilai GTID_MODE dari ON_PERMISSIVE tidak didukung.

   Nilai yang harus Anda gunakan bergantung pada persyaratan migrasi:

   • Jika Anda bermigrasi ke instance tujuan yang ada yang telah mengaktifkan replika baca, tetapkan GTID_MODE ke ON.
   • Jika Anda menggunakan dump manual untuk memigrasikan data, tetapkan GTID_MODE ke ON.
   Untuk informasi selengkapnya tentang GTID_MODE, lihat Variabel Sistem ID Transaksi Global.

7. Anda harus mengonfigurasi akun pengguna yang digunakan untuk terhubung ke database sumber agar dapat menerima koneksi dari mana saja (host = %). Akses dapat dibatasi untuk pengguna ini pada langkah berikutnya.

   Agar aspek database lainnya tidak terpengaruh, sebaiknya buat akun terpisah untuk tujuan ini.

   Ada empat jenis kombinasi migrasi dan dump:

   • Jenis 1: Migrasi berkelanjutan dan dump terkelola
   • Jenis 2: Migrasi berkelanjutan dan dump manual
   • Jenis 3: Migrasi satu kali dan dump terkelola
   • Jenis 4: Migrasi satu kali dan dump manual

   Hak istimewa untuk setiap jenis kombinasi migrasi dan dump tercantum di tab di bawah.

   Jenis 1

   Akun pengguna yang Anda konfigurasi harus memiliki hak istimewa berikut:

   • REPLICATION SLAVE
   • EXECUTE
   • SELECT
   • SHOW VIEW
   • REPLICATION CLIENT
   • RELOAD
   • TRIGGER
   • (Khusus untuk migrasi dari Amazon RDS dan Amazon Aurora) LOCK TABLES

   MySQL versi 8.0 atau yang lebih baru: Untuk performa yang optimal, pastikan Anda tidak memberikan hak istimewa BACKUP_ADMIN ke akun ini.

   Untuk mengetahui informasi selengkapnya tentang hak istimewa, lihat Hak Istimewa yang Diberikan oleh MySQL. Untuk mengetahui informasi selengkapnya tentang akun pengguna, lihat Format akun pengguna MySQL.

   Jenis 2

   Akun pengguna yang Anda konfigurasi harus memiliki hak istimewa berikut:

   • REPLICATION SLAVE
   • EXECUTE

   Untuk mengetahui informasi selengkapnya tentang hak istimewa, lihat Hak Istimewa yang Diberikan oleh MySQL. Untuk mengetahui informasi selengkapnya tentang akun pengguna, lihat Format akun pengguna MySQL.

   Jenis 3

   Akun pengguna yang Anda konfigurasi harus memiliki hak istimewa berikut:

   • SELECT
   • SHOW VIEW
   • TRIGGER
   • (Khusus untuk migrasi dari Amazon RDS dan Amazon Aurora) LOCK TABLES
   • (Khusus untuk bermigrasi dari sumber dengan setelan GTID_MODE = ON)RELOAD

   MySQL versi 8.0 atau yang lebih baru: Untuk performa yang optimal, pastikan Anda tidak memberikan hak istimewa BACKUP_ADMIN ke akun ini.

   Untuk mengetahui informasi selengkapnya tentang hak istimewa, lihat Hak Istimewa yang Diberikan oleh MySQL. Untuk mengetahui informasi selengkapnya tentang akun pengguna, lihat Format akun pengguna MySQL.

   Jenis 4

   Tidak ada hak istimewa yang diperlukan.

   Untuk mengetahui informasi selengkapnya tentang hak istimewa, lihat Hak Istimewa yang Diberikan oleh MySQL. Untuk mengetahui informasi selengkapnya tentang akun pengguna, lihat Format akun pengguna MySQL.

8. Sebelum mengonfigurasi log biner, pastikan Anda:
   • Aktifkan log biner di database sumber Anda.
   • Gunakan logging biner berbasis baris.
   • Simpan log biner untuk jangka waktu yang cukup lama guna mendukung migrasi database. Umumnya, satu minggu sudah cukup.

   Untuk mengonfigurasi log biner, luaskan bagian untuk sumber Anda:

   MySQL yang dihosting sendiri

   Bergantung pada versi MySQL Anda, tentukan periode dengan waktu yang cukup untuk replikasi terjadi:

   • MySQL 5.5 - 5.7: expire_logs_days
   • MySQL 8.0: expire_logs_days, binlog_expire_logs_seconds

   Microsoft Azure Database untuk MySQL

   Logging biner diaktifkan secara default di Microsoft Azure Database for MySQL. Anda tidak perlu mengaktifkannya. Untuk informasi selengkapnya, lihat dokumentasi Microsoft.

   Konfigurasikan parameter yang diperlukan berikut:

   1. Tetapkan binlog_expire_logs_seconds ke periode yang cukup lama untuk mendukung migrasi database.

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

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

   Amazon RDS

   Untuk Amazon RDS, Anda menetapkan konfigurasi berbasis baris di grup parameter dengan mengonfigurasi parameter binlog retention hours. Parameter ini digunakan untuk menentukan jumlah jam yang harus dipertahankan Amazon RDS untuk file log biner.

   Untuk menetapkan periode retensi log biner di Amazon RDS, gunakan prosedur tersimpan mysql.rds_set_configuration dan tentukan periode dengan waktu yang cukup untuk replikasi. Contoh:

   call mysql.rds_set_configuration('binlog retention hours',168);

   Nilai maksimum yang dapat Anda tetapkan untuk parameter ini adalah 168 jam (atau 7 hari).

   Amazon Aurora

   Untuk Amazon Aurora, ikuti langkah-langkah berikut:

   1. Aktifkan logging biner untuk database MySQL Anda.
   2. Tetapkan periode retensi log biner:

      mysql> call mysql.rds_set_configuration('binlog retention hours', 168);

      Anda memasukkan perintah ini karena ingin memastikan replikasi yang tepat dengan mengonfigurasi sistem untuk menyimpan log biner minimal selama 7 hari (atau 168 jam).
   3. Mulai ulang server agar perubahan yang Anda buat dapat diterapkan.
9. Semua tabel (kecuali tabel dalam database sistem) menggunakan mesin penyimpanan InnoDB.

   Untuk informasi selengkapnya tentang InnoDB, lihat Mesin Penyimpanan InnoDB. Untuk informasi selengkapnya tentang cara melakukan konversi ke InnoDB, lihat Mengonversi Tabel dari MyISAM ke InnoDB.

10. Panjang kata sandi akun pengguna yang digunakan untuk terhubung ke database sumber tidak boleh melebihi 32 karakter. Masalah ini hanya terjadi pada Replikasi MySQL.

    Untuk mengetahui informasi selengkapnya tentang batasan panjang sandi pengguna MySQL, lihat MySQL Bug #43439.

11. Khusus untuk sumber Microsoft Azure Database for MySQL: 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 ditetapkan ke on, pilih Dasar, TLS, atau mTLS.
    • Jika require_secure_transport ditetapkan ke off, pilih None.