В предишната си публикация в блога, която беше за надграждане до най-новата версия на Jira заедно с най-новата версия на MariaDB, накратко споменавам, че при надграждане до MariaDB Server 10.3 трябва да погледнете как се правят архиви. С MariaDB Server 10.3 идва MariaDB Backup, който поддържа най-новите функции на MariaDB Server. Предлага се и на всички същите платформи като MariaDB Server и се разпространява заедно със сървъра.
Ако сте архивирали с XtraBackup и се опитате да изпълните същите тези команди срещу MariaDB Server 10.3, ще получите съобщение за грешка:
$ innobackupex ~/backup_to_dir --user=username --password=password
...
InnoDB: Unsupported redo log format. The redo log was created with MariaDB 10.3.9.
Първото изречение в последното съобщение е за какво става въпрос. XtraBackup не разбира файла(ите) в дневника за повторно изпълнение на 10.3. Забележете, че използвахме стара версия на XtraBackup и затова командата все още е innobackupex .
Поради това и някои други причини, споменати по-долу, MariaDB Server вече се предлага с MariaDB Backup, който поддържа новия формат на дневника за повторно изпълнение. С MariaDB Backup имате същата функционалност, с която сте свикнали с XtraBackup, но с поддръжката на подобрения формат на дневника за повторно изпълнение и поддръжка за криптиране на данни в покой на MariaDB. Друг много търсен аспект е, че MariaDB Backup е достъпен и за Windows, което XtraBackup не е. Ако се интересувате да научите повече за промяната на дневника за повторно изпълнение, прочетете това.
В началото на тази публикация споменавам, че наскоро надстроихме Jira до най-новата версия и MariaDB Server до 10.3. В тази по-стара среда използвахме XtraBackup. За да получим резервни копия за MariaDB Server 10.3, трябваше да актуализираме нашите скриптове за архивиране, за да използваме MariaDB Backup.
След преминаване към MariaDB Backup командата за архивиране изглежда така:
$ mariabackup --backup --target-dir /backup/to/dir --user=username --password=password --parallel=4
Трябваше да променим самата команда от innobackupex към mariabackup и добавихме две опции; – архивиране да кажа на mariabackup че искаме да създаде резервно копие и –target-dir, за да укаже, че дадената директория е мястото, където трябва да отидат архивните файлове. Трябва да се отбележи, че ако използвахме по-нова версия на XtraBackup, опциите на командния ред щяха да са напълно съвместими с XtraBackup, така че единственото нещо, което трябва да се промени тогава, щеше да е самата команда от xtrabackup към mariabackup .
За да сме сигурни, че архивът работи, ще го копираме на друг сървър и ще се опитаме да го възстановим там. За да възстановим резервно копие, първо трябва да го подготвим:
$ mariabackup --prepare --target-dir full-2018-09-11_09-38-32
Забележете, че имам пълен архив на екземпляр на MariaDB Server, който ще замени всичко, което би съществувало в екземпляра, в който възстановявам. Затова ще спра сървъра и ще премахна всички файлове с данни, които съхранява.
$ sudo service mariadb stop
$ sudo rm -rf /var/lib/mysql/*
Сега архивните файлове могат да бъдат поставени в директорията с данни на този сървърен екземпляр. Трябва да се направи с mariabackup, за да се направи правилно. Той прави някои неща, свързани с формата на дневника за повторно изпълнение, обяснен по-горе.
$ sudo mariabackup --copy-back --target-dir full-2018-09-11_09-38-32
Уверете се, че разрешенията са правилни. В моя случай се използват нормален потребител и група. След това стартирайте сървъра.
$ sudo chown mysql:mysql /var/lib/mysql -R
$ sudo service mariadb start
След това нека се свържем със сървъра и да проверим дали има данните, които трябва да има. Реших да потърся максималния номер на проблема в Jira.
# connect to mariadb
$ mysql -uusername -ppassword
# query the database
MariaDB [(none)]> USE jiradb
MariaDB [jiradb]> SELECT MAX(issuenum) FROM jiraissue;
Вуаля! Вече имаме резервни копия, работещи на MariaDB Server 10.3.
