Ketersediaan tinggi di Azure Database for MySQL

  • Artikel

BERLAKU UNTUKAzure Database for MySQL - Server Tunggal

Penting

Server tunggal Azure Database for MySQL berada di jalur penghentian. Kami sangat menyarankan Agar Anda meningkatkan ke server fleksibel Azure Database for MySQL. Untuk informasi selengkapnya tentang migrasi ke server fleksibel Azure Database for MySQL, lihat Apa yang terjadi pada Server Tunggal Azure Database for MySQL?

Layanan Azure Database for MySQL memberikan jaminan ketersediaan tingkat tinggi dengan perjanjian tingkat layanan (SLA) yang didukung secara finansial sebesar 99,99% waktu aktif. Azure Database for MySQL menyediakan ketersediaan tinggi selama peristiwa yang direncanakan seperti operasi komputasi skala yang dimulai pengguna, dan juga ketika peristiwa yang tidak direncanakan seperti kegagalan perangkat keras, perangkat lunak, atau jaringan yang mendasarinya terjadi. Azure Database for MySQL dapat dengan cepat pulih dari keadaan paling kritis, memastikan hampir tidak ada waktu yang tidak berfungsi aplikasi saat menggunakan layanan ini.

Azure Database for MySQL cocok untuk menjalankan database penting misi yang memerlukan waktu aktif tinggi. Dibangun di arsitektur Azure, layanan ini memiliki kemampuan ketersediaan tinggi, redundansi, dan ketahanan yang melekat untuk mengurangi waktu henti database dari penghentian yang direncanakan dan tidak direncanakan, tanpa mengharuskan Anda untuk mengonfigurasi komponen tambahan apa pun.

Komponen dalam Azure Database for MySQL

Komponen Keterangan
Server Database MySQL Azure Database for MySQL menyediakan keamanan, isolasi, perlindungan sumber daya, dan kemampuan mulai ulang cepat untuk server database. Kemampuan ini memfasilitasi operasi seperti penskalaan dan operasi pemulihan server database setelah pemadaman terjadi dalam 60-120 detik tergantung pada aktivitas transaksional pada database.
Modifikasi data di server database biasanya terjadi dalam konteks transaksi database. Semua perubahan database direkam secara sinkron dalam bentuk tulis di depan log (ib_log) di Azure Storage – yang dilampirkan ke server database. Selama proses titik pemeriksaan database, halaman data dari memori server database juga dikirim ke penyimpanan.
Penyimpanan Jarak Jauh Semua file data fisik dan file log MySQL disimpan di Microsoft Azure Storage, yang dirancang untuk menyimpan tiga salinan data dalam wilayah untuk memastikan redundansi, ketersediaan, dan keandalan data. Lapisan penyimpanan juga independen dari server database. Ini dapat dilepas dari server database yang gagal dan disamarkan kembali ke server database baru dalam waktu 60 detik. Selain itu, Microsoft Azure Storage terus memantau kesalahan penyimpanan apa pun. Jika terdeteksi, kerusakan blok secara otomatis diperbaiki dengan menginstansiasi salinan penyimpanan baru.
Gateway Gateway bertindak sebagai proksi database dan merutekan semua koneksi klien ke server database.

Mitigasi waktu henti terencana

Azure Database for MySQL dirancang untuk menyediakan ketersediaan tinggi selama operasi waktu henti yang direncanakan.

view of Elastic Scaling in Azure MySQL

Berikut adalah beberapa skenario pemeliharaan yang direncanakan:

Skenario Keterangan
Peningkatan/penurunan skala komputasi Ketika pengguna melakukan operasi peningkatan/penurunan skala komputasi, server database baru disediakan menggunakan konfigurasi komputasi yang diskalakan. Di server database lama, titik pemeriksaan aktif diizinkan untuk diselesaikan, koneksi klien dikosongkan, setiap transaksi yang tidak didilakukan akan dibatalkan, dan kemudian dimatikan. Penyimpanan kemudian dicopot dari server database lama dan dilampirkan ke server database baru. Ketika aplikasi klien mencoba kembali koneksi, atau mencoba membuat koneksi baru, Gateway akan mengarahkan permintaan koneksi ke server database baru.
Peningkatan Skala Penyimpanan Peningkatan skala penyimpanan adalah operasi online dan tidak mengganggu server database.
Penyebaran Perangkat Lunak Baru (Azure) Peluncuran fitur baru atau perbaikan bug akan otomatis terjadi sebagai bagian dari pemeliharaan terencana layanan. Untuk informasi selengkapnya, lihat dokumentasi, dan periksa juga portal Anda.
Peningkatan versi minor Azure Database for MySQL secara otomatis menambal server database ke versi minor yang ditentukan oleh Azure. Proses ini terjadi sebagai bagian dari pemeliharaan yang direncanakan layanan. Selama pemeliharaan terencana, mungkin ada hidupkan ulang server database atau kegagalan, yang mungkin menyebabkan tidak tersedianya server database untuk pengguna akhir. Azure Database for MySQL berjalan dalam kontainer sehingga menghidupkan ulang server database biasanya cepat, diharapkan selesai biasanya dalam 60-120 detik. Seluruh peristiwa pemeliharaan terencana, termasuk menghidupkan ulang setiap server, dipantau dengan cermat oleh tim rekayasa. Waktu kegagalan server tergantung pada waktu pemulihan database, yang dapat menyebabkan database online lebih lama jika Anda memiliki aktivitas transaksional yang berat di server pada saat kegagalan. Untuk menghindari waktu mulai ulang yang lebih lama, disarankan untuk menghindari transaksi yang berjalan lama (muat massal) selama peristiwa pemeliharaan terencana. Untuk informasi selengkapnya, lihat dokumentasi, dan periksa juga portal Anda.

Mitigasi waktu henti tidak terencana

Waktu henti tidak terencana dapat terjadi sebagai akibat dari kegagalan yang tidak terduga, termasuk kesalahan perangkat keras dasar, masalah jaringan, dan bug perangkat lunak. Jika server database turun secara tiba-tiba, server database baru secara otomatis disediakan dalam 60-120 detik. Penyimpanan jarak jauh secara otomatis dilampirkan ke server database baru. Mesin MySQL melakukan operasi pemulihan menggunakan FILE WAL dan database, dan membuka server database untuk memungkinkan klien terhubung. Transaksi yang tidak terikat hilang, dan harus dicoba ulang oleh aplikasi. Meskipun waktu henti yang tidak direncanakan tidak dapat dihindari, Azure Database for MySQL mengurangi waktu henti dengan secara otomatis melakukan operasi pemulihan di server database dan lapisan penyimpanan tanpa memerlukan intervensi manusia.

view of High Availability in Azure MySQL

Waktu henti yang tidak direncanakan: skenario kegagalan dan pemulihan layanan

Berikut adalah beberapa skenario kegagalan dan bagaimana Azure Database for MySQL secara otomatis pulih:

Skenario Pemulihan otomatis
Kegagalan server database Jika server database mati karena beberapa kesalahan perangkat keras yang mendasarinya, koneksi aktif dijatuhkan, dan setiap transaksi dalam pesawat dibatalkan. Server database baru akan otomatis disebarkan, dan penyimpanan data jarak jauh akan dilampirkan ke server database baru. Setelah pemulihan database selesai, klien bisa tersambung ke server database baru melalui Gateway.

Aplikasi yang menggunakan database MySQL perlu dibangun dengan cara yang mereka deteksi dan coba lagi koneksi yang dijatuhkan dan transaksi yang gagal. Ketika aplikasi dicoba kembali, Gateway secara transparan mengalihkan koneksi ke server database yang baru dibuat.
Kegagalan penyimpanan Aplikasi tidak melihat dampak apa pun untuk masalah terkait penyimpanan seperti kegagalan disk atau kerusakan blok fisik. Karena data disimpan dalam 3 salinan, salinan data dilayani oleh penyimpanan yang bertahan. Kerusakan blok akan otomatis diperbaiki. Jika salinan data hilang, salinan data baru akan dibuat secara otomatis.

Berikut adalah beberapa skenario kegagalan yang pemulihannya memerlukan tindakan pengguna:

Skenario Rencana pemulihan
Kegagalan wilayah Kegagalan suatu wilayah adalah peristiwa langka. Namun, jika memerlukan perlindungan terhadap kegagalan wilayah, Anda dapat mengonfigurasi satu atau beberapa replika baca di wilayah lain untuk pemulihan bencana (DR). (Untuk informasi detailnya, lihat artikel ini yang membahas tentang cara membuat dan mengelola replika baca). Jika terjadi kegagalan tingkat wilayah, Anda dapat secara manual mempromosikan replika baca yang dikonfigurasi di wilayah lain agar menjadi server database produksi Anda.
Kesalahan logika/pengguna Pemulihan dari kesalahan pengguna, seperti tabel yang dijatuhkan secara tidak sengaja atau data yang salah diperbarui, melibatkan operasi pemulihan point-in-time (PITR), dengan memulihkan dan memulihkan data hingga waktu tepat sebelum kesalahan terjadi.

Jika Anda hanya ingin memulihkan sebagian database atau tabel tertentu, bukan semua database di server database, Anda dapat memulihkan server database dalam instans baru, mengekspor tabel melalui mysqldump, lalu menggunakan pemulihan untuk memulihkan tabel tersebut ke database Anda.

Ringkasan

Azure Database untuk MySQL menyediakan kemampuan restart cepat dari server database, penyimpanan yang berlebihan, dan perutean yang efisien dari Gateway. Untuk perlindungan data tambahan, Anda dapat mengonfigurasi cadangan untuk direplikasi secara geografis, dan juga menyebarkan satu atau beberapa replika baca di wilayah lain. Dengan kemampuan ketersediaan tinggi yang melekat, Azure Database for MySQL melindungi database Anda dari pemadaman paling umum, dan menawarkan SLA waktu aktif 99.99% yang didukung oleh industri. Semua kemampuan ketersediaan dan keandalan ini menjadikan Azure sebagai platform yang ideal untuk menjalankan aplikasi misi penting Anda.

Langkah berikutnya