Pemeliharaan terjadwal di Azure Database for MySQL

2025-05-08

Azure Database for MySQL melakukan pemeliharaan berkala untuk membantu menjaga database terkelola Anda tetap aman, stabil, dan terbaru. Selama pemeliharaan, server akan mendapatkan fitur, pembaruan, dan patch baru.

Penting

Hindari semua operasi server (modifikasi, perubahan konfigurasi, memulai/menghentikan) selama pemeliharaan Azure Database for MySQL. Terlibat dalam aktivitas ini dapat menyebabkan hasil yang tidak dapat diprediksi yang dapat memengaruhi performa dan stabilitas server. Tunggu hingga pemeliharaan selesai sebelum Anda melakukan operasi server.

Siklus pemeliharaan

Bagian berikut menjelaskan jenis pemeliharaan. Untuk detail spesifik tentang apa yang harus dilakukan setiap pembaruan pemeliharaan, lihat catatan rilis. Catatan ini memberikan informasi komprehensif tentang pembaruan yang diterapkan selama pemeliharaan, sehingga Anda dapat memahami dan mempersiapkan perubahan apa pun yang memengaruhi lingkungan Anda.

Catatan

Tidak semua server selalu menjalani pemeliharaan selama pembaruan terjadwal, baik rutin atau kritis. Tim Azure MySQL menggunakan kriteria khusus untuk menentukan server mana yang memerlukan pemeliharaan. Pendekatan selektif ini memastikan bahwa pemeliharaan efisien dan penting, disesuaikan dengan kebutuhan unik setiap lingkungan server, dan meminimalkan waktu henti produksi.

Pemeliharaan rutin

Siklus pemeliharaan standar kami tidak kurang sering dari setiap 30 hari. Periode ini membantu memastikan stabilitas dan performa sistem sekaligus meminimalkan gangguan pada layanan Anda.

Pemeliharaan penting

Dalam skenario tertentu, seperti kebutuhan untuk menyebarkan perbaikan keamanan mendesak atau pembaruan yang penting untuk menjaga ketersediaan dan integritas data, kami mungkin melakukan pemeliharaan lebih sering. Pengecualian ini membantu melindungi data Anda dan memastikan pengoperasian layanan Anda secara berkelanjutan.

Pemeliharaan Virtual Canary

Virtual Canary adalah program pemeliharaan eksperimental yang menawarkan akses awal ke pembaruan. Ini memungkinkan pelanggan untuk menguji kompatibilitas beban kerja dengan versi Azure Database for MySQL baru dan memberikan umpan balik tentang fitur baru.

Tidak seperti pemeliharaan rutin, Virtual Canary tidak mengikuti kesenjangan minimum 30 hari atau periode pemberitahuan 7 hari. Program ini membantu pelanggan secara proaktif memvalidasi fitur baru dan memberikan umpan balik awal untuk peningkatan produk. Server tingkat burstable, yang umumnya digunakan untuk lingkungan non-produksi, secara otomatis terdaftar dalam program Virtual Canary.

Pendaftaran Virtual Canary

Azure Database for MySQL memberikan fleksibilitas bagi pelanggan untuk mengelola partisipasi mereka dalam program Virtual Canary. Pelanggan dapat ikut serta atau keluar dari program sesuai kebutuhan untuk penyelarasan dengan persyaratan operasional mereka.

Untuk memverifikasi apakah server Anda terdaftar dalam program Virtual Canary, gunakan perintah berikut. Jika hasilnya mencakup "patchStrategy": "VirtualCanary", server terdaftar dalam program.

az mysql flexible-server show --resource-group {resourcegroupname} --name {servername} --query "maintenancePolicy"

Untuk mendaftarkan server dalam program Virtual Canary, jalankan perintah berikut:

az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy VirtualCanary

Untuk meninggalkan program Virtual Canary dan kembali ke kebijakan pemeliharaan standar, gunakan perintah ini:

az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy Regular

Jeda waktu pemeliharaan

Anda dapat menjadwalkan pemeliharaan selama hari tertentu dalam seminggu dan jendela waktu dalam hari itu. Atau Anda dapat membiarkan sistem memilih hari dan jendela waktu untuk Anda secara otomatis. Bagaimanapun, sistem memberi tahu Anda tujuh hari sebelum menjalankan pemeliharaan apa pun. Sistem ini juga memberi tahu Anda ketika pemeliharaan dimulai dan ketika berhasil diselesaikan.

Notifikasi tentang pemeliharaan terjadwal yang akan datang dapat:

Dikirim melalui email ke alamat tertentu.
Dikirim melalui email ke peran Azure Resource Manager.
Dikirim dalam pesan teks (SMS) ke perangkat seluler.
Didorong sebagai pemberitahuan ke aplikasi Azure.
Dikirim sebagai pesan suara.

Saat Anda menentukan preferensi untuk jadwal pemeliharaan, Anda dapat memilih hari dalam seminggu dan jendela waktu. Jika Anda tidak menentukan preferensi, sistem memilih waktu antara pukul 23.00 dan 07.00 di waktu wilayah server Anda. Anda dapat menentukan jadwal pemeliharaan yang berbeda untuk setiap server fleksibel di langganan Azure.

Anda dapat memperbarui pengaturan penjadwalan kapan saja. Jika pemeliharaan dijadwalkan untuk server fleksibel Anda dan Anda memperbarui preferensi penjadwalan, peluncuran saat ini berlanjut sesuai jadwal. Perubahan pengaturan penjadwalan menjadi efektif setelah berhasil diselesaikan untuk pemeliharaan terjadwal berikutnya.

Anda dapat menentukan jadwal yang dikelola sistem atau jadwal kustom untuk setiap server fleksibel di langganan Azure Anda:

Dengan jadwal kustom, Anda dapat menentukan jendela pemeliharaan untuk server dengan memilih hari dalam seminggu dan jendela waktu satu jam.
Dengan jadwal yang dikelola sistem, sistem memilih jendela satu jam antara pukul 23.00 dan 07.00 di waktu wilayah server Anda.

Penting

Mulai 31 Agustus 2024, Azure Database for MySQL tidak lagi mendukung jendela pemeliharaan kustom untuk instans tingkat Burstable. Perubahan ini membantu menyederhanakan proses pemeliharaan dan memastikan performa optimal. Selain itu, analisis kami menunjukkan bahwa jumlah pengguna yang menggunakan jendela pemeliharaan kustom pada tingkat Burstable minimal.

Instans kelas Burstable yang sudah ada dengan jadwal pemeliharaan khusus tidak terpengaruh. Namun, pengguna tidak dapat lagi mengubah pengaturan ini untuk jendela pemeliharaan kustom.

Untuk pelanggan yang memerlukan jendela pemeliharaan kustom, sebaiknya tingkatkan ke tingkat Tujuan Umum atau Kritis Bisnis.

Dalam kasus yang jarang terjadi, peristiwa pemeliharaan dapat dibatalkan oleh sistem atau mungkin gagal diselesaikan dengan sukses. Jika peristiwa pemeliharaan gagal, pembaruan dikembalikan, dan versi biner sebelumnya dipulihkan. Dalam skenario pembaruan yang gagal, Anda mungkin masih mengalami mulai ulang server selama jendela pemeliharaan.

Jika peristiwa pemeliharaan dibatalkan atau gagal, sistem akan mengirimkan pemberitahuan kepada Anda. Upaya berikutnya untuk melakukan pemeliharaan dijadwalkan sesuai dengan pengaturan Anda saat ini. Anda menerima pemberitahuan tentang upaya berikutnya lima hari sebelumnya.

Pemeliharaan dengan waktu henti yang hampir nol (pratinjau)

Fitur pemeliharaan nyaris tanpa henti di Database Azure untuk MySQL adalah sebuah terobosan bagi server dengan ketersediaan tinggi. Fitur ini dirancang untuk mengurangi waktu henti pemeliharaan secara substansial. Kemampuan ini sangat penting bagi bisnis yang menuntut ketersediaan tinggi dan gangguan minimal dalam operasi database mereka.

Ekspektasi waktu henti yang tepat

Durasi waktu henti: Dalam kebanyakan kasus, waktu henti selama pemeliharaan berkisar antara 10 hingga 30 detik.
Pertimbangan tambahan: Setelah peristiwa failover, ada periode waktu hidup (TTL) DNS yang melekat sekitar 30 detik. Periode ini tidak dikontrol langsung oleh proses pemeliharaan tetapi merupakan bagian standar dari perilaku DNS. Jadi, dari perspektif pelanggan, total waktu henti yang dialami selama pemeliharaan bisa 40 hingga 60 detik.

Ketentuan dan batasan

Untuk mencapai performa optimal yang ditawarkan fitur ini, perhatikan kondisi dan batasan ini:

Kunci primer di semua tabel: Memastikan bahwa setiap tabel memiliki kunci primer sangat penting. Kurangnya kunci primer dapat secara signifikan meningkatkan lag replikasi dan memengaruhi waktu henti.
Beban kerja rendah selama waktu pemeliharaan: Periode pemeliharaan harus bertepatan dengan waktu beban kerja yang rendah di server untuk meminimalkan waktu henti. Kami mendorong Anda untuk menggunakan jendela pemeliharaan kustom untuk menjadwalkan pemeliharaan di luar jam sibuk.
Jaminan waktu henti: Meskipun kami berusaha untuk menjaga waktu henti pemeliharaan serendah mungkin, kami tidak menjamin bahwa itu akan kurang dari 60 detik dalam semua keadaan. Berbagai faktor, seperti beban kerja tinggi atau konfigurasi server tertentu, dapat meningkatkan waktu henti. Dalam skenario terburuk, waktu henti mungkin mirip dengan server mandiri.

Penjadwalan ulang pemeliharaan

Fitur penjadwalan ulang pemeliharaan memberi Anda kontrol yang lebih besar atas waktu aktivitas pemeliharaan di server fleksibel Azure Database for MySQL Anda. Setelah Anda menerima pemberitahuan pemeliharaan, Anda dapat menjadwalkan ulang ke waktu yang lebih nyaman, apakah itu dikelola sistem atau dikelola khusus.

Gunakan fitur ini untuk menghindari gangguan selama operasi database penting. Kami mendorong umpan balik Anda saat kami terus mengembangkan fungsionalitas ini.

Menjadwalkan ulang parameter dan pemberitahuan

Penjadwalan ulang tidak terbatas pada slot waktu tetap. Ini tergantung pada waktu yang paling awal dan terbaru yang diizinkan dalam siklus pemeliharaan saat ini. Siklus biasanya mencakup dari hari pertama hingga hari terakhir jendela pemeliharaan untuk wilayah tersebut. Saat menjadwalkan ulang, Anda mendapatkan pemberitahuan untuk mengonfirmasi perubahan, sesuai dengan kebijakan pemberitahuan standar.

Pertimbangan dan batasan

Perhatikan poin-poin berikut tentang fitur ini:

Ketersediaan tingkat: Penjadwalan ulang pemeliharaan tidak tersedia untuk tingkat komputasi burstable. Fitur ini ditujukan untuk server di lingkungan produksi, sedangkan tingkat Burstable dirancang untuk tujuan non-produksi.
Batasan permintaan: Pemeliharaan terjadwal ulang Anda mungkin dibatalkan jika sejumlah besar aktivitas pemeliharaan terjadi secara bersamaan di wilayah yang sama.
Periode penguncian: Penjadwalan ulang tidak tersedia 15 menit sebelum waktu pemeliharaan yang dijadwalkan awal, untuk mempertahankan keandalan layanan.
Pembatasan penjadwalan ulang: Jika terlalu banyak server di wilayah yang sama dijadwalkan untuk pemeliharaan selama waktu yang sama, permintaan penjadwalan ulang mungkin gagal. Jika kegagalan ini terjadi, Anda menerima pemberitahuan kesalahan yang menyarankan Anda untuk memilih slot waktu alternatif. Pemeliharaan yang berhasil dijadwalkan ulang tidak mungkin dibatalkan.

Tidak ada batasan berapa kali peristiwa pemeliharaan dapat dijadwalkan ulang. Selama peristiwa pemeliharaan belum memasuki status Persiapan , Anda selalu dapat menjadwalkan ulang ke waktu lain.

Catatan

Kami menyarankan agar Anda memantau pemberitahuan dengan cermat selama tahap pratinjau untuk mengakomodasi potensi penyesuaian.

FAQ

Mengapa beberapa server saya menerima pemberitahuan pemeliharaan sementara yang lain tidak?

Waktu mulai pemeliharaan berbeda di seluruh wilayah. Server di berbagai wilayah mungkin menerima pemberitahuan pemeliharaan pada waktu yang berbeda.

Mengapa beberapa server di wilayah yang sama menerima pemberitahuan pemeliharaan sementara yang lain tidak?

Ada kemungkinan bahwa server yang tidak menerima pemberitahuan dibuat lebih baru-baru ini, dan sistem menentukan bahwa mereka belum memerlukan pemeliharaan.

Dapatkah saya menolak pemeliharaan terjadwal?

Tidak, menolak pemeliharaan terjadwal tidak diizinkan. Namun, Anda dapat menggunakan fitur penjadwalan ulang pemeliharaan untuk menyesuaikan waktu. Atau Anda dapat mengaktifkan fitur ketersediaan tinggi untuk meminimalkan waktu henti. Karena Azure Database for MySQL adalah produk database platform as a service (PaaS), melakukan pemeliharaan tepat waktu membantu memastikan keamanan dan keandalan database Anda.