Keandalan dalam Azure Database for MySQL

Azure Database for MySQL adalah layanan database terkelola penuh yang dirancang untuk memberi Anda kontrol dan fleksibilitas terperinci atas fungsi manajemen database dan pengaturan konfigurasi. Layanan ini menyediakan ketersediaan tinggi dan kemampuan pemulihan bencana berdasarkan kebutuhan Anda.

Saat Anda menggunakan Azure, keandalan adalah tanggung jawab bersama. Microsoft menyediakan berbagai kemampuan untuk mendukung ketahanan dan pemulihan. Anda bertanggung jawab untuk memahami cara kerja kemampuan tersebut dalam semua layanan yang Anda gunakan, dan memilih kemampuan yang Anda butuhkan untuk memenuhi tujuan bisnis dan tujuan waktu aktif Anda.

Artikel ini menjelaskan cara membuat Azure Database for MySQL tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, pemadaman zona ketersediaan, pemadaman wilayah, dan pemeliharaan layanan. Ini juga menjelaskan bagaimana Anda dapat menggunakan cadangan untuk memulihkan dari jenis masalah lain, dan menyoroti beberapa informasi utama tentang perjanjian tingkat layanan (SLA) Azure Database for MySQL.

Rekomendasi penyebaran produksi

Untuk mempelajari tentang cara menerapkan Azure Database for MySQL guna mendukung keandalan solusi Anda dan bagaimana keandalan memengaruhi aspek lain dari arsitektur Anda, lihat praktik terbaik arsitektur untuk Azure Database for MySQL dalam Azure Well-Architected Framework.

Gambaran umum arsitektur keandalan

Bagian ini menjelaskan beberapa aspek penting tentang cara kerja layanan yang paling relevan dari perspektif keandalan. Bagian ini memperkenalkan arsitektur logis, yang mencakup beberapa sumber daya dan fitur yang Anda sebarkan dan gunakan. Ini juga membahas arsitektur fisik, yang memberikan detail tentang cara kerja layanan di bawah sampul.

Arsitektur logika

Saat bekerja dengan Azure Database for MySQL, Anda menyebarkan server, yang mewakili sumber daya komputasi dan penyimpanan yang diperlukan untuk mendukung server database Anda. Anda menyebarkan satu atau beberapa database ke server.

Anda dapat menyebarkan server di beberapa tingkat komputasi: Burstable, General Purpose, dan Memory Optimized, yang masing-masing dioptimalkan untuk berbagai jenis beban kerja.

Untuk informasi selengkapnya tentang arsitektur layanan umum dan model penyebaran, lihat Apa Azure Database for MySQL?.

Arsitektur fisik

  • Pemisahan komputasi dan penyimpanan: Azure Database for MySQL menggunakan arsitektur pemisahan komputasi dan penyimpanan guna mendukung ketersediaan yang tinggi. Mesin database berjalan pada komputer virtual. File data disimpan dalam Azure Storage, yang secara sinkron mempertahankan tiga salinan data untuk melindungi dari kegagalan perangkat keras penyimpanan. Bergantung pada konfigurasi ketersediaan tinggi server, file data dapat disimpan di penyimpanan redundan zona (ZRS) atau penyimpanan redundan lokal (LRS).

  • Ketersediaan tinggi: Anda dapat secara opsional mengaktifkan konfigurasi ketersediaan tinggi di server Anda. Saat Anda mengaktifkan konfigurasi ketersediaan tinggi, layanan menyediakan dan memelihara server replika siaga yang hangat. Perubahan data pada server utama direplikasi secara sinkron ke server replika siaga untuk memastikan tidak ada kehilangan data selama kegagalan server utama.

    Arsitektur memisahkan lapisan komputasi dari lapisan penyimpanan, memungkinkan layanan untuk menangani berbagai jenis kegagalan dengan tepat. Untuk ketahanan yang lebih tinggi, Anda dapat menyebarkan server di seluruh zona ketersediaan.

    Server replika siaga disebarkan dalam konfigurasi VM yang sama dengan server utama, termasuk vCores, penyimpanan, dan pengaturan jaringan.

    Anda dapat beralih antar server dengan melakukan failover. Ada dua jenis failover: failover yang tidak direncanakan, yang digunakan ketika server utama gagal, dan failover yang direncanakan, yang digunakan dalam skenario lain di mana Anda perlu meminimalkan waktu henti aplikasi selama failover.

    Untuk informasi selengkapnya, lihat Ketersediaan Tinggi di Azure Database for MySQL.

  • Backups: Azure Database for MySQL secara otomatis membuat cadangan server. Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan.

Ketahanan terhadap kesalahan sementara

Kesalahan sementara adalah kegagalan yang bersifat sementara dan intermiten dalam komponen. Mereka sering terjadi di lingkungan terdistribusi seperti cloud, dan mereka adalah bagian normal dari operasi. Kesalahan sementara memperbaiki diri setelah waktu yang singkat. Penting bahwa aplikasi Anda dapat menangani kesalahan sementara, biasanya dengan mencoba kembali permintaan yang terpengaruh.

Semua aplikasi yang dihosting cloud harus mengikuti panduan penanganan kesalahan sementara Azure saat berkomunikasi dengan API, database, dan komponen lain yang dihosting cloud. Untuk informasi selengkapnya, lihat Rekomendasi untuk menangani kesalahan sementara.

Aplikasi Anda harus menangani kesalahan konektivitas sementara yang dapat terjadi selama pemeliharaan, operasi penskalaan, atau gangguan jaringan. Ikuti rekomendasi berikut:

  • Ketika aplikasi Anda mengalami kesalahan sementara, coba lagi operasi dengan menggunakan backoff eksponensial. Tingkatkan penundaan antara percobaan ulang dan batasi jumlah upaya. Jika operasi masih gagal setelah percobaan ulang maksimum, perlakukan sebagai kegagalan.
  • Jika memungkinkan, gunakan pustaka klien yang secara otomatis menangani percobaan ulang.
  • Kesalahan sementara yang terjadi selama operasi tulis memerlukan pertimbangan yang lebih hati-hati. Pertimbangkan untuk membuat operasi tulis Anda idempoten, sehingga dapat dieksekusi dengan aman beberapa kali.

Ketahanan terhadap kegagalan zona ketersediaan

Zona ketersediaan adalah grup pusat data yang terpisah secara fisik dalam wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.

Anda dapat memilih jenis dukungan zona ketersediaan Anda melalui konfigurasi ketersediaan tinggi . Mengaktifkan fitur ketersediaan tinggi akan menempatkan server replika siaga di samping server utama Anda. Model ketersediaan tinggi ini membantu memastikan bahwa data yang diterapkan tidak pernah hilang selama kegagalan. Model penyebaran ketersediaan tinggi mana pun yang Anda pilih, data diterapkan secara sinkron ke server replika utama dan siaga. Jika gangguan terjadi pada server utama, server secara otomatis beralih ke server replika siaga.

Data disimpan di penyimpanan premium Azure Files. Bergantung pada konfigurasi ketersediaan tinggi server Anda, konfigurasi tersebut menggunakan penyimpanan redundan zona atau penyimpanan redundan lokal (LRS), yang menyimpan tiga salinan data di dalam atau di seluruh zona ketersediaan.

Azure Database for MySQL mendukung dua jenis konfigurasi zona ketersediaan saat Anda menggunakan ketersediaan tinggi:

  • Ketersediaan tinggi zona-redundan: Redundansi zona memberikan tingkat ketahanan zona tertinggi dengan menyebarkan server utama dalam satu zona ketersediaan dan server replika siaga di zona ketersediaan yang berbeda. Server replika siaga menggunakan komputasi, penyimpanan, dan konfigurasi jaringan yang serupa dengan konfigurasi utama. Konfigurasi yang redundan antar zona menyediakan isolasi fisik dari seluruh tumpukan antara server primer dan server siaga.

    Anda memilih zona ketersediaan untuk server utama dan siaga.

    Kami merekomendasikan penerapan redundan zona untuk server produksi.

    Diagram memperlihatkan server zona-redundan, dengan server utama dan siaga di zona ketersediaan yang berbeda.

    Operasi tulis dapat mengalami sedikit peningkatan dalam latensi penyelesaian karena layanan mereplikasi data secara sinkron ke server siaga. Rata-rata, Anda dapat mengharapkan peningkatan latensi 5-10 persen untuk penulisan dan penerapan aplikasi, tetapi dampaknya bervariasi menurut beban kerja, SKU yang dipilih, dan wilayah.

  • Ketersediaan tinggi redundan lokal: Server utama dan siaga menggunakan zona ketersediaan yang sama. Jika gangguan terjadi pada server utama, tetapi zona masih sehat, server secara otomatis beralih ke server siaga.

    Penyebaran redundan lokal memberi Anda ketersediaan tinggi dalam satu zona ketersediaan. Ini melindungi Anda dari kegagalan pada tingkat node dan juga membantu mengurangi waktu henti aplikasi selama kejadian waktu henti yang direncanakan dan tidak terduga. Namun, itu tidak melindungi dari pemadaman di zona itu. Di wilayah dengan zona ketersediaan, konfigurasi semacam ini juga terkadang disebut zonal atau single-zone.

    Diagram memperlihatkan server lokal-redundan, dengan server utama dan siaga di zona ketersediaan yang sama.

    Kami merekomendasikan ketersediaan tinggi dengan redundansi lokal hanya dalam skenario tertentu.

    • Ketika Anda memiliki aplikasi yang sangat sensitif terhadap latensi, Anda telah memvalidasi kebutuhan untuk meminimalkan latensi antara replika utama dan sekunder Anda, dan Anda telah merencanakan ketahanan zona sendiri dengan menggunakan pendekatan arsitektur lainnya.
    • Saat Anda menyebarkan ke wilayah yang tidak mendukung zona ketersediaan, wilayah tersebut pada dasarnya berfungsi sebagai satu zona, menjadikan redundansi lokal untuk ketersediaan tinggi satu-satunya opsi ketersediaan tinggi.

    Karena server berada di zona yang sama, hal ini dapat mengurangi latensi tulis ke aplikasi yang Anda sebarkan dalam zona tersebut.

Jika Anda mengonfigurasi server tanpa ketersediaan tinggi, server berjalan pada satu server. Jika server atau zonanya tidak berfungsi, server Anda tidak tersedia.

Persyaratan

  • Dukungan Wilayah: Dukungan Azure Database untuk MySQL terhadap konfigurasi zona ketersediaan berbeda antara berbagai wilayah Azure. Untuk daftar lengkap wilayah dan jenis dukungan zona ketersediaan serta pertimbangan khusus untuk setiap wilayah tersebut, lihat Azure regions.

  • Tingkat layanan: Ketersediaan tinggi memerlukan tingkat Tujuan Umum atau Memori yang Dioptimalkan. Tingkat Burstable tidak mendukung ketersediaan tinggi (zona-redundan atau redundan lokal).

Biaya

Saat Anda mengaktifkan ketersediaan tinggi, server siaga dibuat dan ditagih dengan tarif yang sama dengan yang utama. Konfigurasi zona ketersediaan tidak memengaruhi biaya. Tidak ada biaya untuk replikasi data di dalam atau di antara zona ketersediaan. Bergantung pada volume penyimpanan cadangan, Anda mungkin juga ditagih untuk penyimpanan cadangan. Untuk informasi harga terperinci, lihat harga Azure Database for MySQL.

Pertimbangan

  • Kunci primer: Kami sarankan Anda menggunakan kunci primer pada semua tabel, karena pendekatan ini mengurangi waktu replikasi dan failover.
  • Batasan dan masalah yang diketahui: Tinjau daftar batasan dan masalah yang diketahui.

Mengonfigurasi dukungan zona ketersediaan

Untuk mengonfigurasi dukungan zona ketersediaan untuk server, Anda mengonfigurasi pengaturan ketersediaan tinggi.

Nota

Saat Anda memilih zona ketersediaan mana yang akan digunakan, Anda benar-benar memilih zona ketersediaan logis. Jika Anda menyebarkan komponen beban kerja lain dalam langganan Azure yang berbeda, komponen tersebut mungkin menggunakan nomor zona ketersediaan logis yang berbeda untuk mengakses zona ketersediaan fisik yang sama. Untuk informasi selengkapnya, lihat Zona ketersediaan fisik dan logis.

Perilaku ketika semua zona sehat

Bagian ini menjelaskan apa yang diharapkan ketika server dikonfigurasi dengan dukungan ketersediaan tinggi dan zona ketersediaan dan semua zona ketersediaan beroperasi.

  • Operasi lintas zona: Aplikasi klien MySQL terhubung ke server utama dengan menggunakan nama domain server database yang sepenuhnya memenuhi syarat (FQDN). Hindari menggunakan alamat IP server utama karena alamat IP dapat berubah, termasuk selama failover.

    Azure Database for MySQL menggunakan konfigurasi aktif/pasif di mana semua koneksi dan kueri database ditangani oleh server utama di zona ketersediaan utama. Server replika siaga tidak melayani lalu lintas klien selama operasi normal.

  • Replikasi data lintas zona: Penulisan dicatat di server utama, dan ditulis secara sinkron pada log untuk server siaga menggunakan ZRS. Server utama tidak menunggu server siaga untuk menerapkan log, tetapi karena log tersebut berada dalam ZRS, log tersebut tetap tersedia bahkan jika terjadi kegagalan replika atau zona.

    Efek replikasi berbeda tergantung pada konfigurasi zona ketersediaan yang digunakan server Anda:

    • Zona-redundan: Karena server berada di zona terpisah, pendekatan ini memastikan tidak ada kehilangan data selama kegagalan zona. Situasi ini juga dikenal sebagai mencapai tujuan titik pemulihan (RPO) nol untuk kegagalan zona.

      Namun, replikasi lintas zona mungkin memperkenalkan sejumlah kecil latensi tambahan. Rata-rata, Anda dapat mengharapkan peningkatan latensi 5-10 persen untuk penulisan dan penerapan aplikasi, tetapi dampaknya bervariasi menurut beban kerja, SKU yang dipilih, dan wilayah.

    • Redundan lokal: Tidak ada lalu lintas yang direplikasi antar zona.

    Nota

    Sistem mereplikasi semua perubahan secara real-time ke server replika siaga, termasuk kesalahan pengguna yang tidak diinginkan seperti penurunan tabel yang tidak disengaja atau pembaruan data yang salah. Karena replikasi langsung, Anda tidak dapat menggunakan replika siaga untuk pemulihan. Untuk memulihkan dari kesalahan pengguna, Anda harus melakukan "pemulihan point-in-time" dari cadangan. Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan ketika server dikonfigurasi untuk mendukung ketersediaan tinggi dan zona ketersediaan, serta ada pemadaman zona ketersediaan.

  • Deteksi dan respons: Azure secara berkala memeriksa kondisi server utama dan siaga. Setelah beberapa ping, jika pemantauan kesehatan mendeteksi bahwa server utama tidak dapat dijangkau, layanan memulai failover otomatis ke server siaga. Algoritma pemantauan kesehatan menggunakan beberapa titik data untuk menghindari situasi positif palsu.

    Jika terjadi kegagalan zona, perilakunya berbeda tergantung pada konfigurasi zona ketersediaan yang digunakan server Anda:

    • Zone-redundant: Azure Database for MySQL secara otomatis mendeteksi kegagalan zona ketersediaan dengan terus memantau beberapa titik akhir server. Untuk informasi selengkapnya, lihat Cara kerja deteksi failover otomatis di server dengan ketersediaan tinggi yang diaktifkan.

      Untuk melihat kemungkinan jenis status ketersediaan tinggi, lihat Memantau ketersediaan tinggi. Ketika sebuah zona gagal, Azure memulai failover yang tidak terencana ke server siaga tanpa mengharuskan Anda mengambil tindakan.

    • Redundansi Lokal: Baik server utama maupun server siaga tidak tersedia jika zona ketersediaan yang menghosting server dengan redundansi lokal menjadi tidak tersedia. Dalam skenario ini, layanan tidak menyediakan failover otomatis. Anda bertanggung jawab untuk mendeteksi pemadaman zona dan melakukan tindakan pemulihan, seperti memulihkan cadangan redundan zona ke server terpisah di zona atau wilayah ketersediaan lain.

  • Notification: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Namun, Anda dapat menggunakan Azure Resource Health untuk memantau kesehatan sumber daya individual, dan Anda dapat menyiapkan pemberitahuan Resource Health untuk memberi tahu Anda tentang masalah. Anda juga dapat menggunakan Azure Service Health untuk memahami kesehatan keseluruhan layanan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

    Azure Database for MySQL menghasilkan peristiwa Azure Resource Health ketika failover yang tidak direncanakan terjadi.

  • Permintaan aktif: Ketika zona ketersediaan menjadi tidak tersedia, permintaan yang sedang berlangsung ke server di zona yang terpengaruh mungkin dihentikan. Aplikasi harus mencoba kembali permintaan ini. Jika klien Anda menangani kesalahan sementara dengan tepat dengan mencoba kembali setelah waktu yang singkat, mereka biasanya menghindari dampak yang signifikan.

  • Kehilangan data yang diharapkan: Jumlah kehilangan data tergantung pada konfigurasi zona ketersediaan server Anda.

    • Redundansi zona: Tidak ada kehilangan data yang diharapkan selama penyelesaian kegagalan zona karena replikasi sinkron antara server utama dan server cadangan di zona yang berbeda.

    • Redundan lokal: Data pada server di zona yang terpengaruh tidak tersedia hingga zona pulih.

  • Waktu henti yang diharapkan: Jumlah waktu henti tergantung pada konfigurasi zona ketersediaan yang digunakan server Anda.

    • Zona-redundan: Failover biasanya selesai dalam waktu 60-120 detik. Jika klien Anda menangani kesalahan sementara dengan tepat dengan mencoba kembali setelah waktu yang singkat, mereka biasanya menghindari dampak yang signifikan.

    • Redundan lokal: Server di zona yang terkena dampak tidak tersedia hingga zona ketersediaan pulih.

  • Redistribusi: Perilaku pengalihan lalu lintas tergantung pada konfigurasi zona ketersediaan yang digunakan server Anda.

    • Zona-redundan: Setelah failover, server siaga sebelumnya menjadi primer baru dan mulai menerima koneksi baru. Azure secara otomatis membuat server siaga di zona utama asli setelah pulih. Untuk detail selengkapnya, lihat Failover yang tidak direncanakan.

    • Redundansi lokal: Ketika sebuah zona tidak tersedia, server Anda juga tidak tersedia. Jika Anda memiliki server terpisah yang Anda buat sebelumnya di zona ketersediaan atau wilayah lain, Anda bertanggung jawab untuk mengalihkan lalu lintas ke server tersebut.

Pemulihan Zona

Perilaku pemulihan zona tergantung pada konfigurasi zona ketersediaan yang digunakan server Anda.

  • Zone-redundant: Ketika zona ketersediaan pulih, Azure Database for MySQL secara otomatis membangun kembali server siaga di zona yang dipulihkan dan menyinkronkannya dengan primer saat ini. Zona yang dipulihkan kemudian berfungsi sebagai lokasi siaga. Layanan tidak secara otomatis memindahkan peran utama kembali ke zona asli untuk menghindari gangguan yang tidak perlu. Anda dapat memulai failover yang direncanakan secara manual jika Anda ingin mengembalikan primer ke zona asli.

  • Redundansi lokal: Setelah zona dalam keadaan sehat, server di zona tersedia kembali. Anda bertanggung jawab atas prosedur pemulihan zona dan sinkronisasi data apa pun yang diperlukan beban kerja Anda.

Uji kegagalan zona

Opsi untuk pengujian kegagalan zona bergantung pada konfigurasi zona ketersediaan yang digunakan instans Anda.

  • Zona-redundan: Anda dapat menguji ketahanan aplikasi Anda terhadap failover dengan memulai failover yang direncanakan. Failover yang direncanakan memungkinkan Anda mensimulasikan skenario pemadaman yang tidak direncanakan saat menjalankan beban kerja Anda dan mengamati waktu henti aplikasi Anda. Sebaiknya jalankan simulasi di lingkungan non-produksi, atau pada waktu yang tenang. Untuk informasi selengkapnya, lihat Failover terencana.

  • Redundan lokal: Meskipun Anda tidak dapat mensimulasikan pemadaman zona penuh, Anda dapat mensimulasikan server Anda tidak tersedia dengan cara yang sama dengan apa yang terjadi selama pemadaman zona. Untuk informasi selengkapnya, lihat:

Ketahanan terhadap kegagalan di seluruh wilayah

Azure Database for MySQL mendukung replika baca lintas-wilayah , yang dapat Anda gunakan untuk mempertahankan salinan database tersinkronisasi di wilayah yang berbeda untuk pemulihan yang lebih cepat.

Anda juga dapat menggunakan cadangan geo-redundan, di wilayah yang didukung, untuk menyediakan pemulihan lintas wilayah. Namun, pencadangan biasanya melibatkan lebih banyak waktu henti dan kehilangan data daripada replikasi. Untuk informasi selengkapnya, lihat Pencadangan dan pemulihan.

Replika baca lintas wilayah

Anda dapat menyebarkan replika baca untuk melindungi database Anda dari kegagalan tingkat wilayah. Setiap replika baca adalah Azure Database for MySQL server yang terpisah. Saat Anda menempatkan replika baca di wilayah Azure kedua, server database Anda dapat memberikan ketahanan terhadap masalah di seluruh wilayah. Anda dapat menyebarkan hingga sepuluh replika baca, yang secara opsional dapat berada di wilayah Azure yang berbeda. Teknologi replikasi fisik MySQL memperbarui replika baca secara asinkron dari server sumber di wilayah utama, dan replika tersebut dapat tertinggal dari sumbernya. Replika baca lintas wilayah dapat secara opsional melayani beban kerja baca-saja untuk mengurangi latensi pada aplikasi yang didistribusikan secara global atau untuk mengurangi beban lalu lintas baca dari server sumber. Untuk informasi selengkapnya tentang fitur dan pertimbangan replika baca, lihat Membaca replika.

Diagram memperlihatkan replika baca di wilayah Azure kedua, dengan aplikasi mengarahkan lalu lintas baca-tulis ke server sumber.

Jika wilayah utama gagal, Anda dapat melakukan failover secara manual sehingga replika sekunder Anda menjadi server utama. Anda melakukan ini dengan menghentikan proses replikasi, yang mempromosikan replika baca menjadi server baca-tulis. Karena replikasi asinkron, failover dapat mengakibatkan kehilangan data. Aplikasi Anda kemudian perlu terhubung ke server utama baru, dan Anda bertanggung jawab atas konfigurasi ulang aplikasi ini.

Diagram memperlihatkan replika baca di wilayah Azure kedua yang telah gagal menjadi server utama, dengan aplikasi sekarang mengarahkan lalu lintas baca-tulis ke wilayah sekunder.

Nota

Bagian ini merangkum beberapa informasi penting tentang bagaimana replika baca dapat mendukung ketahanan terhadap gangguan secara regional. Anda juga dapat menggunakan replika baca untuk meningkatkan performa dan mendukung basis pengguna yang didistribusikan secara geografis skala tinggi. Untuk informasi selengkapnya, lihat Membaca replika.

Persyaratan

  • Region support: Anda dapat membuat replika baca lintas wilayah di wilayah mana pun yang mendukung Azure Database for MySQL. Anda tidak terbatas pada wilayah berpasangan di Azure.

  • Tingkat komputasi: Tingkat komputasi General Purpose dan Memory Optimized mendukung replika baca. Tingkat Burstable ini tidak mendukung replika baca.

Pertimbangan

  • Perbedaan konfigurasi: Saat Anda membuat replika, replika mewarisi beberapa pengaturan dari server sumber, termasuk pembuatan komputasi, vCore, dan penyimpanan. Anda dapat menyesuaikan nilai-nilai ini pada replika baca setelah dibuat. Namun, yang terbaik adalah menggunakan nilai yang sama atau lebih besar untuk memastikan bahwa replika dapat mengikuti perubahan sumbernya.

  • Memantau lag replikasi: Proses replikasi asinkron memerlukan jeda replikasi, yang dapat bervariasi tergantung pada sejumlah faktor. Ketika lag replikasi sangat tinggi, server Anda mungkin mengalami masalah. Penting untuk memantau jeda replikasi sehingga Anda dapat mengurangi masalah sebelum meningkat. Untuk informasi selengkapnya, silahkan lihat Memantau replikasi.

  • Ketersediaan tinggi: Replika baca tidak dapat mengaktifkan ketersediaan tinggi, dan ketika mereka gagal untuk menjadi server utama, mereka juga tidak memiliki ketersediaan tinggi. Anda bertanggung jawab untuk mengonfigurasi ketersediaan tinggi setelah melakukan failover ke replika.

Biaya

Replika baca dikenakan biaya komputasi dan penyimpanan, serta biaya transfer data lintas wilayah untuk replikasi. Untuk informasi harga terperinci, lihat harga Azure Database for MySQL dan harga Bandwidth.

Mengonfigurasi dukungan multiregional

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan ketika server Anda dikonfigurasi dengan replika baca di wilayah lain, dan semua wilayah beroperasi:

  • Perutean lalu lintas antar wilayah: Dalam operasi normal, aplikasi Anda harus mengarahkan lalu lintas baca-tulis ke server sumber di wilayah utama. Anda dapat mengarahkan permintaan baca ke replika baca Anda secara opsional.

  • Replikasi data antar wilayah: Replika baca lintas wilayah menggunakan replikasi asinkron untuk meminimalkan dampak pada performa server sumber. Jumlah lag replikasi tergantung pada sejumlah faktor, termasuk beban tulis dan latensi antara server sumber dan replika. Lag replikasi biasanya setidaknya beberapa menit, tetapi bisa lebih lama lagi. Untuk informasi selengkapnya, lihat replikasi Monitor, dan untuk instruksi terperinci, lihat replikasi Monitor di portal Azure.

Perilaku selama kegagalan wilayah

Bagian ini menjelaskan apa yang diharapkan ketika server Anda dikonfigurasi dengan replika baca di wilayah lain, dan ada pemadaman di wilayah utama:

  • Deteksi dan respons: Anda bertanggung jawab untuk mendeteksi pemadaman di wilayah utama, dan memicu failover secara manual. Tindakan ini dapat mengakibatkan hilangnya data yang tidak direplikasi.

    Penting

    Anda bertanggung jawab memicu failover. Azure tidak melakukan failover untuk membaca replika secara otomatis, bahkan jika ada kegagalan wilayah.

    Fungsi failover mengharuskan Anda:

    1. Hentikan replikasi. Ini adalah prosedur yang tidak dapat diubah, dan server tidak dapat dibuat menjadi replika lagi. Proses ini mengakibatkan kehilangan data. Untuk detail selengkapnya tentang implikasi tindakan ini, lihat Menghentikan replikasi.
    2. Konfigurasi ulang aplikasi Anda untuk menggunakan primer baru.

    Untuk informasi selengkapnya, lihat Failover.

  • Notification: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • Permintaan aktif: Semua koneksi aktif ke wilayah sumber dihilangkan jika server sumber tidak tersedia. Aplikasi perlu mencoba kembali membuat koneksi ke server utama baru setelah proses failover selesai.

  • Kehilangan data yang diharapkan: Selama pemadaman wilayah, Anda harus melakukan failover yang menghentikan replikasi. Proses ini mengakibatkan hilangnya data yang tidak direplikasi secara permanen.

    Jumlah kehilangan data tergantung pada jeda replikasi pada saat pemadaman. Lag replikasi biasanya setidaknya beberapa menit, tetapi bisa lebih lama lagi. Untuk informasi selengkapnya, silahkan lihat Memantau replikasi.

  • Waktu henti yang diharapkan: Menghentikan replikasi biasanya selesai dalam waktu 2 menit setelah dipicu. Anda bertanggung jawab untuk mengonfigurasi ulang aplikasi Anda untuk terhubung ke server utama baru, dan waktu yang diperlukan bagi Anda untuk melakukan konfigurasi ulang juga berkontribusi pada waktu henti Anda secara keseluruhan.

  • Pengalihan lalu lintas: Anda bertanggung jawab untuk mengonfigurasi ulang aplikasi Anda untuk terhubung ke server utama baru.

    Nota

    Setelah Anda melakukan failover pada replika baca untuk menjadi server utama, ketersediaan tinggi tidak diaktifkan pada server tersebut. Anda harus mengaktifkan ketersediaan tinggi secara manual atau menyertakannya dalam otomatisasi Anda.

Pemulihan wilayah

Saat wilayah pulih, Anda bertanggung jawab atas aktivitas failback apa pun untuk melanjutkan operasi di wilayah utama. Microsoft tidak secara otomatis memindahkan server utama. Anda dapat membuat replika baca baru di wilayah utama, lalu melakukan proses failover lain untuk memulihkan operasi di wilayah utama. Pertimbangkan salah satu pendekatan berikut, tergantung pada apakah aplikasi Anda dapat mentolerir waktu henti atau kehilangan data:

  • Buat aplikasi Anda offline, dan tunggu replikasi mengejar semua perubahan. Pendekatan ini membutuhkan waktu henti aplikasi, kira-kira sama dengan jeda replikasi.
  • Lakukan failover dan terima hilangnya data yang tidak direplikasi.

Ingat bahwa Anda juga bertanggung jawab untuk mengonfigurasi ulang aplikasi Anda untuk terhubung ke server utama baru sesuai kebutuhan.

Pengujian untuk mendeteksi kegagalan wilayah

Uji prosedur failover pada replika baca secara teratur untuk memastikan proses Anda valid, dan bahwa kemampuannya memenuhi persyaratan RTO dan RPO yang Anda tetapkan.

Anda dapat mengalihkan replika baca untuk menjadi server utama kapan saja, bahkan saat semua wilayah dalam kondisi normal. Kami sarankan Anda melakukan pengujian ini di lingkungan non-produksi karena dapat mengakibatkan kehilangan data dan memerlukan failback manual.

Sebagai bagian dari strategi pemulihan bencana Anda, jalankan latihan pemulihan penuh secara teratur. Latihan ini harus mencakup validasi data, pengujian fungsionalitas aplikasi, dan prosedur putar kembali yang didokumenkan.

Pencadangan dan pemulihan

Azure Database for MySQL secara otomatis melakukan pencadangan yang menyediakan kemampuan pemulihan pada titik waktu tertentu (point-in-time recovery), dan membantu melindungi Anda dari kerusakan dan penghapusan data yang tidak disengaja. Microsoft sepenuhnya mengelola cadangan, tidak mengganggu ketersediaan server, dan menyertakan pencadangan penuh dan pencadangan log transaksi.

  • Penyimpanan cadangan: Jika server dikonfigurasi dengan ketersediaan tinggi zona-redundan, cadangan disimpan di penyimpanan zona redundan (ZRS). Untuk server yang dikonfigurasi tanpa ketersediaan tinggi, atau dengan ketersediaan tinggi redundan lokal, cadangan disimpan dalam penyimpanan redundan lokal (LRS).

    Di wilayah Azure yang berpasangan, Anda dapat mengonfigurasi penyimpanan cadangan geo-redundan (GRS) pada saat pembuatan server untuk mereplikasi cadangan ke wilayah pasangan Azure guna perlindungan tambahan terhadap kegagalan wilayah. Pencadangan direplikasi secara asinkron.

    Periode retensi cadangan default adalah 7 hari, dengan opsi untuk memperpanjang retensi hingga 35 hari. Semua cadangan dienkripsi.

  • Mengembalikan: Pemulihan titik waktu memungkinkan Anda memulihkan database kapan saja dalam periode retensi cadangan. Proses pemulihan membuat server database baru dengan nama server baru yang disediakan pengguna, yang kemudian dapat Anda gunakan as-is atau menyalin data.

    Saat memulihkan cadangan geo-redundant, Anda membuat server baru di wilayah pasangan. Di beberapa wilayah, Anda dapat menggunakan Universal Geo-Restore untuk memulihkan cadangan geo-redundan ke wilayah yang bukan wilayah berpasangan wilayah utama Anda.

    Kemampuan ini berguna untuk memulihkan dari modifikasi data yang tidak disengaja, kesalahan aplikasi, atau skenario pengujian.

Untuk sebagian besar solusi, Anda tidak boleh mengandalkan cadangan secara eksklusif. Sebagai gantinya, gunakan kemampuan lain yang dijelaskan dalam panduan ini untuk mendukung persyaratan ketahanan Anda. Namun, pencadangan melindungi dari beberapa risiko yang tidak dapat dicegah oleh pendekatan lain. Untuk informasi selengkapnya, lihat Apa itu redundansi, replikasi, dan cadangan?.

Untuk informasi selengkapnya, lihat Backup dan pemulihan di Azure Database for MySQL.

Ketahanan terhadap pemeliharaan layanan

Azure Database for MySQL secara otomatis menangani tugas layanan penting termasuk patching perangkat keras, sistem operasi, dan mesin database yang mendasarinya. Layanan ini mencakup pembaruan keamanan, pembaruan perangkat lunak, dan peningkatan versi minor sebagai bagian dari pemeliharaan terencana. Untuk informasi selengkapnya, lihat Pemeliharaan Terjadwal di Azure Database for MySQL.

Untuk memastikan server Anda tetap tersedia selama jendela pemeliharaan, ikuti rekomendasi berikut:

  • Hindari operasi manajemen selama periode pemeliharaan: Jangan melakukan operasi manajemen server saat pemeliharaan sedang berlangsung, karena operasi ini dapat memengaruhi keandalan server Anda.

  • Gunakan pemeliharaan waktu henti mendekati nol: Jika server Anda mengaktifkan ketersediaan tinggi dan memenuhi kriteria kelayakan lainnya, operasi pemeliharaan sering selesai dalam waktu 10-30 detik. Jika Anda mengaktifkan ketersediaan tinggi, operasi pemeliharaan biasanya menggunakan pembaruan bergulir untuk meminimalkan waktu henti. Aktivitas pemeliharaan berkala seperti peningkatan versi minor terjadi pada replika siaga terlebih dahulu. Untuk mengurangi downtime, perangkat standby diangkat menjadi node utama agar beban kerja dapat terus berjalan saat tugas pemeliharaan diterapkan pada node lainnya. Urutan ini berlaku apakah server Anda menggunakan redundansi zona atau redundansi lokal untuk ketersediaan tinggi. Untuk informasi selengkapnya, lihat Pemeliharaan dengan waktu henti mendekati nol.

  • Mengonfigurasi jendela pemeliharaan kustom: Anda dapat mengonfigurasi jadwal pemeliharaan agar dikelola sistem atau menentukan jendela pemeliharaan kustom untuk meminimalkan dampak pada operasi bisnis Anda. Anda juga dapat menjadwalkan ulang operasi pemeliharaan terencana. Jadwalkan pemeliharaan selama periode aktivitas rendah untuk meminimalkan dampak bisnis. Untuk informasi selengkapnya, lihat Kelola pengaturan pemeliharaan terjadwal untuk Azure Database for MySQL.

  • Terapkan logika coba lagi: Pastikan aplikasi Anda dapat menangani gangguan konektivitas singkat yang mungkin terjadi selama pemeliharaan dimulai ulang. Untuk membuat aplikasi Anda tahan terhadap jenis masalah ini, lihat Panduan ketahanan terhadap kesalahan sementara .

  • Aktifkan pemeliharaan Virtual Canary pada server pengembangan dan pengujian: Pemeliharaan Virtual Canary menawarkan akses awal ke pembaruan. Dengan mengaktifkannya pada server pengembangan dan pengujian, Anda dapat memverifikasi bahwa beban kerja Anda tidak terpengaruh oleh pembaruan mendatang sebelum mencapai server produksi Anda. Untuk informasi selengkapnya, lihat Pemeliharaan Virtual Canary.

Perjanjian tingkat layanan

Perjanjian tingkat layanan (SLA) untuk layanan Azure menjelaskan ketersediaan yang diharapkan dari setiap layanan dan kondisi yang harus dipenuhi solusi Anda untuk mencapai harapan ketersediaan tersebut. Untuk informasi selengkapnya, lihat SLA untuk layanan online.

Azure Database for MySQL menyediakan SLA ketersediaan yang berbeda berdasarkan konfigurasi server:

  • Server-server dikonfigurasi dengan ketersediaan tinggi yang redundan antar zona.
  • Server yang dikonfigurasi dengan ketersediaan tinggi dengan redundansi lokal.
  • Server dikonfigurasi tanpa ketersediaan tinggi.

Konten terkait

  • Last updated on