I mitt tidigare blogginlägg som handlade om att uppgradera till den senaste versionen av Jira tillsammans med den senaste versionen av MariaDB, nämner jag kort att när man uppgraderar till MariaDB Server 10.3 bör man titta på hur säkerhetskopieringar görs. Med MariaDB Server 10.3 kommer MariaDB Backup, som stöder de senaste funktionerna i MariaDB Server. Den är också tillgänglig på alla samma plattformar som MariaDB Server och den distribueras tillsammans med servern.
Om du har säkerhetskopierat med XtraBackup och försöker köra samma kommandon mot MariaDB Server 10.3, får du ett felmeddelande:
$ innobackupex ~/backup_to_dir --user=username --password=password
...
InnoDB: Unsupported redo log format. The redo log was created with MariaDB 10.3.9.
Den första meningen i det sista meddelandet är vad det handlar om. XtraBackup förstår inte filen/filerna i 10.3:s redo-logg. Lägg märke till att vi använde en gammal version av XtraBackup och det är därför kommandot fortfarande är innobackupex .
På grund av detta och några andra skäl som nämns nedan kommer MariaDB Server nu med MariaDB Backup som stöder det nya redo-loggformatet. Med MariaDB Backup har du samma funktionalitet som du är van vid med XtraBackup, men med stöd för det förbättrade redo-loggformatet och stöd för MariaDBs data-at-rest-kryptering. En annan mycket efterfrågad aspekt är att MariaDB Backup är tillgänglig för Windows också, vilket XtraBackup inte är. Om du är intresserad av att veta mer om ändringen i loggboken gör du om, läs detta.
I början av detta inlägg nämner jag att vi nyligen uppgraderat Jira till den senaste versionen och MariaDB Server till 10.3. I den äldre miljön använde vi XtraBackup. För att få säkerhetskopior för MariaDB Server 10.3 var vi tvungna att uppdatera våra säkerhetskopieringsskript för att använda MariaDB Backup.
Efter att ha bytt till MariaDB Backup ser backupkommandot ut så här:
$ mariabackup --backup --target-dir /backup/to/dir --user=username --password=password --parallel=4
Vi var tvungna att ändra själva kommandot från att vara innobackupex till mariabackup och vi lade till två alternativ; –säkerhetskopia för att berätta för mariabackup att vi vill att den ska skapa en säkerhetskopia och –target-dir för att specificera att den givna katalogen är där säkerhetskopieringsfilerna ska hamna. Det bör noteras att om vi skulle ha använt en nyare version av XtraBackup skulle kommandoradsalternativen ha varit helt kompatibla med XtraBackup, så det enda som skulle ändras då skulle ha varit själva kommandot från xtrabackup till mariabackup .
För att vara säker på att säkerhetskopieringen fungerar kopierar vi den till en annan server och försöker återställa den där. För att återställa en säkerhetskopia måste vi först förbereda den:
$ mariabackup --prepare --target-dir full-2018-09-11_09-38-32
Observera att jag har en fullständig säkerhetskopia av en MariaDB Server-instans som kommer att ersätta allt som skulle existera i den instans jag återställer till. Jag kommer därför att stoppa servern och ta bort alla datafiler som den innehåller.
$ sudo service mariadb stop
$ sudo rm -rf /var/lib/mysql/*
Nu kan säkerhetskopieringsfilerna placeras i datakatalogen för denna serverinstans. Det bör göras med mariabackup för att få det gjort rätt. Den gör en del saker relaterade till formatet för omloggning som förklaras ovan.
$ sudo mariabackup --copy-back --target-dir full-2018-09-11_09-38-32
Se till att behörigheterna är korrekta. I mitt fall används normal användare och grupp. Starta sedan servern.
$ sudo chown mysql:mysql /var/lib/mysql -R
$ sudo service mariadb start
Låt oss sedan ansluta till servern och verifiera att den har de data den ska ha. Jag bestämde mig för att fråga efter maximalt nummer i Jira.
# connect to mariadb
$ mysql -uusername -ppassword
# query the database
MariaDB [(none)]> USE jiradb
MariaDB [jiradb]> SELECT MAX(issuenum) FROM jiraissue;
Voila! Vi har nu säkerhetskopior som fungerar på MariaDB Server 10.3.