Databasbackups - Jämför MariaDB Mariabackup och Percona Xtrabackup

Din databasserver lagrar en del av ditt företags mest värdefulla information. Att garantera tillförlitliga säkerhetskopior av databas för att förhindra dataförlust i händelse av en olycka eller maskinvarufel är en kritisk kryssruta.

Oavsett om det är en högbelastad server dygnet runt, eller en miljö med låga transaktionsvolymer, kommer du att behöva göra säkerhetskopior till en sömlös procedur utan att störa serverns prestanda i en produktionsmiljö.

I den här bloggen kommer vi att granska två av de mest använda verktygen för att utföra denna uppgift, nämligen Percona XtraBackup och Mariabackup. Vi kommer att gå igenom likheterna och skillnaderna mellan de två, och även hur man använder dem.

Vad är Percona XtraBackup?

Percona XtraBackup är ett verktyg med öppen källkod för att utföra säkerhetskopiering av MariaDB, MySQL och Percona Server-databaser. Den utför online-icke-blockering (för de motorer som stöds), tätt komprimerade och säkra fullständiga säkerhetskopior på transaktionssystem så att applikationer förblir fullt tillgängliga under säkerhetskopieringsfönstret.

Genom att använda detta verktyg kan du:

• Skapa heta InnoDB-säkerhetskopior, som slutförs snabbt och tillförlitligt, utan att pausa din databas eller lägga till belastning på servern
• Gör inkrementella säkerhetskopior
• Flytta tabeller mellan MySQL-servrar online
• Skapa nya MySQL-replikeringsslavar enkelt
• Strömma komprimerade MySQL-säkerhetskopior till en annan server
• Spara på diskutrymme och nätverksbandbredd

Vad är Mariabackup?

Mariabackup är ett verktyg med öppen källkod som tillhandahålls av MariaDB för att utföra fysiska säkerhetskopieringar online. Det är en gaffel av Percona XtraBackup designad för att fungera med krypterade och komprimerade tabeller, och är den rekommenderade säkerhetskopieringsmetoden för MariaDB-databaser.

MariaDB Server 10.1 introducerade MariaDB Compression och Data-at-Rest Encryption, men de befintliga säkerhetskopieringslösningarna stödde inte full säkerhetskopieringskapacitet för dessa funktioner. Så MariaDB bestämde sig för att utöka XtraBackup (version 2.3.8) och döpte denna lösning till Mariabackup.

Skillnader mellan Percona XtraBackup och Mariabackup

Som vi noterade tidigare är Mariabackup det rekommenderade säkerhetskopieringsverktyget för MariaDB, och den största skillnaden från XtraBackup är att det fungerar med krypterade och komprimerade tabeller.

Hur som helst, om du av någon speciell anledning vill använda XtraBackup för din MariaDB-databas, finns det några punkter att ta hänsyn till beroende på vilken MariaDB-serverversion du har:

• MariaDB 10.1:Med okomprimerad och okrypterad MariaDB-data kan du använda XtraBackup. Om kryptering eller komprimering används, eller när innodb_page_size är inställt på något annat värde än 16K kommer det inte att fungera.
• MariaDB 10.2:Du kanske också vill prova att använda XtraBackup, men var medveten om att problem troligen beror på inkompatibilitetsfelet för MySQL 5.7 ångra loggformat som fixades i MariaDB 10.2.2. På grund av denna bugg kan säkerhetskopior som förbereds med XtraBackup misslyckas med att återställa vissa transaktioner. Endast om du kör servern med inställningen innodb_undo_logs=1 skulle detta inte vara ett problem.
• MariaDB 10.3 och senare:Det här fallet är enklare. XtraBackup är inte kompatibel.

Det finns också några begränsningar att ta hänsyn till när du använder Mariabackup:

• MyRocks:Från och med MariaDB 10.2.16 och MariaDB 10.3.8 kommer Mariabackup att säkerhetskopiera MyRocks Storage Engine-data. Partiell säkerhetskopiering av MyRocks-data stöds för närvarande inte. Inkrementell säkerhetskopiering lagrar en fullständig kopia av MyRocks-data.
• Exportera filfunktioner:Före MariaDB 10.2.9 stödde Mariabackup inte --export-funktionen (den skapar en exportfil för att exportera data från databasen). Du kan kringgå denna begränsning genom att förbereda säkerhetskopian som vanligt (utan --export-flaggan), starta sedan servern och kör FLUSH TABLES FOR EXPORT.
• Loggfiler:Mariabackup-versioner fram till 10.2.8 skapar inte tomma loggfiler och förlitar sig på --copy-back-åtgärden som utförs av användaren (som tar bort gamla innodb-loggfiler, om några). Om användaren inte använder --copy-back eller ser till att datakatalogen är tom före återställning, kan säkerhetskopiorna som skapas med dessa versioner mycket väl bli inkonsekventa/skadade (på grund av förekomsten av överblivna InnoDB-loggar).
• Gcrypt:Säkerhetskopieringsverktygsbaserad kryptering (gcrypt) stöds inte på Mariabackup.
• Innobackupex-alternativ:Ingen symbollänk till innobackupex (använd parametern --innobackupex istället). Verktyget innobackupex korrigerar och tillhandahåller ytterligare funktioner jämfört med verktyget innobackup för säkerhetskopiering av InnoDB- och MyISAM-tabeller.
• Kompakt alternativ:--kompakt alternativ stöds inte.
• Alternativ för ombyggnad av index:--rebuild_indexes-alternativet stöds inte.
• Tar för säkerhetskopieringsfiler:Stöd för --stream=tar togs bort i Mariabackup 10.1.24 (alternativen --streams strömmar säkerhetskopior till stdout).

Äntligen men inte minst kan Mariabackup installeras på Windows.

Hur man gör - Percona XtraBackup och Mariabackup

Låt oss se hur vi kan installera och använda det.

Installation

Du har olika metoder för att installera både XtraBackup och Mariabackup. Låt oss prova installationen från förråd.

XtraBackup-installation

På Debian/Ubuntu

$ wget https://repo.percona.com/apt/percona-release_0.1-6.$(lsb_release -sc)_all.deb
$ sudo dpkg -i percona-release_0.1-6.$(lsb_release -sc)_all.deb
$ sudo apt-get update
$ sudo apt-get install percona-xtrabackup-24

På RedHat/CentOS

$ sudo yum install http://www.percona.com/downloads/percona-release/redhat/0.1-6/percona-release-0.1-6.noarch.rpm
$ sudo yum install percona-xtrabackup-24

Installation av Mariabackup

På Debian/Ubuntu

Mariabackup är en del av MariaDB Server som börjar med MariaDB 10.1.23.

$ sudo apt-get install software-properties-common
$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
$ sudo add-apt-repository 'deb [arch=amd64,arm64,ppc64el] http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu bionic main'
$ sudo apt-get update
$ sudo apt-get install mariadb-server-10.1

På CentOS / RedHat

$ sudo vi /etc/yum.repos.d/MariaDB.repo
[mariadb]
name=MariaDB
baseurl=http://yum.mariadb.org/10.1/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
$ sudo yum install MariaDB-backup

Konfiguration

Både Xtrabackup och Mariabackup läser [mysqld] och [xtrabackup] sektionerna av alla MySQL-konfigurationsfiler, i den ordningen. På detta sätt kan den läsa MySQL-parametrar, såsom datadir eller InnoDB-parametrar.

Vi kan modifiera parametrarna som ingår i [mysqld]-sektionen genom att modifiera deras värde i [xtrabackup], som vi nämnde tidigare, de läses i ordning, så det sista vi har i [xtrabackup] kommer att ha prioritet.

[mysqld]
datadir=/data/datadir
[xtrabackup]
target_dir=/backups/

Användaren med de minimibehörigheter som krävs för fullständiga säkerhetskopior skulle vara RELOAD, LOCK TABLES, PROCESS and REPLICATION CLIENT:

mysql> CREATE USER 'backupuser'@'localhost' IDENTIFIED BY 'Password';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'backupuser'@'localhost';

Och sedan kan du lägga till den här användaren i MySQL-konfigurationsfilerna:

[xtrabackup]
user=backupuser
password=Password

Du kan också använda Xtrabackup eller Mariabackup för att utföra State Snapshot Transfers när du använder ett Percona XtraDB Cluster eller MariaDB Galera Cluster. Du måste ställa in variablerna wsrep_sst_method och wsrep_sst_auth i konfigurationsfilerna:

[mysqld]
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=backupuser:Password

Eller

[mysqld]
wsrep_sst_method=mariabackup
wsrep_sst_auth=backupuser:Password

Användning

Eftersom Mariabackup är baserat på XtraBackup kan den användas på liknande sätt.

Låt oss nu se ett exempel som använder båda metoderna för att skapa, förbereda och återställa en fullständig säkerhetskopia.

Skapa en säkerhetskopia

För att skapa en ny säkerhetskopia med XtraBackup eller Mariabackup måste du lägga till alternativen --backup och --target-dir på kommandoraden:

$ xtrabackup --backup --target-dir=/backups/

Eller

$ mariabackup --backup --target-dir=/backups/

Målkatalogen, där säkerhetskopian kommer att lagras, kan anges i MySQL-konfigurationsfilerna. Säkerhetskopieringsprocessen kommer inte att skriva över befintliga filer. Om filen finns kommer säkerhetskopieringen att misslyckas.

Transaction log of lsn (9755450) to (9755467) was copied.
181122 23:02:44 completed OK!

Om allt gick bra ska den sista raden som du ser vara "slutförd OK!". Du kan avbryta säkerhetskopieringen när som helst, eftersom den inte ändrar databasens innehåll.

[[email protected] ~]# ls -l /backups/
total 102448
-rw-r----- 1 root root       488 Nov 22 23:02 backup-my.cnf
-rw-r----- 1 root root       482 Nov 22 23:02 ib_buffer_pool
-rw-r----- 1 root root 104857600 Nov 22 23:02 ibdata1
drwxr-x--- 2 root root      4096 Nov 22 23:02 mysql
drwxr-x--- 2 root root      4096 Nov 22 23:02 performance_schema
drwxr-x--- 2 root root      4096 Nov 22 23:02 sakila
drwxr-x--- 2 root root     12288 Nov 22 23:02 sys
-rw-r----- 1 root root        64 Nov 22 23:02 xtrabackup_binlog_info
-rw-r----- 1 root root       113 Nov 22 23:02 xtrabackup_checkpoints
-rw-r----- 1 root root       533 Nov 22 23:02 xtrabackup_info
-rw-r----- 1 root root      2560 Nov 22 23:02 xtrabackup_logfile

Detta bör vara innehållet i din säkerhetskopia. Det kan ändras beroende på dina databaser.

Förbereder en säkerhetskopia

När du har skapat din säkerhetskopia med XtraBackup eller Mariabackup måste du förbereda den för att återställas. Datafiler är inte konsekventa förrän de har förberetts, eftersom de kopierades vid olika tidpunkter under säkerhetskopieringen. Om du försöker återställa den och starta din databas kommer den att upptäcka korruption och krascha sig själv för att förhindra att du kör på inkonsekventa data.

För att förbereda säkerhetskopian måste du köra kommandot xtrabackup eller mariabackup med alternativet --prepare och ange målkatalogen där säkerhetskopian lagras.

$ xtrabackup --prepare --target-dir=/backups/

Eller

$ mariabackup --prepare --target-dir=/backups/
InnoDB: Shutdown completed; log sequence number 9757224
181122 23:05:29 completed OK!

Den sista raden som du ser bör vara "Avslutad avstängning; logga sekvensnummer xxxxxxx" och "slutförd OK!" om allt gick bra. Det rekommenderas inte att avbryta förberedelseprocessen eftersom det kan orsaka datafilkorruption och säkerhetskopian blir oanvändbar.

Om du vill använda denna säkerhetskopia med en inkrementell säkerhetskopia senare, bör du använda alternativet --apply-log-only när du förbereder den, annars kommer du inte att kunna göra det.

Återställa en säkerhetskopia

Efter att ha förberett säkerhetskopian kan du använda återställningsalternativet med parametrarna --copy-back eller --move-back, för att kopiera eller flytta säkerhetskopian till datakatalogen. Om du inte har tillräckligt med diskutrymme bör du förmodligen använda alternativet flytta. Vi måste också ange målkatalogen där säkerhetskopian lagras. Tänk på att datakatalogen måste vara tom och databastjänsten bör vara nere innan du återställer säkerhetskopian.

$ xtrabackup --copy-back --target-dir=/backups/

Eller

$ mariabackup --copy-back --target-dir=/backups/

Det kommer först att kopiera/flytta MyISAM-tabellerna och indexen, InnoDB-tabellerna och indexen därefter och loggfilerna till sist. Det kommer att bevara filens attribut när du kopierar dem, du kanske måste ändra filernas äganderätt till mysql innan du startar databasservern, eftersom de kommer att ägas av användaren som skapade säkerhetskopian.

$ sudo chown -R mysql:mysql /var/lib/mysql

Det finns flera parametrar att använda med Xtrabackup och Mariabackup. Du kan kontrollera dessa parametrar här för XtraBackup och här för Mariabackup.

Hantera dina säkerhetskopior på ClusterControl

Som vi såg ovan är att köra en backup inte raketvetenskap. Det kan också schemaläggas med cron (men se upp för tysta misslyckanden!). Ett skript för att regelbundet skapa säkerhetskopior är dock inte en lösning för säkerhetskopiering. Du behöver ett sätt att rapportera om dina säkerhetskopior och varna om fel. Att konfigurera säkerhetskopior i din miljö och se att säkerhetskopiorna fungerar utan fel betyder inte att allt är bra. Du kanske har hört talas om Schrödingers säkerhetskopia, som säger att tillståndet för en säkerhetskopia är okänt tills en återställning har gjorts. För det värsta som kan hända är en katastrof och du inser att säkerhetskopiorna är fel av någon anledning. Du försöker återställa filerna som säkerhetskopierades, och det återställer inte det du tror att du har säkerhetskopierat, eller så återställs det inte alls! Sedan finns det saker som att flytta säkerhetskopior utanför platsen, t.ex. till extern molnlagring, för katastrofåterställning. Kryptering och hantering av nycklar är viktigt för säkerheten. Bevarande av lokala såväl som externa/arkiverade säkerhetskopior måste också hanteras.

Låt oss se hur ClusterControl kan hjälpa.

Om du vill använda funktionen ClusterControl Backup, gå till ClusterControl -> Välj Cluster -> Backup, och där kan du se dina nuvarande säkerhetskopior, skapa eller schemalägga en ny.

Genom att använda alternativet skapa eller schemalägga kan vi välja båda, XtraBackup eller Mariabackup-metoden. I samma avsnitt kan vi välja vilken server vi ska ta backupen från, aktivera partiell backup, välja var du vill lagra backupen och om du vill ladda upp backupen till molnet (AWS, Azure eller Google Cloud).

Sedan kan vi välja säkerhetskopieringsparametrar som komprimering, kryptering och retention.

Och dessa bör vara kommandona som ClusterControl kör åt dig:

[16:37:58]: 192.168.100.120: Launching ( LC_ALL=C /usr/bin/innobackupex --defaults-file=/etc/my.cnf --galera-info --parallel 1 --stream=xbstream --no-timestamp . | gzip -6 - > /root/backups/BACKUP-13/backup-full-2018-11-14_193757.xbstream.gz ) 2>&1.

Eller

[16:29:57]: 192.168.100.131: Launching ( LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - > /root/backups/BACKUP-11/backup-full-2018-11-14_192957.xbstream.gz ) 2>&1.

Detta kommando kan vara annorlunda beroende på vilka parametrar du väljer.

Som vi kunde se är ClusterControl en god vän om vi vill använda XtraBackup eller Mariabackup. Vi kan köra komplexa säkerhetskopieringskommandon på ett enkelt sätt genom att välja alternativen från ClusterControl-gränssnittet.
ClusterControl stöder både fullständig eller inkrementell säkerhetskopiering, så vi kan konfigurera all vår säkerhetskopieringsstrategi från ett användarvänligt gränssnitt.

Slutsats

När du säkerhetskopierar en MariaDB-server rekommenderas att du använder verktyget Mariabackup. Men om du av någon anledning föredrar att använda XtraBackup kan du fortfarande göra det. Men du måste tänka på de restriktioner som gäller, som vi har noterat i den här bloggen. Och slutligen diskuterade vi hur ett skript för att säkerhetskopiera en databas inte är samma sak som en säkerhetskopieringshanteringslösning, och tittade snabbt på ClusterControl.

Låt oss veta om vi missade några skillnader mellan XtraBackup och MariaBackup.

De icke-blockerande säkerhetskopieringarna stöds för InnoDB-, XtraDB- och HailDB-lagringsmotorer. Följande lagringsmotorer kan säkerhetskopieras genom att kort pausa skrivningar i slutet av säkerhetskopieringen:MyISAM, Merge och Archive, inklusive partitionerade tabeller, utlösare och databasalternativ.