PolarDB:FAQ cadangan dan pemulihan

Cadangan PolarDB diukur berdasarkan dua metrik: ukuran logis setiap cadangan (② pada gambar berikut) dan ukuran fisik seluruh cadangan (① pada gambar berikut).

• Ukuran logis: Volume data (data dan log) pada titik waktu snapshot yang konsisten (③ pada gambar berikut).

• Ukuran fisik: Ukuran rantai snapshot cadangan. PolarDB menggunakan mekanisme rantai snapshot inkremental untuk cadangan. Mekanisme ini menyimpan status snapshot pada setiap titik waktu. Ketika sebuah blok data dimodifikasi, sistem menyimpan versi historis blok data tersebut untuk snapshot. Data hanya dihapus dari rantai snapshot ketika snapshot sebelumnya telah kedaluwarsa.

  Contoh: Asumsikan volume data sebuah kluster adalah 100 GB. Siklus cadangan untuk cadangan level-1/cadangan data dilakukan sekali per hari, dan periode retensi adalah 3 hari.

  Tanggal	Proses modifikasi data	Ukuran data dalam storage	Ukuran rantai snapshot yang sesuai (cadangan fisik)
  Senin	Tambahkan 100 GB data	100 GB + 100 GB = 200 GB	+ 0 GB = 0 GB Catatan Ini tidak memperhitungkan ukuran rantai snapshot (cadangan fisik) sebelum Senin. Dalam skenario nyata, penambahan bukan 0 GB. Blok data yang direferensikan oleh snapshot mungkin belum sepenuhnya ditulis. Jika data baru harus ditulis ke blok data tersebut, salinan baru dari blok data akan dibuat. Oleh karena itu, menulis data setelah pembuatan snapshot juga meningkatkan ukuran rantai snapshot (cadangan fisik).
  Selasa	Modifikasi 1 GB data dan tambahkan 1 GB data	200 GB + 1 GB = 201 GB	0 GB + 1 GB = 1 GB
  Rabu	Hapus 100 GB data Catatan Data yang dihapus adalah data yang ditambahkan pada hari Senin.	201 GB - 100 GB = 101 GB	1 GB + 100 GB = 101 GB
  Kamis	Modifikasi 1 GB data dan tambahkan 1 GB data	101 GB + 1 GB = 102 GB	101 GB + 1 GB = 102 GB
  Jumat	Modifikasi 1 GB data dan tambahkan 1 GB data	102 GB + 1 GB = 103 GB	102 GB + 1 GB = 103 GB Catatan Pada titik ini, snapshot dari Senin telah kedaluwarsa. Namun, ukuran rantai snapshot (cadangan fisik) tidak berkurang. Sistem terus menyimpan versi historis blok data untuk set cadangan dari Selasa.
  Sabtu	Modifikasi 1 GB data dan tambahkan 1 GB data	103 GB + 1 GB = 104 GB	103 GB + 1 GB - 100 GB = 4 GB Catatan Pada titik ini, snapshot dari Selasa telah kedaluwarsa. Sistem tidak lagi perlu menyimpan versi historis blok data untuk data yang ditambahkan pada Senin dan dihapus pada Rabu. Oleh karena itu, ukuran rantai snapshot (cadangan fisik) berkurang sebesar 100 GB.

  Catatan

  • Contoh di atas hanya sebagai referensi. Contoh ini hanya mempertimbangkan data bisnis dalam kluster dan tidak mencakup file sistem. Ukuran aktual dapat berbeda.

  • Untuk mengurangi ukuran cadangan fisik tanpa mengubah frekuensi modifikasi blok data, Anda dapat memperpendek siklus cadangan dan periode retensi. Untuk informasi lebih lanjut, lihat Bagaimana cara mengurangi volume data dan biaya cadangan level-1, cadangan level-2, dan cadangan log?

  

Tidak. Perbedaan antara cadangan level-1 dan cadangan data adalah sebagai berikut:

Cadangan PolarDB memiliki dua metrik ukuran: ukuran logis setiap set cadangan dan ukuran fisik seluruh cadangan. PolarDB menggunakan mekanisme rantai snapshot untuk cadangan, di mana setiap blok data unik hanya disimpan sekali. Oleh karena itu, total ukuran fisik lebih kecil daripada jumlah ukuran logis dan kadang-kadang bahkan lebih kecil daripada ukuran logis satu set cadangan.

Anda dikenai biaya untuk ruang penyimpanan yang digunakan oleh cadangan level-1/cadangan data, cadangan level-2, dan cadangan log. Cadangan level-1/cadangan data dan cadangan log diaktifkan secara default, dan kuota gratis disediakan. Cadangan level-2 dinonaktifkan secara default. Untuk informasi lebih lanjut, lihat Backup storage (ditagih untuk penggunaan yang melebihi kuota gratis).

Biaya penyimpanan cadangan bergantung pada Storage Type kluster Anda.

• Enterprise SSD (PL0, PL1, PL2, PL3, dan AutoPL)

  • Rumus: Biaya per jam = (Total ukuran cadangan data - Kuota gratis) × Harga per jam

  • Kuota gratis: Kapasitas penyimpanan × 50%

  Contoh: Di Tiongkok daratan, jika total ukuran cadangan data adalah 700 GB dan penggunaan penyimpanan database adalah 1.000 GB, biaya per jam adalah [700 GB - (1.000 GB × 50%)] × USD 0,00003231/GB/jam = USD 0,006462/jam. Untuk informasi lebih lanjut, lihat Backup storage (ditagih untuk penggunaan yang melebihi kuota gratis).

• PSL4/PSL5

  • Rumus: Biaya per jam = (Total ukuran cadangan level-1 - Kuota gratis) × Harga per jam

  • Kuota gratis: Rumus perhitungan kuota gratis bervariasi berdasarkan Storage Payment Method. Rumusnya sebagai berikut:

    • Subscription (ditagih berdasarkan ruang): Kapasitas penyimpanan × 50%.

    • Pay-as-you-go (ditagih berdasarkan kapasitas): Penggunaan penyimpanan × 50%.

  Contoh: Untuk kelas penyimpanan PSL5 di Tiongkok daratan, jika total ukuran cadangan level-1 (snapshot) adalah 700 GB dan penggunaan penyimpanan database adalah 1.000 GB, biaya per jam adalah [700 GB - (1.000 GB × 50%)] × USD 0,000464/GB/jam = USD 0,0928/jam. Untuk informasi lebih lanjut, lihat Backup storage (ditagih untuk penggunaan yang melebihi kuota gratis).

• Perpendek periode retensi data cadangan sesuai kebutuhan. Untuk informasi lebih lanjut, lihat Konfigurasikan kebijakan cadangan.

  • Perpendek periode retensi untuk cadangan level-1, misalnya dari 7 hari menjadi 3 hari.

  • Perpendek periode retensi untuk cadangan level-2, misalnya dari 70 hari menjadi 30 hari.

    Catatan

    Memperpendek periode retensi cadangan level-1 dan level-2 membawa risiko. Jika set cadangan yang Anda butuhkan lebih tua daripada periode retensi, Anda tidak dapat menggunakannya untuk memulihkan data.

  • Perpendek periode retensi untuk cadangan log, misalnya dari 7 hari menjadi 3 hari.

    Catatan

    Memperpendek periode retensi cadangan log membawa risiko. Anda tidak dapat melakukan point-in-time restore ke waktu yang lebih awal daripada cadangan log tertua yang masih disimpan.

• Kurangi frekuensi pencadangan (siklus cadangan) sesuai kebutuhan. Untuk informasi lebih lanjut, lihat Konfigurasikan kebijakan cadangan.

  • Kurangi frekuensi cadangan level-1, misalnya dari sekali sehari menjadi tiga kali seminggu.

    Catatan

    Mengurangi frekuensi cadangan level-1 dapat meningkatkan waktu yang diperlukan untuk point-in-time restore.

  • Kurangi frekuensi cadangan level-2, misalnya dari tiga kali seminggu menjadi dua kali seminggu.

• Hapus set cadangan yang tidak diperlukan dari cluster recycle bin untuk mengurangi biaya cadangan level-2. Untuk informasi lebih lanjut, lihat Hapus cadangan.

Ya.

Periode retensi file cadangan manual ditentukan oleh Backup Retention Period yang Anda tetapkan untuk Level-1 Backup atau Level-2 Backup di bawah Data Backup pada Backup Policy Settings.

Anda dapat melihat ukuran cadangan level-2 pada tab Data Backups. Untuk mengakses tab ini, buka halaman Settings and Management > Backup and Restoration di Konsol.

Jika Anda memilih untuk mempertahankan set cadangan saat merilis kluster, Anda dapat melihatnya di cluster recycle bin di PolarDB console. Untuk informasi lebih lanjut, lihat Cluster recycle bin.

Anda dapat mengunduh file cadangan ke komputer Anda. Namun, Anda tidak dapat langsung menggunakan data cadangan yang diunduh untuk memulihkan kluster PolarDB for MySQL. Anda dapat menggunakannya untuk memulihkan data dari file cadangan ke database MySQL yang dikelola sendiri.

Anda dapat menggunakan salah satu metode berikut untuk melakukan arsip jangka panjang file cadangan PolarDB for MySQL ke OSS:

• Gunakan Alibaba Cloud Database Backup Service (DBS) untuk menyimpan file cadangan PolarDB for MySQL di OSS. Lakukan langkah-langkah berikut:

  1. Di Konsol OSS, buat bucket.

  2. Konfigurasikan secara manual jadwal cadangan logis untuk PolarDB for MySQL. Setelah pencadangan selesai, Anda dapat mengelola set cadangan tersebut. Misalnya, Anda dapat menanyakan set cadangan atau mengunduh set cadangan.

• Gunakan mysqldump atau Data Management (DMS) untuk mengekspor file cadangan, lalu unggah ke OSS. Lakukan langkah-langkah berikut:

  1. Gunakan mysqldump atau DMS untuk mengekspor file cadangan PolarDB for MySQL.

  2. Unggah secara manual file cadangan yang diekspor ke OSS. Untuk informasi lebih lanjut, lihat Unggah file.

Produk ini saat ini tidak mendukung konfigurasi langsung peringatan untuk kegagalan cadangan. Namun, Anda dapat menerapkan mekanisme peringatan sendiri. Misalnya, Anda dapat secara berkala memanggil operasi DescribeBackups untuk mengambil bidang BackupStatus dari pekerjaan cadangan. Anda kemudian dapat memeriksa statusnya dan memicu peringatan kustom, seperti email, pesan teks, atau notifikasi pada platform pemantauan, jika statusnya Failed.

Log fisik kluster PolarDB adalah log redo. Setiap file log redo memiliki ukuran tetap 1 GB. Cadangan hanya dipicu setelah file 1 GB tersebut sepenuhnya ditulis. Jika kluster baru saja dibuat atau memiliki volume akses rendah, file log redo 1 GB mungkin belum penuh. Dalam kasus ini, cadangan tidak dipicu, dan tidak ada catatan yang muncul di daftar cadangan log redo.

Didukung.

Tidak. Point-in-time restore pertama-tama memulihkan cadangan data lengkap dari waktu sebelum titik waktu yang dipilih ke kluster. Kemudian, menggunakan log redo untuk memulihkan data secara inkremental hingga titik waktu yang dipilih.

Didukung.

Didukung.

Tidak. PolarDB for MySQL membuat database dan tabel baru di kluster saat ini untuk operasi pemulihan.