Batasan umum

Sebelum Anda memilih untuk memigrasikan database ke Cloud SQL, pertimbangkan batasan yang diketahui untuk skenario migrasi ini.

Catatan: Anda juga dapat menggunakan Google Cloud Migration Center untuk menemukan kesenjangan dalam dukungan fitur. Lihat Menemukan dan mengimpor database dalam dokumentasi Migration Center.

Batasan umum untuk menggunakan database MySQL sebagai sumber meliputi:

• Untuk memigrasikan database terenkripsi, Anda harus memberikan kunci enkripsi ke Database Migration Service. Database Migration Service mendukung migrasi data dari database Amazon Aurora atau Amazon RDS yang dienkripsi karena database ini menangani dekripsi secara transparan dalam layanannya. Untuk mengetahui informasi selengkapnya, lihat Mengenkripsi resource Amazon Aurora, Mengenkripsi resource Amazon RDS, dan Mengonfigurasi kunci enkripsi yang dikelola pelanggan (CMEK).

• Migrasi ke MySQL 5.6, MySQL 8.4, atau MySQL 9.7 dengan file cadangan fisik Percona XtraBackup tidak didukung.

• Untuk migrasi MySQL 8.0 ke MySQL 8.4 dan MySQL 8.4 ke MySQL 9.7:

  • Database tujuan Anda harus memiliki flag local_infile yang ditetapkan ke ON.
  • Akun migrasi khusus di instance sumber tidak boleh memiliki hak istimewa BACKUP_ADMIN.

  Pertimbangan ini juga dibahas di bagian yang relevan, seperti halaman Mengonfigurasi database sumber.

• Saat bermigrasi di seluruh versi utama MySQL (misalnya, dari MySQL 8.0 ke MySQL 8.4), Anda harus mengatasi kemungkinan ketidakkompatibelan untuk memastikan migrasi yang lancar tanpa masalah konsistensi data.

  Saat Anda bersiap untuk migrasi lintas versi, tinjau fitur yang didukung oleh Cloud SQL untuk MySQL serta catatan rilis untuk versi utama target guna menentukan inkompatibilitas yang perlu Anda atasi.

  • MySQL 9.7
  • MySQL 8.4
  • MySQL 8.0
  • MySQL 5.7

• Selama fase dump data lengkap, Anda tidak dapat melakukan operasi bahasa definisi data (DDL) (seperti ALTER TABLE, DROP TABLE, TRUNCATE TABLE) pada database sumber. Menjalankan operasi ini selama fase dump penuh dapat menyebabkan deadlock metadata, sehingga proses migrasi gagal (dengan error Table definition has changed) atau berhenti merespons (dan melaporkan error waktu tunggu seperti ERROR: While 'Loading data': Dump timeout atau MySQL Error 2013 (HY000): Lost connection to MySQL server during query). Anda dapat melakukan perubahan DDL pada database sumber selama fase CDC. Untuk mengetahui informasi selengkapnya, lihat entri berikut di bagian pemecahan masalah:

  • Table definition has changed
  • While 'Loading data': dump timeout
  • MySQL Error 2013: Lost connection to MySQL server during query
  • Timeout waiting for no write traffic on the source: context deadline exceeded

• Jika sumbernya adalah Amazon RDS MySQL, Amazon Aurora MySQL, atau sumber yang tidak memberikan hak istimewa SUPERUSER, langkah-langkah tambahan diperlukan agar migrasi berhasil, termasuk periode nonaktif tulis singkat di sumber. Untuk mengetahui informasi selengkapnya, lihat bagian Mengonfigurasi database sumber untuk Amazon RDS dan Khusus Amazon Aurora.

• Database Migration Service tidak dapat memigrasikan data dari instance replika baca Amazon Aurora atau instance replika baca MySQL Oracle Cloud Infrastructure (OCI) karena file log biner tidak dapat diambil dari instance tersebut. Untuk mengetahui informasi selengkapnya tentang Amazon Aurora, lihat bagian khusus Amazon Aurora.

• Saat bermigrasi dari replika baca MySQL yang dikelola sendiri, GTID tidak didukung. Anda harus menggunakan file log biner dan replikasi berbasis posisi. Untuk mengetahui informasi selengkapnya, lihat Jenis dan fase migrasi.

• Database sistem MySQL tidak dimigrasikan sebagai bagian dari migrasi server, sehingga informasi tentang akun pengguna, login, dan peran tidak disertakan.

• Meskipun dapat memilih database tertentu untuk dimigrasikan, Anda tidak dapat memfilter atau memilih objek database individual dalam database (seperti tabel, tampilan, atau prosedur tersimpan tertentu) saat melakukan migrasi menggunakan Database Migration Service. Semua tabel dan objek InnoDB dari setiap database yang dipilih akan dimigrasikan, kecuali skema sistem berikut: mysql, performance_schema, information_schema, dan sys. Sebelum memulai migrasi, pastikan database sumber Anda tidak berisi objek yang mereferensikan tabel dalam skema ini. Jika tidak, migrasi Anda dapat gagal dengan pesan ERROR 1109 (42S02): Unknown table in <schema name here>. Lihat Mengonfigurasi database sumber dan Mendiagnosis masalah.

• Selama migrasi, database Cloud SQL tujuan berada dalam mode hanya baca, untuk mencegah modifikasi database yang dapat merusak proses migrasi atau integritas data. Setelah dipromosikan, tujuan akan dapat ditulis.

• Database Migration Service tidak kompatibel dengan MariaDB.

• Anda harus menetapkan format log biner ke ROW. Mengonfigurasi log biner ke format lain, seperti STATEMENT atau MIXED, dapat menyebabkan replikasi gagal. Misalnya, menggunakan pernyataan LOAD DATA IN FILE.

  Pelajari lebih lanjut batasan ini untuk format STATEMENT atau MIXED.

• Jika Anda membuat tugas migrasi berkelanjutan menggunakan file dump Anda sendiri, jangan gunakan utilitas mysqldump dari MySQL versi 5.7.36. Untuk informasi selengkapnya, lihat bug #105761 dalam dokumentasi MySQL.

• InnoDB adalah satu-satunya mesin penyimpanan yang didukung untuk Cloud SQL. Bermigrasi dengan MyISAM dapat menyebabkan inkonsistensi data dan validasi data perlu dilakukan. Untuk mendapatkan bantuan dalam mengonversi tabel dari MyISAM ke InnoDB, lihat dokumentasi MySQL.

• Metode konektivitas antarmuka Private Service Connect hanya didukung untuk migrasi ke instance tujuan yang ada. Jika Anda ingin menggunakan konektivitas IP pribadi dan bermigrasi ke instance tujuan baru, gunakan peering VPC.

Pertimbangan paralelisme dump data

Paralelisme dump data memungkinkan Anda bermigrasi dari database MySQL menggunakan mekanisme dump berperforma tinggi, sehingga meningkatkan kecepatan migrasi secara signifikan. Saat menggunakan paralelisme dump data, pertimbangkan hal berikut:

• Paralelisme dump data hanya tersedia saat bermigrasi ke MySQL versi 5.7, 8.0, 8.4, atau 9.7.

• Pada awal dump data, Database Migration Service mengunci database sumber Anda sebentar, sehingga tidak tersedia untuk sementara untuk penulisan. Durasi penguncian bergantung pada jumlah tabel dalam database sumber:

  Jumlah tabel	Perkiraan waktu penguncian
  100	1 detik
  10K	9 detik
  50 RB	49 detik

Catatan: Untuk skenario yang tidak memungkinkan penguncian database sumber, gunakan replika baca sebagai database sumber. Untuk mengetahui informasi tentang cara bermigrasi dari replika baca di Amazon RDS, lihat Bermigrasi dari RDS MySQL.

Batasan untuk migrasi ke instance tujuan yang ada

• Instance tujuan yang ada hanya dapat berisi database sistem default yang disiapkan secara otomatis saat Anda membuat instance tujuan. Migrasi ke instance tujuan yang sudah ada yang berisi data pengguna (seperti tabel dalam skema sistem, atau database) tidak didukung.

  Jika Anda mengalami masalah karena data tambahan di instance tujuan yang ada, hapus database di instance tujuan dan coba lagi tugas migrasi. Lihat Menghapus data tambahan dari instance tujuan yang ada.

• Anda hanya dapat mengonfigurasi satu tugas migrasi per instance tujuan.
• Anda hanya dapat bermigrasi ke instance Cloud SQL mandiri. Migrasi ke replika server eksternal tidak didukung.
• Migrasi ke instance Cloud SQL yang memiliki replika baca mengharuskan instance sumber Anda mengaktifkan logging ID transaksi global (GTID).
• Anda tidak dapat menggunakan replika baca Cloud SQL untuk MySQL sebagai instance tujuan migrasi.
• Untuk pengguna Terraform: Database Migration Service mengubah setelan pencadangan dan pemulihan instance tujuan Anda. Hal ini dapat menyebabkan setelan instance tujuan berbeda dari konfigurasi Terraform yang Anda gunakan untuk penyediaan. Jika Anda mengalami masalah ini, ikuti panduan di Mendiagnosis masalah.

Kuota

• Hingga 2.000 profil koneksi dan 1.000 tugas migrasi dapat ada kapan saja. Untuk mengosongkan ruang, tugas migrasi (termasuk yang telah selesai) dan profil koneksi dapat dihapus.