Ringkasan kelangsungan bisnis dengan Azure Database for MySQL - Server Fleksibel

  • Artikel

BERLAKU UNTUK: Azure Database for MySQL - Server Fleksibel

Server fleksibel Azure Database for MySQL memungkinkan kemampuan kelangsungan bisnis yang melindungi database Anda jika terjadi pemadaman yang direncanakan dan tidak direncanakan. Fitur seperti pencadangan otomatis dan ketersediaan tinggi membahas berbagai tingkat perlindungan kesalahan dengan waktu pemulihan yang berbeda dan pencahayaan kehilangan data. Saat Anda merancang aplikasi Anda untuk melindungi dari kesalahan, Anda harus mempertimbangkan tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) untuk setiap aplikasi. RTO adalah toleransi waktu henti dan RPO adalah toleransi kehilangan data setelah gangguan pada layanan database.

Tabel berikut mengilustrasikan fitur yang ditawarkan server fleksibel Azure Database for MySQL.

Fitur Keterangan Pembatasan
Microsoft Azure Backup & Pemulihan Layanan ini secara otomatis melakukan pencadangan harian file database Anda dan terus mencadangkan log transaksi. Pencadangan dapat dipertahankan untuk periode apa pun antara 1 hingga 35 hari. Anda dapat memulihkan server database Anda ke titik waktu mana pun dalam periode retensi cadangan Anda. Waktu pemulihan tergantung pada ukuran data yang akan dipulihkan + waktu untuk melakukan pemulihan log. Lihat Konsep - Microsoft Azure Backup dan Pemulihan untuk detail selengkapnya. Data Microsoft Azure Backup tetap berada di dalam wilayah
Pencadangan lokal yang redundan Cadangan layanan disimpan secara otomatis dan aman di penyimpanan redundan lokal dalam suatu wilayah dan di zona ketersediaan yang sama. Cadangan yang redundan secara lokal mereplikasi file data cadangan server tiga kali dalam satu lokasi fisik di wilayah utama. Penyimpanan cadangan yang berlebihan secara lokal menyediakan setidaknya 99.999999999%(11 sembilan) ketahanan objek selama tahun tertentu. Lihat Konsep - Microsoft Azure Backup dan Pemulihan untuk detail selengkapnya. Berlaku di semua wilayah
Cadangan geo-redundan Cadangan layanan dapat dikonfigurasi sebagai geo-redundan pada waktu pembuatan. Mengaktifkan Geo-redundansi akan mereplikasi file data cadangan server di wilayah utama yang dipasangkan untuk memberikan ketahanan regional. Penyimpanan cadangan geo-redundan menyediakan setidaknya 99,99999999999999% (16 angka sembilan) ketahanan objek selama tahun tertentu. Lihat Konsep - Microsoft Azure Backup dan Pemulihan untuk detail selengkapnya. Tersedia di semua wilayah berpasangan Azure
Ketersediaan tinggi dengan redundansi zona Layanan ini dapat disebarkan dalam mode ketersediaan tinggi, yang menyebarkan server utama dan siaga di dua zona ketersediaan yang berbeda dalam suatu wilayah. Ketersediaan tinggi zona redundan melindungi dari kegagalan tingkat zona dan juga membantu mengurangi waktu henti aplikasi selama peristiwa waktu henti yang direncanakan dan tidak direncanakan. Data dari server utama direplikasi secara sinkron ke replika siaga. Selama kejadian waktu henti, server database secara otomatis gagal ke replika siaga. Lihat Konsep - Ketersediaan tinggi untuk detail lebih lanjut. Didukung di tingkat komputasi tujuan umum dan Penting bagi Bisnis. Ketersediaan tinggi hanya didukung di wilayah tempat beberapa zona tersedia.
Berbagi file Premium File database disimpan dalam berbagi file premium Azure yang sangat tahan lama dan andal yang menyediakan redundansi data dengan tiga salinan replika yang disimpan dalam zona ketersediaan dengan kemampuan pemulihan data otomatis. Lihat Berbagi File Premium untuk detail selengkapnya. Data yang disimpan dalam zona ketersediaan

Mitigasi waktu henti terencana

Berikut adalah beberapa skenario pemeliharaan terencana yang mengalami waktu henti:

Skenario Proses
Penskalaan komputasi (Pengguna) Ketika Anda melakukan operasi penskalaan komputasi, server fleksibel baru disediakan menggunakan konfigurasi komputasi berskala. Di server database yang ada, titik pemeriksaan aktif diizinkan untuk diselesaikan, koneksi klien digunakan, setiap transaksi yang tidak terikat dibatalkan, dan kemudian dimatikan. Penyimpanan kemudian dilampirkan ke server baru dan database dimulai, yang melakukan pemulihan jika perlu sebelum menerima koneksi klien.
Penyebaran Perangkat Lunak Baru (Azure) Peluncuran fitur baru atau perbaikan bug secara otomatis terjadi sebagai bagian dari pemeliharaan terencana layanan dan Anda dapat menjadwalkan kapan aktivitas tersebut terjadi. Untuk informasi lebih lanjut, lihat dokumentasi, dan juga periksa portal Anda
Peningkatan versi minor (Azure) Server fleksibel Azure Database for MySQL secara otomatis menambal server database ke versi minor yang ditentukan oleh Azure. Proses ini terjadi sebagai bagian dari pemeliharaan yang direncanakan layanan. Ini akan dikenakan waktu henti singkat dalam hal detik, dan server database secara otomatis dimulai ulang dengan versi minor baru. Untuk informasi lebih lanjut, lihat dokumentasi, dan juga periksa portal Anda.

Ketika server fleksibel dikonfigurasi dengan zona ketersediaan tinggi berlebihan, server fleksibel melakukan operasi pada server siaga terlebih dahulu dan kemudian di server utama tanpa kegagalan. Lihat Konsep - Ketersediaan tinggi untuk detail lebih lanjut.

Mitigasi waktu henti tidak terencana

Waktu henti yang tidak direncanakan dapat terjadi sebagai akibat dari kegagalan yang tidak terduga, termasuk kesalahan perangkat keras yang mendasarinya, masalah jaringan, dan bug perangkat lunak. Jika server database turun secara tiba-tiba, jika dikonfigurasi dengan ketersediaan tinggi [HA], maka replika siaga diaktifkan. Jika tidak, maka server database baru secara otomatis disediakan. Meskipun waktu henti yang tidak diencana tidak dapat dihindari, server fleksibel mengurangi waktu henti dengan secara otomatis melakukan operasi pemulihan di server database dan lapisan penyimpanan tanpa memerlukan intervensi manusia.

Waktu henti yang tidak direncanakan: skenario kegagalan dan pemulihan layanan

Berikut adalah beberapa skenario kegagalan yang tidak direncanakan dan proses pemulihan:

Skenario Proses pemulihan [non-HA] Proses pemulihan [HA]
Kegagalan server database Jika server database mati karena beberapa kesalahan perangkat keras yang mendasarinya, koneksi aktif dijatuhkan, dan setiap transaksi dalam pesawat dibatalkan. Azure mencoba menghidupkan ulang server database. Jika itu berhasil, maka pemulihan database dilakukan. Jika hidupkan ulang gagal, mulai ulang server database dicoba pada simpul fisik lain.

Waktu pemulihan (RTO) tergantung pada berbagai faktor termasuk aktivitas pada saat kesalahan seperti transaksi besar dan jumlah pemulihan yang akan dilakukan selama proses startup server database. RPO adalah nol karena tidak ada kehilangan data yang diharapkan untuk transaksi yang dilakukan. Aplikasi yang menggunakan database MySQL perlu dibangun dengan cara yang mereka deteksi dan coba lagi koneksi yang dijatuhkan dan transaksi yang gagal. Ketika aplikasi mencoba kembali, koneksi diarahkan ke server database yang baru dibuat.

Opsi lain yang tersedia dipulihkan dari cadangan. Anda dapat menggunakan PITR atau pemulihan Geo dari wilayah yang dipasangkan.
PITR : RTO: Bervariasi, RPO=0sec
Pemulihan Geo : RTO: Bervariasi RPO <1 jam.

Anda juga dapat menggunakan replika pembacaan sebagai solusi DR. Anda dapat menghentikan replikasi, yang membuat replika baca-tulis (mandiri lalu mengalihkan lalu lintas aplikasi ke database ini). RTO dalam banyak kasus adalah beberapa menit dan RPO < 1 jam. RTO dan RPO dapat jauh lebih tinggi dalam beberapa kasus tergantung pada berbagai faktor termasuk latensi antara situs, jumlah data yang akan ditransmisikan, dan yang penting beban kerja penulisan database utama.		 Jika kegagalan server database atau kesalahan yang tidak dapat dipulihkan terdeteksi, server database siaga diaktifkan, sehingga mengurangi waktu henti. Lihat halaman konsep KETERSEDIAAN TINGGI untuk detail selengkapnya. RTO diharapkan menjadi 60-120 detik, dengan RPO=0.

Catatan: Opsi untuk proses Pemulihan [non-HA] juga berlaku di sini.
Kegagalan penyimpanan Aplikasi tidak melihat dampak apa pun untuk masalah terkait penyimpanan seperti kegagalan disk atau kerusakan blok fisik. Karena data disimpan dalam tiga salinan, salinan data dilayani oleh penyimpanan yang masih ada. Kerusakan blok akan otomatis diperbaiki. Jika salinan data hilang, salinan data baru akan dibuat secara otomatis.

Dalam skenario yang jarang terjadi atau kasus terburuk jika semua salinan rusak, kita dapat menggunakan pemulihan dari pemulihan Geo (wilayah yang dipasangkan). RPO akan menjadi < 1 jam dan RTO akan bervariasi.

Anda juga dapat menggunakan replika pembacaan sebagai solusi DR seperti yang dijelaskan di atas.		 Untuk skenario ini, opsi sama dengan proses Pemulihan [non-HA] .
Kesalahan logika/pengguna Pemulihan dari kesalahan pengguna, seperti tabel yang dijatuhkan secara tidak sengaja atau data yang salah diperbarui, melibatkan operasi pemulihan point-in-time (PITR), dengan memulihkan dan memulihkan data hingga waktu tepat sebelum kesalahan terjadi.

Anda dapat memulihkan sumber daya server fleksibel yang dihapus dalam waktu lima hari sejak penghapusan server. Untuk panduan terperinci tentang cara memulihkan server yang dihapus, [lihat langkah-langkah terdokumentasi] (../flexible-server/how-to-restore-dropped-server.md). Untuk melindungi sumber daya server pasca penyebaran dari penghapusan yang tidak disengaja atau perubahan tak terduga, administrator dapat menggunakan kunci manajemen.		 Kesalahan pengguna ini tidak dilindungi dengan high availability karena semua operasi pengguna juga direplikasi ke siaga. Untuk skenario ini, opsi sama dengan proses Pemulihan [non-HA]
Kegagalan zona ketersediaan Meskipun ini merupakan peristiwa yang jarang terjadi, jika Anda ingin memulihkan dari kegagalan tingkat zona, Anda dapat melakukan pemulihan Geo dari ke wilayah yang dipasangkan. RPO akan menjadi <1 jam dan RTO akan bervariasi.

Anda juga dapat menggunakan replika pembacaan sebagai solusi DR dengan membuat replika di zona ketersediaan lain. RTO\RPO seperti yang dijelaskan di atas.		 Jika Anda telah mengaktifkan ketersediaan tinggi zona redundan, server fleksibel melakukan failover otomatis ke situs siaga. Lihat konsep high availability untuk detail selengkapnya. RTO diharapkan menjadi 60-120 detik, dengan RPO=0.

Opsi lain yang tersedia dipulihkan dari cadangan. Anda dapat menggunakan PITR atau pemulihan Geo dari wilayah yang dipasangkan.
PITR : RTO: Bervariasi, RPO=0 detik
Pemulihan Geografis : RTO: Bervariasi, RPO <1 jam

Catatan:Jika Anda mengaktifkan KETERSEDIAAN TINGGI zona yang sama, opsinya sama dengan untuk proses Pemulihan [non-HA].
Kegagalan wilayah Meskipun ini adalah peristiwa yang jarang terjadi, jika Anda ingin memulihkan dari kegagalan tingkat wilayah, Anda dapat melakukan pemulihan database dengan membuat server baru menggunakan cadangan geo-redundan terbaru yang tersedia di bawah langganan yang sama untuk mendapatkan data terbaru. Server fleksibel baru disebarkan ke wilayah yang dipilih. Waktu yang diambil untuk memulihkan tergantung pada cadangan sebelumnya dan jumlah log transaksi untuk pulih. RPO dalam banyak kasus akan menjadi <1 jam dan RTO akan bervariasi. Untuk skenario ini, opsi sama dengan proses Pemulihan [non-HA] .

Persyaratan dan Batasan

Residensi Data Wilayah

Secara default, server fleksibel Azure Database for MySQL tidak memindahkan atau menyimpan data pelanggan ke luar wilayah tempat data disebarkan. Namun, pelanggan dapat secara opsional memilih untuk mengaktifkan cadangan geo-redundan atau menyiapkan replikasi lintas wilayah untuk menyimpan data di wilayah lain.

Langkah berikutnya