sql >> Database teknologi >  >> RDS >> MariaDB

Database-sikkerhedskopier - Sammenligning af MariaDB Mariabackup og Percona Xtrabackup

Din databaseserver gemmer nogle af din virksomheds mest værdifulde oplysninger. At garantere pålidelige databasesikkerhedskopier for at forhindre tab af data i tilfælde af en ulykke eller hardwarefejl er et kritisk afkrydsningsfelt.

Uanset om det er en 24x7 højt belastet server eller et miljø med lavt transaktionsvolumen, vil du have behov for at gøre sikkerhedskopier til en problemfri procedure uden at forstyrre serverens ydeevne i et produktionsmiljø.

I denne blog skal vi gennemgå to af de mest brugte værktøjer til at udføre denne opgave, nemlig Percona XtraBackup og Mariabackup. Vi vil gennemgå lighederne og forskellene mellem de to af dem, og også hvordan man bruger dem.

Hvad er Percona XtraBackup?

Percona XtraBackup er et open source-værktøj til at udføre backup af MariaDB, MySQL og Percona Server-databaser. Den udfører online ikke-blokering (for de understøttede motorer), tæt komprimerede og sikre fulde sikkerhedskopier på transaktionssystemer, så applikationer forbliver fuldt tilgængelige i hele sikkerhedskopieringsvinduet.

Ved at bruge dette værktøj kan du:

  • Opret hot InnoDB-sikkerhedskopier, der fuldføres hurtigt og pålideligt uden at sætte din database på pause eller tilføje belastning til serveren
  • Lav trinvise sikkerhedskopier
  • Flyt tabeller mellem MySQL-servere online
  • Opret nemt nye MySQL-replikeringsslaver
  • Stream komprimerede MySQL-sikkerhedskopier til en anden server
  • Spar på diskplads og netværksbåndbredde

Hvad er Mariabackup?

Mariabackup er et open source-værktøj leveret af MariaDB til at udføre fysiske online sikkerhedskopier. Det er en gaffel af Percona XtraBackup designet til at arbejde med krypterede og komprimerede tabeller og er den anbefalede backupmetode til MariaDB-databaser.

MariaDB Server 10.1 introducerede MariaDB-komprimering og Data-at-Rest-kryptering, men de eksisterende backup-løsninger understøttede ikke fuld backup-kapacitet for disse funktioner. Så MariaDB besluttede at udvide XtraBackup (version 2.3.8) og gav denne løsning navnet Mariabackup.

Forskelle mellem Percona XtraBackup og Mariabackup

Som vi bemærkede tidligere, er Mariabackup det anbefalede sikkerhedskopieringsværktøj til MariaDB, og den største forskel fra XtraBackup er, at det fungerer med krypterede og komprimerede tabeller.

Under alle omstændigheder, hvis du af en bestemt grund vil bruge XtraBackup til din MariaDB-database, er der nogle punkter at tage hensyn til afhængigt af den MariaDB-serverversion, du har:

  • MariaDB 10.1:Med ukomprimerede og ukrypterede MariaDB-data kan du bruge XtraBackup. Hvis der bruges kryptering eller komprimering, eller når innodb_page_size er indstillet til en anden værdi end 16K, fungerer det ikke.
  • MariaDB 10.2:Du vil måske også prøve at bruge XtraBackup, men vær opmærksom på, at problemer sandsynligvis skyldes MySQL 5.7 fortryd logformat inkompatibilitetsfejlen, der blev rettet i MariaDB 10.2.2. På grund af denne fejl kan sikkerhedskopier forberedt med XtraBackup muligvis ikke gendanne nogle transaktioner. Kun hvis du kører serveren med indstillingen innodb_undo_logs=1 ville dette ikke være et problem.
  • MariaDB 10.3 og nyere:Denne sag er mere enkel. XtraBackup er ikke kompatibel.

Der er også nogle begrænsninger, der skal tages i betragtning, når du bruger Mariabackup:

  • MyRocks:Fra og med MariaDB 10.2.16 og MariaDB 10.3.8 vil Mariabackup sikkerhedskopiere MyRocks Storage Engine-data. Delvis sikkerhedskopiering af MyRocks-data er i øjeblikket ikke understøttet. Inkrementel backup vil gemme en fuld kopi af MyRocks-data.
  • Eksporter filfunktionalitet:Før MariaDB 10.2.9 understøttede Mariabackup ikke --export-funktionaliteten (den opretter en eksportfil til at eksportere data fra databasen). Du kan omgå denne begrænsning ved at forberede sikkerhedskopien som sædvanligt (uden --export-flaget), start derefter serveren og udfør FLUSH TABLES FOR EKSPORT.
  • Logfiler:Mariabackup-versioner indtil 10.2.8 opretter ikke tomme logfiler og er afhængige af --copy-back-handlingen udført af brugeren (som sletter gamle innodb-logfiler, hvis nogen). Hvis brugeren ikke bruger --copy-back eller sørger for, at databiblioteket er tomt før gendannelse, kan sikkerhedskopierne, der er oprettet med disse versioner, meget vel blive inkonsistente/ødelagte (på grund af tilstedeværelsen af ​​resterende InnoDB-logfiler).
  • Gcrypt:Sikkerhedskopieringsværktøj baseret kryptering (gcrypt) understøttes ikke på Mariabackup.
  • Innobackupex mulighed:Intet symbollink til innobackupex (brug parameteren --innobackupex i stedet). Innobackupex-værktøjet retter og giver yderligere funktioner i forhold til innobackup-værktøjet til sikkerhedskopiering af InnoDB- og MyISAM-tabeller.
  • Kompakt mulighed:--kompakt mulighed er ikke understøttet.
  • Genopbygg indekser mulighed:--rebuild_indexes mulighed er ikke understøttet.
  • Tar for backup-filer:Understøttelse af --stream=tar blev fjernet i Mariabackup 10.1.24 (--streams-indstillingerne streamer backup-filer til stdout).

Til sidst, men ikke mindst, kan Mariabackup installeres på Windows.

Sikkerhedskopieringsproces Gendannelsesproces

Sådan - Percona XtraBackup og Mariabackup

Lad os se, hvordan vi kan installere og bruge det.

Installation

Du har forskellige metoder til at installere både XtraBackup og Mariabackup. Lad os prøve installationen fra repositories.

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

Mariabackup-installation

På Debian / Ubuntu

Mariabackup er en del af MariaDB Server starter 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 og Mariabackup læser [mysqld] og [xtrabackup] sektionerne af enhver MySQL konfigurationsfil i den rækkefølge. På denne måde kan den læse MySQL-parametre, såsom datadir eller InnoDB-parametre.

Vi kan ændre parametrene inkluderet i [mysqld] sektionen ved at ændre deres værdi i [xtrabackup], som vi nævnte før, læses de i rækkefølge, så det sidste vi har i [xtrabackup] vil have prioritet.

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

Brugeren med de minimumsrettigheder, der kræves til fuld sikkerhedskopiering, vil være RELOAD, LÅS TABELLER, PROCES og REPLIKATIONSKLIENT:

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

Og så kan du tilføje denne bruger i MySQL-konfigurationsfilerne:

[xtrabackup]
user=backupuser
password=Password

Du kan også bruge Xtrabackup eller Mariabackup til at udføre State Snapshot-overførsler, når du bruger en Percona XtraDB Cluster eller MariaDB Galera Cluster. Du skal indstille wsrep_sst_method og wsrep_sst_auth variablerne i konfigurationsfilerne:

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

Eller

[mysqld]
wsrep_sst_method=mariabackup
wsrep_sst_auth=backupuser:Password

Brug

Da Mariabackup er baseret på XtraBackup, kan den bruges på samme måde.

Lad os nu se et eksempel med begge metoder til at oprette, forberede og gendanne en fuld sikkerhedskopi.

Oprettelse af en sikkerhedskopi

For at oprette en ny sikkerhedskopi med XtraBackup eller Mariabackup skal du tilføje --backup og --target-dir mulighederne til kommandolinjen:

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

Eller

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

Målkataloget, hvor sikkerhedskopien vil blive gemt, kan angives i MySQL-konfigurationsfilerne. Sikkerhedskopieringsprocessen vil ikke overskrive eksisterende filer. Hvis filen findes, vil sikkerhedskopieringen mislykkes.

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

Hvis alt gik fint, skulle den sidste linje, du ser, være "fuldført OK!". Du kan annullere sikkerhedskopieringen til enhver tid, da den ikke ændrer databasens indhold.

[[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

Dette bør være indholdet af din sikkerhedskopi. Det kan ændre sig afhængigt af dine databaser.

Forberedelse af en sikkerhedskopi

Når du har lavet din backup med XtraBackup eller Mariabackup, skal du forberede den til at blive gendannet. Datafiler er ikke konsistente, før de er blevet forberedt, fordi de blev kopieret på forskellige tidspunkter i løbet af sikkerhedskopieringen. Hvis du forsøger at gendanne den og starte din database, vil den opdage korruption og nedbryde sig selv for at forhindre dig i at køre på inkonsistente data.

For at forberede sikkerhedskopien skal du køre kommandoen xtrabackup eller mariabackup med --prepare option og specificere måladressen, hvor sikkerhedskopien er gemt.

$ 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 sidste linje, du ser, skulle være "Slukning fuldført; log sekvensnummer xxxxxxx" og "fuldført OK!" hvis alt gik fint. Det anbefales ikke at annullere forberedelsesprocessen, da det kan forårsage datafilkorruption, og sikkerhedskopien bliver ubrugelig.

Hvis du vil bruge denne sikkerhedskopi med en trinvis sikkerhedskopi senere, skal du bruge --apply-log-only muligheden, når du forbereder den, ellers vil du ikke være i stand til at gøre det.

Gendannelse af en sikkerhedskopi

Efter at have forberedt sikkerhedskopien, kan du bruge gendannelsesindstillingen med parametrene --copy-back eller --move-back, til at kopiere eller flytte sikkerhedskopien til datadir. Hvis du ikke har nok diskplads, bør du sandsynligvis bruge flyttemuligheden. Vi er også nødt til at angive måladressen, hvor sikkerhedskopien er gemt. Husk, at datadirigenten skal være tom, og databasetjenesten skal være nede, før sikkerhedskopien gendannes.

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

Eller

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

Det vil først kopiere/flytte MyISAM-tabellerne og indekserne, derefter InnoDB-tabeller og indekser og til sidst logfilerne. Det vil bevare filens attributter, når du kopierer dem, du skal muligvis ændre filernes ejerskab til mysql, før du starter databaseserveren, da de vil være ejet af den bruger, der oprettede sikkerhedskopien.

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

Der er flere parametre at bruge med Xtrabackup og Mariabackup. Du kan tjekke disse parametre her for XtraBackup, og her for Mariabackup.

ClusterControlSingle Console for hele din databaseinfrastrukturFind ud af, hvad der ellers er nyt i ClusterControlInstaller ClusterControl GRATIS

Administration af dine sikkerhedskopier på ClusterControl

Som vi så ovenfor, er det ikke raketvidenskab at køre en backup. Det kan også planlægges med cron (men pas på lydløse fejl!). Et script til regelmæssigt at oprette sikkerhedskopier er dog ikke en løsning til backupadministration. Du har brug for en måde at rapportere om dine sikkerhedskopier og advare om fejl. At konfigurere sikkerhedskopier i dit miljø og se sikkerhedskopierne fungere uden fejl betyder nu ikke, at alt er godt. Du har måske hørt om Schrödingers backup, som siger, at tilstanden af ​​enhver backup er ukendt, indtil en gendannelse er forsøgt. Fordi det værste, der kan ske, er en katastrofe, og du indser, at sikkerhedskopierne er forkerte af en eller anden grund. Du forsøger at gendanne de filer, der blev sikkerhedskopieret, og det gendanner ikke det, du tror, ​​du har taget backup af, eller det gendanner slet ikke! Så er der ting som at flytte backup-filer offsite, f.eks. til ekstern cloud-lagring, til katastrofegendannelse. Kryptering og håndtering af nøgler er vigtigt for sikkerheden. Opbevaring af lokale såvel som eksterne/arkiverede sikkerhedskopier skal også administreres.

Lad os se, hvordan ClusterControl kan hjælpe.

Hvis du vil bruge funktionen ClusterControl Backup, skal du gå til ClusterControl -> Vælg Cluster -> Backup, og der kan du se dine nuværende sikkerhedskopier, oprette eller planlægge en ny.

ClusterControl Backup Section

Ved at bruge muligheden for at oprette eller planlægge kan vi vælge begge, XtraBackup eller Mariabackup-metoden. I samme afsnit kan vi vælge den server, som vi vil tage backup fra, aktivere delvis backup, vælge hvor du vil gemme backup, og om du vil uploade backup til skyen (AWS, Azure eller Google Cloud).

ClusterControl Opret sikkerhedskopi 1

Derefter kan vi vælge sikkerhedskopieringsparametre som komprimering, kryptering og opbevaring.

ClusterControl Opret sikkerhedskopi 2

Og disse bør være de kommandoer, som ClusterControl vil køre for 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.

Denne kommando kan være anderledes afhængigt af hvilke parametre du vælger.

Som vi kunne se, er ClusterControl en god ven, hvis vi vil bruge XtraBackup eller Mariabackup. Vi kan køre komplekse backupkommandoer på en nem måde ved at vælge mulighederne fra ClusterControl UI.
ClusterControl understøtter både fuld eller trinvis backup, så vi kan konfigurere al vores backupstrategi fra en brugervenlig UI.

Konklusion

Når du sikkerhedskopierer en MariaDB-server, anbefales det at bruge Mariabackup-værktøjet. Men hvis du af en eller anden grund foretrækker at bruge XtraBackup, kan du det stadig. Men du skal huske på de begrænsninger, der gælder, som vi har bemærket i denne blog. Og til sidst diskuterede vi, hvordan et script til at sikkerhedskopiere en database ikke er det samme som en backup-administrationsløsning, og vi fik et hurtigt kig på ClusterControl.

Fortæl os, hvis vi savnede nogen forskelle mellem XtraBackup og MariaBackup.

De ikke-blokerende sikkerhedskopier understøttes af InnoDB-, XtraDB- og HailDB-lagringsmotorer. Følgende lagermotorer kan sikkerhedskopieres ved kort at sætte skrivninger på pause i slutningen af ​​sikkerhedskopieringen:MyISAM, Merge og Archive, inklusive partitionerede tabeller, triggere og databaseindstillinger.


  1. Administrer MySQL med phpMyAdmin på Debian 5 (Lenny)

  2. Forenkle indlejret store og små bogstaver, når sætning

  3. hvordan udføres et .sql-script på heroku?

  4. Bedste måde at fange sql unikke begrænsninger i c# under indsættelser