Praktik terbaik untuk menyiapkan instance Cloud SQL untuk MySQL

Cloud SQL untuk MySQL adalah layanan database yang terkelola sepenuhnya untuk membantu Anda menyiapkan, memelihara, mengelola, dan mengatur database relasional MySQL di Google Cloud. Setelah siap membuat instance Cloud SQL untuk MySQL, Anda memiliki beberapa opsi, termasuk konsol UI, gcloud CLI, Terraform, dan REST API. Anda dapat mengikuti dokumentasi kami untuk mengetahui detail setiap jalur ini, tetapi untuk tujuan artikel ini, kita akan menggunakan UI untuk ilustrasi karena kami membahas berbagai praktik terbaik untuk menyiapkan instance.

Memilih sandi yang kuat

Ini adalah sandi untuk pengguna database “root”@”% default yang akan dibuat dengan instance. Jika Anda ingin mempertahankan pengguna root sebagai pengguna admin, pastikan untuk memilih sandi yang kuat di sini. Sebaiknya gunakan pengguna admin yang tidak terlalu umum alih-alih "root" untuk masalah keamanan. Lihat bagian "Mengelola pengguna database". 

Membuat kebijakan sandi tingkat instance

Fitur kebijakan sandi memungkinkan keamanan database yang lebih baik. Dengan fitur ini, Anda dapat mengonfigurasi kebijakan terkait panjang sandi, kompleksitas, akhir masa berlaku, dan penggunaan ulang yang dibatasi. Lihat Melakukan Hardening pada Instance MySQL untuk mengetahui detailnya.

Mempertimbangkan versi 8.0 untuk performa yang lebih baik

Cloud SQL MySQL mendukung beberapa versi minor 8.0 dengan v8.0.26 sebagai default saat ini. Pengujian benchmark di berbagai jenis mesin menunjukkan throughput kueri yang lebih baik dengan versi default 8.0 daripada versi 5.7 dan 5.6.  

Jangan menempatkan instance produksi Anda di versi GA terbaru 

Oracle dan Cloud SQL telah melakukan pengujian yang ekstensif. Namun, rilis MySQL terbaru tidak sepenuhnya diuji berdasarkan berbagai skenario dunia nyata yang kompleks. Oleh karena itu, sebaiknya tetap gunakan versi stabil untuk instance produksi Anda serta gunakan instance dev dan staging untuk menguji upgrade versi minor terbaru di Cloud SQL untuk MySQL.

Mengonfigurasi beberapa zona untuk instance produksi

Cloud SQL untuk MySQL menawarkan ketersediaan regional melalui failover otomatis ke zona kedua sebagai solusi ketersediaan tinggi. Untuk mendapatkan ketersediaan terbaik, konfigurasikan opsi beberapa zona untuk instance produksi sehingga Anda otomatis memiliki pencadangan harian dan pemulihan point-in-time (lihat bagian "Jadwal pencadangan" untuk mengetahui informasi selengkapnya)

Mengevaluasi penggunaan CPU/memori saat ini untuk membuat keputusan migrasi yang tepat

Saat memigrasikan instance yang ada ke Cloud SQL, workload Anda saat ini dapat membantu Anda memilih ukuran VM yang tepat. 

• CPU: Berapa penggunaan CPU Anda dalam kondisi workload normal? Bagaimana dengan workload puncak? Apakah instance terikat CPU atau terikat I/O? Jika persentase CPU pengguna dan/atau sistem relatif tinggi, itu merupakan indikasi workload yang terikat CPU. Jika persentase I/O relatif tinggi, itu merupakan indikasi workload yang terikat I/O. 
• Memori: Demikian pula, berapa penggunaan memori normal untuk instance tersebut, dan berapa penggunaan puncaknya? 

Sebagai referensi, 1 vCPU di Cloud SQL untuk MySQL dapat mendukung memori hingga 6,5 GB. 

Merencanakan 20%-50% ruang tambahan untuk CPU dan memori

Bahkan dalam instance yang umumnya stabil, rencanakan setidaknya 20% ruang ekstra untuk CPU dan memori guna menyerap lonjakan yang tidak direncanakan. Ini khususnya sangat penting bagi bisnis yang sedang berkembang—pertimbangkan tambahan 50%. 

Cloud SQL memudahkan Anda mengupgrade jenis mesin. Perlu diperhatikan bahwa ada periode nonaktif terkait upgrade.

Menggunakan SSD untuk performa database yang lebih baik

Cloud SQL untuk MySQL menawarkan HDD sebagai opsi penyimpanan ekonomis. Namun, jika Anda memerlukan database berperforma tinggi, gunakan opsi SSD. Berikut perbandingan performa I/O. 

Merencanakan penyeimbangan performa vs. biaya dalam hal kapasitas penyimpanan

IOPS dan throughput disk berhubungan dengan ukuran persistent disk. Kapasitas yang lebih tinggi memberikan IOPS dan throughput yang lebih besar dalam batas instance. 

Untuk SSD, konfigurasi zona dan regional akan memengaruhi performa. Lihat data performa SSD zona vs. regional untuk mengetahui detail selengkapnya. Jika Anda memilih ketersediaan beberapa zona, lihat data performa SSD regional. Singkatnya, IOPS baca dan tulis adalah 30 per GB, dan throughput sebesar 0,48 MB per GB. Dengan SSD regional, data performanya serupa, tetapi IOPS tulis dan throughput tulis per instance lebih rendah. 

Perhatikan bahwa ukuran penyimpanan maksimum yang didukung adalah 64 TB pada instance Cloud SQL. 

Mengaktifkan peningkatan penyimpanan otomatis dan memantau perkembangan disk

Cloud SQL memiliki fitur peningkatan penyimpanan otomatis untuk mencegah instance kehabisan kapasitas disk (OOD). Saat fitur ini diaktifkan, penyimpanan diperiksa setiap 30 detik, dan kapasitas penyimpanan inkremental akan ditambahkan jika diperlukan. 

Meskipun fitur ini melindungi dari OOD, kapasitas yang ditingkatkan bersifat permanen—Anda tidak dapat memperkecil ukuran instance nanti. Mulailah dengan menyiapkan pemberitahuan tentang ukuran disk sehingga Anda dapat mengelola dan merencanakan kapasitas penyimpanan. 

Memahami opsi enkripsi

Cloud SQL mengenkripsi data dalam penyimpanan secara default. Namun, ada opsi untuk menggunakan kunci enkripsi yang dikelola pelanggan (CMEK), bukan kunci default yang dimiliki dan dikelola oleh Google jika lebih sesuai dengan kebutuhan Anda.

Menilai kompromi antara IP pribadi dan IP publik

IP pribadi dan publik mengacu pada jenis alamat yang digunakan oleh perangkat dalam jaringan. IP pribadi menawarkan keamanan jaringan yang lebih baik dan latensi jaringan yang lebih rendah dibandingkan IP publik. Namun, IP pribadi memerlukan konfigurasi API dan IAM tambahan untuk disiapkan, dan terkadang IP publik sebenarnya diwajibkan. Jika tahu bahwa Anda perlu menggunakan IP publik, tetapi ingin meningkatkan keamanan, Anda dapat memilih untuk mewajibkan jaringan yang diotorisasi atau menggunakan proxy Auth Cloud SQL. 

Mempertimbangkan proxy Cloud SQL Auth untuk koneksi aman

Proxy Auth Cloud SQL menyediakan akses aman ke instance Cloud SQL sebagai pengganti konfigurasi SSL atau jaringan yang diotorisasi. Aplikasi ini berkomunikasi dengan klien proxy Auth, yang berjalan di lingkungan lokal dan menggunakan tunnel yang aman untuk berkomunikasi dengan server proxy pada instance Cloud SQL.

Mengaktifkan pencadangan dan pemulihan point-in-time serta meninjau kebijakan retensi Anda 

Pencadangan data rutin dan pemulihan data yang dapat diverifikasi sangat penting untuk pengelolaan database yang optimal. Praktik ini sangat berharga dalam situasi seperti kerusakan data atau operasi data yang tidak diinginkan. Kedua situasi ini tidak dapat dimitigasi dengan ketersediaan tinggi. 

Cloud SQL menawarkan pencadangan otomatis, verifikasi cadangan, dan pemulihan point-in-time (PITR). Konfigurasi ini diaktifkan secara default dan diperlukan pada instance dengan beberapa zona. Pencadangan otomatis dilakukan setiap hari dan kebijakan retensi default-nya adalah tujuh salinan cadangan dan tujuh hari log biner (diperlukan untuk PITR). Anda dapat menyesuaikan kebijakan retensi di bagian Opsi Lanjutan.

Flag database adalah konfigurasi server yang masuk ke file my.cnf. Ada daftar flag db yang dapat dikonfigurasi dan flag terkelola tertentu yang tidak dapat dikonfigurasi. Sebaiknya tinjau flag db dan konfigurasi ke nilai yang tepat pada waktu pembuatan instance. Karena sejumlah flag db tidak bersifat dinamis, mengubahnya akan memicu proses mulai ulang instance. 

Meninjau character_set_server 

Pada instance Cloud SQL untuk MySQL, character_set_server default adalah utf8 pada v5.6 dan v5.7 serta utf8mb4 pada v8.0. character_set_server menetapkan character_set_server, character_set_server, character_set_server, dan character_set_server ke nilai yang sama. Untuk character_set_system, defaultnya adalah utf8mb3 pada v8.0. 

Jika Anda memigrasikan instance dan konfigurasi saat ini menggunakan himpunan karakter yang berbeda (misalnya, latin1), pastikan untuk menetapkan character_set_server secara eksplisit pada instance baru. 

Meninjau time_zone

Default zona waktu adalah system_time_zone, yang merupakan UTC. Jika Anda ingin menggunakan time_zone yang berbeda, tetapkan melalui default_time_zone. Flag ini menggunakan dua format: offset zona waktu, misalnya, +08:00, dan nama zona waktu, misalnya, America/Los_Angeles. Jika ditentukan berdasarkan nama zona waktu, zona waktu akan otomatis disesuaikan dengan waktu musim panas (jika relevan). Flag default_time_zone tidak bersifat dinamis dan instance db harus dimulai ulang untuk membuat perubahan. 

Mengaktifkan log kueri lambat 

Secara default, slow_query_log disetel ke NONAKTIF. Sebaiknya aktifkan log kueri lambat dan setel slow_query_log ke nilai minimum yang wajar bagi aplikasi. Log kueri lambat membantu mengambil kueri yang berjalan lama untuk analisis dan pengoptimalan. Informasi ini tidak hanya membantu kueri individu, tetapi juga throughput server secara keseluruhan dan analisis retrospektif workload yang tidak terduga. 

Meninjau innodb_buffer_pool_size

Konfigurasi ini paling efektif untuk mendorong performa InnoDB. Makin banyak data yang dapat di-buffer di memori, makin baik performa server Anda. Pada saat yang sama, perlu dicadangkan memori yang cukup untuk buffer global dan buffer dinamis per thread. 

Di Cloud SQL, nilai default, nilai minimum yang diizinkan, dan nilai maksimum yang diizinkan dari flag innodb_buffer_pool_size bergantung pada memori instance seperti yang dijelaskan dalam dokumentasi. 

Innodb_buffer_pool_size yang efektif tidak harus berisi semua data, tetapi hanya data yang sering diakses. Variabel status yang mencerminkan efisiensi buffer pool adalah Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests. Variabel Innodb_buffer_pool_read_requests adalah jumlah permintaan operasi baca logis dan Innodb_buffer_pool_read_requests adalah jumlah operasi baca logis yang tidak terpenuhi dari buffer pool dan harus dibaca dari disk. Dalam kasus yang ideal, yakni saat data sepenuhnya berada dalam buffer pool, rasio Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests akan mendekati nol. Memantau variabel ini akan memberikan gambaran tentang efisiensi buffer pool InnoDB. Jika innodb_buffer_pool_size mencapai nilai maksimum yang diizinkan, buffer pool tidak memiliki efisiensi yang baik, dan aplikasi mengalami masalah performa kueri, sebaiknya upgrade instance Anda agar memiliki memori yang lebih besar. 

Variabel ini menjadi dinamis di MySQL v5.7 dan v8.0, sedangkan di v5.6, instance harus dimulai ulang untuk mengubah variabel tersebut. 

Meninjau innodb_log_file_size

Sebelum versi 8.0.30, innodb_log_file_size dan innodb_log_file_size_in_group tidak bersifat dinamis dan perubahan innodb_log_file_size memerlukan penonaktifan tuntas (clean shutdown). Versi 8.0.30 memperkenalkan innodb_redo_log_capacity untuk menggantikan innodb_log_file_size dan innodb_log_files_in_group.  

Instance Cloud SQL untuk MySQL dikonfigurasi dengan innodb_log_file_size=512 MB, innodb_log_files_in_group=2 (atau innodb_redo_log_capacity=1 GB). Hal ini memungkinkan InnoDB menyimpan lebih banyak perubahan dalam buffer pool tanpa menyinkronkan ke disk sehingga meningkatkan performa server. Kelemahan dari file log redo berukuran besar adalah waktu pemulihan error lebih lama. Bergantung pada persyaratan dan penyiapan HA instance, keputusan ini memerlukan keseimbangan antara performa dan ketersediaan. 

Umumnya, sebaiknya sediakan file log redo dengan ukuran yang cukup besar untuk menyimpan aktivitas operasi tulis selama satu jam. Salah satu cara untuk mengukur hal ini adalah dengan mengamatiInnodb_os_log_written sepanjang hari dan kemudian memastikanInnodb_os_log_written * Innodb_os_log_written cukup besar untuk jam puncak pengamatan. 

Meninjau innodb_log_buffer_size 

Di MySQL v5.6 dan v5.7, innodb_log_buffer_size tidak bersifat dinamis, dan instance harus dimulai ulang untuk mengubahnya. Oleh karena itu, sebaiknya setel saat inisialisasi. 

Jika ukuran innodb_log_buffer_size cukup besar untuk menampung seluruh transaksi, tidak akan ada flushing tambahan ke disk selama eksekusi transaksi. Secara default, innodb_log_buffer_size disetel ke 16 MB, yang umumnya sudah cukup. Namun, untuk mengetahui apakah transaksi besar mungkin memerlukan buffer yang lebih besar, pantau variabel status Innodb_log_waits saat Anda melakukan transaksi besar. Jika innodb_log_buffer_size terlalu kecil dan perlu menunggu flush, innodb_log_buffer_size akan bertambah sebesar satu. 

Menyesuaikan variabel dinamis sesuai kebutuhan

Beberapa flag db terkait performa bersifat dinamis, seperti table_open_cache, thread_cache_size. Sebaiknya tentukan ukuran yang tepat untuk memulai serta lakukan pengukuran dan penyesuaian sesuai kebutuhan. 

Flag table_open_cache digunakan untuk jumlah tabel yang terbuka. Cache yang memadai membantu mengurangi waktu buka tabel, sehingga meningkatkan performa kueri. Variabel status Opened_tables menampilkan jumlah tabel yang telah dibuka. Jika Opened_tables terus meningkat, pertimbangkan untuk meningkatkan table_open_cache. 

Flag thread_cache_size digunakan untuk menyimpan thread dalam cache agar dapat digunakan kembali setelah klien memutuskan koneksi. Jika sebuah instance diperkirakan akan mendapat banyak koneksi baru secara bersamaan, tetapkan ukuran yang lebih besar. Rasio variabel status Threads_created dan Connections menunjukkan efisiensi cache thread. Rasio rendah lebih baik. 

Menggunakan pendekatan konservatif terkait flag memori per thread

Sejumlah buffer memori per thread memengaruhi performa kueri, misalnya, tmp_table_size, max_heap_table_size, join_buffer_size, sort_buffer_size, dan lainnya. Variabel ini memiliki cakupan global maupun sesi. Cakupan global menetapkan nilai per thread untuk semua koneksi baru, sedangkan cakupan sesi berlaku untuk kueri berikutnya pada sesi saat ini. Memori yang lebih besar untuk setelan seperti ini menghasilkan performa kueri yang lebih baik. Namun, karena bersifat dinamis dan mengalokasikan satu atau beberapa per thread, keduanya dapat menyebabkan skenario kehabisan memori (OOM).

Sebaiknya gunakan angka sedang untuk nilai global dan cadangkan jumlah yang lebih besar untuk sesi tertentu guna mencapai performa yang lebih baik dengan cara yang terkontrol.

Mempertimbangkan performance_schema 

performance_schema ditetapkan secara default ke NONAKTIF sebelum MySQL v8.0.26 dan memerlukan proses mulai ulang untuk mengaktifkannya. performance_schema mengaktifkan berbagai instrumentasi dan menyediakan kumpulan data yang beragam untuk menganalisis operasi server, tetapi akan mengorbankan performa dan memori. Instrumentasi default menghasilkan penurunan performa sekitar 5%, dan ini akan bertambah seiring dengan semakin banyaknya instrumen yang ditambahkan. Lakukan benchmark instrumentasi dengan workload Anda karena konsumsi memori dapat meningkat hingga 1 GB atau lebih. Anda dapat mengamati konsumsi memori ini dalam tabel memory_summary_global_by_event_name table. 

Setelah membuat instance Cloud SQL, ada satu pengguna database yang tersedia, ‘root’@’%’. Anda mungkin perlu membuat pengguna database tambahan. 

Membatasi akses pengguna ke operasi yang diperlukan

Hanya berikan akses ke kebutuhan minimum kepada pengguna sebagai prosedur pembatasan. 

Saat membuat pengguna melalui MySQL CLI, Anda perlu memberikan hak istimewa secara eksplisit. 

Saat membuat pengguna melalui Konsol Cloud, pengguna tersebut akan memiliki hak istimewa yang sama dengan pengguna ‘root’@’%’. Di MySQL v5.6 dan v5.7, hak istimewa default mencakup semua hak istimewa dengan opsi pemberian kecuali hak istimewa SUPER dan FILE. Pada v8.0, pengguna memiliki hak istimewa dinamis. Meski hak istimewa SUPER dan FILE masih dibatasi, peran admin lainnya tersedia untuk pengguna tersebut (misalnya, APPLICATION_PASSWORD_ADMIN, CONNECTION_ADMIN, ROLE_ADMIN, SET_USER_ID dan XA_RECOVER_ADMIN). Anda harus mencabut semua hak istimewa yang tidak diperlukan melalui MySQL CLI. Pada instance v8.0, variabel partial_revokes diaktifkan. 

Mempertimbangkan untuk mengganti 'root'@'%' dengan pengguna admin tertentu

Pengguna ‘root’@’%’ adalah pengguna super default dan paling populer sehingga sering kali menjadi target peretas. Sebaiknya buat pengguna admin Anda sendiri dengan kumpulan hak istimewa yang sama seperti pengguna 'root'@'%', lalu ganti untuk mendapatkan keamanan yang lebih baik.

Sangat penting untuk memantau dan melacak berbagai aspek operasi database dan resource sistem. Hal ini memungkinkan Anda meninjau dan menganalisis kondisi operasional instance dari waktu ke waktu, yang juga dapat membantu perencanaan resource. 

• Halaman ringkasan Konsol Cloud dilengkapi dengan daftar metrik inti. 
• Cloud Monitoring menawarkan metrik tambahan. Anda dapat membuat dasbor dengan metrik yang dipilih untuk instance db Anda. Di Konsol Cloud, dari menu Navigasi kiri atas, pilih OPERATIONS --> Monitoring untuk mengakses Cloud Monitoring. 
• Gunakan Query Insights di Cloud SQL untuk analisis performa kueri. Bagian ringkasannya menampilkan beban CPU yang dikelompokkan menurut database, pengguna, atau alamat klien. Penggunaan CPU juga diperinci untuk menunjukkan waktu tunggu I/O dan waktu kunci. Kode ini juga mencantumkan kueri teratas berdasarkan ringkasan kueri. Untuk setiap ringkasan kueri, Anda dapat melihat waktu eksekusi rata-rata, jumlah kueri, dan rata-rata baris yang dipindai dan ditampilkan. Metrik ini sangat membantu untuk mengidentifikasi hot spot dan kueri yang perlu dioptimalkan. 
• Anda juga dapat melengkapi data di atas dengan alat pemantauan buatan sendiri dan/atau alat pihak ketiga. Tujuan utamanya adalah memahami operasi database yang dapat memengaruhi pengoptimalan serta pemecahan masalah kueri dan server. 

Pemberitahuan yang tepat sangat penting untuk memastikan server dalam kondisi baik. Hal ini membantu mencegah gangguan layanan, seperti kehabisan memori (OOM) atau gangguan sistem karena saturasi CPU. 

Jika menggunakan Cloud Monitoring, Anda dapat membuat pemberitahuan berbasis metrik. Lihat dokumentasi untuk mengetahui detailnya. 

Jika Anda menggunakan alat pemantauan lain, pastikan untuk mengonfigurasi pemberitahuan.

Untuk menskalakan operasi baca, pertimbangkan untuk menambahkan replika baca. Anda dapat menggunakan HAProxy, ProxySQL, atau load balancer lain untuk mendistribusikan operasi baca di antara beberapa replika baca. 

Cloud SQL juga mendukung replikasi berantai, yang dapat Anda pelajari di bagian replika bertingkat.  

Replika baca dibuat dengan versi MySQL yang sama dengan instance utama. Setelah dibuat, Anda dapat memilih untuk mengupgrade replika ke yang utama.

Solusi ketersediaan tinggi menyediakan redundansi data di zona sekunder dalam region yang sama. Pada saat bencana, satu region mungkin menjadi tidak tersedia. Replika baca lintas region adalah resource penting dalam disaster recovery plan karena dapat dipromosikan menjadi instance utama saat diperlukan. Baca dokumentasi untuk mengetahui detail selengkapnya.