Pertimbangan penting sebelum migrasi Aurora ke Cloud SQL untuk MySQL

Aurora menggunakan himpunan karakter default server latin1 (hingga MySQL v 5.7). Hal ini berbeda dengan konfigurasi default Cloud SQL untuk MySQL untuk database, tabel, prosedur tersimpan, dan fungsi, yang dibuat dengan utf8 sebagai himpunan karakter default selama migrasi. Hal ini dapat menimbulkan situasi yang menyebabkan masalah performa.

Misalnya, pengguna dapat berakhir dalam situasi di mana tabel dibuat dengan himpunan karakter latin1 dan prosedur tersimpan atau fungsi dibuat dengan himpunan karakter utf8 default Cloud SQL. Dalam kasus tersebut, jika prosedur tersimpan atau fungsi mengharapkan variabel sebagai parameter utf8 dan membandingkan variabel tersebut dengan nilai kolom, yang berada dalam himpunan karakter latin1, akan terjadi masalah performa karena perbandingan antara dua himpunan karakter dan kolasi yang berbeda. 

Anda dapat memeriksa himpunan karakter rutinitas dengan menggunakan perintah di bawah ini:

mysql> select ROUTINE_NAME, ROUTINE_SCHEMA, CHARACTER_SET_NAME, COLLATION_NAME from information_schema.ROUTINES;

Jika Anda menggunakan himpunan karakter default di Aurora (hingga v 5.7) yakni latin1, maka himpunan karakter default harus diubah dari utf8 ke latin1 di Cloud SQL sebelum mengimpor data.

Solusi lainnya adalah mengubah semuanya menjadi utf8. Namun, dalam kasus ini pengguna harus menguji aplikasi dan set data yang lengkap karena perubahan pada himpunan karakter dapat menghasilkan representasi data yang tidak terduga.

Pengguna dapat mengedit setelan ini di instance Cloud SQL di bagian flag, seperti yang digambarkan di bawah.

Aurora MySQL 5.7 memiliki banyak kolasi (misalnya utf8mb4_0900_ai_ci untuk himpunan karakter utf8mb4) yang saat ini hanya tersedia di Cloud SQL untuk MySQL 8.0. Jika Anda menggunakan kolasi seperti itu dan mengimpor data di Cloud SQL untuk MySQL 5.7, Anda akan menerima pesan error seperti "Error 'character set '#255' is not a compile character set".

Solusinya adalah dengan mengubah kolasi tersebut menjadi kolasi yang tersedia di MySQL versi 5.7.

Tidak seperti Aurora, Cloud SQL untuk MySQL tidak mendukung mesin MyISAM. Sebaiknya konversi semua tabel menjadi InnoDB sebelum memulai Migrasi dari Aurora ke Cloud SQL. 

Jika ada tabel di mesin selain InnoDB, pengguna dapat mengubah mesin tabel menggunakan perintah "ALTER":

mysql> alter table table_1 engine='Innodb' ;

Query OK, 0 rows affected (2.89 sec)

Records: 0 Duplicates: 0 Warnings: 0

Catatan: Waktu kueri bergantung pada ukuran tabel, dan selama proses berlangsung, operasi lain di tabel yang sama dapat terkunci. Anda juga dapat menggunakan alat perubahan skema online seperti pt-online-schema-change atau gh-ost untuk mengubah tabel tanpa memblokir operasi lain.

Di Aurora, pengguna dapat menyiapkan beberapa pembaca di balik satu endpoint, tetapi pengguna Cloud SQL untuk MySQL tidak begitu saja memiliki fitur ini. Setiap replika baca di Cloud SQL untuk MySQL memiliki IP sendiri dan pengguna harus menggunakan alat seperti ProxySQL untuk membagi traffic di antara beberapa instance replika baca.

Berikut adalah panduan yang menunjukkan cara menggunakan ProxySQL untuk merutekan traffic di antara beberapa replika baca.

Buffer perubahan adalah struktur data khusus yang meng-cache perubahan ke halaman indeks sekunder saat halaman tersebut tidak berada dalam gabungan buffer untuk kemudian digabungkan saat halaman tersebut dimuat ke dalam gabungan buffer oleh operasi baca lainnya. Untuk mengetahui detail selengkapnya, baca Buffer Perubahan.

Untuk kasus penggunaan ketika workload memiliki banyak operasi tulis pada tabel dengan indeks sekunder, Aurora dapat berperforma lebih lambat daripada Cloud SQL untuk MySQL, yang menggunakan fitur buffer perubahan InnoDB default untuk menunda pembaruan tersebut ke tahap selanjutnya. Pengguna harus melakukan tolok ukur terhadap performa sesuai dengan workload aplikasi mereka.

Cache kueri menyimpan perintah select beserta hasilnya dalam lapisan penyimpanan perantara. Jika kemudian ada pernyataan yang sama diterima, server akan memeriksa dan mengambil hasil dari cache kueri, bukan mengeksekusi perintah tersebut lagi. Cache kueri dibagikan di antara sesi, sehingga semua sesi bisa mendapatkan manfaat dari hasil yang di-cache oleh pernyataan yang sudah dieksekusi dari sesi lain. Baca selengkapnya tentang cache kueri.

Aurora mengaktifkan cache kueri secara default, namun Komunitas MySQL menonaktifkan cache kueri di versi 5.7 dan menghapusnya sepenuhnya di versi 8.0. Hal yang sama dilakukan di Cloud SQL MySQL. Jika kueri Anda mengandalkan fitur cache kueri dari Aurora, performanya dapat bervariasi di Cloud SQL MySQL. Sebaiknya uji performa kueri Anda di Cloud SQL MySQL dengan membandingkan waktu eksekusinya dengan Aurora.

Untuk replika baca dalam sebuah region, Aurora menggunakan konsep volume cluster yang memiliki salinan data di tiga zona ketersediaan dalam region tersebut. Jeda replikasi di Aurora biasanya jauh kurang dari 100 milidetik karena baik instance primer maupun replika dalam cluster database yang sama melihat data dalam volume cluster sebagai satu volume logis. Selain itu, untuk replika baca lintas region, Aurora menggunakan sinkronisasi data berbasis disk di seluruh region, bukan replikasi berbasis log biner.

Singkatnya, replikasi ditangani oleh lapisan penyimpanan di Aurora, sedangkan di Cloud SQL untuk MySQL, digunakan mekanisme replikasi standar, yaitu mentransfer log biner ke instance replika, lalu memutar ulang log tersebut dalam instance MySQL replika. Kita dapat meningkatkan performa replikasi dengan mengonfigurasi replikasi paralel di Cloud SQL. Baca detail tentang menyiapkan replikasi paralel.

Meskipun jeda replikasi bergantung pada jumlah data yang diubah oleh aplikasi dan jaringan antara instance primer dan replika, sebagian besar aplikasi berfungsi dengan baik tanpa ada jeda yang signifikan di Aurora dan Cloud SQL untuk MySQL. Namun, jika aplikasi memiliki banyak operasi tulis dan aplikasi membaca dari replika, sebaiknya lakukan tolok ukur jeda replikasi di AWS Aurora dan CloudSQL MySQL sebelum migrasi.

Tidak seperti AWS Aurora yang menggunakan sinkronisasi data berbasis disk, Cloud SQL untuk MySQL menggunakan replikasi GTID. Pengguna harus memeriksa batasan GTID yang tercantum di bawah sebelum migrasi dan melakukan perubahan yang diperlukan pada aplikasi jika alur kerja aplikasi memiliki dependensi pada salah satu fitur tersebut:

• Pernyataan CREATE TABLE ... SELECT tidak diizinkan bila menggunakan replikasi berbasis GTID.
• Pernyataan CREATE TEMPORARY TABLE dan DROP TEMPORARY TABLE tidak didukung di dalam transaksi, prosedur, fungsi, dan pemicu. Pernyataan ini dapat digunakan dengan GTID yang diaktifkan, tetapi hanya di luar transaksi apa pun, dan hanya dengan autocommit=1.

Untuk informasi selengkapnya tentang batasan berbasis GTID, baca Batasan pada GTID.