La funzione di gestione centralizzata del backup di ClusterControl supporta lo standard mysqldump, il backup Percona Xtrabackup e il Mariabackup forniti da MariaDB. Riteniamo che gli argomenti della riga di comando scelti per i rispettivi metodi siano ottimali per la maggior parte dei carichi di lavoro del database e siano conformi alle migliori pratiche di backup di MySQL. Ci basiamo su tutti i feedback che abbiamo ricevuto nel corso degli anni, lavorando con DBA e amministratori di sistema. Tuttavia, la configurazione potrebbe non essere sufficiente in alcune circostanze. Potresti comunque volerlo personalizzare per adattarlo al tuo ambiente, usando il rispettivo metodo di backup. In questo post, ti mostreremo come farlo.
mysqldump
Per eseguire un backup dall'interfaccia utente di ClusterControl, andare su ClusterControl -> Seleziona cluster -> sezione Backup. Qui puoi vedere i backup generati e puoi crearne o programmarne uno nuovo.
Dall'interfaccia utente di ClusterControl, abbiamo diverse opzioni per eseguire il backup. Possiamo creare un dumpfile per ogni database, abilitare il backup parziale, archiviare il backup sul nodo o sul server ClusterControl; possiamo specificare la directory e la sottodirectory di backup, oppure possiamo archiviare automaticamente il backup nel cloud (AWS, Google Cloud o Azure) utilizzando la funzione di caricamento nel cloud.
Inoltre, possiamo utilizzare la compressione, crittografare il nostro backup e specificare il periodo di conservazione.
Per impostazione predefinita, ClusterControl ci consente di scegliere tra 4 diversi tipi di dump per eseguire il backup:
- Schema e dati:schema e dati del database
- Solo schema:schema del database
- Solo dati:dati del database
- Solo MySQL Db:database di sistema MySQL
Diciamo che abbiamo 5 database e abbiamo scelto di eseguirne il backup tutti. Ecco cosa eseguirà ClusterControl durante l'esecuzione del backup utilizzando il metodo mysqldump (i comandi sono tagliati con una barra rovesciata per la leggibilità):
- Schema e dati
$ /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'. - Solo 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'. - Solo dati
$ /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'. - Solo 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'.
Se il nostro nodo MySQL sta generando log binari, avremo il parametro master-data=2 incluso nei comandi sopra e 1 tipo di dump aggiuntivo disponibile:
- Completo PITR-compatibile
$ /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'.
Dalle righe di comando precedenti, possiamo vedere che in ogni comando mysqldump, ClusterControl include il file di configurazione MySQL nel suo argomento --defaults-file. In questo modo, il processo mysqldump è in grado di leggere il contenuto della direttiva mysqldump. Per impostazione predefinita, ClusterControl configura le credenziali dell'utente di backup in un file separato in /etc/my.cnf.d/secrets-backup.cnf e max_allowed_packet in my.cnf, simile al seguente:
$ mio.cnf
[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8$ secrets-backup.cnf
[mysqldump]
user=backupuser
password=ETgAG5VnpvuyXniEIl vantaggio di questo è che possiamo includere alcune opzioni extra per mysqldump. Sfortunatamente, l'argomento --defaults-file può essere specificato solo come argomento principale. Fai attenzione che gli ultimi argomenti della riga di comando abbiano la precedenza su ciò che è stato configurato all'interno di my.cnf sotto la direttiva [mysqldump] in base all'ordine in cui appaiono. Ad esempio, se aggiungiamo skip-comments=0 all'interno di my.cnf, mentre alla fine del comando mysqldump è presente un --skip-comments (o --skip-comments=1), il primo verrà ignorato e quest'ultimo verrà utilizzato.
Tuttavia, possiamo ancora usarlo come parte della nostra personalizzazione del backup utilizzando altre opzioni di backup di mysqldump. Ad esempio, possiamo escludere le tabelle di cui non vogliamo eseguire il backup utilizzando il parametro ignore-table (con formattazione "database.table"). Aggiungi le seguenti righe nel file di configurazione di MySQL:
[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8
ignore-table=sbtest.sbtest9
ignore-table=sbtest.sbtest10
ignore-table=sbtest.sbtest1Una volta configurati, possiamo semplicemente attivare un nuovo lavoro mysqldump da ClusterControl e avremo quelle tabelle saltate da mysqldump. Non è richiesto il riavvio di MySQL.
Puoi controllare la documentazione di mysqldump per ulteriori informazioni.
Percona Xtrabackup
ClusterControl esegue Xtrabackup in base alle opzioni scelte. Può essere completo o incrementale ed è possibile scegliere diverse variabili dall'interfaccia utente di ClusterControl. Considera quanto segue:
In questo passaggio puoi scegliere alcune variabili che abbiamo menzionato in precedenza nella sezione mysqldump, quindi:
Possiamo specificare alcuni dettagli come il nodo di desincronizzazione durante il backup, i thread di copia parallela di Xtrabackup e altro.
Sulla base delle opzioni precedenti, il comando Xtrabackup completo sarebbe:
$ 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.Il primo comando “ulimit -n 256000” serve a garantire che Percona Xtrabackup disponga di privilegi sufficienti per accedere a un numero enorme di descrittori di file (nel caso in cui i database contengano molte tabelle). Prendi nota di --defaults-file=/etc/mysql/my.cnf, che è simile a mysqldump, dove innobackupex legge il contenuto della configurazione di MySQL sulle seguenti direttive e variabili:
[mysqld]
datadir=[physical path to MySQL data directory]
tmpdir=[path to temporary directory]
[xtrabackup]
user=backupuser
password=[random password]Se desideri personalizzare le opzioni di backup per Percona Xtrabackup, puoi aggiungerle direttamente nella direttiva [xtrabackup]. Ad esempio, diciamo che vogliamo che Xtrabackup stampi la posizione del log binario quando viene eseguito il backup, possiamo aggiungere qualcosa del genere:
[xtrabackup]
user=backupuser
password=[random password]
slave-info=1L'attivazione del lavoro xtrabackup includerà quindi un file chiamato file xtrabackup_slave_info. Non è richiesto il riavvio di MySQL.
Puoi controllare la documentazione di Percona per maggiori informazioni su come funziona.
Backup Maria
Mariabackup è un fork di Percona XtraBackup con supporto aggiuntivo per la compressione MariaDB 10.1 e la crittografia dei dati inattivi. È incluso in MariaDB 10.1.23 e versioni successive.
Il metodo di backup può essere completo o incrementale e puoi selezionare le stesse variabili che hai per Percona XtraBackup, come Compressione, Xtrabackup Parallel Copy Threads o Encryption.
Il comando Mariabackup sarebbe:
$ /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 si basa su Percona XtraBackup, quindi utilizza le stesse informazioni di Percona per eseguire il backup. Per impostazione predefinita, ClusterControl aggiunge le seguenti righe nel file my.cnf:
[xtrabackup]
databases-exclude=lost+found
# ssl_mode = DISABLED
ssl = 0E le credenziali nel file secrets-backup.cnf:
[xtrabackup]
user=backupuser
password=[random password]Se vuoi aggiungere qualche variabile, puoi aggiungerla nella sezione [xtrabackup].
Puoi controllare la documentazione di MariaDB per ulteriori informazioni su quale parametro aggiungere.
In ogni caso, puoi controllare i tuoi backup dalla sezione Backup dell'interfaccia utente di ClusterControl:
Ci auguriamo che questo ti aiuti a configurare meglio i tuoi backup MySQL:puoi scaricare ClusterControl dal nostro sito Web (è gratuito).
