ApsaraDB RDS：Memulihkan data dari instans ApsaraDB RDS for MySQL dari file cadangan logis ke instans MySQL yang dikelola sendiri

Prasyarat

• Instans RDS Anda harus memenuhi persyaratan berikut:

  • Instans RDS menjalankan MySQL 8.0, MySQL 5.7, MySQL 5.6, atau MySQL 5.5.

  • Seri: Seri Ketersediaan Tinggi (HA).

  • Instans RDS menggunakan SSD lokal.

  Catatan

  Anda dapat pergi ke halaman Informasi Dasar instans RDS untuk melihat informasi di atas.

• File cadangan logis telah dibuat untuk instans RDS. Untuk informasi lebih lanjut, lihat Konfigurasikan kebijakan pencadangan otomatis untuk instans ApsaraDB RDS for MySQL.

Lingkungan runtime

Instans yang dikelola sendiri diinstal dalam sistem operasi Linux 64-bit dan menjalankan versi MySQL yang sama dengan instans RDS. Dalam topik ini, CentOS 7 dan MySQL 5.7 digunakan sebagai contoh.

Prosedur

1. Buka halaman Instans. Di bilah navigasi atas, pilih wilayah tempat instans RDS berada. Kemudian, temukan instans RDS dan klik ID instans tersebut.

2. Di panel navigasi sisi kiri, klik Backup and Restoration.

3. Dalam daftar Base Backups > Data Backup, temukan file cadangan logis yang ingin Anda unduh dan klik Download Instance Backup File di kolom Actions.

   Catatan

   • Anda harus secara manual membuat cadangan logis. Untuk informasi lebih lanjut, lihat Secara manual mencadangkan instans ApsaraDB RDS for MySQL.

   • Jika tombol Download Instance Backup File tidak ditampilkan, periksa apakah instans RDS Anda mendukung unduhan cadangan.

4. Dalam kotak dialog Download Instance Backup File, klik Copy di sebelah kanan URL unduhan eksternal untuk menyalin URL tersebut.

   Penting

   • Kuota gratis untuk unduhan cadangan melalui Internet disediakan. Jika jumlah lalu lintas yang Anda konsumsi untuk mengunduh file cadangan melalui Internet melebihi kuota gratis, Anda akan dikenakan biaya untuk lalu lintas tambahan yang Anda konsumsi. Untuk informasi lebih lanjut, lihat Penagihan.

   • Jika instans Elastic Compute Service (ECS) Anda berada di virtual private cloud (VPC) yang sama dengan instans RDS, Anda dapat menggunakan URL internal untuk mengunduh file cadangan logis. Metode unduhan ini lebih cepat dan stabil.

5. Masuk ke sistem operasi Linux tempat database yang dikelola sendiri diterapkan dan jalankan perintah berikut untuk mengunduh file cadangan logis:

   wget -c '<URL unduhan eksternal file cadangan data>' -O <Nama file kustom>.tar

   Catatan

   • Opsi -c mengaktifkan fitur unduhan yang dapat dilanjutkan.

   • Opsi -O menentukan bahwa file cadangan logis yang diunduh disimpan berdasarkan nama file yang ditentukan.

6. Ekstrak file cadangan logis, termasuk file terkompresi dari database sistem dan database yang dibuat pengguna.

   1. Jalankan perintah berikut untuk mengekstrak file cadangan:

      tar xvf <Nama file kustom>.tar -C /tmp

      Catatan

      • Jika pesan kesalahan seperti This does not look like a tar archive ditampilkan selama proses ekstraksi, periksa apakah file yang Anda unduh adalah file cadangan logis dari instans RDS.

      • Jika pesan kesalahan seperti Wrote only 512 of 10240 bytes. Exiting with failure status due to previous errors ditampilkan selama proses ekstraksi, periksa apakah ruang disk Anda penuh. Anda dapat mengubah konfigurasi untuk memperluas ruang disk dan mencoba lagi.

   2. Jalankan perintah berikut untuk melihat struktur direktori setelah ekstraksi:

      tree /tmp/backup_root/  # Ganti dengan direktori root aktual setelah ekstraksi

      Contoh struktur file cadangan multi-level:

      /tmp/backup_root/
      ├── database1/   # Direktori database target 1
      │ ├── schema.sql # File struktur database
      │ └── data.sql   # File data
      ├── database2/   # Direktori database target 2
      │ ├── schema.sql
      │ └── data.sql
      └── config.txt    # Metadata cadangan (tidak diperlukan)

7. Jalankan perintah berikut untuk masuk ke direktori database target:

   cd /tmp/backup_root/database_name  # Ganti dengan nama database aktual

8. Ekstrak file terkompresi dari database tujuan yang ingin Anda pulihkan (dengan ekstensi .sql.gz) dengan menjalankan perintah berikut:

   gzip -d schema.sql.gz  # Ekstrak file struktur
   gzip -d data.sql.gz    # Ekstrak file data

   Catatan

   File .sql yang diperoleh dari ekstraksi akan diimpor pada Langkah 10.

9. Masuk ke database dan buat database kosong dengan menjalankan perintah berikut:

   Catatan

   Pengguna yang digunakan dalam langkah-langkah berikutnya harus memiliki izin untuk mengeksekusi semua pernyataan SQL dalam file .sql.

   mysql -u user -p<Kata sandi database>
   create database <Nama database kosong>;
   exit

10. Jalankan perintah berikut untuk mengimpor file .sql ke dalam database:

    # Impor skema tabel
    mysql -u user -p <Nama database kosong> < schema.sql
    
    # Impor data
    mysql -u user -p <Nama database kosong> < data.sql

    Catatan

    • Setelah perintah di atas berhasil dijalankan, sistem akan menampilkan pesan yang meminta Anda memasukkan kata sandi. Masukkan kata sandi dan tekan Enter.

    • Jika pesan kesalahan "Can't find master key from keyring" ditampilkan, periksa apakah instans RDS memenuhi semua prasyarat.

11. Verifikasi hasil pemulihan. Jika data ditampilkan di database, migrasi berhasil.

    mysql -u user -p
    mysql> USE <Nama database kosong>;
    mysql> SHOW TABLES;       # Periksa apakah tabel ada
    mysql> SELECT COUNT(*) FROM <Nama tabel>;  # Verifikasi volume data

FAQ

• Mengapa instans RDS saya tidak memiliki file cadangan logis?

  Secara default, ApsaraDB RDS membuat cadangan fisik. Anda harus secara manual membuat cadangan logis jika diperlukan. Untuk informasi lebih lanjut, lihat Konfigurasikan kebijakan pencadangan otomatis untuk instans ApsaraDB RDS for MySQL.

• Mengapa nilai Restore Point in Time adalah 0 saat saya mengunduh file cadangan logis?

  File cadangan fisik dan file cadangan log dari instans ApsaraDB RDS for MySQL dapat digunakan untuk memulihkan data ke titik waktu tertentu. Oleh karena itu, nilai Restore Point in Time (timestamp) tertentu ditampilkan. File cadangan logis tidak dapat digunakan untuk memulihkan data ke titik waktu tertentu. Oleh karena itu, nilai Consistent Time adalah 0.

• Bagaimana cara menyelesaikan kesalahan ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.?

  Masalah ini terjadi karena GTID. Anda dapat menggunakan metode berikut untuk menyelesaikan masalah:

  • Aktifkan fitur GTID. Kemudian, ulangi langkah-langkah di bagian "Prosedur" dari topik ini untuk memulihkan data.

  • Jika Anda tidak ingin mengaktifkan fitur GTID, Anda dapat memberi komentar pada semua konten GTID_PURGED dalam file impor (dengan ekstensi .sql). Kemudian, ulangi langkah-langkah di bagian "Prosedur" dari topik ini untuk memulihkan data.

  • Jika Anda tidak perlu mereplikasi data antara instans utama dan instans sekunder, Anda dapat masuk ke database dan menjalankan perintah RESET MASTER. Kemudian, ulangi langkah-langkah di bagian "Prosedur" dari topik ini untuk memulihkan data.

• Bagaimana cara menyelesaikan kesalahan ERROR 3546 (HY000) at line 26: @@GLOBAL.GTID_PURGED cannot be changed: the added gtid set must not overlap with @@GLOBAL.GTID_EXECUTED?

  Jika file impor (dengan ekstensi .sql) berisi informasi GTID, database tidak boleh berisi informasi GTID lainnya. Masuk ke database dan jalankan perintah RESET MASTER untuk mereset database. Kemudian, ulangi langkah-langkah di bagian "Prosedur" dari topik ini untuk memulihkan data.

  

• Setelah data dipulihkan ke instans yang dikelola sendiri, mengapa data tidak disinkronkan secara otomatis ke instans sekunder dari instans yang dikelola sendiri?

  Anda dapat memeriksa apakah file impor (dengan ekstensi .sql) berisi SESSION.SQL_LOG_BIN= 0. Pengaturan ini mencegah operasi pada instans utama disinkronkan ke instans sekunder.