Как да възстановим една MySQL таблица с помощта на mysqldump?

Mysqldump е най-популярният инструмент за логично архивиране за MySQL. Той е включен в дистрибуцията на MySQL, така че е готов за използване във всички MySQL екземпляри.

Логическите архиви обаче не са най-бързият, нито най-ефективният за пространството начин за архивиране на MySQL бази данни, но имат огромно предимство пред физическите архиви.

Физическите архиви обикновено са резервни копия с всички или нищо. Въпреки че може да е възможно да се създаде частично архивиране с Xtrabackup (описахме това в една от предишните ни публикации в блога), възстановяването на такъв архив е трудно и отнема много време.

По принцип, ако искаме да възстановим една таблица, трябва да спрем цялата верига на репликация и да извършим възстановяването на всички възли наведнъж. Това е основен проблем - в наши дни рядко можете да си позволите да спрете всички бази данни.

Друг проблем е, че нивото на таблицата е най-ниското ниво на детайлност, което можете да постигнете с Xtrabackup:можете да възстановите една таблица, но не можете да възстановите част от нея. Логическото архивиране обаче може да бъде възстановено по начина на изпълнение на SQL изрази, следователно може лесно да се извърши на работещ клъстер и вие можете (не бихме го нарекли лесно, но все пак) да изберете кои SQL изрази да се изпълняват, за да можете направете частично възстановяване на таблица.

Нека да разгледаме как това може да се направи в реалния свят.

Възстановяване на една MySQL таблица с помощта на mysqldump

В началото, моля, имайте предвид, че частичните архиви не осигуряват последователен изглед на данните. Когато правите резервни копия на отделни таблици, не можете да възстановите такова архивиране до известна позиция навреме (например, за да осигурите подчинения за репликация), дори ако искате да възстановите всички данни от архива. Като имаме това зад гърба си, нека продължим.

Имаме главен и подчинен:

Наборът от данни съдържа една схема и няколко таблици:

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)

Сега трябва да направим резервно копие. Има няколко начина, по които можем да подходим към този проблем. Можем просто да направим последователно архивиране на целия набор от данни, но това ще генерира голям един файл с всички данни. За да възстановим единичната таблица, ще трябва да извлечем данни за таблицата от този файл. Разбира се, възможно е, но отнема доста време и е доста ръчна операция, която може да се скриптира, но ако нямате подходящи скриптове, писането на ad hoc код, когато вашата база данни не работи и сте под силен натиск, е не е непременно най-сигурната идея.

Вместо това можем да подготвим архивиране по начин, по който всяка таблица ще се съхранява в отделен файл:

[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 ; done

Моля, обърнете внимание, че ние задаваме --set-gtid-purged=OFF. Нуждаем се от него, ако ще заредим тези данни по-късно в базата данни. В противен случай MySQL ще се опита да зададе @@GLOBAL.GTID_PURGED, което най-вероятно ще се провали. MySQL също така би задал SET @@SESSION.SQL_LOG_BIN=0; което определено не е това, което искаме. Тези настройки са необходими, ако бихме направили последователно архивиране на целия набор от данни и бихме искали да го използваме за предоставяне на нов възел. В нашия случай знаем, че това не е последователно архивиране и няма начин да възстановим нещо от него. Всичко, което искаме, е да генерираме дъмп, който можем да заредим на главния и да го оставим да се репликира на подчинени.

Тази команда генерира хубав списък от sql файлове, които могат да бъдат качени в производствения клъстер:

[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.sql

Когато искате да възстановите данните, всичко, което трябва да направите, е да заредите SQL файла в главния възел:

[email protected]:~/backup# mysql -uroot -ppass sbtest < 20200318_sbtest.sbtest11.sql

Данните ще бъдат заредени в базата данни и репликирани на всички подчинени устройства.

Как да възстановим една MySQL таблица с помощта на ClusterControl?

Понастоящем ClusterControl не предоставя лесен начин за възстановяване само на една таблица, но все пак е възможно да го направите само с няколко ръчни действия. Има две опции, които можете да използвате. Първо, подходящ за малък брой таблици, можете основно да създадете график, при който да извършвате частично архивиране на отделни таблици една по една:

Тук правим резервно копие на таблица sbtest.sbtest1. Можем лесно да планираме друго архивиране за таблица sbtest2:

Алтернативно можем да направим архивиране и да поставим данни от една схема в отделен файл:

Сега можете или да намерите липсващите данни на ръка във файла, да възстановите това архивиране на отделен сървър или оставете ClusterControl да го направи:

Поддържате сървъра работещ и можете да извличате данните, които исках да възстановя с помощта на mysqldump или SELECT ... INTO OUTFILE. Такива извлечени данни ще бъдат готови за прилагане към производствения клъстер.