Bagikan melalui

Pemeliharaan terjadwal di Azure Database for MySQL - Server Fleksibel

  • Artikel

BERLAKU UNTUK: Azure Database for MySQL - Server Fleksibel

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

Penting

Harap hindari semua operasi server (modifikasi, perubahan konfigurasi, server mulai/berhenti) selama pemeliharaan Server Fleksibel Azure Database for MySQL. Terlibat dalam aktivitas ini dapat menyebabkan hasil yang tidak dapat diprediksi, mungkin memengaruhi performa dan stabilitas server. Tunggu hingga pemeliharaan selesai sebelum melakukan operasi server.

Siklus Pemeliharaan

Pemeliharaan Rutin

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

Pemeliharaan Kritis

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

Menemukan Detail Pemeliharaan

Untuk detail spesifik tentang apa yang harus dilakukan setiap pembaruan pemeliharaan, lihat catatan rilis kami. Catatan ini memberikan informasi komprehensif tentang pembaruan yang diterapkan selama pemeliharaan, memungkinkan Anda memahami dan mempersiapkan perubahan apa pun yang memengaruhi lingkungan Anda.

Catatan

Tidak semua server akan 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 Anda.

Pilih jendela pemeliharaan

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

Notifikasi tentang pemeliharaan terjadwal yang akan datang dapat:

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

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

Anda dapat memperbarui pengaturan penjadwalan kapan saja. Jika ada pemeliharaan yang dijadwalkan untuk Server fleksibel Anda dan Anda memperbarui preferensi penjadwalan, peluncuran saat ini akan dilanjutkan sesuai jadwal dan perubahan pengaturan penjadwalan akan efektif setelah pemeliharaan terjadwal berikutnya berhasil diselesaikan.

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 akan 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 akan lagi mendukung jendela pemeliharaan kustom untuk instans SKU yang dapat meledak. Perubahan ini disebabkan oleh kebutuhan untuk menyederhanakan proses pemeliharaan, memastikan performa optimal, dan analisis kami menunjukkan bahwa jumlah pengguna yang menggunakan jendela pemeliharaan kustom pada SKU yang dapat meledak minimal. Instans SKU yang dapat meledak yang ada dengan konfigurasi jendela pemeliharaan kustom akan tetap tidak terpengaruh; namun, pengguna tidak akan dapat memodifikasi pengaturan jendela pemeliharaan kustom ini ke depannya.

Untuk pelanggan yang memerlukan jendela pemeliharaan kustom, sebaiknya tingkatkan ke Tujuan Umum atau SKU Penting Bisnis untuk terus menggunakan fitur ini.

Dalam kasus langka, kejadian pemeliharaan dapat dibatalkan oleh sistem atau mungkin gagal diselesaikan. Jika pembaruan gagal, pembaruan dikembalikan, dan versi biner sebelumnya dipulihkan. Dalam skenario pembaruan yang gagal seperti itu, Anda mungkin masih mengalami mulai ulang server selama jendela pemeliharaan. Jika pembaruan dibatalkan atau gagal, sistem akan membuat notifikasi tentang kejadian pemeliharaan yang dibatalkan atau gagal agar Anda diberi tahu. Upaya berikutnya untuk melakukan pemeliharaan akan dijadwalkan sesuai pengaturan penjadwalan Anda saat ini dan Anda akan menerima pemberitahuan tentang hal itu 5 hari sebelumnya.

Pemeliharaan waktu henti mendekati nol (Pratinjau publik)

Fitur "Near Zero Downtime Maintenance" Azure Database for MySQL Flexible Server adalah pengembangan terapan untuk server yang diaktifkan KETERSEDIAAN TINGGI (Ketersediaan Tinggi). Fitur ini dirancang untuk mengurangi waktu henti pemeliharaan secara substansial, memastikan bahwa dalam banyak kasus, waktu henti pemeliharaan diperkirakan antara 40 hingga 60 detik. 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 DNS Time-To-Live (TTL) 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 berada di kisaran 40 hingga 60 detik.

Batasan dan Prasyarat

Untuk mencapai performa optimal yang dijanjikan oleh fitur ini, kondisi dan batasan tertentu harus dicatat:

  • Kunci Primer di Semua Tabel: Memastikan bahwa setiap tabel memiliki kunci primer sangat penting. Kurangnya kunci primer dapat secara signifikan meningkatkan lag replikasi, berdampak pada waktu henti.
  • Beban Kerja Rendah Selama Waktu Pemeliharaan: Periode pemeliharaan harus bertepatan dengan waktu beban kerja yang rendah di server untuk memastikan waktu henti tetap minimal. Kami mendorong Anda untuk menggunakan fitur jendela pemeliharaan kustom untuk menjadwalkan pemeliharaan selama jam sibuk.
  • Jaminan Waktu Henti: Meskipun kami berusaha untuk menjaga waktu henti pemeliharaan serendah mungkin, kami tidak menjamin bahwa itu akan selalu kurang dari 60 detik dalam semua keadaan. Berbagai faktor, seperti beban kerja tinggi atau konfigurasi server tertentu, dapat menyebabkan waktu henti yang lebih lama. 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 pada instans Server Fleksibel Azure Database for MySQL Anda. Setelah menerima pemberitahuan pemeliharaan, Anda dapat menjadwalkan ulang ke waktu yang lebih nyaman, terlepas dari apakah itu sistem atau dikelola kustom.

Menjadwalkan ulang parameter dan pemberitahuan

Penjadwalan ulang tidak terbatas pada slot waktu tetap; itu tergantung pada waktu yang paling awal dan terbaru yang diizinkan dalam siklus pemeliharaan saat ini, yang biasanya mencakup dari hari pertama hingga hari terakhir jendela pemeliharaan untuk wilayah tersebut. Setelah penjadwalan ulang, pemberitahuan akan dikirim untuk mengonfirmasi perubahan, mengikuti kebijakan pemberitahuan standar.

Pertimbangan dan batasan

Perhatikan hal-hal berikut saat menggunakan fitur ini:

  • Batasan Permintaan: Pemeliharaan terjadwal ulang Anda mungkin dibatalkan karena banyaknya aktivitas pemeliharaan yang 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.
  • Reschedule Throttle Jika terlalu banyak server di wilayah yang sama dijadwalkan untuk pemeliharaan selama waktu yang sama, penjadwalan ulang permintaan mungkin gagal. Pengguna akan menerima pemberitahuan kesalahan jika ini terjadi dan disarankan untuk memilih slot waktu alternatif. Pemeliharaan yang berhasil dijadwalkan ulang tidak mungkin dibatalkan.

Tidak ada batasan berapa kali pemeliharaan dapat dijadwalkan ulang, selama pemeliharaan belum masuk ke status "Dalam persiapan", Anda selalu dapat menjadwalkan ulang pemeliharaan Anda ke waktu lain.

Catatan

Sebaiknya pantau pemberitahuan dengan cermat selama tahap pratinjau untuk mengakomodasi potensi penyesuaian.

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

FAQ

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

A: Waktu mulai pemeliharaan berbeda di seluruh wilayah, sehingga server di berbagai wilayah mungkin menerima pemberitahuan pemeliharaan pada waktu yang berbeda.

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

A: Ini bisa jadi karena server yang tidak menerima pemberitahuan dibuat lebih baru-baru ini, dan sistem menentukan bahwa server belum memerlukan pemeliharaan.

T: Dapatkah saya menolak pemeliharaan terjadwal?

A: Tidak, memilih keluar dari pemeliharaan terjadwal tidak diizinkan. Namun, Anda dapat menggunakan fitur penjadwalan ulang pemeliharaan untuk menyesuaikan waktu atau mengaktifkan fitur Ketersediaan Tinggi (HA) untuk meminimalkan waktu henti. Sebagai produk database PaaS, penting untuk melakukan pemeliharaan tepat waktu untuk memastikan keamanan dan keandalan database Anda.

Langkah berikutnya