W moim poprzednim poście na blogu, który dotyczył aktualizacji do najnowszej wersji Jira wraz z najnowszą wersją MariaDB, krótko wspominam, że podczas uaktualniania do MariaDB Server 10.3 należy przyjrzeć się, jak wykonuje się kopie zapasowe. Wraz z MariaDB Server 10.3 dostępna jest usługa MariaDB Backup, która obsługuje najnowsze funkcje MariaDB Server. Jest również dostępny na wszystkich tych samych platformach co MariaDB Server i jest dystrybuowany razem z serwerem.
Jeśli tworzysz kopię zapasową za pomocą XtraBackup i próbujesz uruchomić te same polecenia na serwerze MariaDB Server 10.3, pojawi się komunikat o błędzie:
$ innobackupex ~/backup_to_dir --user=username --password=password
...
InnoDB: Unsupported redo log format. The redo log was created with MariaDB 10.3.9.
O co chodzi w pierwszym zdaniu ostatniej wiadomości. XtraBackup nie rozumie plików w dzienniku przeróbek 10.3. Zauważ, że użyliśmy starej wersji XtraBackup i dlatego poleceniem nadal jest innobackupex .
Z tego powodu oraz z kilku innych powodów wymienionych poniżej serwer MariaDB Server jest teraz dostarczany z kopią zapasową MariaDB, która obsługuje nowy format dziennika ponawiania. Dzięki MariaDB Backup masz te same funkcje, co w przypadku XtraBackup, ale z obsługą ulepszonego formatu dziennika ponawiania i obsługą szyfrowania danych w spoczynku MariaDB. Innym bardzo pożądanym aspektem jest to, że MariaDB Backup jest również dostępna dla systemu Windows, czego XtraBackup nie jest. Jeśli chcesz dowiedzieć się więcej o zmianie dziennika ponawiania, przeczytaj to.
Na początku tego wpisu wspominam, że niedawno zaktualizowaliśmy Jira do najnowszej wersji i MariaDB Server do 10.3. W tym starszym środowisku użyliśmy XtraBackup. Aby uzyskać kopie zapasowe dla MariaDB Server 10.3, musieliśmy zaktualizować nasze skrypty kopii zapasowych, aby używały MariaDB Backup.
Po przejściu do MariaDB Backup polecenie tworzenia kopii zapasowej wygląda tak:
$ mariabackup --backup --target-dir /backup/to/dir --user=username --password=password --parallel=4
Musieliśmy zmienić samo polecenie z innobackupex do mariabackup i dodaliśmy dwie opcje; –kopia zapasowa powiedzieć mariabackup że chcemy, aby utworzył kopię zapasową i –target-dir, aby określić, że dany katalog to miejsce, w którym powinny znaleźć się pliki kopii zapasowej. Należy zauważyć, że gdybyśmy korzystali z nowszej wersji XtraBackup, opcje wiersza poleceń byłyby całkowicie kompatybilne z XtraBackup, więc jedyną rzeczą do zmiany byłaby sama komenda z xtrabackup do mariabackup .
Aby mieć pewność, że kopia zapasowa działa, skopiujemy ją na inny serwer i tam spróbujemy ją przywrócić. Aby przywrócić kopię zapasową, najpierw musimy ją przygotować:
$ mariabackup --prepare --target-dir full-2018-09-11_09-38-32
Zauważ, że mam pełną kopię zapasową instancji MariaDB Server, która zastąpi wszystko, co istniałoby w instancji, do której przywracam. Dlatego zatrzymam serwer i usunę wszystkie przechowywane przez niego pliki danych.
$ sudo service mariadb stop
$ sudo rm -rf /var/lib/mysql/*
Teraz pliki kopii zapasowej można umieścić w katalogu danych tej instancji serwera. Należy to zrobić za pomocą mariabackup, aby zrobić to dobrze. Wykonuje pewne czynności związane z opisanym powyżej formatem dziennika przeróbek.
$ sudo mariabackup --copy-back --target-dir full-2018-09-11_09-38-32
Upewnij się, że uprawnienia są prawidłowe. W moim przypadku używany jest zwykły użytkownik i grupa. Następnie uruchom serwer.
$ sudo chown mysql:mysql /var/lib/mysql -R
$ sudo service mariadb start
Połączmy się wtedy z serwerem i sprawdźmy, czy ma dane, które powinien mieć. Postanowiłem zapytać o maksymalny numer wydania w Jira.
# connect to mariadb
$ mysql -uusername -ppassword
# query the database
MariaDB [(none)]> USE jiradb
MariaDB [jiradb]> SELECT MAX(issuenum) FROM jiraissue;
Voila! Mamy teraz kopie zapasowe działające na MariaDB Server 10.3.
