sql >> Database teknologi >  >> RDS >> Mysql

Sådan tilpasser du dine MySQL- og MariaDB-sikkerhedskopier med ClusterControl

ClusterControls centraliserede backupstyringsfunktion understøtter standard mysqldump, Percona Xtrabackup backup og Mariabackup leveret af MariaDB. Vi mener, at de valgte kommandolinjeargumenter for de respektive metoder er optimale til de fleste database-arbejdsbelastninger og overholder MySQL-sikkerhedskopiets bedste praksis. Vi baserer os på al den feedback, vi har fået gennem årene, når vi arbejder med DBA'er og sysadmins. Konfigurationen er dog muligvis ikke nok under nogle omstændigheder. Du vil måske stadig tilpasse det, så det passer til dit miljø, ved hjælp af den respektive backupmetode. I dette indlæg vil vi vise dig, hvordan du gør dette.

mysqldump

For at udføre en sikkerhedskopi fra ClusterControl UI, skal du gå til ClusterControl -> Vælg Cluster -> Sikkerhedskopiering sektion. Her kan du se de genererede sikkerhedskopier, og du kan oprette eller planlægge en ny.

Fra ClusterControl UI har vi nogle forskellige muligheder for at tage backup. Vi kan oprette en dumpfil for hver database, aktivere delvis backup, gemme backup på noden eller på ClusterControl-serveren; vi kan angive sikkerhedskopieringsbiblioteket og underbiblioteket, eller vi kan automatisk arkivere sikkerhedskopien til skyen (AWS, Google Cloud eller Azure) ved hjælp af skyuploadfunktionen.

Vi kan også bruge komprimering, kryptere vores backup og angive opbevaringsperioden.

Som standard giver ClusterControl os mulighed for at vælge mellem 4 forskellige dumptyper for at udføre sikkerhedskopieringen:

  • Skema og data:Databaseskema og data
  • Kun skema:Databaseskema
  • Kun data:Databasedata
  • Kun MySQL Db:MySQL-systemdatabase

Lad os sige, at vi har 5 databaser, og vi valgte at tage backup af dem alle. Her er, hvad ClusterControl vil udføre, når sikkerhedskopieringen udføres ved hjælp af mysqldump-metoden (kommandoer trimmes med omvendt skråstreg for læsbarhed):

  • Skema og 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'.
  • Kun skema
    $ /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'.
  • Kun 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'.
  • Kun 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'.

Hvis vores MySQL-node genererer binære logfiler, har vi parameteren master-data=2 inkluderet i kommandoerne ovenfor og 1 ekstra dumptype tilgængelig:

  • Fuldfør 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'.

Fra ovenstående kommandolinjer kan vi se, at på hver mysqldump-kommando inkluderer ClusterControl MySQL-konfigurationsfilen i dens --defaults-file-argument. Ved at have dette er mysqldump-processen i stand til at læse indholdet af mysqldump-direktivet. Som standard konfigurerer ClusterControl sikkerhedskopieringsbrugerlegitimationsoplysningerne i en separat fil i /etc/my.cnf.d/secrets-backup.cnf og max_allowed_packet i my.cnf, svarende til følgende:

$ my.cnf

[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8

$ secrets-backup.cnf

[mysqldump]
user=backupuser
password=ETgAG5VnpvuyXniE

Fordelen ved dette er, at vi kan inkludere nogle ekstra muligheder for mysqldump. Desværre kan --defaults-file-argumentet kun angives som det forreste argument. Vær opmærksom på, at de sidstnævnte kommandolinjeargumenter har forrang for, hvad der er blevet konfigureret inde i my.cnf under [mysqldump]-direktivet baseret på den rækkefølge, de vises. For eksempel, hvis vi tilføjer skip-comments=0 inde i my.cnf, mens der i slutningen af ​​mysqldump-kommandoen er en --skip-comments (eller --skip-comments=1), vil førstnævnte blive ignoreret og sidstnævnte vil blive brugt.

Ikke desto mindre kan vi stadig bruge det som en del af vores backup tilpasning ved at bruge andre mysqldump backup muligheder. For eksempel kan vi udelukke tabeller, som vi ikke ønsker at sikkerhedskopiere, ved at bruge ignorer-table-parameteren (med "database.table"-formatering). Tilføj følgende linjer 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 de er konfigureret, kan vi bare udløse et nyt mysqldump-job fra ClusterControl, og vi vil få disse tabeller sprunget over af mysqldump. Ingen MySQL-genstart er påkrævet.

Du kan tjekke mysqldump-dokumentationen for mere information.

Percona Xtrabackup

ClusterControl udfører Xtrabackup afhængigt af de muligheder, du har valgt. Den kan være fuld eller trinvis, og du kan vælge flere variabler fra ClusterControl UI. Overvej følgende:

I dette trin kan du vælge nogle variabler, som vi nævnte tidligere i mysqldump-sektionen, og derefter:

Vi kan specificere nogle detaljer såsom desync node under backup, Xtrabackup Parallel Copy Threads og mere.

Baseret på ovenstående muligheder vil den komplette Xtrabackup-kommando være:

$ 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.

Den første kommando "ulimit -n 256000" er at sikre, at Percona Xtrabackup har tilstrækkelige privilegier til at få adgang til et stort antal filbeskrivelser (i tilfælde af, at databaserne indeholder mange tabeller). Læg mærke til --defaults-file=/etc/mysql/my.cnf, som ligner mysqldump, hvor innobackupex læser indholdet af MySQL-konfiguration på følgende direktiver og variabler:

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

Hvis du gerne vil tilpasse sikkerhedskopieringsmulighederne for Percona Xtrabackup, kan du tilføje dem direkte under [xtrabackup]-direktivet. Lad os f.eks. sige, at vi vil have Xtrabackup til at udskrive den binære logposition, når sikkerhedskopien tages, vi kan tilføje noget som dette:

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

Udløsning af xtrabackup-jobbet vil derefter inkludere en fil kaldet xtrabackup_slave_info-fil. Ingen MySQL-genstart er påkrævet.

Du kan tjekke Percona-dokumentationen for mere information om, hvordan det virker.

Mariabackup

Mariabackup er en gaffel af Percona XtraBackup med tilføjet understøttelse af MariaDB 10.1-komprimering og data-at-rest-kryptering. Det er inkluderet i MariaDB 10.1.23 og nyere.

Sikkerhedskopieringsmetoden kan være fuld eller trinvis, og du kan vælge de samme variabler, som du har til Percona XtraBackup, såsom komprimering, Xtrabackup Parallel Copy Threads eller Encryption.

Mariabackup-kommandoen ville være:

$ /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 er baseret på Percona XtraBackup, så den bruger de samme oplysninger som Percona til at udføre sikkerhedskopieringen. Som standard tilføjer ClusterControl følgende linjer i my.cnf-filen:

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

Og legitimationsoplysningerne i filen secrets-backup.cnf:

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

Hvis du vil tilføje en variabel, kan du tilføje den i [xtrabackup] sektionen.

Du kan tjekke MariaDB-dokumentationen for mere information om, hvilken parameter du skal tilføje.

I hvert tilfælde kan du kontrollere dine sikkerhedskopier fra afsnittet Backup på ClusterControl UI:

Vi håber, at dette hjælper dig med bedre at konfigurere dine MySQL-sikkerhedskopier - du kan downloade ClusterControl fra vores hjemmeside (det er gratis).


  1. Hvordan bruger man skemaer i Django?

  2. Vælg TOP X (eller nederste) procent for numeriske værdier i MySQL

  3. Tilslutning til MySQL ved hjælp af Python

  4. 2 måder at få antallet af dage i en måned i Oracle