In mijn vorige blogpost die ging over het upgraden naar de nieuwste versie van Jira samen met de nieuwste versie van MariaDB, vermeld ik kort dat je bij het upgraden naar MariaDB Server 10.3 moet kijken hoe back-ups worden gemaakt. Met MariaDB Server 10.3 komt MariaDB Backup, die de nieuwste functies van MariaDB Server ondersteunt. Het is ook beschikbaar op dezelfde platforms als MariaDB Server en wordt samen met de server gedistribueerd.
Als u een back-up hebt gemaakt met XtraBackup en dezelfde opdrachten probeert uit te voeren tegen MariaDB Server 10.3, krijgt u een foutmelding:
$ innobackupex ~/backup_to_dir --user=username --password=password
...
InnoDB: Unsupported redo log format. The redo log was created with MariaDB 10.3.9.
De eerste zin in het laatste bericht is waar het over gaat. XtraBackup begrijpt het bestand/de bestanden in het opnieuw uitvoeren van 10.3 niet. Merk op dat we een oude versie van XtraBackup gebruikten en daarom is het commando nog steeds innobackupex .
Om deze en enkele andere redenen die hieronder worden genoemd, wordt MariaDB Server nu geleverd met MariaDB Backup die de nieuwe log-indeling voor opnieuw uitvoeren ondersteunt. Met MariaDB Backup heb je dezelfde functionaliteit die je gewend bent met XtraBackup, maar met de ondersteuning voor het verbeterde redo log-formaat en ondersteuning voor MariaDB's data-at-rest-codering. Een ander veelgevraagd aspect is dat MariaDB Backup ook beschikbaar is voor Windows, wat XtraBackup niet is. Als je meer wilt weten over de wijziging van het logboek voor opnieuw uitvoeren, lees dan dit.
In het begin van dit bericht vermeld ik dat we onlangs Jira hebben geüpgraded naar de nieuwste versie en MariaDB Server naar 10.3. In die oudere omgeving gebruikten we XtraBackup. Om back-ups voor MariaDB Server 10.3 te krijgen, moesten we onze back-upscripts bijwerken om MariaDB Backup te gebruiken.
Na het overschakelen naar MariaDB Backup ziet het back-upcommando er als volgt uit:
$ mariabackup --backup --target-dir /backup/to/dir --user=username --password=password --parallel=4
We moesten het commando zelf veranderen van innobackupex naar mariaback-up en we hebben twee opties toegevoegd; –back-up om mariabackup . te vertellen dat we willen dat het een back-up maakt en -target-dir om aan te geven dat de opgegeven map is waar de back-upbestanden moeten komen. Opgemerkt moet worden dat als we een recentere versie van de XtraBackup zouden hebben gebruikt, de opdrachtregelopties volledig compatibel zouden zijn geweest met XtraBackup, dus het enige dat dan zou moeten worden gewijzigd, zou de opdracht zelf zijn van xtrabackup naar mariaback-up .
Om er zeker van te zijn dat de back-up werkt, kopiëren we deze naar een andere server en proberen we hem daar te herstellen. Om een back-up te herstellen, moeten we deze eerst voorbereiden:
$ mariabackup --prepare --target-dir full-2018-09-11_09-38-32
Merk op dat ik een volledige back-up heb van een MariaDB Server-instantie die alles zal vervangen dat zou bestaan in de instantie waarnaar ik herstel. Ik stop daarom de server en verwijder alle gegevensbestanden die erop staan.
$ sudo service mariadb stop
$ sudo rm -rf /var/lib/mysql/*
Nu kunnen de back-upbestanden in de gegevensmap van deze serverinstantie worden geplaatst. Het moet met mariabackup worden gedaan om het goed te doen. Het doet een aantal dingen die te maken hebben met het opnieuw uit te voeren log-formaat dat hierboven is uitgelegd.
$ sudo mariabackup --copy-back --target-dir full-2018-09-11_09-38-32
Zorg ervoor dat de rechten correct zijn. In mijn geval zijn normale gebruiker en groep in gebruik. Start vervolgens de server.
$ sudo chown mysql:mysql /var/lib/mysql -R
$ sudo service mariadb start
Laten we vervolgens verbinding maken met de server en controleren of deze de gegevens heeft die deze zou moeten hebben. Ik besloot om het maximale nummernummer in Jira op te vragen.
# connect to mariadb
$ mysql -uusername -ppassword
# query the database
MariaDB [(none)]> USE jiradb
MariaDB [jiradb]> SELECT MAX(issuenum) FROM jiraissue;
Voila! We hebben nu back-ups die werken op MariaDB Server 10.3.