Pulihkan data MySQL penuh - ApsaraDB RDS - Alibaba Cloud Documentation Center

Jika Anda memiliki cadangan data dan cadangan log untuk instans sumber, Anda dapat memulihkannya ke instans baru. Ini berguna untuk skenario seperti pemulihan dari operasi tidak sengaja atau analisis data historis.

Prasyarat

Instans sumber harus memenuhi persyaratan berikut:

Instans berada dalam status Running dan tidak terkunci.
Tidak ada tugas migrasi yang sedang berjalan.
Setidaknya satu cadangan telah selesai. ApsaraDB RDS melakukan pencadangan otomatis secara default. Untuk informasi lebih lanjut tentang metode pencadangan, lihat Ikhtisar solusi pencadangan.
Untuk pemulihan berdasarkan titik waktu, cadangan log harus diaktifkan. Untuk informasi lebih lanjut, lihat Cadangan log untuk instans ApsaraDB RDS for MySQL.
Untuk memulihkan data dari set cadangan, instans sumber harus memiliki setidaknya satu cadangan fisik. Untuk informasi lebih lanjut, lihat Pencadangan otomatis.

Cara kerja

Item	Deskripsi
Pemulihan cakupan	Seluruh instans dipulihkan.
Konfigurasi instans baru	Pengaturan daftar putih, pengaturan pencadangan, dan pengaturan parameter instans baru konsisten dengan instans sumber.
Informasi Akun Instance Baru	Instans baru berisi informasi akun dari instans sumber pada titik waktu pemulihan yang dipilih atau dari set cadangan yang dipilih.
Data instans baru	Data dalam instans baru identik dengan data dalam file cadangan yang digunakan untuk pemulihan.
Titik pemulihan	Jika cadangan log dinonaktifkan, Anda hanya dapat memulihkan data ke titik waktu saat cadangan data yang ada dibuat. Jika pencadangan log reguler diaktifkan, Anda dapat memulihkan data ke titik waktu apa pun dalam periode retensi cadangan log. Jika pemulihan berdasarkan titik waktu (versi tingkat lanjut dari pencadangan log) diaktifkan, Anda dapat memulihkan data ke titik waktu apa pun dalam periode yang ditentukan oleh Days Available for Point-in-time Restore. Catatan Untuk melihat kebijakan retensi cadangan log saat ini, lihat Cadangan log untuk instans ApsaraDB RDS for MySQL. Untuk informasi lebih lanjut, lihat Perbedaan antara pemulihan berdasarkan titik waktu dan pencadangan log.
Durasi pemulihan	Durasi pemulihan dipengaruhi oleh banyak faktor. Misalnya, diperlukan sekitar 3 jam untuk memulihkan data sebesar 200 GB. Untuk informasi lebih lanjut, lihat bagian FAQ dalam topik ini.

Penagihan

Pemulihan data membuat instans baru, yang dikenai biaya.

Catatan

Untuk penggunaan sementara, Anda dapat membuat instans pay-as-you-go atau Serverless, migrasikan data ke instans sumber, lalu rilis instans baru tersebut.
Penagihan untuk instans dimulai setelah instans dibuat.

Aktifkan fitur

Anda tidak perlu mengaktifkan fitur ini secara manual. Setelah instans baru dibuat, sistem secara otomatis melakukan pencadangan berkala. Anda dapat menggunakan cadangan data dan cadangan log yang dihasilkan untuk memulihkan instans.

Prosedur

Saat Anda memulihkan data dari cadangan instans sumber, sebuah instans baru akan dibuat. Proses ini tidak memengaruhi kinerja instans sumber.

Buka halaman Instances. Di bilah navigasi atas, pilih wilayah tempat instans RDS berada. Lalu, temukan instans RDS dan klik ID instans tersebut.
Di panel navigasi kiri, klik Restoration.
Di pojok kiri atas halaman, klik Restore Instance (Previously Clone Instance).

Catatan
Anda juga dapat membuka halaman Basic Information dan klik Restore Instance di bagian Instance Distribution.

Di halaman Restore Database, pilih titik waktu pemulihan atau set cadangan, lalu konfigurasikan resource dasar untuk instans baru.

Parameter	Description
Billing Method	Subscription : Metode prabayar yang cocok untuk kebutuhan jangka panjang. Semakin lama masa subscription, semakin besar diskon yang diberikan. Pay-As-You-Go: Metode pascabayar (ditagih per jam) yang cocok untuk kebutuhan jangka pendek. Anda dapat melepas instans saat tidak lagi diperlukan.
Restore Mode	By Backup Set: Memulihkan data dari set cadangan tertentu. Cadangan logis tidak didukung. By Time: Memulihkan data ke titik waktu apa pun dalam periode retensi. Fitur ini memerlukan agar log backup diaktifkan.
Product Type	Jika instans sumber adalah Basic Edition, parameter ini tidak tersedia. Jika instans sumber adalah High-availability Edition: Jika Storage Type adalah Enhanced SSD atau General ESSD, Anda dapat memilih Standard atau YiTian. Untuk informasi lebih lanjut, lihat Product types. Jika Storage Type adalah Local SSD, hanya Standard yang didukung. Jika instans sumber adalah Cluster Edition, Anda dapat memilih Standard atau YiTian.
Zone	Anda dapat mengonfigurasi instans untuk Single-zone Deployment atau Multi-zone Deployment. Single-zone Deployment: Node primary dan secondary berada dalam zona yang sama. Multi-zone Deployment (disarankan): Node primary dan secondary berada di zona berbeda untuk disaster recovery. Catatan Setelah instans dibuat, Anda dapat melihat informasi node primary dan secondary pada halaman Service Availability. Instans Edisi Dasar hanya mendukung penerapan single-zone.
Instance Type	General-purpose: Menyediakan sumber daya memori dan I/O khusus, tetapi berbagi sumber daya CPU dan penyimpanan dengan instans tujuan umum lainnya pada server yang sama. Dedicated: Menyediakan sumber daya CPU, memori, penyimpanan, dan I/O yang sepenuhnya khusus. Instans dedicated-host tingkat atas secara eksklusif menempati seluruh sumber daya pada satu server. Catatan Setiap tipe instans memiliki jumlah core CPU, ukuran memori, jumlah maksimum koneksi, dan IOPS maksimum yang sesuai. Untuk informasi lebih lanjut, lihat Primary instance types.
Storage Capacity	Mencakup ruang untuk data, file sistem, file log biner, dan file transaksi. Dapat disesuaikan dengan penambahan 5 GB.

Klik Next: Instance Configuration, konfigurasikan jenis jaringan dan kelompok sumber daya untuk instans, lalu atur parameter berikut.

Parameter	Deskripsi
Network Type	Classic Network: Jenis jaringan tradisional. VPC (disarankan): Virtual Private Cloud (VPC) adalah lingkungan jaringan terisolasi yang menawarkan keamanan dan kinerja lebih tinggi daripada jaringan klasik. Jika Anda memilih VPC, Anda juga harus memilih VPC dan VSwitch of Primary Node yang sesuai. Jika Anda mengonfigurasi Multi-zone Deployment pada langkah Basic Resources sebelumnya, Anda juga perlu memilih VSwitch of Secondary Node. Catatan Pastikan instans RDS dan instans ECS yang ingin Anda hubungkan berada dalam jenis jaringan yang sama. Jika Anda memilih VPC, keduanya juga harus berada dalam VPC yang sama. Jika tidak, keduanya tidak dapat berkomunikasi melalui jaringan internal.
Resource Group	Kelompok sumber daya adalah mekanisme untuk mengelola resource berdasarkan kelompok di bawah Akun Alibaba Cloud Anda. Ini menyederhanakan pengelompokan resource dan manajemen otorisasi untuk satu akun. Anda dapat memilih kelompok sumber daya yang sudah ada atau membuat yang baru. Jika Anda tidak perlu mengelola resource dalam kelompok, pilih Default Resource Group.

Klik Next: Confirm Order.
Konfirmasi Parameter Configuration, pilih Quantity dan Duration (hanya untuk instans langganan), klik Pay Now, lalu selesaikan pembayaran.

Catatan
Untuk instans langganan, kami menyarankan Anda memilih Auto-renewal. Ini menghemat usaha Anda untuk memperpanjang instans secara manual dan mencegah gangguan layanan akibat lupa memperpanjang.
(Opsional) Setelah instans baru dibuat, Anda dapat login ke instans tersebut untuk memverifikasi data.

Perbaiki data di instans sumber

Setelah data dipulihkan ke instans baru, Anda dapat menggunakan Data Transmission Service (DTS) untuk migrasikan sebagian atau seluruh database dan tabel ke instans sumber guna memperbarui data di instans sumber.

Catatan

Saat membuat tugas migrasi data, tentukan instans baru yang dipulihkan sebagai sumber dan instans sumber sebagai tujuan. Untuk kedua sumber dan tujuan, pilih Alibaba Cloud instance sebagai Access method.

Operasi terkait

Topik ini menjelaskan cara memulihkan seluruh instans. Jika Anda perlu memulihkan database atau tabel tertentu, lihat Pulihkan database dan tabel individual. Untuk solusi pemulihan data lainnya, lihat Ikhtisar solusi pemulihan data.

Untuk memulihkan data ke instans sumber, instans lain yang sudah ada, atau database yang dikelola sendiri, lihat solusi berikut:

Penting

ApsaraDB RDS for MySQL tidak mendukung pemulihan langsung file cadangan yang diunduh ke instans yang sudah ada. Anda harus terlebih dahulu memulihkannya ke instans baru, memverifikasi data, lalu migrasikan ke instans lain yang sudah ada.

Tujuan pemulihan	Metode pemulihan
Pulihkan ke instans sumber	Metode 1: Pertama, pulihkan ke instans baru. Setelah memverifikasi data, migrasikan sebagian atau seluruh database dan tabel ke instans sumber. Metode 2: Gunakan fitur database and table restore untuk memulihkan semua data ke instans sumber. Metode 3: Pulihkan dari cadangan logis yang dibuat oleh Database Backup (DBS). Untuk informasi lebih lanjut, lihat Pulihkan dari cadangan logis.
Pulihkan ke instans lain yang sudah ada	Metode 1: Pertama, pulihkan ke instans baru. Setelah memverifikasi data, migrasikan data ke instans lain yang sudah ada. Metode 2: Pulihkan dari cadangan logis yang dibuat oleh DBS. Untuk informasi lebih lanjut, lihat Pulihkan dari cadangan logis.
Pulihkan ke database yang dikelola sendiri	Metode 1: Pertama, pulihkan ke instans baru. Setelah memverifikasi data, migrasikan data ke database yang dikelola sendiri. Metode 2: Pulihkan dari cadangan logis yang dibuat oleh DBS. Untuk informasi lebih lanjut, lihat Pulihkan dari cadangan logis. Metode 3: Pertama, unduh set cadangan. Lalu, pulihkan file cadangan ke database yang dikelola sendiri. Untuk informasi lebih lanjut, lihat Pulihkan cadangan fisik instans ApsaraDB RDS for MySQL ke database yang dikelola sendiri, Pulihkan cadangan logis instans ApsaraDB RDS for MySQL ke database yang dikelola sendiri, atau Pulihkan cadangan snapshot instans ApsaraDB RDS for MySQL ke database yang dikelola sendiri.

Untuk informasi tentang pemulihan data untuk engine database lain, lihat topik berikut:

FAQ

Apa yang harus saya lakukan jika saya tidak sengaja menghapus satu atau beberapa database?

Anda dapat melakukan database and table restore. Untuk instans yang tidak mendukung fitur ini, Anda dapat mengikuti petunjuk dalam topik ini untuk memulihkan seluruh data ke instans baru. Setelah verifikasi, migrasikan data kembali ke instans sumber.

Bisakah saya memulihkan instans ApsaraDB RDS for MySQL ke titik waktu tertentu?

Bisa. Jika pencadangan log diaktifkan, Anda dapat memulihkan ke titik waktu apa pun dalam periode retensi pencadangan log. Jika pencadangan log dinonaktifkan, Anda hanya dapat memulihkan data ke titik waktu saat cadangan data yang ada dibuat.

Bisakah saya melakukan pemulihan berdasarkan titik waktu jika saya tidak memiliki cadangan data?

Tidak bisa. Pemulihan berdasarkan titik waktu pertama-tama memulihkan cadangan data penuh yang dibuat sebelum titik waktu yang ditentukan, lalu menerapkan data inkremental dari log biner untuk mencapai titik tersebut. Proses ini memerlukan cadangan data.

Periode retensi cadangan saya diatur menjadi 7 hari. Bisakah saya memulihkan data dari waktu yang lebih awal?

Tidak bisa. Cadangan secara otomatis dihapus setelah periode retensi dan tidak dapat dipulihkan.

Periode retensi cadangan saya adalah 7 hari. Bisakah saya menggunakan fitur pelacakan data Data Management (DMS) untuk mengambil cadangan yang dihapus?

Tidak bisa. Fitur pelacakan data bergantung pada log biner untuk memulihkan data. Karena periode retensi Anda 7 hari, log biner yang lebih lama dari itu tidak tersedia. Anda dapat mengubah periode retensi cadangan. Untuk informasi lebih lanjut, lihat Pencadangan otomatis.

Mengapa saya dikenai biaya untuk pemulihan database?

Pemulihan data membuat instans baru, yang dikenai biaya.

Catatan

Untuk penggunaan sementara, Anda dapat membuat instans pay-as-you-go atau Serverless, migrasikan data ke instans sumber, lalu rilis instans baru tersebut.
Penagihan untuk instans dimulai setelah instans dibuat.

Berapa lama waktu yang dibutuhkan untuk memulihkan data ke instans baru?

Waktu yang dibutuhkan untuk memulihkan data ke instans baru bergantung pada volume data dan kondisi jaringan, biasanya berkisar antara beberapa menit hingga beberapa jam. Detailnya sebagai berikut:

Contoh estimasi

Lingkungan uji: Instans Edisi Ketersediaan Tinggi dengan 2 core CPU, memory 4 GB, dan SSD lokal premium.

Operasi	Estimasi waktu
Create instance	5 menit
Configure instance	15 menit
Download backup data	200 GB/jam
Start instance	5 menit
Download binary logs	200 GB/jam
Apply binary logs	Bergantung pada isi log biner.

Catatan

Sebagai contoh, diperlukan sekitar 3 jam untuk memulihkan data sebesar 200 GB. Ini mengasumsikan bahwa pengunduhan data cadangan dan pengunduhan log biner dilakukan secara serial, dan penerapan log biner memerlukan waktu 30 menit.
Untuk pemulihan lebih cepat, Anda dapat mengaktifkan instans sandbox. Sistem secara otomatis menyinkronkan data ke penyimpanan sandbox untuk pemulihan cepat. Untuk informasi lebih lanjut, lihat Emergency recovery for an ApsaraDB RDS for MySQL instance.

Faktor yang memengaruhi

Kecepatan pemulihan dipengaruhi oleh banyak faktor, dan keberhasilan tidak dijamin. Beberapa exception SQL mungkin memerlukan investigasi manual. Faktor utama yang memengaruhi kecepatan pemulihan adalah:

Volume data: Semakin besar volume data, semakin lambat kecepatan pemulihan.
Transaksi besar: Transaksi besar dalam log biner memperlambat proses pemulihan.
Pembaruan hotspot: Pembaruan hotspot dalam log biner memperlambat proses pemulihan.
Batasan kunci asing (FOREIGN KEY): Batasan kunci asing meningkatkan biaya verifikasi dan memperlambat proses pemulihan.
Jumlah log biner: Selama pemulihan berdasarkan titik waktu, semakin banyak log biner yang diperlukan, semakin lambat kecepatan pemulihan.
Jenis penyimpanan: Memulihkan ke disk cloud lebih cepat daripada memulihkan ke SSD lokal premium.
Tipe instans: Instans dengan spesifikasi lebih tinggi memulihkan data lebih cepat.
Versi instans: Versi instans yang berbeda memiliki kebijakan replikasi paralel yang berbeda. Skenario yang tidak mendukung replikasi paralel berjalan dalam mode single-threaded, yang memengaruhi kecepatan pemulihan.

Penting

Selain faktor-faktor di atas, situasi berikut juga dapat menyebabkan kegagalan pemulihan:

Versi engine database instans baru lebih awal daripada instans sumber, yang dapat menyebabkan error parsing pada log biner.
Nama tabel atau kolom yang berisi karakter Cina atau karakter khusus dapat menyebabkan kegagalan pemulihan.
Jika log biner dihapus dari instans sumber, pemulihan tidak dapat diselesaikan.
Jika parameter implicit_primary_key dinonaktifkan di instans sumber, pemulihan tabel tanpa kunci primer akan gagal.

Mengapa saya tidak dapat memilih vSwitch primary selama proses pemulihan?

vSwitch node utama mungkin tidak tersedia pada langkah Jaringan dan Grup Sumber Daya karena tidak ada vSwitch di zona yang Anda pilih pada langkah Konfigurasi Dasar sebelumnya. Anda dapat mengeklik go to the VPC console. untuk membuka konsol VPC dan membuat vSwitch di zona tersebut, lalu memilih vSwitch node utama. Jika saat membuat instance Anda memilih VPC sebagai jenis jaringan dan vSwitch node utama tidak tersedia, klik tautan Create in Console di bawah bidang vSwitch node utama untuk membuka konsol dan membuat vSwitch baru.