Bagikan melalui

Pencadangan dan pemulihan di Azure Database for MySQL - Server Fleksibel

  • Artikel

BERLAKU UNTUK: Azure Database for MySQL - Server Fleksibel

Server fleksibel Azure Database for MySQL secara otomatis membuat cadangan server dan menyimpannya dengan aman di penyimpanan redundan lokal di wilayah tersebut. 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.

Ringkasan pencadangan

Server fleksibel Azure Database for MySQL mendukung dua jenis cadangan untuk memberikan fleksibilitas yang ditingkatkan untuk mempertahankan cadangan data penting bisnis.

Pencadangan otomatis

Server fleksibel Azure Database for MySQL mengambil cadangan rekam jepret file data dan menyimpannya dalam penyimpanan redundan lokal. Server juga melakukan pencadangan log transaksi serta menyimpannya di penyimpanan redundan lokal. Cadangan ini memungkinkan Anda memulihkan server ke titik waktu tertentu dalam periode retensi cadangan yang dikonfigurasikan. Periode retensi cadangan default adalah 7 hari. Anda juga boleh mengonfigurasikan cadangan database dari 1 hingga 35 hari. Semua cadangan dienkripsi menggunakan enkripsi AES 256 bit untuk data yang tersimpan di memori.

Pencadangan Sesuai Permintaan

Server fleksibel Azure Database for MySQL juga memungkinkan Anda memicu pencadangan sesuai permintaan dari beban kerja produksi, selain cadangan otomatis yang diambil oleh layanan dan menyimpannya selaras dengan kebijakan penyimpanan cadangan server. Anda dapat menggunakan cadangan ini sebagai titik pemulihan tercepat untuk melakukan pemulihan titik waktu untuk mengurangi waktu pemulihan hingga 90%. Periode retensi cadangan default adalah 7 hari. Anda juga boleh mengonfigurasikan cadangan database dari 1 hingga 35 hari. Anda dapat memicu total 50 cadangan sesuai permintaan dari portal. Semua cadangan dienkripsi menggunakan enkripsi AES 256 bit untuk data yang tersimpan di memori.

File cadangan ini tidak dapat diekspor. Cadangan hanya dapat digunakan untuk operasi pemulihan di server fleksibel Azure Database for MySQL. Anda juga dapat menggunakan mysqldump dari klien MySQL untuk menyalin database.

Frekuensi pencadangan

Cadangan pada server fleksibel berbasis snapshot. Pencadangan rekam jepret pertama dijadwalkan segera setelah server dibuat. Pencadangan rekam jepret diambil setiap hari sekali. Cadangan log transaksi terjadi setiap lima menit. Jika pencadangan terjadwal gagal, layanan pencadangan kami akan mencoba mengambil pencadangan setiap 20 menit hingga pencadangan berhasil. Kegagalan cadangan ini disebabkan oleh beban produksi transaksional yang berat di instans server.

Opsi redundansi Microsoft Azure Backup

Server fleksibel Azure Database for MySQL menyimpan beberapa salinan cadangan Anda sehingga data Anda terlindungi dari peristiwa yang direncanakan dan tidak direncanakan, termasuk kegagalan perangkat keras sementara, pemadaman jaringan atau listrik, dan bencana alam besar-besaran. Server fleksibel Azure Database for MySQL memberikan fleksibilitas untuk memilih antara penyimpanan cadangan redundan secara lokal, redundan zona, atau geo-redundan di tingkat Dasar, Tujuan Umum, dan Kritis Bisnis. Secara default, penyimpanan cadangan server fleksibel Azure Database for MySQL secara lokal redundan untuk server dengan ketersediaan tinggi zona yang sama (HA) atau tidak ada konfigurasi ketersediaan tinggi, dan zona redundan untuk server dengan konfigurasi KETERSEDIAAN zona-redundan.

Redundansi cadangan memastikan bahwa database Anda memenuhi target ketersediaan dan durabilitasnya bahkan dalam menghadapi kegagalan dan server fleksibel Azure Database for MySQL memperluas tiga opsi untuk pengguna -

  • Penyimpanan cadangan lokal redundan : Bila cadangan disimpan di penyimpanan cadangan yang lokal redundan, beberapa salinan cadangan disimpan di pusat data yang sama. Opsi ini melindungi data Anda dari kegagalan rak server dan drive. Ini juga memberikan setidaknya durabilitas objek Cadangan sebesar 99,999999999% (11 angka 9) selama tahun tertentu. Secara default, penyimpanan cadangan untuk server dengan ketersediaan tinggi (HA) zona yang sama atau tanpa konfigurasi ketersediaan tinggi disetel ke lokal redundan.

  • Penyimpanan cadangan zona-redundan : Ketika cadangan disimpan di penyimpanan cadangan zona-redundan, beberapa salinan tidak hanya disimpan dalam zona ketersediaan tempat server Anda dihosting, tetapi juga direplikasi ke zona ketersediaan lain di wilayah yang sama. Opsi ini dapat dimanfaatkan untuk skenario yang memerlukan ketersediaan tinggi atau untuk membatasi replikasi data ke dalam negara/wilayah untuk memenuhi persyaratan residensi data. Ini juga memberikan setidaknya durabilitas objek Cadangan sebesar 99,9999999999% (12 angka 9) selama tahun tertentu. Pengguna dapat memilih opsi Ketersediaan Tinggi Zona-Redundan pada waktu pembuatan server untuk memastikan penyimpanan cadangan zona-redundan. Ketersediaan Tinggi untuk server dapat dinonaktifkan pasca buat, tetapi penyimpanan cadangan tetap redundan zona.

  • Penyimpanan cadangan Geo-Redundan : Ketika cadangan disimpan dalam penyimpanan cadangan geo-redundan, beberapa salinan tidak hanya disimpan dalam wilayah tempat server Anda dihosting, tetapi juga direplikasi ke wilayah yang dipasangkan secara geografis. Ini memberikan perlindungan dan kemampuan yang lebih baik untuk memulihkan server Anda di wilayah yang berbeda jika terjadi bencana. Juga memberikan setidaknya 99,99999999999999% (16 9' s) daya tahan objek Backups selama tahun tertentu. Seseorang dapat mengaktifkan opsi Geo-Redundancy di waktu pembuatan server untuk memastikan penyimpanan cadangan geo-redundansi. Selain itu, Anda dapat beralih dari penyimpanan redundan lokal ke penyimpanan geo-redundan setelah server dibuat. Geo redundansi didukung untuk server yang dihosting di salah satu wilayah berpasangan Azure.

Catatan

Ketersediaan Tinggi zona-redundan untuk mendukung redundansi zona saat ini muncul sebagai operasi waktu pembuatan saja. Saat ini, untuk geo-redundansi server Ketersediaan Tinggi Zona-redundansi hanya dapat diaktifkan/dinonaktifkan pada waktu pembuatan server.

Berpindah dari opsi penyimpanan cadangan lainnya ke penyimpanan cadangan geo-redundan

Anda dapat memindahkan penyimpanan cadangan yang ada ke penyimpanan geo-redundan menggunakan cara yang disarankan berikut ini:

  • Berpindah dari penyimpanan cadangan lokal redundan ke geo-redundan - Untuk memindahkan penyimpanan cadangan dari penyimpanan yang lokal redundan ke penyimpanan geo-redundan, Anda dapat mengubah konfigurasi server Compute + Storage dari portal Microsoft Azure guna mengaktifkan Geo-redundansi untuk server sumber lokal redundan. Server HA Redundan Zona yang Sama juga dapat dipulihkan sebagai server geo-redundan dengan cara yang sama karena penyimpanan cadangan yang mendasarinya bersifat lokal redundan untuk hal yang sama.

  • Berpindah dari penyimpanan cadangan zona-redundan ke geo-redundan - Server fleksibel Azure Database for MySQL tidak mendukung penyimpanan redundan zona ke konversi penyimpanan geo-redundan melalui perubahan pengaturan Komputasi + Penyimpanan setelah server disediakan. Untuk memindahkan penyimpanan cadangan Anda dari penyimpanan zona-redundan ke penyimpanan geo-redundan, ada dua opsi: a) Gunakan PITR (pemulihan titik waktu) untuk memulihkan server dengan konfigurasi yang diinginkan. b) Buat server baru dengan konfigurasi yang diinginkan dan migrasikan data menggunakan cadangan dan pemulihan.

Retensi Pencadangan

Pencadangan dipertahankan berdasarkan setelan periode penyimpanan cadangan pada server. Anda dapat memilih periode retensi 1 hingga 35 hari dengan periode retensi default adalah tujuh hari. Anda dapat mengatur periode retensi selama pembuatan server atau setelahnya dengan memperbarui konfigurasi cadangan menggunakan portal Azure.

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 tujuh hari, jendela pemulihan dianggap tujuh hari terakhir. Dalam skenario ini, semua cadangan yang diperlukan untuk memulihkan server dalam tujuh hari terakhir dipertahankan. Dengan jendela retensi cadangan selama tujuh hari, snapshot database dan cadangan log transaksi disimpan selama delapan hari terakhir (1 hari sebelum jendela).

Biaya penyimpanan Microsoft Azure Backup

Server fleksibel Azure Database for MySQL menyediakan hingga 100% penyimpanan server yang disediakan 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 penyimpanan 250 GB yang tersedia untuk cadangan server tanpa biaya tambahan. Jika penggunaan cadangan harian adalah 25GB, maka Anda dapat memiliki penyimpanan cadangan gratis hingga 10 hari. Penyimpanan yang digunakan untuk cadangan lebih dari 250 GB dikenakan biaya sesuai model harga.

Anda dapat menggunakan metrik Penyimpanan Microsoft Azure Backup yang digunakan di Azure Monitor yang tersedia di portal Azure untuk memantau penyimpanan cadangan yang digunakan oleh server. Metrik Penyimpanan Cadangan menunjukkan jumlah penyimpanan yang digunakan oleh semua cadangan database lengkap dan cadangan log yang dipertahankan berdasarkan periode retensi cadangan yang ditetapkan untuk server. Aktivitas transaksional yang berat di server dapat menyebabkan penggunaan penyimpanan cadangan meningkat terlepas dari ukuran total database. Penyimpanan cadangan yang digunakan untuk server geo-redundan besarnya adalah dua kali lipat dari server lokal redundan.

Cara utama mengontrol biaya penyimpanan cadangan adalah dengan mengatur periode penyimpanan cadangan yang sesuai. Anda dapat memilih periode retensi antara 1 hingga 35 hari.

Penting

Pencadangan dari server database yang dikonfigurasikan dalam zona konfigurasi ketersediaan tinggi redundan terjadi dari server database utama karena kelebihan biayanya cukup kecil dengan cadangan snapshot.

Menampilkan Pencadangan Penuh yang Tersedia

Bilah Pencadangan dan Pemulihan di portal Azure menyediakan daftar lengkap cadangan lengkap yang tersedia untuk Anda pada titik waktu tertentu. Ini termasuk pencadangan otomatis serta cadangan Sesuai Permintaan. Seseorang dapat menggunakan bilah ini untuk melihat cap waktu penyelesaian untuk semua pencadangan penuh yang tersedia dalam periode retensi server dan untuk melakukan operasi pemulihan menggunakan pencadangan penuh ini. Daftar cadangan yang tersedia mencakup semua cadangan penuh dalam periode retensi, tanda waktu yang menunjukkan keberhasilan penyelesaian, tanda waktu yang menunjukkan berapa lama cadangan akan dipertahankan, dan tindakan pemulihan.

Pulihkan

Di server fleksibel Azure Database for MySQL, melakukan pemulihan membuat server baru dari cadangan server asli. Ada dua jenis data lalu lintas yang tersedia:

  • Pemulihan titik waktu : tersedia dengan opsi redundansi cadangan dan membuat server baru di wilayah yang sama dengan server asli Anda.
  • Pemulihan geografis: hanya tersedia jika Anda mengonfigurasi server Anda untuk penyimpanan geo-redundan dan memungkinkan Anda memulihkan server Anda ke wilayah yang dipasangkan secara geografis atau wilayah lain yang didukung Azure di mana server fleksibel tersedia.

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.

Catatan

Server berkemampuan Ketersediaan Tinggi akan menjadi non-HA (Ketersediaan Tinggi dinonaktifkan) setelah pemulihan untuk pemulihan Point-in-time dan Pemulihan geografis.

Pemulihan titik waktu

Di server fleksibel Azure Database for MySQL, melakukan pemulihan point-in-time membuat server baru dari cadangan server fleksibel di wilayah yang sama dengan server sumber Anda. Ini dibuat dengan konfigurasi server asli untuk tingkat komputasi, jumlah vCore, ukuran penyimpanan, periode retensi cadangan, dan opsi redundansi cadangan. Selain itu, tag dan pengaturan seperti jaringan virtual dan firewall diwarisi dari server sumber. Tingkat komputasi dan penyimpanan server yang dipulihkan, konfigurasi dan pengaturan keamanan dapat diubah setelah pemulihan selesai.

Catatan

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 menjadi nilai DEFAULT SISTEM
  • event_scheduler - Event_scheduler diatur menjadi NONAKTIF di server yang dipulihkan

Pemulihan point-in-time berguna dalam beberapa skenario. Beberapa kasus penggunaan yang umum termasuk -

  • Kapan pengguna secara tidak sengaja menghapus data dalam database
  • Pengguna menghilangkan tabel atau database penting
  • Aplikasi pengguna secara tidak sengaja menimpa data baik dengan data buruk karena cacat aplikasi.

Anda dapat memilih antara titik pemulihan terbaru, titik pemulihan khusus dan titik pemulihan tercepat (pulihkan menggunakan pencadangan penuh) melaluiportal Microsoft Azure.

  • Titik pemulihan terbaru: Opsi titik pemulihan terbaru membantu Anda mengembalikan server ke tanda waktu saat operasi pemulihan dipicu. Opsi ini berguna untuk memulihkan server dengan cepat ke status yang paling diperbarui.
  • Titik pemulihan kustom: Opsi ini memungkinkan Anda memilih titik waktu apa pun dalam periode retensi yang ditentukan untuk server ini. Opsi ini berguna untuk memulihkan server pada titik waktu yang tepat untuk memulihkan dari kesalahan pengguna.
  • Titik pemulihan tercepat: Opsi ini memungkinkan pengguna memulihkan server dalam waktu secepat mungkin untuk hari tertentu dalam periode retensi yang ditentukan untuk server mereka. Pemulihan tercepat dimungkinkan dengan memilih titik waktu pemulihan di mana pencadangan penuh selesai. Operasi pemulihan ini hanya mengembalikan cadangan salinan bayangan penuh dan tidak menjamin pemulihan atau pemulihan log yang membuatnya cepat. Kami menyarankan Anda memilih stempel waktu pencadangan penuh yang lebih besar dari titik pemulihan paling awal untuk operasi pemulihan yang berhasil.

Perkiraan waktu pemulihan tergantung pada beberapa faktor termasuk ukuran database, ukuran pencadangan log transaksi, ukuran komputasi SKU, dan waktu pemulihan juga. Pemulihan log transaksi adalah bagian yang paling memakan waktu dari proses pemulihan. Jika waktu pemulihan dipilih lebih dekat ke jadwal pencadangan rekam jepret, pemulihan lebih cepat karena aplikasi log transaksi minimal. Untuk memperkirakan waktu pemulihan server secara akurat, sebaiknya uji di lingkungan Anda karena server memiliki terlalu banyak variabel khusus- lingkungan.

Penting

Jika Anda memulihkan instans server fleksibel Azure Database for MySQL yang dikonfigurasi dengan ketersediaan tinggi zona redundan, server yang dipulihkan dikonfigurasi di wilayah dan zona yang sama dengan server utama Anda, dan disebarkan sebagai server tunggal dalam mode non-HA. Lihat ketersediaan tinggi zona redundan untuk server fleksibel.

Penting

Anda dapat memulihkan sumber daya server fleksibel Azure Database for MySQL yang dihapus dalam waktu 5 hari sejak waktu penghapusan server. Untuk mendapatkan panduan mendetail tentang cara memulihkan server yang dihapus, lihat langkah-langkah terdokumentasi. Untuk melindungi sumber daya server pascapenyebaran dari penghapusan yang tidak disengaja atau perubahan yang tidak terduga, administrator dapat memanfaatkan kunci manajemen.

Pemulihan Geo

Anda dapat memulihkan server ke wilayah yang dipasangkan secara geografis di mana layanan tersedia jika Anda telah mengonfigurasi server Anda untuk cadangan geo-redundan atau wilayah lain yang didukung Azure tempat server fleksibel Azure Database for MySQL tersedia. Kemampuan untuk memulihkan ke wilayah yang didukung Azure yang tidak dipasangkan (kecuali Brazil South, USGov Virginia dan West US 3) dikenal sebagai "Universal Geo-restore".

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 penundaan antara ketika cadangan diambil dan kapan direplikasi ke wilayah yang berbeda. Penundaan ini bisa sampai satu jam, jadi jika bencana terjadi bisa ada kehilangan data hingga satu jam.

Pemulihan-geo juga dapat dilakukan pada server yang memanfaatkan Azure CLI, yang dihentikan. Baca Memulihkan server fleksibel Azure Database for MySQL dengan Azure CLI untuk mempelajari selengkapnya tentang pemulihan geografis server dengan Azure CLI.

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.

Catatan

Jika Anda memulihkan instans server fleksibel Azure Database for MySQL yang dikonfigurasi dengan ketersediaan tinggi zona redundan, server yang dipulihkan dikonfigurasi di wilayah yang dipasangkan secara geografis dan zona yang sama dengan server utama Anda dan disebarkan sebagai instans server fleksibel Azure Database for MySQL tunggal dalam mode non-HA. Lihat ketersediaan tinggi zona redundan untuk server fleksibel Azure Database for MySQL.

Penting

Saat wilayah utama tidak berfungsi, Anda tidak dapat membuat server geo-redundan di wilayah masing-masing yang dipasangkan secara geografis karena penyimpanan tidak dapat disediakan di wilayah utama. Anda harus menunggu wilayah utama hingga menyediakan server geo-redundan di wilayah yang dipasangkan secara geografis. Dengan wilayah utama tidak berfungsi, Anda masih dapat memulihkan server sumber secara geografis ke wilayah yang dipasangkan secara geografis dengan menonaktifkan opsi geo-redundansi di pengaturan Compute + Storage Configure Server dalam pengalaman portal pemulihan dan memulihkan sebagai server yang berlebihan secara lokal untuk memastikan kelangsungan bisnis.

Melakukan tugas pasca-pemulihan

Setelah pemulihan dari mekanisme pemulihan titik pemulihan terbaru atau titik pemulihan kustom, Anda harus melakukan tugas-tugas berikut untuk membuat pengguna dan aplikasi Anda aktif dan dijalankan:

  • Jika server baru dimaksudkan untuk mengganti server asli, alihkan klien dan aplikasi klien ke server baru.
  • Pastikan firewall tingkat server dan aturan jaringan virtual yang sesuai tersedia bagi pengguna untuk tersambung.
  • Pastikan izin masuk dan izin tingkat database yang sesuai telah diberlakukan.
  • Konfigurasikan pemberitahuan, sebagaimana mestinya.

Retensi jangka panjang (pratinjau)

Layanan server fleksibel Azure Backup dan Azure Database for MySQL telah membangun solusi pencadangan jangka panjang kelas perusahaan untuk instans server fleksibel Azure Database for MySQL yang mempertahankan cadangan hingga 10 tahun. Anda dapat menggunakan retensi jangka panjang secara independen atau selain solusi pencadangan otomatis yang ditawarkan oleh server fleksibel Azure Database for MySQL, yang menawarkan retensi hingga 35 hari. Pencadangan otomatis adalah cadangan rekam jepret yang cocok untuk pemulihan operasional, terutama ketika Anda ingin memulihkan dari cadangan terbaru. Pencadangan jangka panjang membantu Anda dengan kebutuhan kepatuhan dan kebutuhan audit Anda. Selain retensi jangka panjang, solusi ini menawarkan kemampuan berikut:

  • Pencadangan terjadwal dan sesuai permintaan yang dikontrol pelanggan
  • Kelola dan pantau semua operasi dan pekerjaan terkait cadangan di seluruh server, grup sumber daya, lokasi, langganan, dan penyewa dari satu panel kaca yang disebut Pusat Cadangan.
  • Cadangan disimpan dalam domain keamanan dan kesalahan terpisah. Jika server sumber atau langganan disusupi, cadangan tetap aman di brankas Cadangan (di akun penyimpanan terkelola Azure Backup).

Batasan dan pertimbangan

  • Dalam pratinjau, pemulihan LTR saat ini tersedia sebagai RestoreasFiles ke akun penyimpanan. Kemampuan RestoreasServer akan ditambahkan di masa mendatang.
  • Dukungan untuk pembuatan dan manajemen LTR melalui Azure CLI saat ini tidak didukung.

Untuk informasi selengkapnya tentang melakukan pencadangan jangka panjang, kunjungi panduan cara penggunaan

Pencadangan dan Ekspor sesuai permintaan (pratinjau)

Server Fleksibel Azure Database for MySQL sekarang menawarkan kemampuan untuk memicu pencadangan fisik server saat ini sesuai permintaan dan mengekspornya ke akun penyimpanan Azure (penyimpanan blob Azure). Setelah diekspor, cadangan ini dapat digunakan untuk pemulihan data, migrasi, dan redundansi. File cadangan fisik yang diekspor ini dapat digunakan untuk memulihkan kembali ke server MySQL lokal untuk membantu memenuhi kebutuhan audit/kepatuhan/pengarsipan organisasi. Fitur ini saat ini dalam pratinjau publik dan hanya tersedia di wilayah cloud publik.

Untuk informasi selengkapnya mengenai pencadangan ekspor, kunjungi panduan cara penggunaan

Tanya Jawab Umum (FAQ)

  • Bagaimana cara mencadangkan server saya?

    Secara default, server fleksibel Azure Database for MySQL memungkinkan pencadangan otomatis seluruh server Anda (mencakup semua database yang dibuat) dengan periode retensi 7 hari default. Anda juga dapat memicu pencadangan manual menggunakan fitur pencadangan Sesuai Permintaan. Cara lain untuk mengambil cadangan secara manual adalah dengan menggunakan alat komunitas seperti mysqldump seperti yang didokumenkan di sini atau mydumper seperti yang didokumenkan di sini. Jika Anda ingin mencadangkan instans server fleksibel Azure Database for MySQL ke penyimpanan Blob, lihat blog komunitas teknologi kami Backup Azure Database for MySQL flexible server ke Blob Storage.

  • Bisakah saya mengonfigurasi cadangan otomatis yang akan disimpan untuk jangka panjang?

    Tidak, saat ini kami hanya mendukung maksimal 35 hari retensi cadangan otomatis. Anda dapat mengambil cadangan manual dan menggunakannya untuk kebutuhan retensi jangka panjang.

  • Apa jendela cadangan untuk server saya? Bisakah saya menyesuaikannya?

    Pencadangan rekam jepret pertama dijadwalkan segera setelah server dibuat. Pencadangan rekam jepret diambil sekali setiap hari. Cadangan log transaksi terjadi setiap lima menit. Jendela cadangan dikelola secara inheren oleh Azure dan tidak dapat disesuaikan.

  • Apakah cadangan saya dienkripsi?

    Semua data server fleksibel Azure Database for MySQL, cadangan, dan file sementara yang dibuat selama eksekusi kueri dienkripsi menggunakan enkripsi AES 256-bit. Enkripsi penyimpanan selalu aktif dan tidak dapat dinonaktifkan.

  • Dapatkah saya memulihkan satu/beberapa database?

    Memulihkan database atau tabel tunggal/beberapa tidak didukung. Jika Anda ingin memulihkan database tertentu, lakukan Point in Time Restore lalu ekstrak tabel atau database yang diperlukan.

  • Apakah server saya tersedia selama jendela cadangan?

    Ya. Cadangan adalah operasi online dan berbasis rekam jepret. Operasi rekam jepret hanya membutuhkan waktu beberapa detik dan tidak mengganggu beban kerja produksi, memastikan ketersediaan server yang tinggi.

  • Saat menyiapkan jendela pemeliharaan untuk server, apakah kita perlu memperhitungkan jendela cadangan?

    Tidak, cadangan dipicu secara internal sebagai bagian dari layanan terkelola dan tidak memiliki bantalan pada Jendela Pemeliharaan Terkelola.

  • Cadangan otomatis saya disimpan di mana dan bagaimana cara mengelola retensinya?

    Server fleksibel Azure Database for MySQL secara otomatis membuat cadangan server dan menyimpannya di penyimpanan yang dikonfigurasi pengguna dan redundan secara lokal atau dalam penyimpanan geo-redundan. File cadangan tidak dapat diekspor. Periode retensi cadangan default adalah 7 hari. Anda juga boleh mengonfigurasikan cadangan database dari 1 hingga 35 hari.

  • Bagaimana cara memvalidasi cadangan saya?

    Cara terbaik untuk memvalidasi ketersediaan cadangan yang berhasil diselesaikan adalah dengan melihat cadangan otomatis penuh yang diambil dalam periode retensi di bilah Backup dan Restore. Jika pencadangan gagal, cadangan tidak tercantum dalam daftar cadangan yang tersedia, dan layanan cadangan akan mencoba setiap 20 menit untuk mengambil cadangan sampai cadangan berhasil diambil. Kegagalan cadangan ini disebabkan oleh beban produksi transaksional yang berat di server.

  • Di mana saya bisa melihat penggunaan cadangan?

    Di portal Azure, di bawah tab Pemantauan - Metrik, Anda dapat menemukan metrik Penyimpanan Cadangan yang Digunakan, yang dapat membantu Anda memantau total penggunaan cadangan.

  • Apa yang terjadi pada cadangan jika saya menghapus server?

    Jika Anda menghapus server, semua cadangan milik server juga akan dihapus dan tidak dapat dipulihkan. Untuk melindungi sumber daya server pasca penyebaran dari penghapusan yang tidak disengaja atau perubahan tak terduga, administrator dapat menggunakan kunci manajemen.

  • Apa yang terjadi pada cadangan saya ketika saya memulihkan server?

    Jika Anda memulihkan server, server selalu menghasilkan pembuatan server baru bersih yang telah dipulihkan menggunakan cadangan server asli. Cadangan lama dari server asli tidak disalin ke server yang baru dipulihkan dan tetap dengan server asli. Namun, untuk server yang baru dibuat, cadangan rekam jepret pertama dijadwalkan segera setelah server dibuat dan layanan memastikan cadangan otomatis harian diambil dan disimpan sesuai periode retensi server yang dikonfigurasi.

  • Bagaimana saya ditagih dan ditagih untuk penggunaan cadangan saya?

    Server fleksibel Azure Database for MySQL menyediakan hingga 100% penyimpanan server yang disediakan sebagai penyimpanan cadangan tanpa biaya tambahan. Penyimpanan cadangan lainnya yang digunakan dikenakan biaya dalam GB per bulan sesuai model harga. Penagihan penyimpanan cadangan juga diatur oleh periode retensi cadangan yang dipilih dan opsi redundansi cadangan yang dipilih, selain aktivitas transaksional di server, yang berdampak pada total penyimpanan cadangan yang digunakan secara langsung.

  • Bagaimana cadangan disimpan untuk server yang dihentikan?

    Tidak ada cadangan baru yang dilakukan untuk server yang dihentikan. Semua cadangan lama (dalam jendela retensi) pada saat menghentikan server dipertahankan sampai server dimulai ulang, posting retensi cadangan mana untuk server aktif yang diatur oleh jendela retensi cadangannya.

  • Bagaimana prosedur penagihan untuk cadangan bagi server yang dihentikan?

    Saat instans server Anda dihentikan, Anda dikenakan biaya untuk penyimpanan yang disediakan (termasuk IOPS yang Disediakan) dan penyimpanan cadangan (cadangan yang disimpan dalam jendela retensi yang Ditentukan). Penyimpanan cadangan gratis terbatas pada ukuran database yang Anda sediakan dan hanya berlaku untuk server aktif.

  • Bagaimana data cadangan saya dilindungi?

    Server Fleksibel Azure database for MySQL melindungi data cadangan Anda dengan memblokir operasi apa pun yang dapat menyebabkan hilangnya titik pemulihan selama periode retensi yang dikonfigurasi. Cadangan yang diambil selama periode retensi hanya dapat dibaca untuk tujuan pemulihan dan dihapus pasca periode retensi. Selain itu, semua cadangan di server fleksibel Azure Database for MySQL dienkripsi menggunakan enkripsi AES 256-bit untuk data yang disimpan saat tidak aktif.

  • Bagaimana operasi Pemulihan Point-In-Time (PITR) memengaruhi penggunaan IOPS?

    Selama operasi PITR di Azure Database for MySQL - Server Fleksibel, server baru dibuat dan data disalin dari penyimpanan server sumber ke penyimpanan server baru. Proses ini menghasilkan peningkatan penggunaan IOPS pada server sumber. Peningkatan penggunaan IOPS ini adalah kejadian normal dan tidak menunjukkan masalah apa pun dengan server sumber atau operasi PITR. Setelah operasi PITR selesai, penggunaan IOPS di server sumber akan kembali ke tingkat yang biasa.

  • Bagaimana cara memulihkan server saya? portal Azure mendukung Pemulihan Titik Waktu untuk semua server, memungkinkan pengguna memulihkan ke titik pemulihan terbaru atau kustom. Untuk memulihkan server Anda secara manual dari cadangan yang diambil oleh mysqldump/myDumper, lihat Memulihkan database Anda menggunakan myLoader.

  • Mengapa pemulihan saya membutuhkan waktu yang lama?

    Estimasi waktu untuk pemulihan server tergantung pada beberapa faktor:

    • Ukuran database. Sebagai bagian dari proses pemulihan, database perlu terhidrasi dari cadangan fisik terakhir dan karenanya waktu yang dibutuhkan untuk pulih akan sebanding dengan ukuran database.
    • Porsi aktivitas transaksi aktif yang perlu diputar ulang untuk pemulihan. Pemulihan dapat memakan waktu lebih lama tergantung pada aktivitas transaksi tambahan dari titik pemeriksaan terakhir yang berhasil.
    • 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 di database Anda.

  • Akankah memodifikasi variabel database tingkat sesi berdampak pada pemulihan?

    Memodifikasi variabel tingkat sesi dan menjalankan pernyataan DML dalam sesi klien MySQL dapat memengaruhi operasi PITR (pemulihan titik waktu), karena modifikasi ini tidak dicatat dalam log biner yang digunakan untuk operasi pencadangan dan pemulihan. Misalnya, foreign_key_checks adalah salah satu variabel tingkat sesi seperti itu, yang jika dinonaktifkan untuk menjalankan pernyataan DML yang melanggar batasan kunci asing menghasilkan kegagalan PITR (pemulihan titik waktu). Satu-satunya solusi dalam skenario seperti itu adalah memilih waktu PITR lebih awal dari waktu di mana foreign_key_checks dinonaktifkan. Rekomendasi kami adalah TIDAK memodifikasi variabel sesi apa pun untuk operasi PITR yang berhasil.

Langkah berikutnya