Успешни стратегии за архивиране и възстановяване на MySQL/MariaDB

Важна част от предотвратяването на всякакъв вид загуба на данни във всяка ситуация е наличието на подходящи политики за архивиране и възстановяване. Също така е от съществено значение да се осигури възстановяване на данни във всеки един момент от жизнения цикъл на работния процес на приложението. И MySQL, и MariaDB предлагат решения за тези случаи. Тази статия ще разгледа съществуващите опции и процедури, както и други потенциални опции за архивиране на MySQL и MariaDB.

Стратегии за архивиране

Тъй като данните са най-важната част от всяко приложение, защитата на тяхната цялост е жизненоважна за оцеляването в битката за съществуване. Всяко нарушаване на достъпността или целостта на данните за всеки момент може сериозно да навреди на приложението и бизнеса/услугата, която предоставя.

За да осигурите успешен работен поток на приложението и непрекъснатост на бизнеса, трябва да приложите подходящи политики за архивиране и възстановяване с ежедневни, седмични, месечни и годишни архиви. Такива архиви ще се изпълняват в критични периоди, като например:

• преди ежедневен пакетен прозорец;
• преди масивно поглъщане на данни;
• преди надграждане на приложението;
• седмично, месечно и годишно архивиране, за да отговарят на регулаторните изисквания;
• или друга ежедневна/седмична поддръжка.

Инструменти за архивиране

MySQL и MariaDB предлагат няколко начина за настройка и изпълнение на планове за архивиране и възстановяване. Тези методи включват физическо архивиране с инструмента за архивиране на MySQL Enterprise mysqlbackup , инструментът за архивиране на MariaDB , или инструментът XtraBackup на Percona . Също така, логически архиви, създадени с инструмента mysqldump на Mysql може да е полезно. Друг вариант е възстановяването в момента с базите данни bin-logs (регистрационните файлове на транзакциите) в комбинация с инструментите, споменати по-рано.

Можете да усвоите подходящи методи във вашата стратегия за архивиране, за да увеличите максимално възстановимостта на базата данни в случай на повреда или бедствие.

Забележка:Във версията на MariaDB 10.4.6, символната връзка на mysqldump се нарича mariadb-dump . В по-късните версии, включително 10.5.2, имената се промениха отново – mysqldump станасимволна връзка .

За да илюстрирам процедурите, ще използвам инструмента mariabackup за създаване на физически резервни копия. Основната функционалност на инструмента е същата като в гореспоменатите инструменти, въпреки че има някои малки разлики, уникални за всеки инструмент.

Архивиране на физическа база данни

Физическите архиви са резервни копия на ниво файл, които ви предоставят бързи методи за копиране на файлове. Такива резервни копия са за предпочитане при сценарии за възстановяване при бедствие, клониране на бази данни и/или създаване на подчинени бази данни.

Когато правите физически архиви, можете да изберете да създадете пълни или инкрементални архиви. Пълните архиви включват пълно архивиране на сървъра на базата данни. Инкременталните архиви запазват промените само от последното пълно или инкрементално архивиране.

Важно:Размерът на базата данни регулира времето за архивиране. Поради тази причина добра стратегия за архивиране на много голяма база данни може да бъде комбинирането на пълни и инкрементални архиви. По този начин спестявате както пространството за съхранение на архивни копия, така и общото време за архивиране и възстановяване.

Друг момент, който трябва да забележите, е, че когато възстановявате данните от физическо архивиране, трябва да спрете процеса на екземпляр на база данни MySQL/MariaDB, докато не бъдат завършени последните стъпки за възстановяване.

Можете да извършите изпълнението на просто пълно физическо архивиране, както следва:

 mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220 \
   --user=backupuser --password=backuppasswd

–target-dir опцията казва на инструмента за архивиране къде да постави архива.

В този пример съм организирал резервното си копие в директорията, наречена ГГГГГММДД където се съхранява всяко пълно архивиране (D означава Daily). По този начин имаме лесен начин на действие за възстановяване на базата данни от резервното копие, направено на определена дата.

Следващият пример демонстрира изпълнение на просто инкрементално архивиране:

mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220_inc1/ \
   --incremental-basedir=/data/backups/mariadb/D20210220/ \
   --user=backupuser --password=backuppasswd 

Следващото инкрементално архивиране ще изглежда по следния начин:

mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220_inc2/ \
   --incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
   --user=backupuser --password=backuppasswd

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

Сега нека разберем какво е името на файла с физическа база данни, в който се съхраняват всички данни от директорията. Базата данни, която се намира на домейн контролери, е Active Directory. Тази директория се използва за управление на потребители, данни и т.н. Ядрото на Active Directory е файлът на базата данни NTDS.DIT, който се състои от връзка, дескриптор за защита и таблици с данни. Всички данни от директорията се съхраняват в този файл на физическа база данни.

Необходимо е да се прави разлика между физически и логически файлове. Действителните системни данни се намират във физически файлове, докато логическите файлове съдържат описанието на записите, съхранявани във физически файлове.

Задачата за възстановяване на базата данни MySQL от физически файлове понякога може да бъде трудна. mysqldumpът командата може да е полезна в този случай. Ще разгледаме тази тема допълнително.

Архивиране на логически бази данни

Логическите архиви се създават с mysqldump инструмент. Този метод за архивиране е по-гъвкав от физическото архивиране. Състои се от всички DML и/или DDL SQL оператори, необходими за формиране на последователно архивиране, съчетаващо всички заети данни и промени, направени преди и по време на архивирането. Ако искате да научите повече за това как да архивирате и възстановите всички бази данни, можете да прочетете тази статия.

Логическото архивиране може да бъде един файл или няколко файла (създадени с конкретен скрипт). Освен това можете да възстановите структурата и/или данните, без да изключвате вашия MySQL/MariaDB екземпляр (процес). Съответно логическите архиви се извършват на ниво база данни и/или таблица, докато физическото архивиране се извършва на ниво файлова система (директории и файлове).

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

Създаването на логическо архивиране на целия MySQL/MariaDB екземпляр е по-долу:

mysqldump --all-databases --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/full-backup-$(date +'%Y%m%d_%H%M%S').sql

Забележете, че физическите и логическите архиви са специално разграничени във файловата система за целите на управлението на архивирането.

За разлика от предишния пример, логическо архивиране на единична база данни (схема) се създава по следния начин:

mysqldump empdb --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-full-backup-$(date +'%Y%m%d_%H%M%S').sql

И накрая, за да създадете логическо архивиране на една таблица в база данни, добавете името на таблицата след базата данни:

mysqldump empdb departments --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-departments-full-backup-$(date +'%Y%m%d_%H%M%S').sql

Когато трябва да редактирате и добавите изразите DROP DATABASE или DROP TABLE към сценария за възстановяване, работата с големи архивни файлове може да има ограничаващи ефекти върху текстовите редактори до степен, че те се задушават.

В такива случаи помислете за добавяне на други опции, като например –add-drop-database и/или – add-drop-table за да включите тези оператори DROP в архива. В други сценарии може да искате да изключите тези твърдения и да ги замените с –skip-add-drop-table опция към командата.

Можете обаче също да създадете резервни копия само за данни или само за DDL, като използвате –no-create-info или –без данни настроики. Отделните архиви на данни и структура могат да бъдат добър избор в някои сценарии за възстановяване, особено когато се нуждаете само от DDL структурата, за да създадете празна клонирана база данни и/или нейните таблици.

Архивиране на база данни с помощта на дискови моментни снимки

С нарастването на данните може да се наложи организирането им на няколко диска и/или файлови системи. Освен причините за производителността, тъй като I/O се разпределя между множество дискове/файлови системи, трябва да гарантирате, че ефективните стратегии за архивиране и възстановяване включват възможностите за моментна снимка на диска и файловата система.

Започнете с проектиране и изграждане на оформления на файловата система, където се намира всяка база данни, група от таблици и индекси. След това организирайте вашите таблици и конфигурирайте системата на базата данни. Те трябва или да се намират всички в една директория:

innodb_home_dir = /<path where your InnoDB tables will reside>

Или можете да използвате DATA_DIRECTORY и INDEX_DIRECTORY опции в СЪЗДАВАНЕ таблица, за да ги разпределите отделно на различни местоположения на файловата система.

За InnoDB не забравяйте да използвате file_per_table =ON (по подразбиране е ВКЛЮЧЕНО в най-новите версии). Изберете внимателно пътя за InnoDB таблиците, когато ги създавате. Невъзможно е да промените пътя, без да изпуснете и създадете отново таблицата.

Полезно е да имате правилни файлови системи с вградени възможности за моментни снимки, напр. XFS и ZFS на Linux. Забележете, че създаването на резервни копия на моментни снимки е подобно на създаването на физически архиви, но има специфики. Това изисква спиране на процеса на писане (FLUSH с READ LOCK или подобен — вижте РЕЗЕРВЕН ЕТАП команда в онлайн документацията на MariaDB), преди да направите моментната снимка и да освободите LOCKS веднага след завършване на моментната снимка. Необходимо е да се осигури последователност на данните.

Трябва да обмислите и използвате резервните копия на моментни снимки в сценарии за възстановяване при бедствие. Те обаче са подходящи и за клониране на екземпляри на база данни.

Стратегии за възстановяване

Възстановяване от физически архиви

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

Например, DBA прави пълни архиви в неделя и допълнителни архиви в други дни. Възниква повреда след извършване на постепенно архивиране в сряда. Следователно те трябва да възстановят базата данни. При такива обстоятелства нашият DBA трябва да използва пълното архивиране, направено в неделя, и постепенните архиви, направени в понеделник, вторник и сряда. Ако имаше ежедневни пълни архиви, би било достатъчно да възстановите архива от сряда.

За да възстановите „най-близкото“ архивно копие след неуспех, независимо дали е пълно или инкрементално архивиране, трябва да уверите, че ВСИЧКИ архивни файлове са последователни в даден момент с времето на най-близкото резервно завършване. В противен случай механизмът InnoDB ще отхвърли данните, като ги смята за повредени.

Друг ключов момент е, когато подготвяте резервни копия, копирайте включените пълни архиви на друго място преди да приложите стъпките, за да осигурите последователност в момента. По този начин запазвате първоначалното състояние на архивиране, което може да е полезно по-късно. Силно препоръчвам да се придържате към този подход.

За да подготвите пълно архивиране, изберете най-близкото до грешката, копирайте го на предпочитаното място и изпълнете следната команда:

mariabackup --prepare \
   --target-dir=data/backups/mariadb/COPY_D20210220

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

Постигаме това чрез изпълнение на prepare команда за всяко инкрементално архивиране, както е показано по-долу:

mariabackup --prepare \
   --target-dir=/data/backups/mariadb/COPY_D20210220 \
   --incremental-dir=/data/backups/mariadb/D20210220_INC#

След като подготвим резервното копие, трябва да изключим екземпляра на базата данни (процес). Също така, ниетрябва да изпразни директория на базата данни преди да завършите процеса на възстановяване. Можете да издадете командата с –копиране обратно опция

mariabackup --copy-back \
   --target-dir=data/backups/mariadb/COPY_D20210220

или с –преместване назад опция:

mariabackup --move-back \
   --target-dir=data/backups/mariadb/COPY_D20210220

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

Последната стъпка преди стартиране на екземпляра на базата данни е да коригирате собствеността на файловете, за да съответстват на потребителя и групата на собственика на процеса. Обикновено това е MySQL.

Възстановяване от логически архиви

Доста често пренебрегваме един ключов момент, когато възстановяваме бази данни и/или таблици с помощта на логически архиви. Тази точка задава max_allowed_packet размер на сесията (може да е по-разумно да се зададе глобално) на максимална стойност от 1073741824. Необходимо е да се гарантира, че големите буфери и операторите INSERT се вписват в един пакет между клиента и сървъра. Това трябва да намали времето за възстановяване.

Друг ключов аспект при създаване на резервно копие е да включите или изключите операторите DROP, както беше споменато по-рано. Нуждаем се от него, за да гарантираме възможно най-гладкото протичане на процеса на възстановяване от архивно копие. Имайки това предвид, използвайте кода по-долу, за да изпълните възстановяването от резервно копие:

mysql -u backupuser -p backuppasswd  < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sql

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

mysql -u backupuser -p backuppasswd  newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sql

Възстановяване с дискови моментни снимки

За възстановяване от моментната снимка на диска винаги започнете сосигуряване че системата на базата данни еизключена преди процесът на възстановяване се изпълнява . Всеки опит за възстановяване на жива база данни с помощта на моментна снимка на диска ще доведе до несъответствия на данните и по-вероятно повреда на данните.

Възстановяване в определен момент

Възстановяването по точка във времето (PITR) е, както подсказва името, метод за възстановяване на бази данни и таблици възможно най-близо до времето преди повредата. Или, ако ежедневният пакетен процес се е провалил и трябва да се изпълни отново, имате и единствената възможност – да направите възстановяване на PITR резервно копие.

Жизненоважно е да активирате bin-log на базата данни и да зададете bin-log формата на базирано на декларации, базирано на редове или смесено регистриране, в зависимост от типа на натоварването, което изпълнява вашата база данни. Освен това може да се наложи да активирате компресията чрез log_bin_compress =ON (по подразбиране OFF) за да спестите дисково пространство.

Тъй като bin-log е регистър на транзакциите и е създаден в последователност, от решаващо значение е да направите резервно копие на всички лог файлове. Що се отнася до процеса PITR, той еневъзможен без лог файлове. Освен това поддръжката и жизненият цикъл на bin-log трябва да следват жизнения цикъл на всички пълни и инкрементални архиви. По този начин се уверете, че сте изчистили само регистрационните файлове, които са по-стари от най-старото архивиране в правилата за архивиране.

Можете да изчистите двоичните регистрационни файлове по два начина. Първо, това е чрез деклариране на най-близкото име на bin-log към най-старото архивиране, както е показано в командата за изчистване по-долу:

PURGE BINARY LOGS TO 'mariadb-bin.000063';

Второ, това е чрез деклариране на датата на най-старото архивно копие, съхранявано в командата за почистване:

PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';

За да се подготвим за възстановяване, трябва да извлечем всички необходими изявления, за да възпроизведем до необходимия момент във времето. Съберете всички налични регистрационни файлове от момента на стартиране на архивирането до момента, в който възстановявате.

Започнете с разглеждане на списъка с регистрационни файлове от момента, в който архивирането приключи до времето на PITR:

mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql

След това разгледайте временните файлове, за да намерите точните позиции в регистрационните файлове, които искате да приложите и използвате. Това са –начална позиция и–стоп-позиция които задават точните позиции в командата и изпълняват повторно mysqlbinlog команда:

mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql

В този момент процесът на възстановяване е започнал. Използва физически или логически архиви, пълни или инкрементални.

Завършете възстановяването, като приложите final_temporary_PITR_file.sql използвайки MySQL клиента, както е показано по-долу:

mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sql

Завършихме възстановяването на PITR, като възстановихме резервните и възпроизведените транзакции от регистрационния файл до най-близката точка до момента на възникване на грешката.

Работна маса

За проектиране и разработка на база данни, тестване и поддръжка в MySQL и MariaDB, можем да използваме Windows приложение Workbench. Работи и на Linux. С това приложение потребителите могат да проектират бази данни, да преглеждат и променят мета данни, да прехвърлят данни и мета данни и много други. Струва си да добавим, че е възможно да се използва dbForge Studio за MySQL вместо Workbench.

Заключение

Като цяло ние накратко обсъдихме и илюстрирахме техниките за архивиране и възстановяване на базата данни с инструменти и методи, налични в MySQL и MariaDB.

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

За да извършим успешно PITR, се нуждаем от активиран bin-log и от правилното управление на регистрационните файлове на място.

Въпреки това, използването само на един метод за архивиране и липсващи bin-logs би било грешен подход. Това може да доведе до загуба на данни и да навреди на непрекъснатостта на бизнеса на вашето приложение. По този начин комбинирайте различни методи и винаги включвайте регистрационните файлове в политиките за архивиране и възстановяване!