Как да изпълнявате и управлявате резервни копия на MySQL за Oracle DBA

Мигрирането от база данни на Oracle към отворен код може да донесе редица предимства. По-ниската цена на собственост е примамлива и подтиква много компании да мигрират. В същото време DevOps, SysOps или DBA трябва да поддържат строги SLA, за да отговорят на бизнес нуждите.

Едно от основните притеснения, когато планирате миграция на данни към друга база данни, особено с отворен код, е как да избегнете загуба на данни. Не е твърде далеч, че някой случайно е изтрил част от базата данни, някой е забравил да включи клауза WHERE в заявка DELETE или случайно да изпълни DROP TABLE. Въпросът е как да се възстановим от подобни ситуации.

Такива неща може и ще се случат, това е неизбежно, но въздействието може да бъде катастрофално. Както някой каза:„Всичко е забавление и игри, докато архивирането не успее“. Най-ценният актив не може да бъде компрометиран. Точка.

Страхът от неизвестното е естествен, ако не сте запознати с новите технологии. Всъщност познаването на решенията за бази данни на Oracle, надеждността и страхотните функции, които Oracle Recovery Manager (RMAN) предлага, може да обезкуражи вас или вашия екип да мигрирате към нова система за бази данни. Обичаме да използваме неща, които знаем, така че защо да мигрираме, когато настоящото ни решение работи. Кой знае колко проекта бяха задържани, защото екипът или индивидът не бяха убедени в новата технология?

Логически архиви (exp/imp, expdp/impdb)

Според документацията на MySQL логическото архивиране е „резервно копие, което възпроизвежда структура на таблицата и данни, без да копира действителните файлове с данни“. Тази дефиниция може да се прилага както за MySQL, така и за Oracle светове. Същото е „защо“ и „кога“ ще използвате логическото архивиране.

Логическите архиви са добър вариант, когато знаем какви данни ще бъдат променени, за да можете да архивирате само частта, от която се нуждаете. Той опростява потенциалното възстановяване по отношение на време и сложност. Също така е много полезно, ако трябва да преместим част от малък/среден набор от данни и да копираме обратно в друга система (често в различна версия на базата данни). Oracle използва помощни програми за експортиране като exp и expdp, за да чете данни от базата данни и след това да ги експортира във файл на ниво операционна система. След това можете да импортирате данните обратно в база данни, като използвате помощните програми за импортиране imp или impdp.

Помощните програми за експортиране на Oracle ни дават много възможности да изберем какви данни трябва да бъдат експортирани. Определено няма да намерите същия брой функции с mysql, но повечето от нуждите са покрити, а останалото може да се направи с допълнителни скриптове или външни инструменти (проверете mydumper).

MySQL идва с пакет от инструменти, които предлагат много основна функционалност. Те са mysqldump, mysqlpump (модерната версия на mysqldump, която има естествена поддръжка за паралелизиране) и MySQL клиент, който може да се използва за извличане на данни в плосък файл.

По-долу можете да намерите няколко примера за това как да ги използвате:

Архивна само структура на базата данни

mysqldump --no-data -h localhost -u root -ppassword mydatabase > mydatabase_backup.sql

Архивна структура на таблицата

mysqldump --no-data --single- transaction -h localhost -u root -ppassword mydatabase table1 table2 > mydatabase_backup.sql

Архивирайте конкретни редове

mysqldump -h localhost --single- transaction -u root -ppassword mydatabase table_name --where="date_created='2019-05-07'" > table_with_specific_rows_dump.sql

Импортиране на таблицата

mysql -u username -p -D dbname < tableName.sql

Горната команда ще спре зареждането, ако възникне грешка.

Ако заредите данни директно от mysql клиента, грешките ще бъдат игнорирани и клиентът ще продължи

mysql> source tableName.sql

За да регистрирате изхода, трябва да използвате

mysql> tee import_tableName.log

Можете да намерите всички флагове, обяснени под връзките по-долу:

https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html
https://dev.mysql.com/doc/refman/8.0/en/mysqlimport.html
https://dev.mysql.com/doc/refman/8.0/en/mysql.html

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

USE mydatabase;
SELECT @@character_set_database, @@collation_database;

Друг начин за извличане на системната променлива collation_database е да използвате SHOW VARIABLES.

SHOW VARIABLES LIKE 'collation%';

Поради ограниченията на mysql dump често се налага да променяме изхода. Пример за такава модификация може да бъде необходимостта от премахване на някои линии. За щастие имаме гъвкавостта да преглеждаме и модифицираме изхода с помощта на стандартни текстови инструменти преди възстановяване. Инструменти като awk, grep, sed могат да станат ваш приятел. По-долу е даден прост пример за това как да премахнете третия ред от дъмп файла.

sed -i '1,3d' file.txt

Възможностите са безкрайни. Това е нещо, което няма да намерим с Oracle, тъй като данните се записват в двоичен формат.

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

Съображения за логически архивиране

Когато такова архивиране се изпълни, ще бъдат извършени следните стъпки.

таблица LOCK TABLE.
ПОКАЖЕТЕ таблицата CREATE TABLE.
ИЗБЕРЕТЕ * ОТ таблица INTO OUTFILE временен файл.
Запишете съдържанието на временния файл в края на дъмп файла.
ОТКЛЮЧАЙТЕ МАСИ

По подразбиране mysqldump не включва рутинни процедури и събития в изхода си - трябва изрично да зададете флагове --routines и --events.

Друго важно съображение е двигател, който използвате за съхраняване на вашите данни. Надяваме се, че в наши дни повечето производствени системи използват ACID съвместим двигател, наречен InnoDB. По-старият двигател MyISAM трябваше да заключи всички таблици, за да осигури последователност. Това е, когато се изпълни FLUSH TABLES WITH READ LOCK. За съжаление, това е единственият начин да се гарантира последователна моментна снимка на MyISAM таблици, докато MySQL сървърът работи. Това ще накара MySQL сървъра да стане само за четене, докато не се изпълни UNLOCK TABLES.

За таблици в системата за съхранение на InnoDB се препоръчва да се използва опцията --single- транзакция. След това MySQL създава контролна точка, която позволява на дъмп да улови всички данни преди контролната точка, докато получава входящи промени.

Опцията --single-transaction на mysqldump не прави ФЛУШИВАНЕ НА ТАБЛИЦИТЕ СЪС ЗАКЛЮЧВАНЕ НА ЧЕТЕНЕ. Това кара mysqldump да настрои ПОВТОРЯЩА се транзакция за четене за всички таблици, които се изхвърлят.

Архивът на mysqldump е много по-бавен от инструментите на Oracle exp, expdp. Mysqldump е инструмент с една нишка и това е най-същественият му недостатък – производителността е добра за малки бази данни, но бързо става неприемлива, ако наборът от данни нарасне до десетки гигабайта.

ЗАПОЧНЕТЕ ТРАНЗАКЦИЯТА С ПОДХОДЯЩА МОМЕНТА СНИМКА.
За всяка схема и таблица на базата данни дъмпът изпълнява следните стъпки:
- ПОКАЖЕТЕ таблицата CREATE TABLE.
- ИЗБЕРЕТЕ * ОТ таблица INTO OUTFILE временен файл.
- Запишете съдържанието на временния файл в края на дъмп файла.
ЗАВЪРЖАНЕ.

Физически архиви (RMAN)

За щастие повечето от ограниченията на логическото архивиране могат да бъдат решени с инструмента Percona Xtrabackup. Percona XtraBackup е най-популярният софтуер за горещо архивиране на MySQL/MariaDB с отворен код, който извършва неблокиращи архиви за InnoDB и XtraDB бази данни. Той попада в категорията за физическо архивиране, която се състои от точни копия на директорията с данни на MySQL и файловете под нея.

Това е същата категория инструменти като Oracle RMAN. RMAN идва като част от софтуера на базата данни, XtraBackup трябва да се изтегли отделно. Xtrabackup се предлага като rpm и deb пакет и поддържа само Linux платформи. Инсталацията е много проста:

$ wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-8.0.4/binary/redhat/7/x86_64/percona-XtraBackup-80-8.0.4-1.el7.x86_64.rpm
$ yum localinstall percona-XtraBackup-80-8.0.4-1.el7.x86_64.rpm

XtraBackup не заключва вашата база данни по време на процеса на архивиране. За големи бази данни (100+ GB), той осигурява много по-добро време за възстановяване в сравнение с mysqldump. Процесът на възстановяване включва подготовка на MySQL данни от архивните файлове, преди да ги замените или превключите с текущата директория с данни на целевия възел.

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

Когато XtraBackup е инсталиран, най-накрая можете да извършите първите си физически архиви.

xtrabackup --user=root --password=PASSWORD --backup --target-dir=/u01/backups/

Друга полезна опция, която администраторите на MySQL правят, е стрийминг на архивиране към друг сървър. Такъв поток може да се извърши с помощта на инструмента xbstream, като в примера по-долу:

Стартирайте слушател на външния сървър на предпочитания порт (в този пример 1984)

nc -l 1984 | pigz -cd - | pv | xbstream -x -C /u01/backups

Изпълнете архивиране и прехвърлете към външен хост

innobackupex --user=root --password=PASSWORD --stream=xbstream /var/tmp | pigz  | pv | nc external_host.com 1984

Както може да забележите, процесът на възстановяване е разделен на две основни стъпки (подобно на Oracle). Стъпките са възстановени (копиране обратно) и възстановяване (прилагане на дневника).

XtraBackup --copy-back --target-dir=/var/lib/data
innobackupex --apply-log --use-memory=[values in MB or GB] /var/lib/data

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

Възстановяване на точка във времето (RMAN възстановяване)

В Oracle RMAN изпълнява всички стъпки, когато извършваме възстановяване на базата данни. Може да се направи или към SCN, или по време, или въз основа на набора от архивни данни.

RMAN> run
{
allocate channel dev1 type disk;
set until time "to_date('2019-05-07:00:00:00', 'yyyy-mm-dd:hh24:mi:ss')";
restore database;
recover database; }

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

Основната процедура би била

Възстановяване на пълен архив
Възстановяване на инкрементални архиви
За идентифициране на началния и крайния час за възстановяване (това може да е краят на архивирането и номера на позицията, преди за съжаление да отпадне таблицата).
Конвертирайте необходимите binglogs в SQL и приложете новосъздадените SQL файлове в правилната последователност - не забравяйте да изпълните една единствена команда mysqlbinlog.
```
> mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p
```

Шифроване на резервни копия (Oracle Wallet)

Percona XtraBackup може да се използва за криптиране или декриптиране на локални или стрийминг архиви с опция xbstream, за да добавите още един слой защита към архивите. Опцията --encrypt-key и опцията --encryptkey-file могат да се използват за определяне на ключа за криптиране. Ключовете за криптиране могат да се генерират с команди като

$ openssl rand -base64 24
$ bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1

След това тази стойност може да се използва като ключ за криптиране. Пример за командата innobackupex с помощта на --encrypt-key:

$ innobackupex --encrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1” /storage/backups/encrypted

За да декриптирате, просто използвайте опцията --decrypt с подходящ --encrypt-key:

$ innobackupex --decrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1”
/storage/backups/encrypted/2019-05-08_11-10-09/

Правила за архивиране

Няма вградена функционалност на политиката за архивиране нито в MySQL/MariaDB, нито дори в инструмента на Percona. Ако искате да управлявате вашите MySQL логически или физически архиви, можете да използвате ClusterControl за това.

ClusterControl е всеобхватна система за управление на база данни с отворен код за потребители със смесени среди. Той предоставя разширена функционалност за управление на архивиране за MySQL или MariaDB.

С ClusterControl можете:

Създайте правила за архивиране
Наблюдавайте състоянието на архивиране, изпълнението и сървърите без архивиране
Извършване на архивиране и възстановяване (включително възстановяване в момент)
Контролирайте запазването на резервни копия
Запазване на резервни копия в хранилище в облак
Проверете резервните копия (пълен тест с възстановяването на самостоятелния сървър)
Шифроване на резервни копия
Компресиране на резервни копия
И много други

ClusterControl:Управление на архивиране

Пазете резервни копия в облака

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

Облакът промени индустрията за архивиране на данни. Поради достъпната си цена, по-малките фирми имат външно решение, което архивира всичките им данни (и да, уверете се, че са криптирани). Както Oracle, така и MySQL не предлагат вградени решения за съхранение в облак. Вместо това можете да използвате инструментите, предоставени от доставчиците на облак. Пример тук може да бъде s3.

aws s3 cp severalnines.sql s3://severalnine-sbucket/mysql_backups

Заключение

Има няколко начина за архивиране на вашата база данни, но е важно да прегледате нуждите на бизнеса, преди да вземете решение за стратегия за архивиране. Както можете да видите, има много прилики между резервните копия на MySQL и Oracle, които се надяваме да ви отговорят на вашите SLA.

Винаги се уверете, че практикувате тези команди. Не само когато сте нов в технологията, но и когато СУБД стане неизползваема, за да знаете какво да правите.

Ако искате да научите повече за MySQL, моля, вижте нашата бяла книга The DevOps Guide to Database Backups за MySQL и MariaDB.