PolarDB:Pemulihan database dan tabel: Pemulihan berdasarkan titik waktu

Lingkup penerapan

Set cadangan tersedia. Pemulihan berdasarkan titik waktu pertama-tama memulihkan cadangan penuh terbaru yang diambil sebelum titik waktu yang dipilih ke kluster, lalu memutar ulang log redo untuk menerapkan data inkremental hingga mencapai titik waktu tersebut. Untuk mempercepat pemulihan, Anda dapat mengaktifkan enhanced backup guna memperpendek interval cadangan dan meningkatkan kerapatan cadangan.

Skenario

Catatan penggunaan

• Pemulihan berdasarkan titik waktu mengacu pada pemilihan titik waktu tertentu untuk memulihkan tabel database. Setelah pemulihan, tabel database hanya berisi data hingga titik waktu tersebut, sehingga data dalam database konsisten dengan kondisi pada titik waktu tersebut.

• Mode "Restore to a past point in time" dalam fitur pemulihan database dan tabel hanya mendukung pemulihan dari titik waktu masa lalu pada cadangan tingkat pertama. Pemulihan dari cadangan tingkat kedua tidak didukung.

• Operasi pemulihan database dan tabel gagal dalam skenario berikut.

  • Nama database atau tabel yang ditentukan sudah ada di kluster asal.

  • Antara waktu pembuatan set cadangan dan titik waktu pemulihan, tabel yang akan dipulihkan telah dihapus, atau kluster berisi database atau tabel dengan nama yang sama dengan database atau tabel tujuan.

• Pemulihan database dan tabel hanya memulihkan tabel tertentu. Pastikan Anda telah memilih semua tabel yang perlu dipulihkan.

  Catatan

  Jika Anda tidak dapat menentukan semua tabel yang terlibat, kami menyarankan Anda memulihkan data historis seluruh kluster ke kluster baru, lalu memigrasikan data tersebut ke kluster asal. Untuk informasi lebih lanjut, lihat Restore from a backup set dan Restore a cluster to a point in time.

• Jika Anda tidak memulihkan seluruh database, maksimal 100 tabel dapat dipulihkan sekaligus untuk setiap database. Jika Anda memulihkan seluruh database, semua tabel dalam database tersebut akan dipulihkan.

  Catatan

  • Jika terlalu banyak tabel dipulihkan sekaligus, proses pemulihan akan memakan waktu lama. Oleh karena itu, kami menyarankan agar Anda tidak memulihkan terlalu banyak tabel sekaligus.

  • Jika Anda perlu memulihkan sejumlah besar tabel, kami menyarankan Anda memulihkan data historis lengkap ke kluster baru. Untuk langkah-langkah operasionalnya, lihat Restore from a backup set dan Restore a cluster to a point in time.

• Anda dapat menggunakan fitur pemulihan database dan tabel meskipun kluster memiliki lebih dari 50.000 tabel (termasuk tabel sistem).

  Catatan

  • Fitur ini saat ini sedang dalam tahap peluncuran bertahap. Untuk menggunakannya, Anda dapat Contact us untuk menambahkan kluster ke daftar putih dan mengaktifkan fitur ini.

  • Kueri jumlah tabel (termasuk tabel sistem) dalam kluster. Pernyataan SQL-nya sebagai berikut:

    SELECT COUNT(*) FROM information_schema.tables;

  • Kueri jumlah tabel sistem dalam kluster. Pernyataan SQL-nya sebagai berikut:

    SELECT COUNT(*) FROM information_schema.tables WHERE table_schema IN ('sys', 'performance_schema', 'mysql', 'information_schema', '__recycle_bin__');

• Pemulihan database dan tabel tidak mendukung pemulihan trigger. Jika tabel asal memiliki trigger yang dikonfigurasi, trigger tersebut tidak akan dipulihkan.

• Pemulihan database dan tabel tidak mendukung pemulihan foreign key. Jika tabel asal memiliki foreign key yang dikonfigurasi, foreign key tersebut tidak akan dipulihkan.

• Kami menyarankan Anda melakukan pemulihan data selama jam sepi.

Langkah 1: Identifikasi waktu kesalahan operasi

Jika Anda sudah mengetahui waktu operasi tidak disengaja tersebut, Anda dapat melewati langkah ini. Jika tidak yakin dengan waktu pastinya, ikuti petunjuk berikut untuk menentukannya.

Metode 1: SQL Explorer

Jika Anda telah mengaktifkan SQL Explorer untuk kluster PolarDB for MySQL Cluster Edition Anda, Anda dapat menggunakan fitur ini untuk melihat log audit dan menentukan waktu operasi tidak disengaja tersebut.

SQL Explorer hanya dapat menampilkan log SQL yang dihasilkan setelah fitur tersebut diaktifkan. Jika SQL Explorer belum diaktifkan pada kluster saat insiden terjadi, gunakan Metode 2.

Metode 2: Ambil dan urai binary log secara remote

1. Aktifkan binary logging untuk kluster. Untuk petunjuk detail, lihat Enable binary logging.

   Catatan

   Anda harus mengaktifkan binary logging untuk kluster sebelum dapat melihat dan mengambil binary log. Jika tidak, akan dikembalikan error You are not using binary logging.

2. Instal MySQL di server lokal Anda dan hubungkan ke kluster menggunakan client MySQL. Untuk petunjuk detail, lihat Connect to a database cluster. Topik ini menggunakan sistem Linux sebagai contoh.

   root@xxx:~# mysql -h xxx-polardb.rwlb.rds.aliyuncs.com -P3306 -utest_api -p
   Enter password:
   Welcome to the MySQL monitor.  Commands end with ; or \g.
   Your MySQL connection id is xxx
   Server version: 8.0.13 Source distribution
   Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
   Oracle is a registered trademark of Oracle Corporation and/or its
   affiliates.  Other names may be trademarks of their respective
   owners.
   Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
   mysql>

3. Di client MySQL yang terhubung, jalankan perintah berikut untuk melihat daftar file binary log untuk kluster target:

   show binary logs;

   Perintah tersebut mengembalikan output berikut:

   +------------------+-----------+
   | Log_name         | File_size |
   +------------------+-----------+
   | mysql-bin.000005 |      2639 |
   +------------------+-----------+
   1 row in set (0.00 sec)

4. Ambil binary log secara remote dan simpan ke mesin lokal Anda.

   Topik ini menggunakan sistem Linux sebagai contoh. Pertama, jalankan exit untuk keluar dari client MySQL. Lalu, jalankan perintah berikut untuk mengambil binary log.

   mysqlbinlog -u<username> -p<password> -h<endpoint> --read-from-remote-server --raw mysql-bin.******

   Parameter	Deskripsi	Contoh
   -u	Username akun database di kluster.	test_api
   -p	Password akun. Jika Anda biarkan kosong, Anda akan diminta memasukkannya setelah menjalankan perintah.	TestPwd123
   -h	Titik akhir publik kluster. Catatan Jika titik akhir kluster Anda menggunakan port default 3306, Anda dapat menghilangkan nomor port. Jika tidak, Anda harus menambahkan nomor port ke titik akhir tersebut. Saat ini, Anda hanya dapat mengambil binary log secara remote melalui titik akhir publik node utama atau titik akhir kluster (termasuk titik akhir kluster default dan kustom). Untuk mengetahui cara mengajukan titik akhir publik, lihat Manage endpoints.	test-polardb.rwlb.rds.aliyuncs.com
   --read-from-remote-server	Menunjukkan bahwa binary log dibaca dari server MySQL, bukan dari file log lokal.	--read-from-remote-server
   --raw	Menunjukkan bahwa file binary log yang diambil dicetak dalam format aslinya, bukan sebagai data yang telah diurai.	--raw
   mysql-bin.******	Nama file binary log target, seperti yang tercantum dalam kolom Log_name dari perintah show binary logs;.	mysql-bin.000005

   Contoh:

   mysqlbinlog -utest_api -p -htest-polardb.rwlb.rds.aliyuncs.com --read-from-remote-server --raw mysql-bin.000005

5. Jalankan perintah berikut untuk melihat isi file binary log menggunakan tool mysqlbinlog:

   mysqlbinlog -vv --base64-output=decode-rows mysql-bin.****** | more

   Catatan

   • -vv: Menampilkan pernyataan SQL spesifik dan komentar.

   • --base64-output=decode-rows: Mengurai file binary log.

   Outputnya mirip dengan berikut:

   [root@iZxxx ~]# mysqlbinlog -vv --base64-output=decode-rows mysql-bin.000110 | more
   /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
   /*!40019 SET @@session.max_insert_delayed_threads=0*/;
   /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
   DELIMITER /*!*/;
   # at 4
   #160217 23:04:37 server id 2802943055  end_log_pos 107  Start: binlog v 4, server v 5.5.18.1-log created 160217 23:04:37
   # at 107
   #160217 23:04:38 server id 2802943055  end_log_pos 171  Query    thread id=584632    exec time=0    error code=0
   SET TIMESTAMP=1xxx8/*!*/;
   SET @@session.pseudo_thread_id=584632/*!*/;
   SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
   SET @@session.sql_mode=2097152/*!*/;
   SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
   /*!\C utf8 *//*!*/;
   SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
   SET @@session.lc_time_names=0/*!*/;
   SET @@session.collation_database=DEFAULT/*!*/;
   BEGIN
   /*!*/;
   # at 171

6. Setelah Anda mengambil isi file binary log, Anda dapat mengurai binary log.

Langkah 2: Mulai pemulihan database dan tabel

1. Login ke PolarDB console。Di panel navigasi kiri, klik Clusters. Pilih Region tempat kluster dideploy, lalu klik ID kluster untuk membuka halaman detail kluster。

2. Di panel navigasi kiri, pilih Settings and Management > Backup and Restoration lalu klik Restore Databases/Tables.

3. Di kotak dialog yang muncul, atur Restoration Type ke Point in Time, lalu pilih titik waktu tujuan pemulihan Restoration Time.

   Catatan

   • Titik waktu yang Anda pilih untuk Restoration Time harus berada dalam rentang Restore To. Selain itu, tabel yang akan dipulihkan harus ada dalam set cadangan penuh terbaru yang diambil sebelum titik waktu tersebut agar fitur Point in Time berfungsi dengan baik. Rentang titik waktu yang dapat dipulihkan bergantung pada periode Log Retention Period (Days) dalam pengaturan cadangan, yang secara default adalah 7 hari.

   • Fitur pemulihan database dan tabel menyediakan tiga konfigurasi kecepatan berdasarkan konsumsi IOPS: Quick, Standard, dan Secure. Pilih konfigurasi sesuai kebutuhan bisnis Anda. Untuk perkiraan durasi pemulihan setiap konfigurasi kecepatan, lihat Referensi pengujian kecepatan pemulihan database dan tabel.

     • Quick: Saat data dipulihkan ke kluster saat ini, sejumlah besar IOPS mungkin dikonsumsi. Kami menyarankan Anda memilih konfigurasi ini selama jam sepi.

     • Standard (direkomendasikan untuk kluster dengan lebih dari 4 core): Saat data dipulihkan ke kluster saat ini, sejumlah IOPS moderat mungkin dikonsumsi.

     • Secure (direkomendasikan untuk kluster dengan 4 core atau kurang): Saat data dipulihkan ke kluster saat ini, hanya sejumlah kecil IOPS yang dikonsumsi, tetapi kecepatan pemulihan mungkin terpengaruh signifikan.

     Untuk kluster dengan 4 core atau kurang, kami menyarankan Anda memverifikasi bahwa innodb_io_capacity dan innodb_io_capacity_max diatur ke nilai yang sesuai dengan spesifikasi kluster. Untuk IOPS maksimum yang didukung setiap spesifikasi kluster, lihat Spesifikasi node komputasi untuk Edisi Perusahaan dan Spesifikasi node komputasi untuk Edisi Standar. Kami menyarankan Anda menggunakan kecepatan Secure untuk pemulihan.

4. Di bagian Databases and Tables to Restore, pilih database tujuan di sisi kiri dan tabel tujuan di sisi kanan.

   Catatan

   • Jika Anda tidak menentukan nama database atau tabel baru, sistem akan menambahkan _backup ke nama database atau tabel asli untuk menghasilkan nama database dan tabel baru secara otomatis. Misalnya, jika nama tabel asli adalah test, nama tabel baru yang dihasilkan secara otomatis adalah test_backup.

   • Jika Anda memilih database tujuan tetapi tidak menentukan tabel, semua tabel dalam database tersebut akan dipulihkan secara default.

5. Setelah memastikan Anda telah memilih database dan tabel yang ingin dipulihkan, klik OK.

Langkah 3: Verifikasi data yang dipulihkan

Setelah pemulihan database dan tabel selesai, Anda dapat login ke kluster untuk memverifikasi data yang dipulihkan.

Anda dapat login ke kluster melalui DMS atau menggunakan client lain atau CLI. Topik ini menjelaskan cara login ke kluster melalui DMS untuk verifikasi. Untuk metode lain, lihat Connect to a cluster.

1. Di pojok kanan atas halaman Basic Information kluster, klik Log on to Database.

2. Di kotak dialog yang muncul, masukkan Database Account dan Database Password kluster, lalu klik Search.

3. Setelah login ke DMS, refresh halaman. Di panel navigasi kiri, klik Logged in instance.

4. Di daftar Logged in instance, klik nama kluster tujuan, lalu cari dan klik ganda nama database tujuan untuk beralih ke database tersebut guna pengelolaan.

5. Temukan data yang terkena operasi tidak disengaja dan verifikasi apakah data tersebut telah dipulihkan ke kondisi sebelum operasi tersebut, serta apakah data lainnya juga konsisten dengan kondisi sebelum operasi tersebut.