Bagikan melalui

Ringkasan kelangsungan bisnis dengan Azure Database for MySQL-Server tunggal

  • Artikel

BERLAKU UNTUK: Azure Database for MySQL - Server Tunggal

Penting

Server tunggal Azure Database for MySQL berada di jalur penghentian. Kami sangat menyarankan Agar Anda meningkatkan ke server fleksibel Azure Database for MySQL. Untuk informasi selengkapnya tentang migrasi ke server fleksibel Azure Database for MySQL, lihat Apa yang terjadi pada Server Tunggal Azure Database for MySQL?

Artikel ini menjelaskan kemampuan yang disediakan Azure Database for MySQL untuk kelangsungan bisnis dan pemulihan bencana. Pelajari tentang pemulihan dari peristiwa mengganggu yang dapat menyebabkan kehilangan data atau menyebabkan database dan aplikasi Anda menjadi tidak tersedia. Pelajari tindakan yang harus dilakukan saat kesalahan pengguna atau aplikasi memengaruhi integritas data, wilayah Azure mengalami pemadaman, atau aplikasi Anda memerlukan pemeliharaan.

Fitur yang bisa Anda gunakan untuk menyediakan kelangsungan bisnis

Saat Anda mengembangkan rencana kelangsungan bisnis, Anda perlu memahami waktu maksimum yang dapat diterima sebelum aplikasi pulih sepenuhnya setelah peristiwa yang mengganggu - ini adalah Tujuan Waktu Pemulihan (RTO) Anda. Anda juga perlu memahami jumlah maksimum pembaruan data terbaru (interval waktu) aplikasi dapat mentolerir kehilangan saat pulih setelah peristiwa yang mengganggu - ini adalah Tujuan Titik Pemulihan (RPO) Anda.

Server tunggal Azure Database for MySQL menyediakan fitur kelangsungan bisnis dan pemulihan bencana yang mencakup cadangan geo-redundan dengan kemampuan untuk memulai pemulihan geografis, dan menyebarkan replika baca di wilayah yang berbeda. Masing-masing memiliki karakteristik yang berbeda untuk waktu pemulihan dan potensi kehilangan data. Dengan fiturGeo-restore, server baru dibuat menggunakan data cadangan yang direplikasi dari wilayah lain. Waktu keseluruhan yang diperlukan untuk pemulihan dan pulih total tergantung ukuran database dan jumlah log yang akan dipulihkan. Waktu keseluruhan untuk membuat server bervariasi berkisar dari menit hingga jam. Dengan replika baca, log transaksi dari primer dialirkan ke replika secara asinkron. Jika terjadi pemadaman database utama karena kesalahan tingkat zona atau tingkat wilayah, pengalihan ke replika memberikan RTO yang lebih pendek dan mengurangi kehilangan data.

Catatan

Lag antara primer dan replika tergantung pada latensi antarsitus, jumlah data yang akan dikirimkan, dan yang paling penting, beban kerja tulis server utama. Penulisan beban kerja yang berat dapat menimbulkan jeda yang signifikan.

Karena sifat asinkron replikasi yang digunakan untuk replika baca, maka tidak boleh dianggap sebagai solusi Ketersediaan Tinggi (HA) karena semakin lama lag-nya dapat berarti RTO dan RPO yang semakin tinggi. Hanya untuk beban kerja di mana kelambatan tetap lebih kecil melalui waktu puncak dan non-puncak beban kerja, replika baca dapat bertindak sebagai alternatif HA. Jika tidak, replika baca ditujukan untuk skala baca sejati untuk beban kerja berat yang siap dan untuk skenario DR (Pemulihan Bencana).

Tabel berikut membandingkan RTO dan RPO dalam beban kerja umum skenario:

Kemampuan Dasar Tujuan Umum Memori Dioptimalkan
Pemulihan Titik Waktu dari cadangan Titik pemulihan apa pun dalam periode retensi
RTO - Bervariasi
RPO < 15 mnt		 Titik pemulihan apa pun dalam periode retensi
RTO - Bervariasi
RPO < 15 mnt		 Titik pemulihan apa pun dalam periode retensi
RTO - Bervariasi
RPO < 15 mnt
Geo-pemulihan dari cadangan yang direplikasi secara geografis Tidak didukung RTO - Bervariasi
RPO < 1 j		 RTO - Bervariasi
RPO < 1 j
Replika baca RTO - Menit*
RPO < 5 mnt*		 RTO - Menit*
RPO < 5 mnt*		 RTO - Menit*
RPO < 5 mnt*

* RTO dan RPO bisa jauh lebih tinggi dalam beberapa kasus bergantung pada berbagai faktor termasuk latensi antar situs, jumlah data yang akan dikirim, dan yang terpenting beban kerja penulisan database utama.

Memulihkan server setelah kesalahan pengguna atau aplikasi

Anda dapat menggunakan cadangan layanan untuk memulihkan server dari berbagai peristiwa yang mengganggu. Pengguna mungkin tidak sengaja menghapus beberapa data, tidak sengaja menghilangkan tabel penting, atau bahkan menghapus seluruh database. Suatu aplikasi mungkin tidak sengaja menimpa data baik dengan data buruk karena cacat aplikasi, dan sebagainya.

Anda dapat memulihkan titik waktu untuk membuat salinan server ke titik waktu yang baik yang diketahui. Titik waktu ini harus berada dalam periode retensi cadangan yang telah dikonfigurasi untuk server Anda. Setelah data dipulihkan ke server baru, Anda dapat mengganti server asli dengan server yang baru dipulihkan atau menyalin data yang diperlukan dari server yang dipulihkan ke server asli.

Penting

Server yang dihapus hanya dapat dipulihkan dalamlima hari setelah penghapusan, setelah cadangan dihapus. Cadangan basis data dapat diakses dan dipulihkan hanya dari langganan Azure yang menghosting server. Untuk memulihkan server yang dihapus, lihatlangkah-langkah yang didokumentasikan. Untuk melindungi sumber daya server, setelah penyebaran, dari penghapusan tak disengaja atau perubahan tak terduga, admin dapat memanfaatkan manajemen kunci.

Pulihkan dari pemadaman pusat data regional Azure

Meskipun jarang, pusat data Azure dapat mengalami pemadaman. Ketika pemadaman terjadi, akan menyebabkan gangguan bisnis yang mungkin hanya berlangsung beberapa menit atau bisa juga berjam-jam.

Salah satu opsinya adalah menunggu server Anda kembali daring saat pemadaman pusat data berakhir. Ini berfungsi untuk aplikasi yang mampu memiliki server offline selama jangka waktu tertentu, misalnya lingkungan pengembangan. Ketika pusat data mengalami pemadaman, Anda tidak tahu berapa lama pemadaman akan berlangsung, jadi opsi ini hanya berfungsi jika Anda tidak memerlukan server untuk sementara waktu.

Pemulihan Geo

Fitur pemulihan geografis memulihkan server menggunakan cadangan geo-redundan. Cadangan di-hosting di wilayah berpasangan server Anda. Cadangan ini dapat diakses bahkan ketika wilayah tempat server Anda dihosting sedang luring. Anda dapat memulihkan dari cadangan ini ke wilayah lain dan membawa server Anda kembali daring. Pelajari selengkapnya tentang pemulihan geografis di artikel konsep pencadangan dan pemulihan.

Penting

Pemulihan geo hanya dimungkinkan jika Anda memprovisikan server dengan penyimpanan cadangan geo-redundan. Jika ingin beralih dari pencadangan redundan lokal ke geo-redundan untuk server yang ada, Anda harus mengambil cadangan menggunakan mysqldump dari server yang ada dan memulihkannya ke server yang baru dibuat, yang dikonfigurasi dengan cadangan geo-redundan.

Replika baca lintas wilayah

Anda bisa menggunakan replika baca lintas wilayah untuk meningkatkan kelangsungan bisnis dan perencanaan pemulihan bencana Anda. Replika baca diperbarui secara asinkron menggunakan teknologi replikasi log biner MySQL. Pelajari selengkapnya tentang replika baca, wilayah yang tersedia, dan cara mengalihkan dari artikel konsep replika baca.

FAQ

Di mana Azure Database for MySQL menyimpan data pelanggan?

Secara default, Azure Database for MySQL tidak memindahkan atau menyimpan data pelanggan ke luar wilayah penyebaran data. Akan tetapi, pelanggan dapat memilih untuk mengaktifkan cadangan geo-redundan atau membuat replika baca lintas wilayah untuk menyimpan data di wilayah lain.

Langkah berikutnya