Proses keseluruhan dan perkiraan waktu untuk pemulihan database dan tabel - PolarDB

Jika Anda secara tidak sengaja memodifikasi tabel, Anda dapat menggunakan fitur pemulihan database dan tabel untuk memulihkan tabel yang terdampak ke kluster asal.

Anda dapat memulihkan database dan tabel menggunakan Pemulihan berdasarkan titik waktu atau dengan memulihkan dari set cadangan (snapshot). Jika titik pemulihan yang dituju sama dengan waktu pembuatan set cadangan, memulihkan dari set cadangan tersebut lebih praktis. Namun, jika titik pemulihan berbeda dari waktu pembuatan setiap set cadangan yang tersedia, Anda harus menggunakan Pemulihan berdasarkan titik waktu.

Catatan

Alur kerja baru untuk pemulihan database dan tabel, yang mencakup fitur Fast Import, tersedia dalam rilis bertahap untuk kluster PolarDB for MySQL 8.0.1 dengan versi minor 8.0.1.1.49 atau lebih baru.

Proses keseluruhan

Baik menggunakan Pemulihan berdasarkan titik waktu maupun memulihkan dari set cadangan (snapshot), proses utamanya tetap sama. Pertama, sebuah node temporary dibuat dan data dari titik waktu tertentu dipulihkan ke node tersebut. Selanjutnya, data dipulihkan dari node temporary ke kluster asal.

Versi baru fitur pemulihan database dan tabel dirilis pada 3 April 2024. Dibandingkan versi sebelumnya, versi ini mengurangi waktu yang diperlukan untuk memulihkan data ke kluster asal. Data juga secara otomatis disinkronkan ke Hot Standby Clusters dan kluster sekunder GDN, sehingga waktu pemulihan secara signifikan berkurang.

Skenario

Fitur pemulihan database dan tabel mendukung Edisi Perusahaan dan Edisi Standar PolarDB, namun memerlukan versi revisi kluster tertentu. Tabel berikut mencantumkan versi revisi minimum yang diperlukan untuk berbagai skenario.

Fitur Dasar: Versi revisi minimum yang diperlukan untuk mendukung pemulihan database dan tabel.
Proses pemulihan baru: Diperlukan versi revisi yang lebih tinggi untuk memperoleh manfaat dari optimasi kecepatan pada proses pemulihan baru.

Seri Edisi	Versi MySQL	Arsitektur	Fitur Dasar (Versi Revisi Minimum)	Proses Pemulihan Baru (Versi Revisi Minimum)
Enterprise Edition (Cluster Edition)	5.6	X86	`5.6.1.0.25`	`5.6.1.0.42`
	5.7	X86	`5.7.1.0.8`	`5.7.1.0.36`
	8.0.1	X86	`8.0.1.1.14`	`8.0.1.1.46`
	8.0.2	X86	`8.0.2.2.0`	`8.0.2.2.26`
Standard Edition	5.6	X86	`5.6.1.0.42`	`5.6.1.0.42`
	5.7	X86	`5.7.1.0.30`	`5.7.1.0.30`
	8.0.1	X86	`8.0.1.1.38.2`	`8.0.1.1.38.2`
	8.0.1	Yitian (ARM)	`8.0.1.1.41`	`8.0.1.1.41`
	8.0.2	X86	`8.0.2.2.21`	`8.0.2.2.21`

Catatan

Anda dapat melihat versi kernel kluster Anda di bagian Configuration Information pada halaman Basic Information kluster PolarDB for MySQL Anda.

Diagram alur versi lama dan baru

Jika versi revisi kluster Anda memenuhi persyaratan, alur kerja pemulihan database dan tabel yang baru akan digunakan secara otomatis. Diagram berikut menggambarkan perbandingan antara alur kerja lama dan baru.

Catatan

Kami sarankan Anda memulihkan data selama jam-jam sepi.

Waktu perkiraan

Waktu perkiraan untuk setiap langkah

Langkah	Waktu perkiraan
Buat node sementara dan pulihkan data dari set cadangan ke node tersebut.	Sekitar 3 hingga 10 menit.
Pulihkan data inkremental dari redo logs. Catatan Langkah ini hanya diperlukan untuk Pemulihan berdasarkan titik waktu. Waktu yang diperlukan bergantung pada ukuran redo logs yang harus diterapkan.	1,5 GB/menit.
Pulihkan data ke klaster asli.	Untuk perkiraan waktunya, lihat Referensi untuk pengujian kecepatan pemulihan database dan tabel.

Catatan

Data di atas hanya untuk referensi.
Untuk memulihkan data dalam skala terabyte, operasi pemulihan database dan tabel mungkin memakan waktu lama. Untuk pemulihan yang lebih cepat, gunakan fitur pemulihan penuh dari set cadangan. Proses ini biasanya hanya memerlukan beberapa menit. Untuk informasi selengkapnya, lihat Metode 1 untuk pemulihan penuh: Pulihkan data dari set cadangan.

Referensi untuk pengujian kecepatan pemulihan database dan tabel

CPU dan memori (dedicated)	Data uji	innodb_io_capacity	innodb_io_capacity_max	Alur kerja lama			Alur kerja baru			Perbandingan kecepatan: Alur kerja baru vs. lama
				Aktifkan hot standby untuk penyimpanan	Durasi pemulihan	Kecepatan pemulihan	Konfigurasi kecepatan pemulihan	Durasi pemulihan	Kecepatan pemulihan	Hot Standby Cluster diaktifkan (Alur kerja lama)	Peningkatan kecepatan
2 core, 8 GB	Tabel tunggal, sekitar 200 GB	4000	8000	Ya	3 jam 38 menit 25 detik	1,03 GB/menit	Standar	1 jam 43 menit 36 detik	2,16 GB/menit	Ya	110%
				Tidak	2 jam 23 menit 0 detik	1,57 GB/menit				Tidak	38%
4 core, 16 GB	Tabel tunggal, sekitar 200 GB	4000	8000	Ya	3 jam 3 menit 31 detik	1,14 GB/menit	Cepat	54 menit 13 detik	3,70 GB/menit	Ya	225%
										Tidak	88%
							Standar	1 jam 20 menit	2,5 GB/menit	Ya	119%
				Tidak	1 jam 45 menit 53 detik	1,97 GB/menit				Tidak	27%
							Safe	2 jam 12 menit	1,52 GB/menit	Ya	33%
										Tidak	-30%
		8000	16000	Ya	3 jam 3 menit 15 detik	1,14 GB/menit	Cepat	42 menit 18 detik	4,76 GB/menit	Ya	318%
										Tidak	142%
							Standar	54 menit 16 detik	3,70 GB/menit	Ya	225%
				Tidak	1 jam 45 menit 53 detik	1,97 GB/menit				Tidak	88%
							Safe	1 jam 20 menit	2,5 GB/menit	Ya	119%
										Tidak	27%
8 core, 32 GB	Tabel tunggal, sekitar 200 GB	4000	8000	Ya	2 jam 50 menit 56 detik	1,19 GB/menit	Cepat	54 menit 39 detik	3,70 GB/menit	Ya	211%
										Tidak	80%
							Standar	1 jam 21 menit	2,47 GB/menit	Ya	108%
				Tidak	1 jam 38 menit 57 detik	2,05 GB/menit				Tidak	20%
							Safe	2 jam 12 menit	1,52 GB/menit	Ya	28%
										Tidak	-35%
		18000	36000	Ya	2 jam 51 menit 5 detik	1,19 GB/menit	Cepat	41 menit 48 detik	4,88 GB/menit	Ya	310%
										Tidak	273%
							Standar	54 menit 43 detik	3,70 GB/menit	Ya	211%
				Tidak	1 jam 38 menit 33 detik	1,31 GB/menit				Tidak	182%
							Safe	1 jam 21 menit	2,47 GB/menit	Ya	108%
										Tidak	89%
16 core, 64 GB	Tabel tunggal, sekitar 200 GB	4000	8000	Ya	2 jam 55 menit 26 detik	1,17 GB/menit	Cepat	53 menit 28 detik	3,77 GB/menit	Ya	222%
										Tidak	88%
							Standar	1 jam 20 menit	2,5 GB/menit	Ya	114%
				Tidak	1 jam 42 menit 20 detik	2,01 GB/menit				Tidak	24%
							Safe	2 jam 12 menit	1,52 GB/menit	Ya	30%
										Tidak	-32%
		20000	40000	Ya	2 jam 53 menit 49 detik	1,19 GB/menit	Cepat	41 menit 1 detik	4,88 GB/menit	Ya	310%
										Tidak	138%
							Standar	54 menit 5 detik	3,70 GB/menit	Ya	211%
				Tidak	1 jam 40 menit 35 detik	2,05 GB/menit				Tidak	80%
							Safe	1 jam 20 menit	2,5 GB/menit	Ya	110%
										Tidak	22%

Catatan

Kecepatan pemulihan mengacu pada kecepatan data dipulihkan ke kluster asal. Ini tidak termasuk waktu yang diperlukan untuk membuat node temporary atau memulihkan log inkremental dalam proses pemulihan.
Kecepatan pemulihan bergantung pada beberapa faktor: apakah Hot Standby Cluster diaktifkan, spesifikasi node primary, nilai parameter innodb_io_capacity, konfigurasi kecepatan pemulihan, dan jumlah tabel yang dipulihkan.
Anda dapat menyesuaikan kecepatan pemulihan dengan mengubah secara dinamis nilai parameter innodb_io_capacity dan innodb_io_capacity_max. Mengubah nilai parameter ini memiliki efek kecil pada kecepatan pemulihan alur kerja lama, tetapi berdampak besar pada alur kerja baru.
Kecepatan pemulihan dikategorikan ke dalam tiga konfigurasi berdasarkan operasi input/output per detik (IOPS) yang digunakan: Quick, Standard, dan Safe. Nilai IOPS yang lebih tinggi menghasilkan kecepatan pemulihan yang lebih cepat. Peningkatan kecepatan terutama terlihat saat Anda memulihkan tabel besar.
Konfigurasi kecepatan pemulihan memiliki efek kecil pada kecepatan pemulihan alur kerja lama, tetapi berdampak besar pada alur kerja baru.
Karena spesifikasi 2-core, 8 GB bersifat kecil dan memiliki fluktuasi I/O yang tinggi, konfigurasi kecepatan pemulihan mungkin tidak memberikan efek yang nyata. Oleh karena itu, hasil pengujian untuk konfigurasi ini tidak dicantumkan.
Data pengujian di atas tidak mencakup skenario di mana banyak tabel dipulihkan sekaligus. Jika Anda memulihkan banyak tabel secara bersamaan, kecepatan pemulihan juga akan terpengaruh.
Data pengujian di atas hanya sebagai referensi. Kecepatan pemulihan aktual dipengaruhi oleh faktor-faktor seperti model mesin dasar dan kondisi jaringan.