Ketersediaan tinggi di Azure Database for MySQL

Server Fleksibel Azure Database for MySQL memungkinkan Anda mengonfigurasi ketersediaan tinggi dengan failover otomatis. Solusi ini memastikan bahwa kegagalan tidak pernah menyebabkan hilangnya data yang diterapkan dan bahwa database bukan satu titik kegagalan dalam arsitektur perangkat lunak Anda. Saat Anda mengonfigurasi ketersediaan tinggi, Server Fleksibel secara otomatis menyediakan dan mengelola replika siaga. Anda membayar komputasi dan penyimpanan yang disediakan untuk replika utama dan sekunder. Tersedia dua model arsitektur dengan ketersediaan tinggi:

• Ketersediaan tinggi zona-redundan. Opsi ini menyediakan isolasi lengkap dan redundansi infrastruktur di beberapa zona ketersediaan. Ini menawarkan tingkat ketersediaan tertinggi, tetapi mengharuskan Anda untuk mengonfigurasi redundansi aplikasi di seluruh zona. Pilih ketersediaan tinggi zona-redundan saat Anda ingin melindungi dari kegagalan infrastruktur apa pun di zona ketersediaan dan ketika latensi di seluruh zona ketersediaan dapat diterima. Anda dapat mengaktifkan ketersediaan tinggi zona-redundan hanya ketika Anda membuat server. Ketersediaan tinggi zona-redundan tersedia di subset wilayah Azure di mana wilayah mendukung beberapa zona ketersediaan dan berbagi file Premium zona-redundan tersedia.

• Redundansi lokal ketersediaan tinggi. Opsi ini menyediakan redundansi infrastruktur dengan latensi jaringan yang lebih rendah karena server utama dan siaga berada di zona ketersediaan yang sama. Ini menawarkan ketersediaan tinggi tanpa perlu mengonfigurasi redundansi aplikasi di seluruh zona. Pilih HA yang redundan lokal ketika Anda ingin mencapai tingkat ketersediaan tertinggi di dalam satu zona ketersediaan dengan latensi jaringan terendah. Lokal-redundan HA tersedia di setiap wilayah Azure tempat Azure Database for MySQL Flexible Server dapat diakses.

Arsitektur ketersediaan tinggi (HA) zona redundan

Saat Anda menyebarkan server dengan ketersediaan tinggi zona-redundan, Azure membuat dua server:

• Server utama dalam satu zona ketersediaan.
• Server replika siaga di zona ketersediaan lain dari wilayah Azure yang sama. Server replika siaga memiliki konfigurasi yang sama dengan server utama, termasuk tingkat komputasi, ukuran komputasi, ukuran penyimpanan, dan konfigurasi jaringan.

Anda dapat memilih zona ketersediaan untuk server utama dan replika siaga. Menempatkan server database siaga dan aplikasi siaga di zona yang sama mengurangi latensi. Ini juga membantu Anda mempersiapkan situasi pemulihan bencana dan skenario "zona turun".

File log dan data dihosting dalam penyimpanan zona redundan (ZRS). Server siaga terus membaca dan memutar ulang file log dari akun penyimpanan server utama, yang dilindungi replikasi tingkat penyimpanan.

Jika failover terjadi:

• Replika siaga diaktifkan.
• File log biner dari server utama terus berlaku ke server siaga untuk membuatnya online ke transaksi terakhir yang dilakukan di server utama.

Log di ZRS dapat diakses meskipun server utama tidak tersedia. Ketersediaan ini membantu memastikan tidak ada kehilangan data. Setelah replika siaga diaktifkan dan log biner diterapkan, server replika siaga saat ini mengambil peran server utama. Pembaruan DNS sehingga koneksi klien diarahkan ke primer baru saat klien tersambung kembali. Failover sepenuhnya transparan dari aplikasi klien dan tidak memerlukan tindakan apa pun dari Anda. Solusi ketersediaan tinggi kemudian mengembalikan server utama lama jika memungkinkan dan menempatkannya sebagai siaga.

Anda menggunakan nama server database untuk menyambungkan aplikasi ke server utama. Solusi ini tidak mengekspos informasi replika siaga untuk akses langsung. Penerapan dan penulisan diakui setelah file log dialirkan di ZRS server utama. Karena teknologi replikasi sinkronisasi yang digunakan dalam penyimpanan ZRS, Anda dapat mengharapkan peningkatan latensi 5-10 persen untuk penulisan dan penerapan aplikasi.

Cadangan otomatis, baik cadangan rekam jepret maupun log, dilakukan di penyimpanan zona redundan dari server database utama.

Arsitektur lokal-redundan dengan ketersediaan tinggi (HA)

Saat Anda menyebarkan server dengan ketersediaan tinggi redundan lokal, Anda membuat dua server di zona yang sama:

• Server utama
• Server replika siaga yang memiliki konfigurasi yang sama dengan server utama (tingkat komputasi, ukuran komputasi, ukuran penyimpanan, dan konfigurasi jaringan)

Server siaga menyediakan redundansi infrastruktur dengan komputer virtual (komputasi) terpisah. Redundansi ini mengurangi waktu failover dan latensi jaringan antara aplikasi dan server database karena kolokasi.

File log dan data dihosting dalam penyimpanan redundan lokal (LRS). Server siaga terus membaca dan memutar ulang file log dari akun penyimpanan server utama, yang dilindungi oleh replikasi tingkat penyimpanan.

Jika failover terjadi:

• Replika siaga diaktifkan.
• File log biner dari server utama terus berlaku ke server siaga untuk membuatnya online ke transaksi terakhir yang dilakukan di server utama.

Log di LRS dapat diakses meskipun server utama tidak tersedia. Ketersediaan ini membantu memastikan tidak ada kehilangan data. Setelah replika siaga diaktifkan dan log biner diterapkan, replika siaga saat ini mengambil peran sebagai server utama. DNS diperbarui untuk mengalihkan koneksi ke server utama baru saat klien terhubung kembali. Failover sepenuhnya transparan dari aplikasi klien dan tidak memerlukan tindakan apa pun dari Anda. Solusi ketersediaan tinggi kemudian mengembalikan server utama lama jika memungkinkan dan menempatkannya sebagai siaga.

Nama server database menghubungkan aplikasi ke server utama. Informasi replika siaga tidak diekspos untuk akses langsung. Penerapan dan penulisan diakui setelah file log dialirkan di LRS server utama. Karena replika utama dan siaga berada di zona yang sama, ada lebih sedikit jeda replikasi dan latensi yang lebih rendah antara server aplikasi dan server database. Pengaturan redundansi lokal tidak menyediakan ketersediaan tinggi ketika infrastruktur yang bergantung tidak berfungsi di dalam zona ketersediaan tertentu. Ada waktu henti sampai semua layanan dependen kembali online untuk zona ketersediaan tersebut.

Pencadangan otomatis, baik snapshot maupun cadangan log, dilakukan pada penyimpanan redundan lokal dari server basis data utama.

Catatan

Untuk ketersediaan tinggi zona-redundan dan Lokal-redundan:

• Jika kegagalan terjadi, waktu yang diperlukan replika siaga untuk mengambil alih peran utama tergantung pada waktu yang diperlukan untuk memutar ulang log biner dari akun penyimpanan utama ke siaga. Untuk mengurangi waktu failover, gunakan kunci primer pada semua tabel. Waktu failover biasanya memakan waktu antara 60 dan 120 detik.
• Server siaga tidak tersedia untuk operasi baca atau tulis. Ini adalah server siaga pasif untuk memungkinkan failover cepat.
• Selalu gunakan nama domain yang sepenuhnya memenuhi syarat (FQDN) untuk terhubung ke server utama Anda. Hindari menggunakan alamat IP untuk terhubung. Jika failover terjadi, setelah peran server utama dan siaga dialihkan, rekaman DNS A mungkin berubah. Perubahan itu mencegah aplikasi tersambung ke server utama baru jika alamat IP digunakan dalam string koneksi.

Proses failover

Selama proses failover di Azure Database for MySQL, sistem secara otomatis beralih dari server utama ke replika siaga. Sakelar ini memastikan kelangsungan dan meminimalkan waktu henti. Ketika sistem mendeteksi kegagalan, sistem mempromosikan replika siaga untuk menjadi server utama baru. Sistem menerapkan file log biner dari server utama asli ke replika siaga. Proses ini menyinkronkan replika siaga dengan transaksi terakhir yang dilakukan dan memastikan tidak ada kehilangan data. Transisi yang mulus ini membantu menjaga ketersediaan tinggi dan keandalan layanan database.

Catatan

Untuk mengurangi ketergantungan waktu proses failover pada penyimpanan sementara DNS, mulai Oktober 2025, semua HA server baru yang dibuat dengan akses publik atau tautan privat akan mengadopsi arsitektur baru yang dilengkapi dengan SLB khusus untuk setiap HA server. Dengan mengelola jalur lalu lintas data MySQL, SLB menghilangkan kebutuhan akan perubahan DNS selama failover dan secara signifikan meningkatkan performa failover. Ini mengalihkan trafik ke instans utama saat ini selama failover menggunakan aturan penyeimbangan beban. Server yang ada dengan akses publik atau tautan privat akan dimigrasikan secara bertahap untuk meminimalkan dampak. Pelanggan yang lebih suka migrasi awal dapat menonaktifkan dan mengaktifkan kembali KETERSEDIAAN TINGGI. Fitur ini tidak didukung untuk server yang menggunakan akses privat dengan integrasi VNet.

Direncanakan: Failover paksa

Failover paksa Azure Database for MySQL Flexible Server memungkinkan Anda memaksa failover secara manual. Kemampuan ini memungkinkan Anda menguji fungsionalitas dengan skenario aplikasi Anda dan membantu Anda mempersiapkan pemadaman.

Failover paksa memicu failover yang mengaktifkan replika siaga menjadi server utama dengan nama server database yang sama dengan memperbarui catatan DNS. Server utama asli memulai ulang dan beralih ke replika siaga. Koneksi klien terputus dan perlu terhubung kembali untuk melanjutkan operasi mereka.

Waktu failover keseluruhan tergantung pada beban kerja saat ini dan titik pemeriksaan terakhir. Secara umum, dibutuhkan antara 60 dan 120 detik.

Catatan

Peristiwa Azure Resource Health dihasilkan selama failover yang direncanakan. Kejadian ini mewakili waktu failover di mana server tidak tersedia. Anda dapat melihat peristiwa yang dipicu saat dipilih di Resource Health di panel kiri. Status mewakili failover yang dimulai pengguna atau manual sebagai "Tidak Tersedia" dan ditandai sebagai "Direncanakan". Contoh - "Operasi failover dipicu oleh pengguna resmi (Terencana)". Jika sumber daya Anda tetap dalam status ini untuk jangka waktu yang lama, buka tiket dukungan dan kami membantu Anda.

Tidak direncanakan: Failover otomatis

Waktu henti layanan yang tidak diencana dapat terjadi karena bug perangkat lunak atau kesalahan infrastruktur, seperti kegagalan komputasi, jaringan, atau penyimpanan. Pemadaman listrik juga dapat memengaruhi ketersediaan database. Jika database menjadi tidak tersedia, replikasi ke replika siaga berhenti, dan replika siaga menjadi database utama. Pembaruan DNS terjadi, dan klien terhubung kembali ke server database, dilanjutkan operasinya.

Waktu failover keseluruhan biasanya antara 60 dan 120 detik. Namun, tergantung pada aktivitas di server database utama pada saat failover (seperti transaksi besar dan waktu pemulihan), failover mungkin memakan waktu lebih lama.

Catatan

Peristiwa Azure Resource Health dihasilkan selama failover yang tidak direncanakan. Kejadian ini mewakili waktu failover ketika server tidak tersedia. Anda dapat melihat peristiwa yang dipicu saat memilih Kesehatan Sumber Daya di panel kiri. Failover otomatis menunjukkan status "Tidak Tersedia" dan ditandai sebagai "Tidak Direncanakan".

Misalnya, Tidak Tersedia: Operasi failover dipicu secara otomatis (Tidak Direncanakan). Jika sumber daya Anda tetap berada dalam status ini untuk waktu yang lama, buka tiket dukungan dan kami membantu Anda.

Cara kerja deteksi failover otomatis di server yang didukung HA

Server utama dan server sekunder masing-masing memiliki dua titik akhir jaringan:

• Titik Akhir Pelanggan: Pelanggan menyambungkan dan menjalankan kueri pada instans dengan menggunakan titik akhir ini.
• Titik Akhir Manajemen: Digunakan secara internal untuk komunikasi layanan ke komponen manajemen dan untuk terhubung ke penyimpanan backend.

Komponen monitor kesehatan terus melakukan pemeriksaan berikut:

• Pemantauan melakukan ping pada Titik Akhir jaringan Manajemen simpul. Jika pemeriksaan ini gagal dua kali berturut-turut, pemeriksaan ini akan memicu operasi failover otomatis. Pemeriksaan kesehatan ini membahas skenario seperti ketidaktersediaan node atau nonresponsif karena masalah OS, masalah jaringan antara komponen manajemen dan simpul, dan masalah serupa.
• Monitor menjalankan kueri sederhana pada instans. Jika kueri gagal dijalankan, failover otomatis akan memicu. Pemeriksaan kesehatan ini membahas skenario seperti daemon MySQL crash, berhenti, atau macet, dan masalah penyimpanan backend dan masalah serupa.

Catatan

Pemeriksaan kesehatan tidak memantau masalah jaringan antara aplikasi dan titik akhir jaringan pelanggan (akses Privat/Publik). Masalah ini dapat terjadi di jalur jaringan, pada titik akhir, atau dalam masalah DNS di sisi klien. Jika Anda menggunakan akses privat, pastikan bahwa aturan NSG untuk jaringan virtual tidak memblokir komunikasi ke titik akhir jaringan pelanggan instans pada port 3306. Untuk akses publik, pastikan bahwa aturan firewall diatur dan lalu lintas jaringan diizinkan pada port 3306 (jika jalur jaringan memiliki firewall lain). Anda juga perlu mengurus resolusi DNS dari sisi aplikasi klien.

Memantau ketersediaan tinggi

Untuk memeriksa status konfigurasi ketersediaan tinggi server, gunakan Status ketersediaan tinggi di panel ketersediaan tinggi server di portal.

Keadaan	Deskripsi
Tidak Diaktifkan	ketersediaan tinggi tidak diaktifkan.
MereplikasiData	Server siaga disinkronkan dengan server utama selama provisi server ketersediaan tinggi atau saat Anda mengaktifkan opsi ketersediaan tinggi.
FailingOver	Server database gagal dari primer ke siaga.
Sehat	opsi ketersediaan tinggi diaktifkan.
Menghapus Standby	Proses penghapusan sedang berlangsung saat Anda menonaktifkan opsi ketersediaan tinggi.

Untuk memantau kesehatan server ketersediaan tinggi, gunakan metrik berikut.

Nama tampilan metrik	Metrik	Satuan	Deskripsi
HA IO Status	ha_io_running	Status	Status HA IO menunjukkan status replikasi HA. Nilai metrik adalah 1 jika utas I/O berjalan dan 0 jika tidak.
HA SQL Status	ha_sql_running	Status	Status HA SQL menunjukkan status replikasi HA. Nilai metrik adalah 1 jika utas SQL berjalan dan 0 jika tidak.
Jeda Replikasi HA	keterlambatan_replikasi	Detik	Lag replikasi adalah jumlah detik siaga berada di belakang dalam memutar ulang transaksi yang diterima di server utama.

Batasan

Ingatlah pertimbangan berikut saat Anda menggunakan ketersediaan tinggi:

• Anda dapat mengonfigurasi ketersediaan tinggi zona-redundan hanya selama pembuatan server.

• Tingkat komputasi yang dapat meledak tidak mendukung ketersediaan tinggi.

• Memulai ulang server database utama untuk menerapkan perubahan parameter statis juga memulai ulang replika siaga.

• Solusi mengaktifkan mode GTID karena menggunakan GTID. Periksa apakah beban kerja Anda memiliki batasan atau batasan pada replikasi dengan GTID.

Catatan

Pertumbuhan otomatis penyimpanan diaktifkan secara default untuk server yang dikonfigurasi dengan ketersediaan tinggi dan tidak dapat dinonaktifkan.

Pemeriksaan kesehatan

Saat Anda mengonfigurasi ketersediaan tinggi (HA) untuk Azure Database for MySQL, pemeriksaan kesehatan memainkan peran penting dalam menjaga keandalan dan performa database Anda. Pemeriksaan ini terus memantau status dan kesehatan replika utama dan siaga, memastikan bahwa mereka mendeteksi masalah apa pun dengan segera. Dengan melacak berbagai metrik seperti responsivitas server, jeda replikasi, dan pemanfaatan sumber daya, pemeriksaan kesehatan membantu memastikan bahwa proses failover dapat dijalankan dengan mulus, meminimalkan waktu henti dan mencegah kehilangan data. Pemeriksaan kesehatan yang dikonfigurasi dengan benar sangat penting untuk mencapai tingkat ketersediaan dan ketahanan yang diinginkan dalam penyiapan database Anda.

Memantau kesehatan

Anda dapat memantau kesehatan penyiapan KETERSEDIAAN TINGGI Anda melalui portal Microsoft Azure. Metrik utama yang harus diamati meliputi:

• Respons server: Menunjukkan apakah server utama dapat dijangkau.
• Lag replikasi: Mengukur penundaan antara replika utama dan siaga, memastikan konsistensi data.
• Pemanfaatan sumber daya: Memantau penggunaan CPU, memori, dan penyimpanan untuk mencegah hambatan.

Konten terkait

• ketersediaan tinggi
• Kelangsungan bisnis
• Ketersediaan tinggi zona-redundan
• Pencadangan dan pemulihan