PolarDB:FAQ tentang pencadangan dan pemulihan

Cadangan PolarDB diukur berdasarkan dua metrik: ukuran logis setiap cadangan dan ukuran fisik seluruh cadangan.

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

• Ukuran fisik: Ukuran rantai snapshot cadangan. PolarDB menggunakan mekanisme rantai snapshot inkremental untuk pencadangan. 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 setelah snapshot sebelumnya kedaluwarsa.

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

  Tanggal	Proses modifikasi data	Ukuran data dalam penyimpanan	Ukuran rantai snapshot yang sesuai (cadangan fisik)
  Senin	Tambahkan data sebesar 100 GB	100 GB + 100 GB = 200 GB	+ 0 GB = 0 GB Catatan Ini tidak memperhitungkan ukuran rantai snapshot (cadangan fisik) sebelum Senin. Dalam skenario dunia nyata, kenaikannya 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, penulisan data setelah pembuatan snapshot juga meningkatkan ukuran rantai snapshot (cadangan fisik).
  Selasa	Modifikasi data sebesar 1 GB dan tambahkan data sebesar 1 GB	200 GB + 1 GB = 201 GB	0 GB + 1 GB = 1 GB
  Rabu	Hapus data sebesar 100 GB 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 data sebesar 1 GB dan tambahkan data sebesar 1 GB	101 GB + 1 GB = 102 GB	101 GB + 1 GB = 102 GB
  Jumat	Modifikasi data sebesar 1 GB dan tambahkan data sebesar 1 GB	102 GB + 1 GB = 103 GB	102 GB + 1 GB = 103 GB Catatan Pada titik ini, snapshot dari hari Senin telah kedaluwarsa. Namun, ukuran rantai snapshot (cadangan fisik) tidak berkurang. Sistem tetap menyimpan versi historis blok data untuk set cadangan dari hari Selasa.
  Sabtu	Modifikasi data sebesar 1 GB dan tambahkan data sebesar 1 GB	103 GB + 1 GB = 104 GB	103 GB + 1 GB - 100 GB = 4 GB Catatan Pada titik ini, snapshot dari hari Selasa telah kedaluwarsa. Sistem tidak perlu lagi menyimpan versi historis blok data untuk data yang ditambahkan pada hari Senin dan dihapus pada hari 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 pencadangan 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. Ukuran fisik merepresentasikan metrik yang berbeda tergantung jenis cadangannya.

Cadangan PolarDB memiliki dua metrik ukuran: ukuran logis setiap set cadangan dan ukuran fisik seluruh cadangan. PolarDB menggunakan mekanisme rantai snapshot untuk pencadangan, 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, serta disediakan kuota gratis. Cadangan level-2 dinonaktifkan secara default. Untuk informasi lebih lanjut, lihat Backup storage (dikenai biaya 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 (dikenai biaya 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:

    • Langganan (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 (dikenai biaya untuk penggunaan yang melebihi kuota gratis).

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

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

  • Perpendek periode retensi 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 cadangan log, misalnya dari 7 hari menjadi 3 hari.

    Catatan

    Memperpendek periode retensi cadangan log membawa risiko. Anda tidak dapat melakukan pemulihan berdasarkan titik waktu ke waktu yang lebih awal daripada cadangan log tertua yang masih disimpan.

• Kurangi frekuensi pencadangan (siklus pencadangan) 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 pemulihan berdasarkan titik waktu.

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

• Hapus set cadangan yang tidak diperlukan dari recycle bin kluster 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 atur untuk Level-1 Backup atau Level-2 Backup di bawah Data Backup dalam 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.

Pada tab Backup Sets, kolom Backup Size menampilkan ukuran setiap catatan cadangan (misalnya, 30,53 MB atau 22,50 MB). Di bagian atas halaman juga ditampilkan total ukuran cadangan level-1 (snapshot) dan kuota gratis.

Jika Anda memilih untuk mempertahankan set cadangan saat merilis kluster, Anda dapat melihatnya di recycle bin kluster 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 Layanan Cadangan Database Alibaba Cloud (DBS) untuk menyimpan file cadangan PolarDB for MySQL di OSS. Lakukan langkah-langkah berikut:

  1. Di OSS console, 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 pencadangan. 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 di 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, pencadangan tidak dipicu, sehingga tidak ada catatan yang muncul di daftar cadangan log redo.

Didukung.

Tidak, Anda tidak dapat melakukannya. Pemulihan berdasarkan titik waktu pertama-tama memulihkan cadangan data lengkap dari 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.