sql >> Databasteknik >  >> RDS >> Mysql

Hur du anpassar dina MySQL- och MariaDB-säkerhetskopier med ClusterControl

ClusterControls centraliserade backuphanteringsfunktion stöder standard mysqldump, Percona Xtrabackup backup och Mariabackup som tillhandahålls av MariaDB. Vi tror att de valda kommandoradsargumenten för respektive metoder är optimala för de flesta databasarbetsbelastningar och överensstämmer med bästa praxis för MySQL backup. Vi baserar oss på all feedback vi har fått genom åren, när vi arbetar med DBA:er och sysadmins. Konfigurationen kanske inte räcker under vissa omständigheter. Du kanske fortfarande vill anpassa den för att passa din miljö, med hjälp av respektive säkerhetskopieringsmetod. I det här inlägget kommer vi att visa dig hur du gör detta.

mysqldump

För att göra en säkerhetskopiering från ClusterControl UI, gå till ClusterControl -> Välj Cluster -> Säkerhetskopiering. Här kan du se de genererade säkerhetskopiorna och du kan skapa eller schemalägga en ny.

Från ClusterControl UI har vi några olika alternativ för att ta säkerhetskopian. Vi kan skapa en dumpfil för varje databas, aktivera partiell backup, lagra backupen på noden eller på ClusterControl-servern; vi kan ange säkerhetskopieringskatalogen och underkatalogen, eller så kan vi automatiskt arkivera säkerhetskopian till molnet (AWS, Google Cloud eller Azure) med hjälp av molnuppladdningsfunktionen.

Vi kan också använda komprimering, kryptera vår säkerhetskopia och ange lagringsperioden.

Som standard tillåter ClusterControl oss att välja mellan 4 olika dumptyper för att utföra säkerhetskopieringen:

  • Schema och data:Databasschema och data
  • Endast schema:Databasschema
  • Endast data:Databasdata
  • Endast MySQL Db:MySQL-systemdatabas

Låt oss säga att vi har 5 databaser och vi valde att säkerhetskopiera alla. Här är vad ClusterControl kommer att köra när säkerhetskopieringen utförs med mysqldump-metoden (kommandon beskärs med omvänt snedstreck för läsbarhet):

  • Schema och data
    $ /usr/bin/mysqldump \
    --defaults-file=/etc/my.cnf \
    --flush-privileges \
    --hex-blob \
    --opt \
    --single-transaction \
    --skip-lock-tables \
    --triggers \
    --routines \
    --events \
    --set-gtid-purged=OFF \
    --databases mysql proxydemo sakila sbtest mydb \
    --ignore-table='mysql.innodb_index_stats' \
    --ignore-table='mysql.innodb_table_stats' \
    |gzip -6 -c > /root/backups/BACKUP-1/mysqldump_2018-11-06_203010_schemaanddata.sql.gz'.
  • Endast schema
    $ /usr/bin/mysqldump \
    --defaults-file=/etc/my.cnf \
    --flush-privileges \
    --hex-blob \
    --opt \
    --no-data \
    --add-drop-table \
    --triggers \
    --routines \
    --events \
    --single-transaction \
    --skip-comments \
    --skip-lock-tables \
    --set-gtid-purged=OFF \
    --databases mysql proxydemo sakila sbtest mydb \
    |gzip -6 -c > /root/backups/BACKUP-2/mysqldump_2018-11-06_210040_schemaonly.sql.gz'.
  • Endast data
    $ /usr/bin/mysqldump \
    --defaults-file=/etc/my.cnf \
    --flush-privileges \
    --hex-blob \
    --opt \
    --no-create-info \
    --single-transaction \
    --skip-comments \
    --skip-lock-tables \
    --skip-triggers \
    --skip-add-locks \
    --set-gtid-purged=OFF \
    --databases mysql proxydemo sakila sbtest mydb \
    --ignore-table='mysql.innodb_index_stats' \
    --ignore-table='mysql.innodb_table_stats' \
    |gzip -6 -c > /root/backups/BACKUP-3/mysqldump_2018-11-06_210445_dataonly.sql.gz'.
  • Endast MySQL DB
    $ /usr/bin/mysqldump \
    --defaults-file=/etc/my.cnf \
    --flush-privileges \
    --hex-blob \
    --opt \
    --single-transaction \
    --skip-comments \
    --skip-lock-tables \
    --skip-add-locks \
    --set-gtid-purged=OFF mysql \
    |gzip -6 -c > /root/backups/BACKUP-5/mysqldump_2018-11-06_211135_mysqldbonly.sql.gz'.

Om vår MySQL-nod genererar binära loggar kommer vi att ha parametern master-data=2 inkluderad i kommandona ovan och 1 extra dumptyp tillgänglig:

  • Fullständig PITR-kompatibel
    $ /usr/bin/mysqldump \
    --defaults-file=/etc/my.cnf \
    --flush-privileges \
    --hex-blob \
    --opt \
    --master-data=1 \
    --single-transaction \
    --skip-lock-tables \
    --skip-lock-tables \
    --triggers \
    --routines \
    --events \
    --all-databases \
    |gzip -6 -c > /root/backups/BACKUP-6/mysqldump_2018-11-06_211451_complete.sql.gz'.

Från ovanstående kommandorader kan vi se att på varje mysqldump-kommando inkluderar ClusterControl MySQL-konfigurationsfilen i dess --defaults-file-argument. Genom att ha detta kan mysqldump-processen läsa innehållet i mysqldump-direktivet. Som standard konfigurerar ClusterControl användaruppgifterna för säkerhetskopiering i en separat fil i /etc/my.cnf.d/secrets-backup.cnf och max_allowed_packet i my.cnf, liknande följande:

$ my.cnf

[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8

$ secrets-backup.cnf

[mysqldump]
user=backupuser
password=ETgAG5VnpvuyXniE

Fördelen med detta är att vi kan inkludera några extra alternativ för mysqldump. Tyvärr kan --defaults-file-argumentet bara anges som det främsta argumentet. Var uppmärksam på att de senare kommandoradsargumenten har företräde för vad som har konfigurerats inuti my.cnf enligt [mysqldump]-direktivet baserat på den ordning de visas. Till exempel, om vi lägger till skip-comments=0 inuti my.cnf, medan det i slutet av mysqldump-kommandot finns en --skip-comments (eller --skip-comments=1), kommer den förra att ignoreras och den senare kommer att användas.

Ändå kan vi fortfarande använda det som en del av vår säkerhetskopieringsanpassning genom att använda andra mysqldump säkerhetskopieringsalternativ. Till exempel kan vi utesluta tabeller som vi inte vill säkerhetskopiera genom att använda parametern ignore-table (med formateringen "database.table"). Lägg till följande rader i MySQL-konfigurationsfilen:

[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8
ignore-table=sbtest.sbtest9
ignore-table=sbtest.sbtest10
ignore-table=sbtest.sbtest1

När vi väl är konfigurerade kan vi bara utlösa ett nytt mysqldump-jobb från ClusterControl och vi kommer att hoppas över dessa tabeller av mysqldump. Ingen MySQL-omstart krävs.

Du kan kontrollera mysqldump-dokumentationen för mer information.

Percona Xtrabackup

ClusterControl exekverar Xtrabackup beroende på de alternativ du väljer. Den kan vara full eller inkrementell och du kan välja flera variabler från ClusterControl UI. Tänk på följande:

I det här steget kan du välja några variabler som vi nämnde tidigare i mysqldump-sektionen, och sedan:

Vi kan specificera vissa detaljer som desync nod under backup, Xtrabackup Parallel Copy Threads och mer.

Baserat på ovanstående alternativ skulle det fullständiga Xtrabackup-kommandot vara:

$ ulimit -n 256000 && LC_ALL=C /usr/bin/innobackupex --defaults-file=/etc/mysql/my.cnf  --galera-info --parallel 1 --stream=xbstream --no-timestamp . | gzip -6 - | socat - TCP4:192.168.100.110:9999 ) 2>&1.

Det första kommandot "ulimit -n 256000" är att säkerställa att Percona Xtrabackup har tillräckliga privilegier för att komma åt ett stort antal filbeskrivningar (ifall databaserna innehåller många tabeller). Notera --defaults-file=/etc/mysql/my.cnf, som liknar mysqldump, där innobackupex läser innehållet i MySQL-konfigurationen på följande direktiv och variabler:

[mysqld]
datadir=[physical path to MySQL data directory]
tmpdir=[path to temporary directory]
[xtrabackup]
user=backupuser
password=[random password]

Om du vill anpassa säkerhetskopieringsalternativen för Percona Xtrabackup kan du lägga till dem direkt under [xtrabackup]-direktivet. Låt oss till exempel säga att vi vill att Xtrabackup ska skriva ut den binära loggpositionen när säkerhetskopian tas, vi kan lägga till något så här:

[xtrabackup]
user=backupuser
password=[random password]
slave-info=1

Att utlösa xtrabackup-jobbet kommer då att inkludera en fil som heter xtrabackup_slave_info file. Ingen MySQL-omstart krävs.

Du kan kontrollera Perconas dokumentation för mer information om hur det fungerar.

Mariabackup

Mariabackup är en gaffel av Percona XtraBackup med extra stöd för MariaDB 10.1-komprimering och data-at-rest-kryptering. Den ingår i MariaDB 10.1.23 och senare.

Säkerhetskopieringsmetoden kan vara fullständig eller inkrementell och du kan välja samma variabler som du har för Percona XtraBackup, som komprimering, Xtrabackup Parallel Copy Threads eller Encryption.

Mariabackup-kommandot skulle vara:

$ /usr/bin/mariabackup \
--defaults-file=/etc/my.cnf \
--backup \
--galera-info \
--parallel 1 \
--stream=xbstream \
--no-timestamp \
| gzip -6 - > /root/backups/BACKUP-8/backup-full-2018-11-07_015807.xbstream.gz ) 2>&1.

Mariabackup är baserat på Percona XtraBackup, så den använder samma information som Percona för att utföra säkerhetskopieringen. Som standard lägger ClusterControl till följande rader i filen my.cnf:

[xtrabackup]
databases-exclude=lost+found
# ssl_mode = DISABLED
ssl = 0

Och referenserna i filen secrets-backup.cnf:

[xtrabackup]
user=backupuser
password=[random password]

Om du vill lägga till någon variabel kan du lägga till den i avsnittet [xtrabackup].

Du kan kontrollera MariaDB-dokumentationen för mer information om vilken parameter du ska lägga till.

I varje fall kan du kontrollera dina säkerhetskopior från avsnittet Säkerhetskopiering på ClusterControl UI:

Vi hoppas att detta hjälper dig att bättre konfigurera dina MySQL-säkerhetskopior - du kan ladda ner ClusterControl från vår webbplats (det är gratis).


  1. Vad är en frågeavvikare och hur man åtgärdar det

  2. Returnera lagrade procedurer och funktioner i en SQL Server-databas:RUTINER (T-SQL-exempel)

  3. Hur man lagrar videoinnehåll i SQLite-databasen (inte videosökvägen)

  4. Beräkna medianen med en dynamisk markör