Bagikan melalui

Gambaran umum kelangsungan bisnis dengan Azure Database for MariaDB

  • Artikel

Penting

Azure Database for MariaDB berada di jalur penghentian. Kami sangat menyarankan Anda bermigrasi ke Azure Database for MySQL. Untuk informasi selengkapnya tentang migrasi ke Azure Database for MySQL, lihat Apa yang terjadi pada Azure Database for MariaDB?.

Artikel ini menjelaskan kemampuan yang disediakan Azure Database for MariaDB 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 apa yang harus dilakukan saat kesalahan pengguna atau kesalahan aplikasi memengaruhi integritas data, wilayah Azure mengalami pemadaman, atau aplikasi Anda memerlukan pemeliharaan.

Fitur untuk kelangsungan bisnis

Saat Anda mengembangkan rencana kelangsungan bisnis, Anda perlu memahami:

  • Tujuan waktu pemulihan (RTO): Waktu maksimum yang dapat diterima sebelum aplikasi sepenuhnya pulih setelah peristiwa yang mengganggu.
  • Tujuan titik pemulihan (RPO): Jumlah maksimum pembaruan data terbaru (interval waktu) yang dapat ditoleransi aplikasi akan hilang saat pulih setelah peristiwa yang mengganggu.

Azure Database for MariaDB menyediakan fitur kelangsungan bisnis dan pemulihan bencana yang mencakup pencadangan geo-redundan dengan kemampuan untuk memulai pemulihan geografis, dan menyebarkan replika baca di wilayah lain. Masing-masing memiliki karakteristik yang berbeda untuk waktu pemulihan dan potensi kehilangan data.

Dengan pemulihan geografis, Azure Database for MariaDB membuat server baru dengan menggunakan data cadangan yang direplikasi dari wilayah lain. Waktu keseluruhan untuk memulihkan dan memulihkan tergantung pada ukuran database dan jumlah data log yang akan dipulihkan. Waktu keseluruhan untuk membuat server bervariasi berkisar dari menit hingga jam.

Dengan replika baca, log transaksi dari database utama dialirkan secara asinkron ke replika. Jika ada pemadaman database utama karena kesalahan tingkat zona atau tingkat wilayah, failover ke replika memberikan RTO yang lebih pendek dan mengurangi kehilangan data.

Catatan

Jeda antara database utama dan replika tergantung pada latensi antara situs, jumlah data yang akan ditransmisikan, dan (yang paling penting) beban kerja tulis server utama. Beban kerja tulis yang berat dapat menghasilkan jeda yang signifikan.

Karena sifat asinkron dari replikasi yang digunakan untuk replika baca, jangan pertimbangkan replika baca sebagai solusi ketersediaan tinggi. Jeda yang lebih tinggi dapat berarti RTO dan RPO yang lebih tinggi. Replika baca dapat bertindak sebagai alternatif ketersediaan tinggi hanya untuk beban kerja di mana jeda tetap lebih kecil melalui waktu puncak dan di luar puncak. Jika tidak, replika baca ditujukan untuk skala baca yang sebenarnya untuk beban kerja baca-berat dan untuk skenario 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 kurang dari 15 menit		 Titik pemulihan apa pun dalam periode retensi
RTO bervariasi
RPO kurang dari 15 menit		 Titik pemulihan apa pun dalam periode retensi
RTO bervariasi
RPO kurang dari 15 menit
Geo-pemulihan dari cadangan yang direplikasi secara geografis Tidak didukung RTO bervariasi
RPO lebih besar dari 24 jam		 RTO bervariasi
RPO lebih besar dari 24 jam
Replika baca RTO adalah menit
RPO kurang dari 5 menit		 RTO adalah menit
RPO kurang dari 5 menit		 RTO adalah menit
RPO kurang dari 5 menit

RTO dan RPO bisa jauh lebih tinggi dalam beberapa kasus, tergantung pada faktor-faktor seperti latensi antara situs, jumlah data yang akan dikirimkan, dan beban kerja tulis database utama.

Pemulihan server setelah kesalahan pengguna atau aplikasi

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

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 Anda konfigurasi 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

Anda hanya dapat memulihkan server yang dihapus dalam waktu lima hari setelah penghapusan. Setelah lima hari, cadangan dihapus. Anda dapat mengakses dan memulihkan cadangan database hanya dari langganan Azure yang menghosting server. Untuk memulihkan server yang dihilangkan, lihat langkah-langkah yang didokumen. Untuk melindungi sumber daya server dari penghapusan tidak disengaja atau perubahan tidak terduga pasca penyebaran, administrator dapat memanfaatkan kunci manajemen.

Pemulihan dari pemadaman pusat data regional Azure

Meskipun jarang terjadi, pusat data Azure dapat mengalami pemadaman. Ketika pemadaman terjadi, itu menyebabkan gangguan bisnis yang mungkin hanya berlangsung beberapa menit tetapi dapat berlangsung selama berjam-jam.

Salah satu opsinya adalah menunggu server Anda kembali online ketika pemadaman pusat data berakhir. Ketika pusat data mengalami pemadaman, Anda tidak tahu berapa lama pemadaman mungkin berlangsung. Jadi opsi ini hanya berfungsi untuk aplikasi yang mampu membuat server offline selama beberapa waktu (misalnya, lingkungan pengembangan).

Pemulihan Geo

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

Penting

Pemulihan geografis hanya dimungkinkan jika Anda menyediakan server dengan penyimpanan cadangan geo-redundan. Jika Anda ingin beralih dari cadangan redundan secara lokal ke geo-redundan untuk server yang ada, Anda harus membuat cadangan server yang ada dengan menggunakan mysqldump. Kemudian, pulihkan ke server yang baru dibuat yang dikonfigurasi dengan cadangan geo-redundan.

Replika baca lintas wilayah

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

FAQ

Di mana Azure Database for MariaDB menyimpan data pelanggan?

Secara default, Azure Database for MariaDB tidak memindahkan atau menyimpan data pelanggan dari wilayah tempat data disebarkan. Namun, Anda dapat secara opsional memilih untuk mengaktifkan cadangan geo-redundan atau membuat replika baca lintas wilayah untuk menyimpan data di wilayah lain.

Langkah berikutnya