Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Azure Database for MySQL adalah layanan database terkelola penuh yang memberi Anda kontrol dan fleksibilitas terperinci atas fungsi manajemen database dan pengaturan konfigurasi. Layanan ini menyediakan kemampuan ketersediaan tinggi (HA) dan pemulihan bencana (DR) 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
Azure Well-Architected Framework memberikan rekomendasi dalam hal reliabilitas, keamanan, biaya, operasi, dan performa. Untuk memahami bagaimana area ini saling memengaruhi dan berkontribusi pada solusi Azure Database for MySQL yang andal, lihat Praktik terbaik arsitektur untuk Azure Database for MySQL.
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 menerapkan server di tier komputasi Burstable, General Purpose, dan Memory Optimized. Setiap tingkat komputasi dioptimalkan untuk berbagai jenis beban kerja.
Untuk informasi selengkapnya tentang arsitektur layanan umum dan model penyebaran, lihat gambaran umum Azure Database for MySQL.
Arsitektur fisik
Pemisahan komputasi dan penyimpanan: Azure Database for MySQL menggunakan arsitektur komputasi dan penyimpanan yang terpisah untuk mendukung HA. Mesin database berjalan pada komputer virtual (VM). 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 (HA) server, berkas data dapat disimpan dalam penyimpanan redundan zona (ZRS) atau penyimpanan redundan lokal (LRS).
HA: Anda dapat mengaktifkan konfigurasi HA secara opsional pada server Anda. Saat Anda mengaktifkan konfigurasi HA, layanan menyiapkan dan memelihara server replika siaga 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, yang 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. Gunakan failover yang tidak direncanakan saat server utama gagal, dan gunakan failover yang direncanakan saat Anda perlu meminimalkan waktu henti aplikasi selama failover.
Untuk informasi selengkapnya, lihat HA 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 terus gagal setelah jumlah maksimum percobaan ulang, 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 penulisan Anda bersifat idempoten agar dapat dijalankan 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.
Pilih jenis dukungan zona ketersediaan melalui konfigurasi HA. Saat Anda mengaktifkan HA, Azure Database for MySQL menerapkan server replika siaga di samping server utama Anda. Model HA ini membantu memastikan bahwa data yang diterapkan tidak pernah hilang selama kegagalan. Model penyebaran HA mana pun yang Anda pilih, layanan secara sinkron menerapkan data ke server replika utama dan siaga. Jika server utama terganggu, server secara otomatis gagal ke server replika siaga.
Layanan ini menyimpan data pada penyimpanan premium Azure Files. Bergantung pada konfigurasi ketersediaan tinggi (HA) server Anda, server menggunakan ZRS atau LRS, yang menyimpan tiga salinan data di dalam satu zona ketersediaan atau lintas zona ketersediaan.
Azure Database for MySQL mendukung dua jenis konfigurasi zona ketersediaan saat menggunakan HA:
HA redundan zona: Redundansi zona memberikan tingkat ketahanan zona tertinggi dengan menempatkan server utama di satu zona ketersediaan dan server replika siaga di zona ketersediaan yang berbeda. Server replika siaga menggunakan komputasi, penyimpanan, dan konfigurasi jaringan serupa ke server 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.
Gunakan deployment dengan redundansi zona untuk server produksi.
Operasi tulis dapat mengalami sedikit peningkatan dalam latensi penyelesaian karena layanan mereplikasi data secara sinkron ke server siaga. Rata-rata, Anda dapat mengharapkan 5% hingga 10% peningkatan latensi untuk penulisan dan penerapan aplikasi. Dampaknya bervariasi menurut beban kerja, SKU, dan wilayah yang dipilih.
HA redundansi lokal: Server utama dan server siaga menggunakan zona ketersediaan yang sama. Jika gangguan terjadi pada server utama, tetapi zona masih sehat, server secara otomatis beralih ke server siaga.
Penerapan redundansi lokal memberikan ketersediaan tinggi dalam satu zona ketersediaan. Hal ini melindungi Anda dari kegagalan pada tingkat node dan juga membantu mengurangi waktu henti aplikasi selama peristiwa henti yang direncanakan maupun tidak direncanakan. Namun, itu tidak melindungi dari pemadaman di zona itu. Di wilayah yang memiliki zona ketersediaan, konfigurasi semacam ini juga terkadang disebut zonal atau zona tunggal.
Gunakan HA lokal-redundan hanya dalam skenario berikut:
Ketika Anda memiliki aplikasi yang sangat sensitif terhadap latensi, Anda memvalidasi kebutuhan untuk meminimalkan latensi antara replika utama dan sekunder Anda, dan Anda merencanakan ketahanan zona dengan menggunakan pendekatan arsitektur lainnya.
Saat Anda menerapkan ke wilayah yang tidak mendukung zona ketersediaan. Dalam skenario ini, wilayah berfungsi sebagai satu zona, yang menjadikan HA redundan lokal sebagai satu-satunya opsi HA.
Server berada di zona yang sama, yang dapat mengurangi latensi tulis ke aplikasi yang Anda sebarkan dalam zona tersebut.
Jika Anda mengonfigurasi server tanpa ketersediaan tinggi, server akan berjalan pada satu server. Jika server atau zonanya gagal, server Anda tidak tersedia.
Persyaratan
Dukungan wilayah: Azure Database for MySQL mendukung konfigurasi zona ketersediaan yang berbeda tergantung pada wilayah Azure Anda. Untuk daftar lengkap wilayah, termasuk jenis dukungan zona ketersediaan dan pertimbangan khusus untuk setiap wilayah, lihat wilayah Azure.
Tingkat layanan: HA memerlukan tingkat Tujuan Umum atau Memori yang Dioptimalkan. Tingkat Burstable tidak mendukung HA (redundan zona atau redundan lokal).
Biaya
Saat Anda mengaktifkan HA, Anda membuat dan membayar server siaga dengan tarif yang sama seperti server utama. Konfigurasi zona ketersediaan tidak memengaruhi biaya. Replikasi data tidak dikenakan biaya 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: Gunakan 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, konfigurasikan pengaturan HA.
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.
Buat server redundan zona. Untuk mempelajari cara membuat server dengan HA dan redundansi zona yang diaktifkan, lihat artikel berikut ini:
Buat server lokal-redundan. Untuk membuat server dengan HA redundansi lokal dalam satu zona ketersediaan, Anda harus menggunakan Azure CLI atau metode deployment terprogram lainnya. Untuk petunjuk Azure CLI, lihat Mengaktifkan HA saat membuat server.
Ubah konfigurasi zona ketersediaan untuk server yang ada. Jika Anda memiliki server yang sudah ada, pendekatan yang Anda ikuti untuk mengaktifkan dukungan zona ketersediaan bergantung pada konfigurasi awal server.
Untuk mengubah server yang ada menjadi HA redundan zona, Anda perlu memigrasikannya ke server baru. Untuk informasi selengkapnya, lihat Bermigrasi dari server yang sudah ada ke server zona-redundan.
Untuk mengubah server yang ada menjadi HA lokal-redundan:
Nonaktifkan HA, jika aktif.
Aktifkan HA redundansi lokal. Anda harus menggunakan Azure CLI atau metode penyebaran terprogram lainnya. Untuk petunjuk Azure CLI, lihat Mengelola ketersediaan tinggi zona redundan di Azure Database for MySQL dengan menggunakan Azure CLI.
Nonaktifkan HA. Menonaktifkan HA menghilangkan server replika siaga, sehingga server Anda tidak tangguh terhadap gangguan pada tingkat zona. Namun, jika cadangan geo-redundan diaktifkan, Anda masih dapat memulihkan server di wilayah yang berbeda dengan menggunakan cadangan tersebut. Untuk informasi selengkapnya, lihat Nonaktifkan HA.
Perilaku ketika semua zona sehat
Bagian ini menjelaskan hal-hal yang dapat Anda harapkan saat mengonfigurasi server dengan HA dan dukungan zona ketersediaan, serta ketika semua zona ketersediaan dalam kondisi operasional.
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 pasif aktif di mana server utama menangani semua koneksi dan kueri database di zona ketersediaan utama. Server replika siaga tidak melayani lalu lintas klien selama operasi normal.
Replikasi data lintas zona: Operasi tulis dikomitkan di server utama dan ditulis secara sinkron ke log untuk server siaga dengan 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 5% hingga 10% peningkatan latensi untuk penulisan dan penerapan aplikasi, tetapi dampaknya bervariasi menurut beban kerja, SKU, dan wilayah yang dipilih.
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 akan terjadi saat Anda mengonfigurasi server dengan HA dan dukungan zona ketersediaan, lalu terjadi gangguan pada 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 kegagalan zona terjadi, perilaku 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 berkemampuan HA.
Untuk melihat jenis status HA yang mungkin, lihat Pantau HA. 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.
Pemberitahuan: 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 berakhir. 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 hingga 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 terpengaruh 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 menjadi server utama baru dan mulai menerima koneksi baru. Azure secara otomatis membuat server siaga di zona utama asli setelah pulih. Untuk informasi 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.
Zona-redundan: Ketika zona ketersediaan pulih, Azure Database for MySQL secara otomatis membangun kembali server siaga di zona yang dipulihkan dan menyinkronkannya dengan server utama 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. Jika Anda ingin mengembalikan primer ke zona asli, Anda dapat memulai failover yang direncanakan secara manual.
Redundansi lokal: Setelah zona dalam keadaan sehat, server di zona tersedia kembali. Anda bertanggung jawab atas prosedur pemulihan zona dan sinkronisasi data 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. Gunakan failover yang direncanakan untuk mensimulasikan pemadaman yang tidak direncanakan saat beban kerja Anda berjalan dan mengamati waktu henti aplikasi Anda. Jalankan simulasi di lingkungan nonproduksi, atau pada waktu yang tenang. Untuk informasi selengkapnya, lihat Failover terencana.
Redundan lokal: Anda tidak dapat mensimulasikan pemadaman zona penuh, tetapi Anda dapat mensimulasikan server Anda tidak tersedia dengan cara yang sama dengan apa yang terjadi selama pemadaman zona. Untuk informasi lebih lanjut, baca artikel berikut:
Ketahanan terhadap kegagalan di seluruh wilayah
Azure Database for MySQL mendukung replika baca lintas wilayah, yang dapat Anda gunakan untuk mempertahankan salinan database yang disinkronkan 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
Terapkan replika baca untuk melindungi database Anda dari kegagalan di 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 10 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, yang berarti bahwa replika 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 terdiri dari wilayah utama, wilayah sekunder, dan aplikasi berlabel ikon. Panah solid menunjuk dari ikon aplikasi ke server utama di wilayah utama. Panah bertitik yang berlabel "replikasi asinkron" mengarah dari server utama ke replika baca di wilayah sekunder.
Jika wilayah utama gagal, Anda dapat melakukan failover secara manual untuk menjadikan replika sekunder Anda sebagai server utama. Untuk melakukan failover secara manual, Anda menghentikan proses replikasi, sehingga replika baca dipromosikan menjadi server baca-tulis. Karena replikasi asinkron, failover dapat mengakibatkan kehilangan data. Aplikasi Anda perlu terhubung ke server utama baru, dan Anda bertanggung jawab atas konfigurasi ulang aplikasi.
Diagram terdiri dari wilayah utama, wilayah sekunder, dan aplikasi berlabel ikon. X di dalam lingkaran di atas server utama di wilayah utama mewakili kegagalan di wilayah ini. Panah utuh menunjuk dari ikon aplikasi ke server utama hasil failover di 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 kinerja dan mendukung basis pengguna berskala besar yang tersebar secara geografis.
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 yang dipasangkan 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 membuatnya, tetapi yang terbaik adalah menggunakan nilai yang sama atau lebih besar untuk memastikan bahwa replika dapat mengikuti perubahan di sumber.
Memantau lag replikasi: Proses replikasi asinkron memerlukan jeda replikasi, yang dapat bervariasi tergantung pada beberapa 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.
HA: Replika baca tidak dapat menggunakan HA, dan ketika dialihkan melalui failover menjadi server utama, replika tersebut juga tidak memiliki HA. Anda bertanggung jawab untuk mengonfigurasi HA setelah 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.
Konfigurasikan dukungan multiregion
Buat replika baca: Untuk mempelajari cara membuat replika baca, lihat artikel berikut ini:
portal Azure: Cara membuat dan mengelola replika baca di server fleksibel Azure Database for MySQL dengan menggunakan portal Azure
Anda dapat mengonfigurasi replika setelah membuat server sumber hanya jika server sumber berjalan dan dapat dijangkau.
Hentikan replikasi: Untuk mempelajari cara menghentikan replikasi, lihat Menghentikan replikasi ke server replika.
Menghapus replika baca: Untuk mempelajari cara menghapus replika baca, lihat Menghapus server replika.
Perilaku ketika semua wilayah sehat
Bagian ini menjelaskan apa yang akan terjadi saat Anda mengonfigurasi server dengan replika baca di wilayah lain, dan semua wilayah berfungsi normal:
Perutean lalu lintas antar wilayah: Selama 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 beberapa 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 akan terjadi saat Anda mengonfigurasi server untuk dukungan replika baca lintas wilayah, dan wilayah utama mengalami gangguan.
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 terjadi kegagalan wilayah.
Failover mengharuskan Anda untuk mengambil langkah-langkah berikut:
Hentikan replikasi. Prosedur ini tidak dapat diubah, dan server tidak dapat dibuat menjadi replika lagi. Proses ini mengakibatkan kehilangan data. Untuk informasi selengkapnya tentang implikasi tindakan ini, lihat Menghentikan replikasi.
Konfigurasi ulang aplikasi Anda untuk menggunakan server utama 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 dua menit setelah Anda memicu tindakan. Anda bertanggung jawab untuk mengonfigurasi ulang aplikasi Anda untuk terhubung ke server utama baru. 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 fail over pada replika baca agar menjadi server utama, HA tidak diaktifkan pada server tersebut. Anda harus mengaktifkan HA secara manual atau menyertakannya dalam otomatisasi Anda.
Pemulihan wilayah
Saat wilayah pulih, Anda bertanggung jawab atas aktivitas failback 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 memerlukan waktu henti aplikasi yang kira-kira sama dengan lag replikasi.
Lakukan failover dan terima hilangnya data yang tidak direplikasi.
Ingatlah 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 replika baca secara teratur untuk memastikan bahwa proses Anda valid dan kemampuan memenuhi persyaratan tujuan waktu pemulihan (RTO) dan RPO Anda.
Anda dapat mengalihkan replika baca untuk menjadi server utama kapan saja, bahkan saat semua wilayah dalam kondisi normal. Kami menyarankan agar Anda melakukan pengujian ini di lingkungan nonproduksi karena dapat menyebabkan kehilangan data dan memerlukan failback manual.
Sebagai bagian dari strategi DR Anda, jalankan latihan pemulihan penuh secara teratur. Latihan ini mencakup validasi data, pengujian fungsionalitas aplikasi, dan prosedur putar kembali yang didokumenkan.
Pencadangan dan pemulihan
Azure Database for MySQL secara otomatis mencadangkan data Anda, sehingga Anda dapat memulihkannya ke titik waktu mana pun dalam periode retensi cadangan. Perlindungan ini membantu Anda menghindari kerusakan dan penghapusan data yang tidak disengaja. Microsoft sepenuhnya mengelola cadangan tanpa mengganggu ketersediaan server. Cadangan mencakup baik cadangan penuh maupun cadangan log transaksi.
Penyimpanan cadangan: Jika Anda mengonfigurasi server dengan HA redundansi zona, sistem menyimpan cadangan di ZRS. Untuk server yang dikonfigurasi tanpa HA atau dengan HA redundansi lokal, sistem menyimpan cadangan dalam LRS.
Di wilayah Azure yang memiliki pasangan, Anda dapat mengonfigurasi penyimpanan geo-redundan (GRS) untuk cadangan saat Anda membuat server. Pendekatan ini mereplikasi cadangan ke wilayah berpasangan Azure untuk perlindungan tambahan terhadap kegagalan wilayah. Sistem mereplikasi cadangan secara asinkron.
Periode retensi cadangan default adalah 7 hari, tetapi Anda dapat memperpanjang retensi hingga 35 hari. Semua cadangan dienkripsi.
Pulihkan: Pemulihan ke titik waktu tertentu (PITR) memungkinkan Anda memulihkan database Anda ke titik waktu mana pun dalam periode retensi cadangan. Proses pemulihan membuat server database baru dengan nama server baru yang disediakan pengguna. Anda dapat menggunakan server baru as-is atau menyalin data darinya.
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.
Gunakan kemampuan ini 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 bahwa 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 dengan waktu henti nyaris nol. Jika HA diaktifkan pada server Anda dan memenuhi kriteria kelayakan lainnya, operasi pemeliharaan biasanya selesai dalam waktu 10 hingga 30 detik. Jika Anda mengaktifkan ketersediaan tinggi (HA), proses pemeliharaan biasanya menggunakan pembaruan bergilir untuk meminimalkan waktu henti. Aktivitas pemeliharaan berkala seperti peningkatan versi minor dilakukan pada replika siaga terlebih dahulu. Untuk mengurangi waktu henti, server siaga dipromosikan ke primer sehingga beban kerja dapat terus berjalan saat tugas pemeliharaan diterapkan pada simpul yang tersisa. Urutan ini berlaku baik server Anda menggunakan jenis HA dengan redundansi zona maupun redundansi lokal. 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.
Menerapkan logika pengulangan. 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 Ketahanan terhadap kesalahan sementara.
Aktifkan pemeliharaan Virtual Canary pada server pengembangan dan pengujian. Pemeliharaan Virtual Canary menyediakan akses awal ke pembaruan. Dengan mengaktifkannya pada server pengembangan dan pengujian, Anda dapat memverifikasi bahwa pembaruan mendatang tidak memengaruhi beban kerja Anda 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 dikonfigurasi dengan ketersediaan tinggi dengan redundansi zona.
- Server dikonfigurasi dengan ketersediaan tinggi redundan lokal.
- Server yang dikonfigurasi tanpa HA.