Apakah Anda ingin memulai dengan database open-source paling populer di dunia, dan bertanya-tanya bagaimana Anda harus menyiapkan hosting MySQL Anda? Begitu banyak default ke Amazon RDS, ketika MySQL berkinerja sangat baik di Azure Cloud. Meskipun Microsoft Azure memang menawarkan solusi terkelola, Azure Database, solusinya memiliki beberapa batasan utama yang harus Anda ketahui sebelum memigrasikan penerapan MySQL Anda. Dalam postingan ini, kami menjelaskan cara terbaik untuk menghosting MySQL di Azure, termasuk solusi terkelola, jenis instans, replikasi ketersediaan tinggi, pencadangan, dan jenis disk yang digunakan untuk mengoptimalkan kinerja basis data cloud Anda.
MySQL DBaaS vs. MySQL yang Dikelola Sendiri
Hal pertama yang perlu dipertimbangkan saat menimbang antara manajemen mandiri dan solusi MySQL Database-as-a-Service (DBaaS) adalah sumber daya internal yang Anda miliki. Jika Anda membaca ini, Anda mungkin sudah mengetahui besarnya tugas operasional yang terkait dengan mempertahankan penyebaran produksi, tetapi untuk rekap cepat, ada penyediaan, deprovisioning, konfigurasi master-slave, pencadangan, penskalaan, peningkatan, rotasi log, patch OS , dan pemantauan untuk beberapa nama.
Seorang ahli MySQL internal, atau tim DBA tergantung pada ukuran aplikasi Anda, tentu saja dapat menangani ini dengan organisasi Anda untuk Anda, tetapi pertanyaannya adalah di mana Anda ingin upaya tim Anda terfokus . Banyak yang memutuskan untuk pindah ke MySQL DBaaS untuk mengotomatisasi tugas-tugas yang memakan waktu ini sehingga mereka dapat lebih fokus pada pengembangan dan optimalisasi database aplikasi mereka. Contoh yang baik adalah analisis kueri yang lambat. Meskipun hampir setiap DBaaS menawarkan alat MySQL Slow Query Analyzer untuk membantu mengidentifikasi kueri bermasalah, tugas ini masih memerlukan keterampilan dan intuisi manusia untuk menentukan cara mengoptimalkan kueri tersebut yang memengaruhi kinerja aplikasi mereka.
Apakah Anda perusahaan rintisan atau bisnis kaya raya, Anda akan menemukan banyak organisasi memilih untuk memanfaatkan DBaaS untuk mengoptimalkan waktu DBA mereka, sementara jenis dan ukuran bisnis yang sama juga memilih untuk tetap dengan manajemen diri internal. Bagi banyak bisnis perusahaan, keputusan sebagian besar bermuara pada penyesuaian dan kontrol. Inilah sebabnya mengapa kami berhati-hati agar tidak default ke Azure Database, atau pesaing AWS-nya, Amazon RDS, karena mereka tidak mengizinkan Anda untuk menyimpan akses pengguna super MySQL atau bahkan akses SSH ke mesin Anda. Selain itu, kemampuan untuk menyesuaikan penyiapan penerapan Anda sangat terbatas, seperti jenis instans, RAM, ukuran disk, atau IOPS yang dapat Anda gunakan. Anda akan mempelajari lebih lanjut tentang jenis instans dan disk terbaik untuk digunakan di bawah ini, dan Anda dapat melihat Perbandingan Penyedia MySQL ini untuk melihat keuntungan dan batasan dari empat solusi MySQL terkelola teratas, ScaleGrid, Compose, Azure Database, dan Amazon RDS.
Penerapan Ketersediaan Tinggi
Jika Anda menerapkan dalam produksi, Anda harus selalu menyiapkan MySQL sebagai penerapan master-slave. Penerapan mandiri adalah node tunggal tanpa replikasi apa pun, dan seharusnya hanya digunakan untuk lingkungan pengembangan atau pengujian. Dengan penerapan master-slave, Anda dapat mengonfigurasi ketersediaan tinggi sehingga jika salah satu node Anda down, Anda dapat melakukan failover ke slave tanpa downtime. Ini biasanya diatur baik sebagai master-slave-slave 3-node, atau master-slave-quorum 2+1 node. Keuntungan menggunakan kuorum adalah bahwa ini adalah alternatif biaya yang lebih rendah, tetapi kerugiannya adalah Anda hanya memiliki 2 node pembawa data karena yang lain bertindak sebagai node kuorum untuk menentukan jalur failover terbaik. Jika aplikasi Anda dapat membaca dari slave, maka Anda perlu melakukan read scaling agar mereka mengembalikan data yang sama dari volume cluster dengan lag minimal.
Cara Terbaik untuk Meng-host MySQL di Azure CloudKlik Untuk Tweet
Saat menggunakan konfigurasi master-slave MySQL, sebaiknya siapkan replikasi semisinkron untuk meningkatkan integritas data Anda dengan redundansi data. Ini memastikan bahwa ketika komit kembali dengan sukses, data ada di master dan slave, jadi jika pusat data mati, master MySQL Anda dapat melakukan failover ke slave tanpa kehilangan data. Anda dapat melakukannya dengan replikasi asinkron atau semisinkron, dan pelajari lebih lanjut tentangnya di MySQL High Availability Explained – Postingan blog Bagian II.
Jadi, bagaimana cara mengonfigurasi ketersediaan tinggi untuk MySQL di Azure? Kami perlu mendistribusikan instans budak kami di berbagai zona ketersediaan Azure (AZ). Jadi, kami ingin memastikan bahwa kami memilih wilayah Azure yang memiliki setidaknya 3 AZ, menempatkan setiap instans di AZ yang berbeda. Kami melakukan ini karena jaminan ketersediaan ada di seluruh AZ, jadi jika 1 zona down, database aplikasi Anda masih dapat tetap online melalui 2 AZ lainnya. Zona ketersediaan cukup baru untuk Azure, jadi jika Anda bekerja di wilayah yang tidak menawarkan AZ, Anda memiliki opsi untuk menggunakan kumpulan ketersediaan. Ini sedikit lebih lemah daripada AZ, tetapi pastikan Anda diterapkan di berbagai domain dan rak untuk melindungi Anda dari potensi pemadaman. Ada juga opsi untuk menerapkan di seluruh wilayah, tetapi ini adalah penyiapan yang lebih rumit, jadi sebaiknya hubungi kami untuk berdiskusi sebelum menerapkan.
Jaringan Virtual Azure
Cara terbaik untuk melindungi database Anda dari internet adalah dengan menerapkannya di subnet pribadi untuk memastikannya tidak terekspos. Azure membuatnya mudah diatur melalui penggunaan Jaringan Virtual (VNET) yang dapat dikonfigurasi untuk server MySQL Anda. Dengan Azure VNET untuk MySQL, Anda dapat mengatur komunikasi yang aman antara server Anda, internet, dan bahkan jaringan cloud pribadi di lokasi Anda. Ini biasanya dikonfigurasi untuk berkomunikasi melalui satu jaringan, tetapi jika Anda perlu menghubungkan lebih dari satu wilayah, Anda dapat membuat beberapa VNET untuk berkomunikasi melalui Peering Jaringan Virtual.
Selain itu, Anda dapat mengelola kontrol akses MySQL Anda melalui aturan Grup Keamanan Jaringan (NSG) tanpa harus berurusan dengan daftar putih IP. Ini tidak tersedia melalui Azure Database untuk MySQL, tetapi VNET dan NSG dapat dikonfigurasi melalui paket MySQL Bring Your Own Cloud (BYOC) kami di Azure di mana Anda dapat meng-host cluster Anda melalui akun cloud Anda sendiri.
Jenis Instance Azure
Aspek penting lainnya yang perlu dipertimbangkan adalah kinerja instans MySQL Anda di cloud publik. Azure cloud menawarkan beberapa jenis instans yang dapat digunakan untuk hosting MySQL Anda, termasuk Es2 v3, Ds2, v2, dan Ls4.
Sebaiknya mulai dengan jenis instans yang dioptimalkan memori karena basis data memerlukan banyak RAM dan mencari kecepatan disk tercepat untuk kinerja terbaik. Seri Es2 biasanya merupakan titik awal yang baik untuk sebagian besar aplikasi beban kerja MySQL. Dari sana, Anda dapat melakukan beberapa pengujian kinerja untuk melihat apakah Anda memerlukan lebih banyak CPU, dalam hal ini, tipe instans seimbang atau tipe instans intensif-CPU mungkin lebih baik melayani kebutuhan MySQL Anda, seperti tipe instans Dv3. Tes kinerja Anda mungkin juga menunjukkan bahwa Anda memerlukan lebih banyak I/O (input/output), Anda dapat pindah ke jenis instans yang membutuhkan banyak disk.
Jika Anda berencana untuk memanfaatkan Azure sebagai penyedia cloud MySQL Anda selama 1-3 tahun ke depan dan mempertahankan konfigurasi penerapan yang cukup konsisten, Anda juga dapat mempertimbangkan instans yang dipesan. Ini pada dasarnya adalah contoh prabayar yang memungkinkan Anda mencapai penghematan biaya yang cukup besar untuk hosting MySQL Anda. Rata-rata, Anda dapat menghemat sekitar 20% hingga 30% untuk instans yang dipesan selama satu tahun, dan 40% hingga 50% untuk instans yang dipesan selama 3 tahun.
Jenis Disk Azure
Penentuan pertama yang perlu Anda buat saat memilih jenis disk Azure untuk penerapan MySQL Anda adalah apakah akan menggunakan disk yang dikelola atau tidak. Disk yang tidak dikelola adalah disk warisan yang ditawarkan Azure di mana Anda harus menyiapkan akun penyimpanan, memetakan disk Anda ke akun penyimpanan, dan memantau penggunaan dan batas IOPS untuk akun penyimpanan tersebut. Kami sangat menyarankan untuk menggunakan disk yang dikelola, dan jika Anda masih menerapkan dengan disk yang tidak dikelola, Anda harus mempertimbangkan untuk pindah ke yang dikelola.
Lingkungan Pengembangan/Pengujian MySQL:Disk Standar
Ada beberapa jenis disk terkelola yang tersedia melalui Azure, standarnya adalah disk standar. Disk standar dapat mendukung hingga 500 IOPS (operasi input/output per detik) dan bagus untuk operasi pengembangan dan pengujian karena dapat diubah ukurannya secara dinamis, tetapi tidak boleh digunakan untuk penerapan produksi MySQL.
Penempatan Produksi MySQL:Disk Premium
Untuk server produksi MySQL Anda, kami sangat menyarankan untuk memanfaatkan disk premium Azure. Ada berbagai macam disk premium yang dapat Anda pilih. Untuk setiap disk premium, Anda dapat memilih ukuran terbaik, dan setiap ukuran dilengkapi dengan IOPS Terprovisi yang berbeda sehingga Anda dapat memilih salah satu yang paling sesuai dengan kebutuhan aplikasi Anda.
Penempatan Produksi MySQL:SSD Lokal
Azure Local SSD adalah alternatif berperforma tinggi untuk disk premium, biasanya paling cocok untuk cluster besar. SSD Lokal memberikan kinerja I/O yang jauh lebih tinggi, dan throughput terbaik di Azure. Namun, mereka memiliki kelemahan karena mereka adalah disk sesaat, bukan penyimpanan permanen, jadi jika Anda menghentikan instans, data akan hilang. Kami merekomendasikan seri Ls v2 yang sangat cepat, tetapi hati-hati bahwa CPU sangat lemah yang dapat menyebabkan kemacetan mesin.
Cadangan MySQL di Azure
Cara terbaik untuk mencadangkan data MySQL Anda di Azure adalah dengan menggunakan snapshot disk yang dikelola. Snapshot adalah titik baca-saja dalam versi waktu dari disk. Cadangan ini dapat dibaca, disalin, atau dihapus, tetapi perhatikan bahwa cadangan tersebut tidak dapat dimodifikasi. Sebaiknya lakukan pencadangan penuh sehingga semua basis data, pengguna, dan pengaturan Anda dicadangkan pada instans jika Anda perlu memulihkan basis data MySQL. Sebaiknya juga mengenkripsi snapshot cadangan Anda sehingga cadangan hanya dapat dipulihkan ke mesin tempat pencadangan diambil.
Cadangan MySQL Anda akan menghasilkan biaya penyimpanan data Azure tambahan, kecuali jika Anda memanfaatkan solusi MySQL di Azure yang lengkap seperti paket Hosting Khusus kami di ScaleGrid. Untuk mengontrol biaya, sebaiknya Anda mengotomatiskan pencadangan melalui jadwal yang dapat disesuaikan yang memungkinkan Anda mengonfigurasi frekuensi pencadangan, jumlah maksimum cadangan yang harus dipertahankan, dan target pencadangan. Ini tentu saja juga membantu Anda memastikan data MySQL Anda dicadangkan secara teratur jika terjadi kehilangan data dalam penerapan produksi sehingga Anda dapat memulihkannya dengan cepat dengan cadangan terbaru.
Jika Anda memiliki pertanyaan tentang cara terbaik untuk meng-host MySQL di Azure, tinggalkan komentar di bawah atau hubungi kami di support@scalegrid. saya Anda juga dapat memulai uji coba gratis selama 30 hari untuk mempelajari keuntungan memanfaatkan layanan MySQL yang terkelola sepenuhnya untuk meningkatkan kinerja penerapan Anda.
