Mysqldump adalah alat pencadangan logis paling populer untuk MySQL. Itu termasuk dalam distribusi MySQL, jadi siap digunakan di semua instance MySQL.
Namun, pencadangan logis bukanlah cara tercepat atau paling hemat ruang untuk mencadangkan basis data MySQL, tetapi memiliki keunggulan besar dibandingkan pencadangan fisik.
Cadangan fisik biasanya semua atau tidak sama sekali jenis cadangan. Meskipun dimungkinkan untuk membuat cadangan sebagian dengan Xtrabackup (kami menjelaskan ini di salah satu posting blog kami sebelumnya), memulihkan cadangan tersebut rumit dan memakan waktu.
Pada dasarnya, jika kita ingin memulihkan satu tabel, kita harus menghentikan seluruh rantai replikasi dan melakukan pemulihan pada semua node sekaligus. Ini adalah masalah besar - akhir-akhir ini Anda jarang dapat menghentikan semua database.
Masalah lainnya adalah tingkat tabel adalah tingkat perincian terendah yang dapat Anda capai dengan Xtrabackup:Anda dapat memulihkan satu tabel tetapi Anda tidak dapat memulihkan sebagian darinya. Pencadangan logis, bagaimanapun, dapat dipulihkan dengan cara menjalankan pernyataan SQL, oleh karena itu dapat dengan mudah dilakukan pada cluster yang sedang berjalan dan Anda dapat (kami tidak akan menyebutnya dengan mudah, tetapi tetap saja) memilih pernyataan SQL mana yang akan dijalankan sehingga Anda dapat melakukan pengembalian sebagian tabel.
Mari kita lihat bagaimana hal ini dapat dilakukan di dunia nyata.
Memulihkan Tabel MySQL Tunggal Menggunakan mysqldump
Pada awalnya, harap diingat bahwa pencadangan sebagian tidak memberikan tampilan data yang konsisten. Saat Anda membuat cadangan tabel terpisah, Anda tidak dapat memulihkan cadangan tersebut ke posisi yang diketahui tepat waktu (misalnya, untuk menyediakan budak replikasi) bahkan jika Anda akan memulihkan semua data dari cadangan. Setelah ini, mari kita lanjutkan.
Kami memiliki tuan dan budak:
Set data berisi satu skema dan beberapa tabel:
mysql> SHOW SCHEMAS;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sbtest |
| sys |
+--------------------+
5 rows in set (0.01 sec)
mysql> SHOW TABLES FROM sbtest;
+------------------+
| Tables_in_sbtest |
+------------------+
| sbtest1 |
| sbtest10 |
| sbtest11 |
| sbtest12 |
| sbtest13 |
| sbtest14 |
| sbtest15 |
| sbtest16 |
| sbtest17 |
| sbtest18 |
| sbtest19 |
| sbtest2 |
| sbtest20 |
| sbtest21 |
| sbtest22 |
| sbtest23 |
| sbtest24 |
| sbtest25 |
| sbtest26 |
| sbtest27 |
| sbtest28 |
| sbtest29 |
| sbtest3 |
| sbtest30 |
| sbtest31 |
| sbtest32 |
| sbtest4 |
| sbtest5 |
| sbtest6 |
| sbtest7 |
| sbtest8 |
| sbtest9 |
+------------------+
32 rows in set (0.00 sec)Sekarang, kita harus membuat cadangan. Ada beberapa cara di mana kita dapat mendekati masalah ini. Kami hanya dapat mengambil cadangan yang konsisten dari seluruh dataset tetapi ini akan menghasilkan satu file besar dengan semua data. Untuk mengembalikan tabel tunggal kita harus mengekstrak data untuk tabel dari file itu. Tentu saja mungkin, tetapi cukup memakan waktu dan cukup banyak operasi manual yang dapat dituliskan tetapi jika Anda tidak memiliki skrip yang tepat, menulis kode ad hoc ketika database Anda sedang down dan Anda berada di bawah tekanan berat adalah belum tentu ide yang paling aman.
Sebaliknya, kita dapat menyiapkan cadangan sedemikian rupa sehingga setiap tabel akan disimpan dalam file terpisah:
[email protected]:~/backup# d=$(date +%Y%m%d) ; db='sbtest'; for tab in $(mysql -uroot -ppass -h127.0.0.1 -e "SHOW TABLES FROM ${db}" | grep -v Tables_in_${db}) ; do mysqldump --set-gtid-purged=OFF --routines --events --triggers ${db} ${tab} > ${d}_${db}.${tab}.sql ; doneHarap diperhatikan bahwa kami menyetel --set-gtid-purged=OFF. Kami membutuhkannya jika nanti kami akan memuat data ini ke database. Jika tidak, MySQL akan mencoba menyetel @@GLOBAL.GTID_PURGED, yang kemungkinan besar akan gagal. MySQL juga akan mengatur SET @@SESSION.SQL_LOG_BIN=0; yang pasti tidak kita inginkan. Pengaturan tersebut diperlukan jika kami akan membuat cadangan yang konsisten dari seluruh kumpulan data dan kami ingin menggunakannya untuk menyediakan node baru. Dalam kasus kami, kami tahu itu bukan cadangan yang konsisten dan tidak ada cara kami dapat membangun kembali apa pun darinya. Yang kami inginkan hanyalah membuat dump yang dapat kami muat di master dan membiarkannya direplikasi ke slave.
Perintah tersebut menghasilkan daftar file sql yang bagus yang dapat diunggah ke cluster produksi:
[email protected]:~/backup# ls -alh
total 605M
drwxr-xr-x 2 root root 4.0K Mar 18 14:10 .
drwx------ 9 root root 4.0K Mar 18 14:08 ..
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest10.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest11.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest12.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest13.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest14.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest15.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest16.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest17.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest18.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest19.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest1.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest20.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest21.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest22.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest23.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest24.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest25.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest26.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest27.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest28.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest29.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest2.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest30.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest31.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest32.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest3.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest4.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest5.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest6.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest7.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest8.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest9.sqlBila Anda ingin memulihkan data, yang perlu Anda lakukan hanyalah memuat file SQL ke dalam master node:
[email protected]:~/backup# mysql -uroot -ppass sbtest < 20200318_sbtest.sbtest11.sqlData akan dimuat ke dalam database dan direplikasi ke semua slave.
Bagaimana Mengembalikan Tabel MySQL Tunggal Menggunakan ClusterControl?
Saat ini ClusterControl tidak menyediakan cara mudah untuk memulihkan hanya satu tabel tetapi masih memungkinkan untuk melakukannya hanya dengan beberapa tindakan manual. Ada dua opsi yang bisa Anda gunakan. Pertama, cocok untuk sejumlah kecil tabel, pada dasarnya Anda dapat membuat jadwal di mana Anda melakukan pencadangan sebagian dari tabel terpisah satu per satu:
Di sini, kami mengambil cadangan tabel sbtest.sbtest1. Kami dapat dengan mudah menjadwalkan pencadangan lain untuk tabel sbtest2:
Atau kita dapat melakukan pencadangan dan memasukkan data dari satu skema ke dalam file terpisah:
Sekarang Anda dapat menemukan data yang hilang dengan tangan di file, memulihkan backup ini ke server terpisah atau biarkan ClusterControl melakukannya:
Anda menjaga server tetap aktif dan Anda dapat mengekstrak data yang Anda ingin memulihkan menggunakan mysqldump atau SELECT ... INTO OUTFILE. Data yang diekstraksi tersebut akan siap untuk diterapkan pada kluster produksi.
