Mysql
 sql >> Datenbank >  >> RDS >> Mysql

So passen Sie Ihre MySQL- und MariaDB-Backups mit ClusterControl an

Die zentralisierte Sicherungsverwaltungsfunktion von ClusterControl unterstützt die von MariaDB bereitgestellten standardmäßigen Sicherungen mysqldump, Percona Xtrabackup und Mariabackup. Wir glauben, dass die gewählten Befehlszeilenargumente für die jeweiligen Methoden für die meisten Datenbank-Workloads optimal sind und den Best Practices für MySQL-Backups entsprechen. Wir stützen uns auf all das Feedback, das wir im Laufe der Jahre bei der Arbeit mit DBAs und Systemadministratoren erhalten haben. Die Konfiguration reicht jedoch unter Umständen nicht aus. Möglicherweise möchten Sie es dennoch mithilfe der entsprechenden Sicherungsmethode an Ihre Umgebung anpassen. In diesem Beitrag zeigen wir Ihnen, wie das geht.

mysqldump

Um eine Sicherung über die ClusterControl-Benutzeroberfläche durchzuführen, gehen Sie zum Abschnitt ClusterControl -> Cluster auswählen -> Sicherung. Hier sehen Sie die generierten Backups und können ein neues erstellen oder planen.

Von der ClusterControl-Benutzeroberfläche aus haben wir einige verschiedene Optionen, um das Backup zu erstellen. Wir können eine Dumpdatei für jede Datenbank erstellen, eine teilweise Sicherung aktivieren, die Sicherung auf dem Knoten oder auf dem ClusterControl-Server speichern; Wir können das Backup-Verzeichnis und Unterverzeichnis angeben oder das Backup mithilfe der Cloud-Upload-Funktion automatisch in der Cloud (AWS, Google Cloud oder Azure) archivieren.

Außerdem können wir die Komprimierung verwenden, unser Backup verschlüsseln und die Aufbewahrungsfrist festlegen.

Standardmäßig erlaubt uns ClusterControl, zwischen 4 verschiedenen Dump-Typen zu wählen, um das Backup durchzuführen:

  • Schema und Daten:Datenbankschema und Daten
  • Nur Schema:Datenbankschema
  • Nur Daten:Datenbankdaten
  • Nur MySQL Db:MySQL-Systemdatenbank

Nehmen wir an, wir haben 5 Datenbanken und wir haben uns entschieden, alle zu sichern. Folgendes wird ClusterControl ausführen, wenn das Backup mit der mysqldump-Methode durchgeführt wird (Befehle sind zur besseren Lesbarkeit mit einem umgekehrten Schrägstrich versehen):

  • Schema und Daten
    $ /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'.
  • Nur 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'.
  • Nur Daten
    $ /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'.
  • Nur 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'.

Wenn unser MySQL-Knoten Binärprotokolle generiert, haben wir den Parameter master-data=2 in den obigen Befehlen und 1 zusätzlichen Dump-Typ verfügbar:

  • Vollstä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'.

Aus den obigen Befehlszeilen können wir ersehen, dass ClusterControl bei jedem mysqldump-Befehl die MySQL-Konfigurationsdatei in sein --defaults-file-Argument einbezieht. Dadurch kann der mysqldump-Prozess den Inhalt der mysqldump-Direktive lesen. Standardmäßig konfiguriert ClusterControl die Backup-Benutzeranmeldeinformationen in einer separaten Datei in /etc/my.cnf.d/secrets-backup.cnf und das max_allowed_packet in my.cnf, ähnlich wie im Folgenden:

$ my.cnf

[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8

$ secrets-backup.cnf

[mysqldump]
user=backupuser
password=ETgAG5VnpvuyXniE

Der Vorteil davon ist, dass wir einige zusätzliche Optionen für mysqldump hinzufügen können. Leider kann das Argument --defaults-file nur als vorderstes Argument angegeben werden. Beachten Sie, dass die letzteren Befehlszeilenargumente Vorrang vor dem haben, was in my.cnf unter der Direktive [mysqldump] konfiguriert wurde, basierend auf der Reihenfolge, in der sie erscheinen. Wenn wir beispielsweise skip-comments=0 in my.cnf einfügen, während am Ende des mysqldump-Befehls ein --skip-comments (oder --skip-comments=1) steht, wird ersteres ignoriert und Letzteres wird verwendet.

Trotzdem können wir es weiterhin als Teil unserer Backup-Anpassung verwenden, indem wir andere mysqldump-Backup-Optionen verwenden. Beispielsweise können wir Tabellen ausschließen, die wir nicht sichern möchten, indem wir den Parameter „ignore-table“ (mit „database.table“-Formatierung) verwenden. Fügen Sie die folgenden Zeilen in die MySQL-Konfigurationsdatei ein:

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

Einmal konfiguriert, können wir einfach einen neuen mysqldump-Job von ClusterControl auslösen und wir werden diese Tabellen von mysqldump überspringen lassen. Es ist kein MySQL-Neustart erforderlich.

Weitere Informationen finden Sie in der mysqldump-Dokumentation.

Percona Xtrabackup

ClusterControl führt das Xtrabackup abhängig von den gewählten Optionen aus. Es kann vollständig oder inkrementell sein und Sie können mehrere Variablen aus der ClusterControl-Benutzeroberfläche auswählen. Beachten Sie Folgendes:

In diesem Schritt können Sie einige Variablen auswählen, die wir zuvor im mysqldump-Abschnitt erwähnt haben, und dann:

Wir können einige Details wie Desync-Knoten während der Sicherung, Xtrabackup Parallel Copy Threads und mehr angeben.

Basierend auf den obigen Optionen wäre der vollständige Xtrabackup-Befehl:

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

Der erste Befehl „ulimit -n 256000“ soll sicherstellen, dass Percona Xtrabackup über ausreichende Berechtigungen verfügt, um auf eine große Anzahl von Dateideskriptoren zuzugreifen (falls die Datenbanken viele Tabellen enthalten). Beachten Sie die --defaults-file=/etc/mysql/my.cnf, die mysqldump ähnlich ist, wo innobackupex den Inhalt der MySQL-Konfiguration in den folgenden Direktiven und Variablen liest:

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

Wenn Sie die Sicherungsoptionen für Percona Xtrabackup anpassen möchten, können Sie diese direkt unter der Direktive [xtrabackup] hinzufügen. Nehmen wir zum Beispiel an, wir möchten, dass Xtrabackup die Position des Binärprotokolls druckt, wenn das Backup erstellt wird, dann können wir so etwas hinzufügen:

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

Das Auslösen des xtrabackup-Jobs enthält dann eine Datei namens xtrabackup_slave_info file. Es ist kein MySQL-Neustart erforderlich.

Weitere Informationen zur Funktionsweise finden Sie in der Percona-Dokumentation.

Mariasicherung

Mariabackup ist ein Fork von Percona XtraBackup mit zusätzlicher Unterstützung für MariaDB 10.1-Komprimierung und Data-at-Rest-Verschlüsselung. Es ist in MariaDB 10.1.23 und höher enthalten.

Die Backup-Methode kann vollständig oder inkrementell sein und Sie können dieselben Variablen auswählen, die Sie für Percona XtraBackup haben, wie Komprimierung, Xtrabackup Parallel Copy Threads oder Encryption.

Der Mariabackup-Befehl wä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 basiert auf Percona XtraBackup, verwendet also dieselben Informationen wie Percona, um die Sicherung durchzuführen. Standardmäßig fügt ClusterControl die folgenden Zeilen in die my.cnf-Datei ein:

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

Und die Anmeldeinformationen in der Datei secrets-backup.cnf:

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

Wenn Sie eine Variable hinzufügen möchten, können Sie sie in den Abschnitt [xtrabackup] einfügen.

In der MariaDB-Dokumentation finden Sie weitere Informationen darüber, welche Parameter hinzugefügt werden müssen.

In jedem Fall können Sie Ihre Backups im Backup-Bereich auf der ClusterControl-Benutzeroberfläche überprüfen:

Wir hoffen, dass dies Ihnen hilft, Ihre MySQL-Backups besser zu konfigurieren – Sie können ClusterControl von unserer Website herunterladen (es ist kostenlos).