Ada berbagai cara untuk bermigrasi ke MySQL di Cloud SQL. Strategi migrasi untuk sumber tertentu bergantung pada beberapa faktor, termasuk ukuran database, ekspektasi periode nonaktif, dan pengalaman engineer yang melakukan migrasi. Mari kita tinjau beberapa strategi migrasi yang paling umum.

Jika Anda bermigrasi melalui database kecil yang ukurannya hanya beberapa gigabyte atau berisi data statis, pendekatan termudah adalah membuat dump database menggunakan utilitas mysqldump. Upload file dump ke Cloud Storage, lalu impor ke instance Cloud SQL dengan mengikuti petunjuk dalam artikel mengekspor dan mengimpor menggunakan file dump SQL.

Karena file dump berisi pernyataan SQL logis, salah satu keuntungan pendekatan ini adalah file dump dapat diedit sebelum dimuat ke Cloud Storage. Namun, mengingat batasan Cloud SQL tertentu, hindari menyertakan apa pun dalam file dump yang dapat mengganggu impor seperti yang tercantum dalam praktik terbaik untuk mengimpor dan mengekspor data.

Saat memigrasi banyak instance MySQL atau untuk migrasi yang lebih besar, pilihan yang lebih baik adalah menggunakan Database Migration Service (DMS). Layanan ini menyediakan berbagai jalur migrasi, termasuk jalur untuk migrasi homogen dan heterogen ke MySQL, serta dukungan untuk SQL Server dan PostgreSQL sebagai tujuan migrasi.

Jika sebagian besar migrasi database berukuran sedang ke besar, penggunaan DMS seharusnya sudah cukup. Situasi ketika DMS mungkin tidak sesuai mencakup database yang sangat besar (seperti beberapa TB yang berukuran), atau jika Anda memiliki engineer MySQL yang berpengalaman dalam melakukan replikasi dan lebih memilih kontrol yang lebih mendetail atas proses migrasi menggunakan replikasi MySQL native.

Jika meminimalkan periode nonaktif merupakan prioritas selama migrasi dan Anda telah berpengalaman sebagai engineer MySQL di tim, mereplikasi dari sumber eksternal (ES) menggunakan replikasi berbasis log biner native adalah sebuah opsi. Metode ini memanfaatkan pengimporan snapshot dasar pengukuran dari database Anda menggunakan metode seperti impor Cloud Storage.

Selanjutnya, Anda akan mengonfigurasi replikasi MySQL dari instance sumber ke instance Cloud SQL target menggunakan serangkaian prosedur tersimpan yang dibuat sebelumnya dan telah tersedia di instance Cloud SQL. Petunjuk lengkapnya dapat ditemukan dalam artikel berjudul Menggunakan impor kustom untuk menyiapkan replikasi dari database eksternal besar.

Satu detail penting saat menggunakan replikasi berbasis log biner untuk migrasi adalah log biner di instance sumber tetap tersedia hingga tidak lagi diperlukan oleh instance Cloud SQL target. Saat menjalankan MySQL di infrastruktur lokal atau dikelola sendiri, parameter seperti expire_logs_days dapat dikonfigurasi untuk mengontrol penghapus permanen log biner. Namun, layanan terkelola vendor cloud lainnya memiliki batasan sendiri terkait retensi log biner.

Misalnya, Amazon Relational Database Service (RDS) memungkinkan konfigurasi retensi log biner menggunakan nama prosedur tersimpan mysql.rds_set_configuration. Hal ini memungkinkan retensi hingga tujuh hari. Dalam kebanyakan kasus, tujuh hari sudah cukup untuk sebagian besar migrasi kecil hingga menengah dari RDS ke Cloud SQL. Dalam situasi seperti itu, pengguna dapat memanfaatkan proses yang terdokumentasi dengan baik, yang melibatkan pembuatan replika RDS yang terkelola. Kemudian lakukan sesuatu untuk "memecah" replikasi, seperti membuat replika dapat ditulisi dan menghapus baris atau memasukkan semacam transaksi "pil beracun" pada transaksi utama yang masuk ke log biner dan merusak replikasi. Otomatisasi RDS tidak akan menghapus permanen log biner selama replika masih membutuhkannya (meskipun tampaknya ada batas keseluruhan 30 hari sebelum RDS "menghentikan" streaming replikasi yang rusak).

Solusi lainnya adalah menggunakan klien mysqlbinlog untuk mendownload log biner ke instance MySQL perantara lainnya untuk mencegah hapus permanen log biner sejak dini. Misalnya, dalam RDS terdapat prosedur tersimpan bernama mysql.rds_set_configuration yang memungkinkan penyetelan periode retensi dalam jam untuk memastikan log biner tetap berada di host cukup lama untuk didownload. Dalam hal ini, Anda tidak perlu menjadikan instance MySQL sebagai perantara karena server apa pun, seperti 'Server Binlog', yang terlihat seperti instance MySQL, tersedia untuk menyimpan dan meneruskan log biner.

MySQL adalah sistem database relasional yang unik karena mendukung beberapa mesin penyimpanan yang dapat dicocokkan. Awalnya MySQL mendukung mesin penyimpanan tunggal yang dikenal sebagai MyISAM dan, hingga MySQL 8.0, sebagian besar tabel sistem menggunakan mesin penyimpanan ini. Namun, MyISAM tidak memiliki dukungan untuk transaksi dan tidak aman dari error jika sistem mengalami penonaktifan sistem atau error database secara tiba-tiba.

Sejak saat itu, InnoDB telah menjadi mesin penyimpanan de facto untuk sebagian besar tabel pengguna MySQL mengingat arsitekturnya yang aman dari error dan dukungan untuk transaksi. Masih ada mesin penyimpanan lain yang biasa ditemui dalam komunitas MySQL, baik lokal maupun di penyedia cloud lainnya, termasuk berikut ini:

• ARCHIVE - Menyimpan data dalam format yang sangat terkompresi untuk tujuan pengarsipan
• CSV - Menyimpan data dalam format yang dipisahkan koma (CSV) dan digunakan untuk membuat log tabel untuk log kueri umum dan lambat
• MEMORY - Menyimpan tabel di memori

Dalam kasus Cloud SQL, kami memerlukan mesin penyimpanan yang bersifat transaksional dan aman dari error untuk mendukung fitur nilai tambah seperti replikasi dan pemulihan point-in-time. Oleh karena itu, semua tabel pengguna yang dimigrasikan ke Cloud SQL perlu menggunakan mesin penyimpanan InnoDB atau dikonversi ke InnoDB selama proses migrasi.

Hal ini sangat penting jika melakukan replikasi MySQL native dari sumber eksternal ke Cloud SQL. Meskipun Cloud SQL tidak mengizinkan pengguna membuat tabel MyISAM secara langsung di instance Cloud SQL menggunakan perintah bahasa definisi data (DDL) seperti CREATE TABLE, saat ini tabel MyISAM dapat direplikasi dari sumber eksternal ke Cloud SQL.

Namun, tabel MyISAM yang diimpor ini di Cloud SQL dapat menyebabkan masalah stabilitas dan keandalan di kemudian hari selama operasi seperti replikasi, pemulihan point-in-time, dan failover. Oleh karena itu, sebaiknya konversi semua tabel pengguna MyISAM ke InnoDB sebelum melakukan migrasi. 

Kueri berikut akan mencantumkan semua tabel MyISAM non-sistem.

Sebagai layanan terkelola, MySQL untuk Cloud SQL tidak mengizinkan hak istimewa SUPER untuk akun pengguna. Ini merupakan perubahan dari sebagian besar penginstalan MySQL lokal yang memungkinkan pengguna root dengan hak istimewa semacam itu. Demikian pula, sebagian besar penyedia cloud lain tidak memberikan hak istimewa SUPER ini di lingkungan MySQL terkelola.

Apa pun kasusnya, pengguna Cloud SQL menerima pengguna MySQL default bernama 'root'@'%' yang telah diberikan sebagian besar hak istimewa yang disediakan oleh MySQL, kecuali yang dapat memengaruhi kemampuan agar Google dapat mengelola layanan seperti SUPER yang disebutkan di atas beserta FILE dan SHUTDOWN. Untuk detail selengkapnya tentang hak istimewa penggunaan yang diberikan di Cloud SQL, tinjau dokumentasi tentang pengguna MySQL.

Saat bersiap melakukan migrasi, tinjau semua akun pengguna di instance sumber. Misalnya, jalankan perintah SHOW GRANTS untuk setiap pengguna guna meninjau kumpulan hak istimewa saat ini dan melihat apakah ada yang dibatasi di Cloud SQL. Demikian pula, alat pt-show-grants dari Percona juga dapat mencantumkan pemberian.

Pembatasan hak istimewa pengguna di Cloud SQL dapat memengaruhi migrasi saat memigrasikan objek database yang memiliki atribut DEFINER. Hal ini sering kali terjadi untuk prosedur, pemicu, fungsi yang ditentukan pengguna, dan tampilan yang tersimpan. Jika pendefinisi untuk objek database di instance sumber adalah pengguna dengan hak istimewa yang tidak didukung di Cloud SQL, hal ini dapat menjadi masalah selama atau setelah migrasi.

Misalnya, prosedur yang tersimpan mungkin memiliki pendefinisi istimewa super untuk menjalankan perintah SQL, seperti mengubah variabel global yang tidak diizinkan di Cloud SQL. Untuk kasus seperti ini, Anda mungkin perlu menulis ulang kode prosedur yang tersimpan atau memigrasikan objek non-tabel seperti prosedur yang disimpan sebagai langkah migrasi terpisah.

Dokumentasi kami memiliki bagian yang berjudul Tugas impor dan migrasi MySQL yang berisi metadata dengan klausa DEFINER yang membahas lebih lanjut tentang masalah lain terkait klausa pendefinisi untuk objek database.

Karena batasan hak istimewa pengguna yang disebutkan sebelumnya, pengguna tidak dapat memanggil perintah SET GLOBAL secara native untuk mengubah parameter database. Sebagai gantinya, Cloud SQL menawarkan serangkaian "tanda" yang telah ditetapkan dan dapat dimodifikasi menggunakan Konsol UI, GCloud CLI, dan REST API untuk mengubah parameter.

Daftar lengkap tanda Cloud SQL yang didukung untuk MySQL dapat ditemukan di dokumentasi publik kami di bagian yang berjudul Tanda yang didukung. Sebelum bermigrasi ke Cloud SQL, tinjau daftar tanda yang didukung versus tanda yang saat ini digunakan di lingkungan sumber. Misalnya, salah satu praktik baiknya adalah membuat instance Cloud SQL pengujian dengan setelan CPU dan memori yang serupa dengan instance sumber, lalu menjalankan SHOW GLOBAL VARIABLES di sumber dan instance Cloud SQL, lalu membandingkan perbedaannya.

Tanda umum yang dapat memiliki setelan berbeda di infrastruktur lokal atau di penyedia cloud versus Cloud SQL untuk MySQL meliputi:

• Setelan kumpulan karakter dan pemeriksaan seperti character_set_server dan collation_server. Setelan default dapat berbeda di antara penginstalan dan menyebabkan perbedaan penyimpanan dan performa. Misalnya, latin1 versus utf8.
• Setelan log biner, seperti binlog_format. Cloud SQL saat ini hanya mendukung logging berbasis baris dalam log biner.
• Setelan replikasi lanjutan. Misalnya, Cloud SQL tidak mendukung parameter filter replikasi seperti replicate-do-table dan replicate-do-db.
• Setelan InnoDB lanjutan. Cloud SQL memungkinkan modifikasi sebagian besar parameter terkait InnoDB, seperti mengubah ukuran kumpulan buffer dengan mengubah innodb_buffer_pool_size. Namun, mungkin ada beberapa setelan InnoDB yang lebih mendetail yang tidak dapat diubah di Cloud SQL atau dengan setelan default yang berbeda dengan penyedia lokal atau penyedia cloud lainnya.