Data merupakan aset inti perusahaan. Seiring dengan pertumbuhan bisnis, volume data meningkat secara eksponensial. Hal ini mengharuskan aplikasi bisnis untuk memproses data secara online dan real-time. Personel O&M database menghadapi tantangan besar dalam melindungi data inti perusahaan akibat penghapusan data yang tidak disengaja, kerentanan sistem dan ransomware, kegagalan perangkat keras, serta bencana alam yang dapat menyebabkan hilangnya data. Oleh karena itu, fitur cadangan dan pemulihan sangat penting bagi database.
PolarDB mendukung cadangan data dan cadangan log redo:
Cadangan data: Membuat set cadangan (snapshot) dari data penuh kluster pada titik waktu tertentu. Ini adalah cadangan penuh.
Cadangan log redo: Mencatat data inkremental yang dihasilkan setelah pembuatan set cadangan. Ini adalah cadangan inkremental.
Pemulihan kluster PolarDB memulihkan data ke kluster saat ini menggunakan set cadangan (snapshot).
Pemulihan database atau tabel PolarDB membuat database atau tabel baru di kluster saat ini untuk memulihkan data.
Dengan cadangan data penuh dan cadangan log redo berikutnya, Anda dapat memulihkan seluruh kluster PolarDB, database, atau tabel tertentu ke titik waktu apa pun.
Aturan Penagihan
Fitur cadangan dan pemulihan dapat digunakan secara gratis. Namun, file cadangan mengonsumsi ruang penyimpanan. Untuk informasi lebih lanjut tentang aturan penagihan, lihat Penyimpanan cadangan melebihi kuota gratis.
Untuk informasi lebih lanjut tentang cara melihat tagihan Anda, lihat Tagihan.
Jika Anda memilih untuk menyimpan set cadangan untuk jangka waktu lama ketika Anda berhenti berlangganan atau melepaskan kluster secara manual, set cadangan akan dipindahkan secara otomatis ke Keranjang daur ulang kluster. Dalam hal ini, file cadangan level-1 secara otomatis menjadi file cadangan level-2 dan Anda akan dikenakan biaya. Untuk informasi lebih lanjut, lihat Keranjang daur ulang kluster.
Cadangan Data
PSL4/PSL5
Cadangan Level-1
Cadangan level-1 menggunakan snapshot redirect-on-write (ROW) dan disimpan langsung di sistem penyimpanan terdistribusi PolarDB. Saat cadangan level-1 dibuat, data tidak disalin. Saat blok data dimodifikasi, sistem menyimpan versi historis blok tersebut untuk snapshot dan menghasilkan blok baru yang direferensikan oleh data sumber. Proses ini disebut redirect. Metode ini memungkinkan cadangan selesai dalam hitungan detik, terlepas dari ukuran database.
Fitur cadangan dan pemulihan PolarDB menggunakan pemrosesan paralel multi-threading dan inovasi lainnya untuk memulihkan kluster baru dari set cadangan (snapshot) dalam waktu sekitar 10 menit. Waktu pemulihan dua kali lipat jika Kluster Hot Standby diaktifkan. Waktu aktual yang diperlukan bergantung pada faktor-faktor seperti jumlah data dalam database.
Lihat ukuran cadangan level-1
Anda dapat membuka Konsol PolarDB dan navigasikan ke halaman untuk melihat ukuran fisik cadangan level-1. Gambar berikut menunjukkan contoh:
Physical Size Of Level-1 Backups dari kluster PolarDB (① pada gambar) adalah jumlah ruang fisik yang secara eksklusif ditempati oleh semua cadangan level-1. Nilai ini digunakan untuk menghitung penggunaan aktual penyimpanan cadangan level-1.
Logical Size Of Backup dari kluster PolarDB (② pada gambar) adalah ukuran logis satu set cadangan dan tidak digunakan untuk penagihan.
Data dari kluster PolarDB dan beberapa cadangan level-1 (snapshot) berbagi blok data fisik yang sama. Blok bersama ini hanya dikenakan biaya sekali.
Untuk jawaban atas pertanyaan umum tentang cadangan, lihat FAQ.
Cadangan level-1 diaktifkan secara default dan tidak dapat dinonaktifkan.
Periode retensi untuk cadangan level-1 adalah 3 hingga 14 hari.
Cadangan Level-2
Cadangan level-2 adalah cadangan level-1 yang dikompresi dan disimpan pada media penyimpanan offline yang berbeda. Biaya penyimpanannya lebih rendah, tetapi pemulihan data dari cadangan level-2 lebih lambat.
Jika cadangan level-1 melebihi periode retensi yang ditentukan, cadangan tersebut secara otomatis dikonversi menjadi cadangan level-2.
Cadangan level-2 mendukung cadangan satu wilayah dan lintas wilayah. Untuk informasi lebih lanjut, lihat Cadangan satu wilayah dan lintas wilayah.
Lihat ukuran cadangan level-2
Anda dapat membuka Konsol PolarDB dan navigasikan ke halaman untuk melihat ukuran total cadangan level-2. Ukuran total cadangan level-2 adalah jumlah ukuran semua file cadangan level-2 individu. Gambar berikut menunjukkan contoh:
Jika konversi cadangan level-1 belum selesai sebelum jadwal konversi cadangan level-1 berikutnya, cadangan level-1 berikutnya akan dihapus alih-alih dikonversi menjadi cadangan level-2. Misalnya, waktu cadangan untuk cadangan level-1 kluster PolarDB adalah pukul 01:00 setiap hari, dan periode retensinya adalah 24 jam. PolarDB menghasilkan cadangan level-1 A pada pukul 01:00 tanggal 1 Januari dan cadangan level-1 B pada pukul 01:00 tanggal 2 Januari. Pada pukul 01:00 tanggal 2 Januari, cadangan A melebihi periode retensinya dan konversinya ke cadangan level-2 dimulai. Karena file cadangan besar, konversi membutuhkan waktu lama dan belum selesai pada pukul 01:00 tanggal 3 Januari. Pada saat ini, cadangan B kedaluwarsa pada pukul 01:00 tanggal 3 Januari dan dihapus alih-alih dikonversi menjadi cadangan level-2.
Cadangan level-2 dinonaktifkan secara default.
Periode retensi untuk cadangan level-2 adalah 30 hingga 7300 hari.
SSD Perusahaan (ESSD)
Cadangan yang disimpan secara lokal disebut cadangan level-1. Cadangan level-1 adalah snapshot yang disimpan pada kluster penyimpanan terdistribusi. Mereka menawarkan kecepatan cadangan dan pemulihan tercepat tetapi dengan biaya lebih tinggi. Penyimpanan jangka panjang dapat sedikit mempengaruhi kinerja tulis database. Kami merekomendasikan periode retensi tidak lebih dari 2 minggu. Kuota gratis untuk penyimpanan cadangan disediakan. Anda akan dikenakan biaya untuk penggunaan yang melebihi kuota gratis. Anda dapat mengubah siklus cadangan untuk mengontrol kapasitas cadangan.
Cadangan level-1 diaktifkan secara default dan tidak dapat dinonaktifkan.
Periode retensi untuk cadangan level-1 adalah 3 hingga 14 hari.
Lihat ukuran cadangan level-1
Anda dapat membuka Konsol PolarDB dan navigasikan ke halaman untuk melihat ukuran fisik cadangan level-1. Gambar berikut menunjukkan contoh:
Physical Size Of Level-1 Backups dari kluster PolarDB (① pada gambar) adalah jumlah ruang fisik yang secara eksklusif ditempati oleh semua cadangan level-1. Nilai ini digunakan untuk menghitung penggunaan aktual penyimpanan cadangan level-1.
Logical Size Of Backup dari kluster PolarDB (② pada gambar) adalah ukuran logis satu set cadangan dan tidak digunakan untuk penagihan.
Data dari kluster PolarDB dan beberapa cadangan level-1 (snapshot) berbagi blok data fisik yang sama. Blok bersama ini hanya dikenakan biaya sekali.
Untuk jawaban atas pertanyaan umum tentang cadangan, lihat FAQ.
Cadangan Log Redo
Cadangan log dibuat dengan mengunggah log redo ke OSS secara paralel dan real-time. Cadangan log mendukung cadangan satu wilayah dan lintas wilayah. Periode retensi berkisar antara 3 hingga 7300 hari. Anda juga dapat mengaktifkan fitur Long-term Retention Before Cluster Deletion untuk penyimpanan log jangka panjang.
Saat ini, hanya kluster Edisi Perusahaan yang mendukung opsi Long-term Retention Before Cluster Deletion.
Cadangan satu wilayah untuk log diaktifkan secara default dan tidak dapat dinonaktifkan.
Cadangan log memungkinkan cadangan konsisten dengan pemulihan pada titik waktu (PITR). Dengan cadangan data penuh (snapshot) dan cadangan log berikutnya, Anda dapat memulihkan kluster PolarDB ke titik waktu apa pun. Ini memastikan keamanan data terbaru dan mencegah kehilangan data akibat operasi yang tidak disengaja. Saat Anda memulihkan ke titik waktu, kecepatan penerapan log redo adalah sekitar 20 hingga 70 detik/GB. Total waktu pemulihan adalah jumlah waktu yang diperlukan untuk memulihkan dari set cadangan (snapshot) dan waktu yang diperlukan untuk menerapkan log redo.
Lihat ukuran cadangan
Ukuran total cadangan log adalah jumlah ukuran semua file cadangan log individu. Gambar berikut menunjukkan contoh:
Ancaman
Jika laju pembuatan log redo dari kluster PolarDB untuk MySQL mencapai 35 MB/s hingga 50 MB/s, log redo mungkin bertumpuk. Hal ini dapat meningkatkan biaya penyimpanan cadangan Anda.
Cadangan satu wilayah dan lintas wilayah
Catatan tentang Cadangan
Tipe Cadangan
Deskripsi
Diaktifkan Secara Default
Skenario
Manfaat
Cadangan Satu Wilayah
Cadangan disimpan di zona berbeda dalam wilayah yang sama.
Ya.
CatatanSaat Anda mengaktifkan cadangan level-2, cadangan satu wilayah diaktifkan secara default.
Arsip jangka panjang.
Anda dapat menurunkan biaya dengan membuang cadangan pada frekuensi yang lebih rendah sesuai kebutuhan.
Cadangan Lintas Wilayah
Cadangan disimpan di wilayah lain selain wilayah saat ini.
PentingFitur ini hanya tersedia untuk PolarDB untuk MySQL Edisi Perusahaan.
Tidak. Anda harus mengaktifkannya secara manual.
Redundansi geo dan kepatuhan MLPS Level 3.
Recovery Point Objective (RPO) rendah. Cocok untuk lingkungan jaringan aman, non-publik. Anda dapat menurunkan biaya dengan pembuangan frekuensi rendah sesuai kebutuhan.
CatatanCadangan level-2 frekuensi rendah: Siklus cadangan cadangan level-2 diatur pada frekuensi yang lebih rendah daripada cadangan level-1.
Wilayah yang Didukung untuk Cadangan Lintas Wilayah
Wilayah sumber
Wilayah tujuan
Daratan Tiongkok
Daratan Tiongkok
AS (Silicon Valley), AS (Virginia)
Hong Kong, Tiongkok
Singapura, Indonesia (Jakarta), Jepang (Tokyo), Malaysia (Kuala Lumpur)
Jerman (Frankfurt)
Hong Kong, Tiongkok
Daratan Tiongkok
AS (Silicon Valley), AS (Virginia)
Jepang (Tokyo), Singapura, Malaysia (Kuala Lumpur), Indonesia (Jakarta)
Jerman (Frankfurt)
Jepang (Tokyo)
Daratan Tiongkok
AS (Silicon Valley), AS (Virginia)
Hong Kong, Tiongkok
Singapura, Malaysia (Kuala Lumpur), Indonesia (Jakarta)
Jerman (Frankfurt)
AS (Silicon Valley)
Daratan Tiongkok
AS (Virginia)
Hong Kong, Tiongkok
Singapura, Malaysia (Kuala Lumpur), Indonesia (Jakarta)
Jerman (Frankfurt)
AS (Virginia)
Daratan Tiongkok
AS (Silicon Valley)
Hong Kong, Tiongkok
Singapura, Malaysia (Kuala Lumpur), Indonesia (Jakarta)
Jerman (Frankfurt)
Singapura
Daratan Tiongkok
AS (Silicon Valley), AS (Virginia)
Hong Kong, Tiongkok
Malaysia (Kuala Lumpur), Indonesia (Jakarta)
Jerman (Frankfurt)
Malaysia (Kuala Lumpur)
Daratan Tiongkok
AS (Silicon Valley), AS (Virginia)
Hong Kong, Tiongkok
Singapura, Indonesia (Jakarta), Jepang (Tokyo)
Jerman (Frankfurt)
Indonesia (Jakarta)
Daratan Tiongkok
AS (Silicon Valley), AS (Virginia)
Hong Kong, Tiongkok
Singapura, Jepang (Tokyo), Malaysia (Kuala Lumpur)
Jerman (Frankfurt)
Jerman (Frankfurt)
Daratan Tiongkok
AS (Silicon Valley), AS (Virginia)
Hong Kong, Tiongkok
Singapura, Indonesia (Jakarta), Jepang (Tokyo), Malaysia (Kuala Lumpur)
Cloud Keuangan China (Hangzhou)
Cloud Keuangan China (Shanghai), Cloud Keuangan China (Shenzhen)
Cloud Keuangan China (Shanghai)
Cloud Keuangan China (Hangzhou), Cloud Keuangan China (Shenzhen)
Cloud Keuangan China (Shenzhen)
Cloud Keuangan China (Hangzhou), Cloud Keuangan China (Shanghai)
FAQ
Untuk jawaban atas pertanyaan umum tentang cadangan dan pemulihan, lihat FAQ.