Bagikan melalui

Cadangkan dan pulihkan di Azure Database for MySQL

  • 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?

Azure Database for MySQL secara otomatis membuat cadangan server dan menyimpannya di penyimpanan redundan atau geo-redundan yang dikonfigurasikan pengguna secara lokal. Cadangan dapat digunakan untuk memulihkan server Anda ke titik waktu. Pencadangan dan pemulihan adalah bagian penting dari strategi kelangsungan bisnis apa pun karena melindungi data Anda dari kerusakan atau penghapusan yang tidak disengaja.

Pencadangan

Azure Database for MySQL mengambil cadangan berkas data dan log transaksi. Cadangan ini memungkinkan Anda memulihkan server ke titik waktu tertentu dalam periode retensi cadangan yang dikonfigurasikan. Periode retensi cadangan default adalah 7 hari. Anda dapat mengonfigurasikannya secara opsional hingga 35 hari. Semua cadangan dienkripsi menggunakan enkripsi AES-256 bit.

Berkas cadangan ini tidak terekspos pengguna dan tak bisa diekspor. Cadangan ini hanya dapat digunakan untuk memulihkan operasi di Azure Database for MySQL. Anda dapat menggunakan mysqldump untuk menyalin database.

Jenis dan frekuensi cadangan tergantung pada penyimpanan backend untuk server.

Jenis dan frekuensi cadangan

Server penyimpanan dasar

Penyimpanan Dasar adalah penyimpanan backend yang mendukungserver tingkat dasar. Cadangan pada server penyimpanan dasar ini berbasis rekam jepret. Rekam jepret database lengkap dilakukan setiap hari. Tidak ada pencadangan diferensial yang dilakukan untuk server penyimpanan dasar dan semua pencadangan rekam jepret hanya pencadangan berbasis data lengkap.

Cadangan log transaksi terjadi setiap lima menit.

Penyimpanan tujuan umum server v1 (mendukung penyimpanan hingga 4 TB)

Penyimpanan tujuan umum adalah penyimpanan backend yang mendukung Tujuan Umum dan server tingkat Yang Dioptimalkan Memori. Untuk server dengan penyimpanan tujuan umum hingga 4 TB, pencadangan penuh terjadi sekali setiap minggu. Pencadangan diferensial terjadi dua kali sehari. Cadangan log transaksi terjadi setiap lima menit. Pencadangan pada penyimpanan tujuan umum hingga penyimpanan 4-TB tidak berbasis rekam jepret dan mengonsumsi bandwidth IO pada saat pencadangan. Untuk database besar (> 1 TB) pada penyimpanan 4-TB, kami merekomendasikan Anda untuk mempertimbangkan

  • Penyediaan lebih banyak IOP untuk memperhitungkan IO cadangan ATAU
  • Atau, migrasikan ke penyimpanan tujuan umum yang mendukung penyimpanan hingga 16 TB jika infrastruktur penyimpanan yang mendasarinya tersedia di wilayah Azure pilihan Anda. Tidak ada biaya tambahan untuk penyimpanan tujuan umum yang mendukung penyimpanan hingga 16-TB. Untuk bantuan tentang migrasi ke penyimpanan 16-TB, silakan buka tiket dukungan dari portal Microsoft Azure.

Penyimpanan tujuan umum server v2 (mendukung penyimpanan hingga 16 TB)

Dalam subset wilayah Azure, semua server yang baru disediakan dapat mendukung penyimpanan hingga 16 TB. Dengan kata lain, penyimpanan hingga penyimpanan 16 TB adalah penyimpanan tujuan umum default untuk semua wilayah yang didukungnya. Pencadangan pada server penyimpanan 16-TB ini berbasis rekam jepret. Pencadangan rekam jepret pertama dijadwalkan segera setelah server dibuat. Pencadangan rekam jepret diambil setiap hari sekali. Cadangan log transaksi terjadi setiap lima menit.

Untuk informasi lebih lanjut tentang penyimpanan tujuan Dasar dan Umum, lihat dokumentasi penyimpanan.

Retensi Pencadangan

Pencadangan dipertahankan berdasarkan setelan periode penyimpanan cadangan pada server. Anda dapat memilih periode retensi 7 hingga 35 hari. Periode retensi default adalah 7 hari. Anda dapat mengatur periode retensi selama pembuatan server atau yang lebih baru dengan memperbarui konfigurasi cadangan menggunakan portal Microsoft Azure atau Azure CLI.

Periode retensi cadangan mengatur seberapa jauh pemulihan titik waktu dapat diambil, karena didasarkan pada cadangan yang tersedia. Periode retensi cadangan juga dapat diperlakukan sebagai jendela pemulihan dari perspektif pemulihan. Semua cadangan yang diperlukan untuk melakukan pemulihan titik waktu dalam periode penyimpanan cadangan dipertahankan dalam penyimpanan cadangan. Misalnya, jika periode retensi cadangan diatur ke 7 hari, jendela pemulihan dianggap 7 hari terakhir. Dalam skenario ini, semua cadangan yang diperlukan untuk memulihkan server dalam 7 hari terakhir dipertahankan. Dengan jendela retensi cadangan selama tujuh hari:

  • Penyimpanan tujuan umum server v1 (mendukung penyimpanan hingga 4 TB) akan menyimpan hingga 2 cadangan database lengkap, semua pencadangan diferensial, dan cadangan log transaksi yang dilakukan sejak pencadangan database lengkap paling awal.
  • Penyimpanan tujuan umum server v2 (mendukung penyimpanan hingga 16 TB) akan menyimpan snapshot database lengkap dan cadangan log transaksi dalam 8 hari terakhir.

Retensi jangka panjang

Retensi cadangan jangka panjang (lebih dari 35 hari) saat ini belum didukung secara asli oleh layanan. Anda memiliki opsi untuk menggunakan mysqldump untuk mengambil cadangan dan menyimpannya untuk retensi jangka panjang. Tim dukungan kami telah membuat blog artikel langkah demi langkah untuk membagikan bagaimana Anda dapat mencapainya.

Opsi redundansi Microsoft Azure Backup

Azure Database for MySQL memberikan fleksibilitas untuk memilih antara penyimpanan cadangan yang redundan secara lokal atau geo-redundan di tingkat Tujuan Umum dan Memori yang Dioptimalkan. Ketika cadangan disimpan dalam penyimpanan cadangan geo-redundan, mereka tidak hanya disimpan di wilayah tempat server Anda dihosting, tetapi juga direplikasi ke pusat data yang dipasangkan. Geo-redundansi ini memberikan perlindungan dan kemampuan yang lebih baik untuk memulihkan server Anda di wilayah yang berbeda jika terjadi bencana. Tingkat Dasar hanya menawarkan penyimpanan cadangan yang berlebihan secara lokal.

Catatan

Untuk wilayah berikut - India Tengah, Prancis Tengah, UAE Utara, Afrika Selatan Utara; Penyimpanan tujuan umum v2 ada di Pratinjau Publik. Jika Anda membuat server sumber di Penyimpanan Tujuan Umum v2 (Mendukung penyimpanan hingga 16 TB) di wilayah yang disebutkan di atas maka mengaktifkan Cadangan Geo-Redundan tidak didukung.

Beralih dari penyimpanan cadangan yang redundan secara lokal ke penyimpanan yang redundan secara geografis

Mengonfigurasi penyimpanan yang redundan secara lokal atau geografis untuk cadangan hanya diizinkan selama pembuatan server. Setelah server disediakan, Anda tidak dapat mengubah opsi redundansi penyimpanan cadangan. Untuk memindahkan penyimpanan cadangan Anda dari penyimpanan redundan secara lokal ke penyimpanan geo-berlebihan, membuat server baru dan memigrasikan data menggunakan dump and restore adalah satu-satunya opsi yang didukung.

Biaya penyimpanan Microsoft Azure Backup

Azure Database for MySQL menyediakan hingga 100 persen dari ukuran penyimpanan server yang tersedia sebagai penyimpanan cadangan tanpa biaya tambahan. Setiap penyimpanan cadangan tambahan yang digunakan dikenakan biaya dalam GB per bulan. Misalnya, jika Anda telah menyediakan server dengan penyimpanan 250 GB, Anda memiliki 250 GB penyimpanan tambahan yang tersedia untuk cadangan server tanpa biaya tambahan. Penyimpanan yang digunakan untuk cadangan lebih dari 250 GB dikenakan biaya sesuai model harga.

Anda dapat menggunakan metrikPenyimpanan Microsoft Azure Backup yang digunakandi Azure Monitor yang tersedia di portal Microsoft Azure untuk memantau penyimpanan cadangan yang digunakan oleh server. Metrik Penyimpanan Microsoft Azure Backup yang digunakan mewakili jumlah penyimpanan yang digunakan oleh semua cadangan database lengkap, pencadangan diferensial, dan pencadangan log yang dipertahankan berdasarkan periode penyimpanan cadangan yang ditetapkan untuk server. Frekuensi pencadangan dikelola layanan dan dijelaskan sebelumnya. Aktivitas transaksional yang berat di server dapat menyebabkan penggunaan penyimpanan cadangan meningkat terlepas dari ukuran total database. Untuk penyimpanan geo-berlebihan, penggunaan penyimpanan cadangan dua kali lipat dari penyimpanan yang berlebihan secara lokal.

Cara utama mengendalikan biaya penyimpanan cadangan adalah dengan menetapkan periode retensi cadangan yang sesuai dan memilih opsi redundansi cadangan yang tepat untuk memenuhi tujuan pemulihan yang Anda inginkan. Anda dapat memilih periode retensi dari kisaran 7 hingga 35 hari. Tujuan Umum dan Memori Server yang Dioptimalkan dapat memilih untuk memiliki penyimpanan geo-redundan untuk cadangan.

Pulihkan

Di Azure Database for MySQL, meakukan pemulihan membuat server baru dari cadangan server asli dan memulihkan semua database yang terkandung dalam server. Pemulihan saat ini tidak didukung jika server asli dalam status berhenti.

Ada dua jenis data lalu lintas yang tersedia:

  • Pemulihan point-in-time tersedia dengan opsi redundansi cadangan dan membuat server baru di wilayah yang sama dengan server asli Anda menggunakan kombinasi pencadangan log transaksi dan penuh.
  • Pemulihan geografis hanya tersedia jika Anda mengkonfigurasi server Anda untuk penyimpanan redundan geografis dan memungkinkan Anda memulihkan server Anda ke wilayah yang berbeda.

Estimasi waktu untuk pemulihan server tergantung pada beberapa faktor:

  • Ukuran database
  • Jumlah log transaksi yang terlibat
  • Jumlah aktivitas yang perlu diputar ulang untuk pulih ke titik pemulihan
  • Bandwidth jaringan jika pemulihan adalah ke wilayah yang berbeda
  • Jumlah permintaan pemulihan bersamaan yang sedang diproses di wilayah target
  • Kehadiran kunci primer dalam tabel dalam database. Untuk pemulihan yang lebih cepat, pertimbangkan untuk menambahkan kunci primer untuk semua tabel dalam database Anda. Untuk memeriksa apakah tabel Anda memiliki kunci primer, Anda bisa menggunakan kueri berikut:
select tab.table_schema as database_name, tab.table_name from information_schema.tables tab left join information_schema.table_constraints tco on tab.table_schema = tco.table_schema and tab.table_name = tco.table_name and tco.constraint_type = 'PRIMARY KEY' where tco.constraint_type is null and tab.table_schema not in('mysql', 'information_schema', 'performance_schema', 'sys') and tab.table_type = 'BASE TABLE' order by tab.table_schema, tab.table_name;

Untuk database besar atau sangat aktif, pemulihan mungkin memakan waktu beberapa jam. Jika ada ketidaktersediaan yang berkepanjangan di suatu wilayah, ada kemungkinan bahwa sejumlah besar permintaan pemulihan geografis akan dimulai untuk pemulihan bencana. Ketika ada banyak permintaan, waktu pemulihan untuk database individu dapat meningkat. Sebagian besar pemulihan database selesai dalam waktu kurang dari 12 jam.

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.

Pemulihan titik waktu

Terlepas dari opsi redundansi cadangan Anda, Anda dapat melakukan pemulihan ke titik waktu mana pun dalam periode penyimpanan cadangan Anda. Server baru dibuat di wilayah Azure yang sama dengan server asli. Ini dibuat dengan konfigurasi server asli untuk tingkat harga, pembuatan komputasi, jumlah vCores, ukuran penyimpanan, periode retensi cadangan, dan opsi redundansi cadangan.

Catatan

Selain itu, setelah operasi pemulihan selesai, ada dua parameter server yang diatur ulang ke nilai default (dan tidak disalin dari server utama) setelah operasi pemulihan

  • time_zone - Nilai ini yang akan diatur ke nilai DEFAULT SISTEM
  • event_scheduler - event_scheduler diatur ke OFF di server yang dipulihkan

Anda perlu mengatur parameter server ini dengan mengonfigurasikan ulang parameter server

Pemulihan point-in-time berguna dalam beberapa skenario. Misalnya, ketika pengguna secara tidak sengaja menghapus data, menjatuhkan tabel atau database penting, atau jika aplikasi secara tidak sengaja menimpa data yang baik dengan data yang buruk karena cacat aplikasi.

Anda mungkin perlu menunggu cadangan log transaksi berikutnya diambil sebelum Anda dapat memulihkan ke titik waktu dalam lima menit terakhir.

Pemulihan Geo

Anda dapat memulihkan server ke wilayah Azure lain tempat layanan tersedia jika Anda telah mengonfigurasikan server Anda untuk pencadangan geo-redundan.

  • Penyimpanan tujuan umum server v1 (mendukung penyimpanan hingga 4 TB) dapat dipulihkan ke wilayah yang dipasangkan secara geografis, atau ke wilayah Azure mana pun yang mendukung Azure Database for MySQL - layanan Server Tunggal.
  • Penyimpanan tujuan umum server v2 (mendukung penyimpanan hingga 16 TB) hanya dapat dipulihkan ke wilayah Azure yang mendukung infrastruktur Penyimpanan tujuan umum server v2. Tinjau tingkat harga Azure Database for MySQL untuk daftar wilayah yang didukung.

Geo-restore adalah opsi pemulihan default ketika server Anda tidak tersedia karena insiden di wilayah tempat server dihosting. Jika insiden skala besar di suatu wilayah mengakibatkan tidak tersedianya aplikasi database Anda, Anda dapat memulihkan server dari cadangan geo-redundan ke server di wilayah lain. Pemulihan-georafis menggunakan cadangan server terbaru. Ada keterlambatan antara ketika cadangan diambil dan ketika direplikasi ke wilayah yang berbeda. Keterlambatan ini bisa sampai satu jam, jadi, jika bencana terjadi, bisa ada kerugian data hingga satu jam.

Penting

Jika pemulihan geografis dilakukan untuk server yang baru dibuat, sinkronisasi cadangan awal mungkin memakan waktu lebih dari 24 jam tergantung pada ukuran data karena waktu salinan cadangan rekam jepret lengkap awal jauh lebih tinggi. Pencadangan rekam jepret berikutnya adalah salinan tambahan dan karenanya pemulihan lebih cepat setelah 24 jam pembuatan server. Jika Anda mengevaluasi pemulihan geografis untuk menentukan RTO Anda, kami sarankan Anda untuk menunggu dan mengevaluasi pemulihan geografis hanya setelah 24 jam pembuatan server untuk perkiraan yang lebih baik.

Selama pemulihan geografis, konfigurasi server yang dapat diubah di antaranya adalah pembuatan komputasi, vCore, periode retensi cadangan, dan opsi redundansi cadangan. Mengubah tingkat harga (Dasar, Tujuan Umum, atau Memori Dioptimalkan) atau ukuran penyimpanan selama pemulihan geografis tidak didukung.

Perkiraan waktu pemulihan tergantung pada beberapa faktor termasuk ukuran database, ukuran log transaksi, bandwidth jaringan, dan jumlah total database yang pulih di wilayah yang sama pada saat yang sama. Waktu pemulihan biasanya kurang dari 12 jam.

Melakukan tugas pasca-pemulihan

Setelah pemulihan dari salah satu mekanisme pemulihan, Anda harus melakukan tugas berikut untuk membuat pengguna dan aplikasi Anda dicadangkan dan dijalankan:

  • Jika server baru dimaksudkan untuk mengganti server asli, alihkan klien dan aplikasi klien ke server baru
  • Pastikan aturan VNet yang sesuai berlaku bagi pengguna untuk tersambung. Aturan ini tidak disalin dari server asli.
  • Pastikan izin tingkat database dan masuk yang sesuai telah diberlakukan
  • Konfigurasikan pemberitahuan, sebagaimana mestinya

Langkah berikutnya