Konsep ketersediaan tinggi di Azure Database for MySQL - Server Fleksibel

  • Artikel

BERLAKU UNTUK: Azure Database for MySQL - Server Fleksibel

Server fleksibel Azure Database for MySQL memungkinkan konfigurasi ketersediaan tinggi dengan failover otomatis. Solusi high availability dirancang untuk memastikan bahwa data yang diterapkan tidak pernah hilang karena kegagalan dan bahwa database tidak akan menjadi satu titik kegagalan dalam arsitektur perangkat lunak Anda. Ketika ketersediaan tinggi telah dikonfigurasi, server fleksibel secara otomatis menyediakan dan mengelola replika siaga. Anda ditagih untuk komputasi dan penyimpanan yang disediakan untuk replika primer dan sekunder. Ada dua model arsitektur ketersediaan tinggi:

  • Ketersediaan Tinggi Zona-redundan. Opsi ini lebih disukai untuk isolasi lengkap dan redundansi infrastruktur di beberapa zona ketersediaan. Opsi ini memberikan tingkat ketersediaan tertinggi, tetapi mewajibkan Anda untuk mengonfigurasi redundansi aplikasi di seluruh zona. Ketersediaan tinggi zona-redundan lebih disukai saat Anda ingin mencapai tingkat ketersediaan tertinggi terhadap kegagalan infrastruktur apa pun di zona ketersediaan dan saat latensi di seluruh zona ketersediaan dapat diterima. Hal ini dapat diaktifkan hanya ketika server dibuat. Ketersediaan tinggi zona-redundan tersedia di subset wilayah Azure di mana wilayah mendukung beberapa zona ketersediaan dan berbagi file Premium zona-redundan tersedia.

  • Ketersediaan tinggi zona yang sama. Opsi ini lebih disukai untuk redundansi infrastruktur dengan latensi jaringan yang lebih rendah karena server utama dan server siaga akan berada di zona ketersediaan yang sama. Zona ini memberikan ketersediaan tinggi tanpa perlu mengonfigurasi redundansi aplikasi di seluruh zona. Ketersediaan tinggi di zona yang sama lebih diprioritaskan jika Anda ingin mencapai tingkat ketersediaan tertinggi dalam satu zona ketersediaan tunggal dengan latensi jaringan terendah. Ketersediaan tinggi zona yang sama tersedia di semua wilayah Azure tempat Anda dapat menggunakan server fleksibel Azure Database for MySQL.

Arsitektur ketersediaan tinggi zona-redundan

Saat Anda menyebarkan server dengan ketersediaan tinggi zona-redundan, dua server akan dibuat:

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

Anda dapat memilih zona ketersediaan untuk replika utama dan siaga. Menempatkan server database siaga dan aplikasi siaga di zona yang sama mengurangi latensi. Hal ini juga memungkinkan Anda untuk lebih mempersiapkan situasi pemulihan bencana dan skenario "zona tidak berfungsi".

Diagram yang menunjukkan arsitektur untuk ketersediaan tinggi zona-redundan.

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

Jika ada failover:

  • Replika siaga diaktifkan.
  • File log biner dari server utama terus diterapkan ke server siaga untuk membawa server siaga 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 sebagai server utama. DNS diperbarui sehingga koneksi klien diarahkan ke server utama baru ketika 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 digunakan untuk menghubungkan aplikasi ke server utama. Informasi replika siaga tidak diekspos 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 ketersediaan tinggi zona yang sama

Saat Anda menerapkan server dengan ketersediaan tinggi zona yang sama, dua server akan dibuat 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 menawarkan redundansi infrastruktur dengan mesin virtual terpisah (komputasi). Redundansi ini mengurangi waktu failover dan latensi jaringan antara aplikasi dan server database karena kolokasi.

Diagram yang menunjukkan arsitektur untuk ketersediaan tinggi di zona yang sama.

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

Jika ada failover:

  • Replika siaga diaktifkan.
  • File log biner dari server utama terus diterapkan ke server siaga untuk membawa server siaga 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 digunakan untuk 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. Penyiapan zona yang sama tidak menyediakan ketersediaan tinggi saat infrastruktur yang bergantung tidak berfungsi untuk zona ketersediaan tertentu. Akan ada waktu henti hingga semua layanan yang bergantung 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 di zona redundan dan zona yang sama:

  • Jika ada kegagalan, 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. Jadi kami sarankan Anda menggunakan kunci primer pada semua tabel untuk mengurangi waktu failover. Waktu failover biasanya 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 ada failover, setelah peran server utama dan siaga ditukar, rekaman DNS A mungkin berubah. Perubahan itu akan mencegah aplikasi terhubung ke server utama baru jika alamat IP digunakan dalam string koneksi.

Proses failover

Direncanakan: Failover paksa

Failover paksa server fleksibel Azure Database for MySQL memungkinkan Anda memaksa failover secara manual. Kemampuan ini memungkinkan Anda untuk menguji fungsionalitas dengan skenario aplikasi dan membantu membuat Anda siap untuk 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 dimulai ulang dan dialihkan 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, diperkirakan akan memakan waktu antara 60 dan 120 detik.

Catatan

Peristiwa Azure Resource Health dihasilkan jika terjadi failover yang direncanakan, mewakili waktu failover di mana server tidak tersedia. Peristiwa yang dipicu dapat dilihat saat diklik "Kesehatan Sumber Daya" di panel kiri. Failover yang dimulai pengguna/ Manual diwakili oleh status 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, silakan buka tiket dukungan dan kami akan membantu Anda.

Tidak direncanakan: Failover otomatis

Waktu henti layanan yang tidak direncanakan dapat disebabkan oleh bug perangkat lunak atau kesalahan infrastruktur seperti kegagalan komputasi, jaringan, atau penyimpanan, atau pemadaman listrik yang memengaruhi ketersediaan database. Jika database menjadi tidak tersedia, replikasi ke replika siaga terputus dan replika siaga diaktifkan sebagai database utama. DNS diperbarui, dan klien terhubung kembali ke server database serta melanjutkan operasi mereka.

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

Catatan

Peristiwa Azure Resource Health dihasilkan jika terjadi failover yang tidak direncanakan, mewakili waktu failover saat server tidak tersedia. Peristiwa yang dipicu dapat dilihat saat diklik "Kesehatan Sumber Daya" di panel kiri. Failover otomatis diwakili oleh status sebagai "Tidak Tersedia" dan ditandai sebagai "Tidak Direncanakan". Contoh - "Tidak Tersedia : Operasi failover dipicu secara otomatis (Tidak Direncanakan)". Jika sumber daya Anda tetap dalam status ini untuk jangka waktu yang lama, silakan buka tiket dukungan dan kami akan membantu Anda.

Cara kerja deteksi failover otomatis di server yang didukung HA

Server utama dan server sekunder memiliki dua titik akhir jaringan,

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

Komponen pemantauan kesehatan tetap melakukan pemeriksaan berikut

  • Pemantauan melakukan ping ke titik akhir jaringan Manajemen simpul. Jika pemeriksaan ini gagal dua kali terus menerus, operasi failover otomatis akan dipicu. Skenario seperti simpul tidak tersedia/tidak merespons karena masalah OS, masalah jaringan antara komponen manajemen dan simpul dll. akan diatasi oleh pemeriksaan kesehatan ini.
  • Pemantau juga menjalankan kueri sederhana pada Instans. Jika kueri gagal dijalankan, failover otomatis akan dipicu. Skenario seperti demon MySQL crash/berhenti/menggantung, Masalah penyimpanan backend, dll. akan diatasi oleh pemeriksaan kesehatan ini.

Catatan

Jika ada masalah jaringan antara aplikasi dan titik akhir jaringan pelanggan (akses Privat/Publik), baik di jalur jaringan, pada titik akhir atau masalah DNS di sisi klien, pemeriksaan kesehatan tidak memantau skenario ini. Jika Anda menggunakan akses privat, pastikan aturan NSG untuk VNet 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). Resolusi DNS dari sisi aplikasi klien juga perlu diperhatikan.

Memantau untuk ketersediaan tinggi

Status Ketersediaan Tinggi yang terletak di panel Ketersediaan Tinggi server di portal dapat digunakan untuk menentukan status konfigurasi KETERSEDIAAN TINGGI server.

Keadaan Keterangan
NotEnabled KETERSEDIAAN TINGGI tidak diaktifkan.
ReplicatingData Server siaga sedang dalam proses sinkronisasi dengan server utama pada saat penyediaan server HA atau ketika opsi HA diaktifkan.
FailingOver Server database sedang dalam proses gagal dari primer ke siaga.
Sehat Opsi KETERSEDIAAN TINGGI diaktifkan.
RemovingStandby Ketika opsi KETERSEDIAAN TINGGI dinonaktifkan, dan proses penghapusan sedang berlangsung.

Anda juga dapat menggunakan metrik di bawah ini untuk memantau kesehatan server HA.

Nama tampilan metrik Metric Unit 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 replication_lag Detik Lag replikasi adalah jumlah detik siaga berada di belakang dalam memutar ulang transaksi yang diterima di server utama.

Batasan

Berikut adalah beberapa pertimbangan yang perlu diingat ketika Anda menggunakan ketersediaan tinggi:

  • Ketersediaan tinggi zona-redundan dapat diatur hanya ketika server fleksibel dibuat.
  • Ketersediaan tinggi tidak didukung dalam tingkatan komputasi burst.
  • Memulai ulang server database utama untuk mengambil perubahan parameter statis juga memulai ulang replika siaga.
  • Mode GTID akan diaktifkan karena solusi ketersediaan tinggi menggunakan GTID. Periksa apakah beban kerja Anda memiliki batasan atau batasan pada replikasi dengan GTID.

Catatan

Jika mengaktifkan kiriman high availability zona yang sama yang dibuat server, Anda harus memastikan parameter server enforce_gtid_consistency” dan “gtid_mode” diatur ke AKTIF sebelum mengaktifkan high availability.

Catatan

Autogrow penyimpanan diaktifkan secara default untuk server yang dikonfigurasi Ketersediaan Tinggi dan tidak dapat dinonaktifkan.

Pertanyaan Umum (FAQ)

  • Apa SLA untuk server Fleksibel berkemampuan HA zona yang sama vs zona redundan?

    Informasi SLA untuk server fleksibel Azure Database for MySQL dapat ditemukan di SLA untuk Azure Database for MySQL.

  • Bagaimana saya ditagih untuk server high availability (HA)? Server yang diaktifkan dengan high availability memiliki replika primer dan sekunder. Replika sekunder dapat berada di zona yang sama atau zona redundan. Anda ditagih untuk komputasi dan penyimpanan yang disediakan untuk replika primer dan sekunder. Misalnya, jika Anda memiliki primer dengan 4 vCore komputasi dan 512 GB penyimpanan yang tersedia, replika sekunder Anda juga akan memiliki 4 vCore dan 512 GB penyimpanan yang tersedia. Server high availability zona redundan Anda akan ditagih untuk 8 vCore dan penyimpanan 1.024 GB. Bergantung pada volume penyimpanan cadangan, Anda mungkin juga ditagih untuk penyimpanan cadangan.

  • Dapatkah saya menggunakan replika siaga untuk operasi baca atau tulis?
    Server siaga tidak tersedia untuk operasi baca atau tulis. Ini adalah server siaga pasif untuk memungkinkan failover cepat.

  • Apakah saya akan kehilangan data saat terjadi failover?
    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, replika siaga saat ini mengambil peran server utama.

  • Apakah saya perlu mengambil tindakan setelah failover?
    Failover sepenuhnya transparan dari aplikasi klien. Anda tidak perlu melakukan tindakan apa pun. Aplikasi seharusnya hanya menggunakan logika coba lagi untuk koneksinya.

  • Apa yang terjadi jika saya tidak memilih zona tertentu untuk replika siaga saya? Dapatkah saya mengubah zona nanti?
    Jika Anda tidak memilih zona, satu zona akan dipilih secara acak. Ini akan menjadi yang digunakan untuk server utama. Untuk mengubah zona nanti, Anda dapat mengatur High Availability ke Dinonaktifkan pada panel High Availability, lalu mengaturnya kembali ke Zona Redundan dan pilih zona.

  • Apakah replikasi antara replika utama dan siaga sinkron?
    Replikasi antara primer dan siaga mirip dengan mode semi sinkron di MySQL. Ketika dilakukan, transaksi tidak selalu berkomitmen untuk siaga. Tetapi ketika primer tidak tersedia, siaga memang mereplikasi semua perubahan data dari primer untuk memastikan tidak ada kehilangan data.

  • Apakah ada failover ke replika siaga untuk semua kegagalan yang tidak direncanakan?
    Jika terdapat crash database atau kegagalan node, Mesin Virtual Server Fleksibel dihidupkan ulang pada node yang sama. Pada saat yang sama, failover otomatis akan terpicu. Jika menghidupkan ulang mesin virtual Server Fleksibel berhasil sebelum failover selesai, operasi failover akan dibatalkan. Penentuan server mana yang akan digunakan sebagai replika utama tergantung pada proses yang selesai terlebih dahulu.

  • Apakah ada dampak kinerja ketika saya menggunakan ketersediaan tinggi?
    Untuk ketersediaan tinggi zona-redundan, meskipun tidak ada dampak performa utama untuk beban kerja baca di seluruh zona ketersediaan, mungkin ada penurunan hingga 40 persen dalam latensi kueri tulis. Peningkatan latensi tulis disebabkan oleh replikasi sinkron di seluruh zona Ketersediaan. Dampak latensi tulis umumnya dua kali di zona redundan HA dibandingkan dengan zona HA yang sama. Untuk KETERSEDIAAN TINGGI zona yang sama, karena replika utama dan siaga berada di zona yang sama, latensi replikasi dan akibatnya latensi tulis sinkron lebih rendah. Singkatnya, jika latensi tulis lebih penting bagi Anda dibandingkan dengan ketersediaan, Anda mungkin ingin memilih ketersediaan tinggi zona yang sama tetapi jika ketersediaan dan ketahanan data Anda lebih penting bagi Anda dengan mengorbankan penurunan latensi tulis, Anda harus memilih ketersediaan tinggi zona-redundan. Untuk mengukur dampak akurat dari penurunan latensi dalam penyiapan KETERSEDIAAN TINGGI, kami sarankan Anda untuk melakukan pengujian performa beban kerja Anda untuk mengambil keputusan berdasarkan informasi.

  • Bagaimana pemeliharaan server ketersediaan tinggi saya terjadi?
    Peristiwa yang direncanakan seperti penskalaan komputasi dan peningkatan versi minor terjadi pada instans siaga asli terlebih dahulu, dan diikuti dengan memicu operasi failover yang direncanakan, lalu beroperasi pada instans utama asli. Anda dapat mengatur jendela pemeliharaan terjadwal untuk server ketersediaan tinggi seperti yang Anda lakukan untuk server fleksibel. Jumlah waktu henti akan sama dengan waktu henti untuk instans server fleksibel Azure Database for MySQL saat KETERSEDIAAN TINGGI dinonaktifkan.

  • Dapatkah saya melakukan pemulihan pada titik waktu tertentu (PITR) server ketersediaan tinggi saya?
    Anda dapat melakukan PITR untuk instans server fleksibel Azure Database for MySQL dengan dukungan HA ke instans server fleksibel Azure Database for MySQL baru yang menonaktifkan KETERSEDIAAN TINGGI. Jika server sumber dibuat dengan ketersediaan tinggi zona-redundan, Anda dapat mengaktifkan ketersediaan tinggi zona-redundan atau ketersediaan tinggi zona-sama di server yang dipulihkan nanti. Jika server sumber dibuat dengan ketersediaan tinggi zona yang sama, Anda hanya dapat mengaktifkan ketersediaan tinggi zona yang sama di server yang dipulihkan.

  • Dapatkah saya mengaktifkan ketersediaan tinggi di server setelah saya membuat server?
    High availability zona-redundan harus diaktifkan saat server dibuat. Anda dapat mengaktifkan ketersediaan tinggi zona yang sama setelah Anda membuat server. Sebelum mengaktifkan high availability zona yang sama pastikan bahwa parameter server enforce_gtid_consistency” dan “gtid_mode” diatur ke AKTIF

  • Dapatkah saya menonaktifkan ketersediaan tinggi untuk server setelah membuatnya?
    Anda dapat menonaktifkan high availability di server setelah Anda membuatnya. Tagihan langsung berhenti.

  • Bagaimana cara mengurangi waktu henti?
    Anda harus dapat mengurangi waktu henti untuk aplikasi Anda bahkan saat Anda tidak menggunakan high availability. Waktu henti layanan, seperti patch terjadwal, peningkatan versi minor, atau operasi yang dimulai oleh pelanggan seperti penskalaan komputasi dapat dilakukan selama periode pemeliharaan terjadwal. Untuk mengurangi dampak aplikasi untuk tugas pemeliharaan yang dimulai Azure, Anda dapat menjadwalkannya pada hari dalam seminggu dan waktu yang meminimalkan dampak pada aplikasi.

  • Dapatkah saya menggunakan replika baca untuk server berkemampuan ketersediaan tinggi?
    Ya, replika baca didukung untuk server HA.

  • Dapatkah saya menggunakan Replikasi Data-masuk untuk server ketersediaan tinggi?
    Dukungan untuk replikasi data masuk untuk server dengan ketersediaan tinggi (HA) yang diaktifkan hanya tersedia melalui replikasi berbasis GTID. Prosedur tersimpan untuk replikasi menggunakan GTID tersedia di semua server berkemampuan HA dengan nama mysql.az_replication_with_gtid.

  • Untuk mengurangi waktu henti, dapatkah saya melakukan failover ke server siaga selama server dihidupkan ulang atau saat meningkatkan atau menurunkan skala?
    Saat ini, server fleksibel Azure Database for MySQL telah menggunakan Failover Terencana untuk mengoptimalkan operasi HA termasuk peningkatan/penurunan skala, dan pemeliharaan terencana untuk membantu mengurangi waktu henti. Ketika operasi tersebut dimulai, operasi akan beroperasi pada instans siaga asli terlebih dahulu, diikuti dengan memicu operasi failover yang direncanakan, lalu beroperasi pada instans utama asli.

  • Dapatkah kita mengubah mode ketersediaan (High availability zona-redundan/zona yang sama) server
    Jika Anda membuat server dengan mode high availability Zona-redundan yang diaktifkan, Anda dapat mengubah dari high availability Zona-redundan menjadi zona yang sama dan sebaliknya. Untuk mengubah mode ketersediaan, Anda dapat mengatur High Availability ke Dinonaktifkan pada panel High Availability, lalu mengaturnya kembali ke Zona redundan atau zona yang sama dan pilih Mode High Availability.

Langkah berikutnya