Il tuo server di database memorizza alcune delle informazioni più preziose della tua azienda. Garantire backup affidabili del database per prevenire la perdita di dati in caso di incidente o guasto hardware è una casella di controllo fondamentale.
Che si tratti di un server ad alto carico 24 ore su 24, 7 giorni su 7 o di un ambiente con un volume di transazioni ridotto, sarà necessario rendere i backup una procedura senza interruzioni senza interrompere le prestazioni del server in un ambiente di produzione.
In questo blog esamineremo due degli strumenti più utilizzati per svolgere questa attività, ovvero Percona XtraBackup e Mariabackup. Esamineremo le somiglianze e le differenze tra i due e anche come usarli.
Cos'è Percona XtraBackup?
Percona XtraBackup è uno strumento open source per eseguire backup di database MariaDB, MySQL e Percona Server. Esegue backup completi online non bloccanti (per i motori supportati), compressi e protetti su sistemi transazionali in modo che le applicazioni rimangano completamente disponibili per la durata della finestra di backup.
Utilizzando questo strumento puoi:
- Crea backup hot di InnoDB, che vengono completati in modo rapido e affidabile, senza mettere in pausa il database o aggiungere carico al server
- Esegui backup incrementali
- Sposta le tabelle tra i server MySQL online
- Crea facilmente nuovi slave di replica MySQL
- Trasmetti in streaming backup MySQL compressi su un altro server
- Risparmia spazio su disco e larghezza di banda di rete
Cos'è Mariabackup?
Mariabackup è uno strumento open source fornito da MariaDB per eseguire backup fisici online. È un fork di Percona XtraBackup progettato per funzionare con tabelle crittografate e compresse ed è il metodo di backup consigliato per i database MariaDB.
MariaDB Server 10.1 ha introdotto la compressione MariaDB e la crittografia dei dati a riposo, ma le soluzioni di backup esistenti non supportavano la funzionalità di backup completa per queste funzionalità. Quindi MariaDB ha deciso di estendere XtraBackup (versione 2.3.8) e ha chiamato questa soluzione Mariabackup.
Differenze tra Percona XtraBackup e Mariabackup
Come notato in precedenza, Mariabackup è lo strumento di backup consigliato per MariaDB e la principale differenza rispetto a XtraBackup è che funziona con tabelle crittografate e compresse.
Ad ogni modo, se per qualche motivo particolare vuoi usare XtraBackup per il tuo database MariaDB, ci sono alcuni punti da tenere in considerazione a seconda della versione del server MariaDB che hai:
- MariaDB 10.1:con i dati MariaDB non compressi e non crittografati, puoi utilizzare XtraBackup. Se viene utilizzata la crittografia o la compressione, o quando innodb_page_size è impostato su un valore diverso da 16K, non funzionerà.
- MariaDB 10.2:potresti anche voler provare a utilizzare XtraBackup, ma tieni presente che i problemi sono probabilmente dovuti al bug di incompatibilità del formato del registro di annullamento di MySQL 5.7 che è stato corretto in MariaDB 10.2.2. A causa di questo bug, i backup preparati con XtraBackup potrebbero non riuscire a recuperare alcune transazioni. Solo se esegui il server con l'impostazione innodb_undo_logs=1 questo non sarebbe un problema.
- MariaDB 10.3 e versioni successive:questo caso è più semplice. XtraBackup non è compatibile.
Inoltre, ci sono alcune limitazioni da tenere in considerazione quando si utilizza Mariabackup:
- MyRocks:a partire da MariaDB 10.2.16 e MariaDB 10.3.8, Mariabackup eseguirà il backup dei dati di MyRocks Storage Engine. Il backup parziale dei dati di MyRocks non è attualmente supportato. Il backup incrementale memorizzerà una copia completa dei dati di MyRocks.
- Funzionalità di esportazione del file:prima di MariaDB 10.2.9, Mariabackup non supportava la funzionalità --export (crea un file di esportazione per esportare i dati dal database). Puoi aggirare questa limitazione preparando il backup come al solito (senza il flag --export), quindi avvia il server ed esegui FLUSH TABLES FOR EXPORT.
- File di registro:le versioni di Mariabackup fino alla 10.2.8 non creano file di registro vuoti e si basano sull'azione --copy-back eseguita dall'utente (che elimina i vecchi file di registro innodb, se presenti). Se l'utente non utilizza --copy-back o si assicura che la directory dei dati sia vuota prima del ripristino, i backup creati con queste versioni potrebbero diventare incoerenti/corrotti (a causa della presenza di log InnoDB rimanenti).
- Gcrypt:la crittografia basata sullo strumento di backup (gcrypt) non è supportata su Mariabackup.
- Opzione Innobackupex:nessun collegamento simbolico a innobackupex (utilizzare invece il parametro --innobackupex). Lo strumento innobackupex corregge e fornisce funzionalità aggiuntive rispetto allo strumento innobackup per il backup delle tabelle InnoDB e MyISAM.
- Opzione compatta:l'opzione --compact non è supportata.
- Opzione Ricostruisci indici:l'opzione --rebuild_indexes non è supportata.
- Tar per i file di backup:il supporto per --stream=tar è stato rimosso in Mariabackup 10.1.24 (le opzioni --streams trasferiscono i file di backup su stdout).
Infine, ma non meno importante, Mariabackup può essere installato su Windows.
Processo di backup Processo di ripristinoCome fare per - Percona XtraBackup e Mariabackup
Vediamo come possiamo installarlo e usarlo.
Installazione
Hai diversi metodi per installare sia XtraBackup che Mariabackup. Proviamo l'installazione dai repository.
Installazione di XtraBackup
Su 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
Su 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
Installazione di Mariabackup
Su Debian/Ubuntu
Mariabackup fa parte di MariaDB Server a partire da 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
Su 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
Configurazione
Sia Xtrabackup che Mariabackup leggono le sezioni [mysqld] e [xtrabackup] di qualsiasi file di configurazione MySQL, in quest'ordine. In questo modo può leggere parametri MySQL, come datadir o parametri InnoDB.
Possiamo modificare i parametri inclusi nella sezione [mysqld] modificando il loro valore in [xtrabackup], come accennato in precedenza, vengono letti in ordine, quindi l'ultima cosa che abbiamo in [xtrabackup] avrà la priorità.
[mysqld]
datadir=/data/datadir
[xtrabackup]
target_dir=/backups/
L'utente con i privilegi minimi richiesti per i backup completi sarebbe RELOAD, LOCK TABLES, PROCESS e REPLICATION CLIENT:
mysql> CREATE USER 'backupuser'@'localhost' IDENTIFIED BY 'Password';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'backupuser'@'localhost';
E poi, puoi aggiungere questo utente nei file di configurazione di MySQL:
[xtrabackup]
user=backupuser
password=Password
Inoltre, puoi utilizzare Xtrabackup o Mariabackup per eseguire i trasferimenti di snapshot di stato quando utilizzi un cluster Percona XtraDB o MariaDB Galera. Devi impostare le variabili wsrep_sst_method e wsrep_sst_auth nei file di configurazione:
[mysqld]
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=backupuser:Password
Oppure
[mysqld]
wsrep_sst_method=mariabackup
wsrep_sst_auth=backupuser:Password
Utilizzo
Poiché Mariabackup è basato su XtraBackup, può essere utilizzato in modo simile.
Vediamo ora un esempio che utilizza entrambi i metodi per creare, preparare e ripristinare un backup completo.
Creazione di un backup
Per creare un nuovo backup con XtraBackup o Mariabackup, devi aggiungere le opzioni --backup e --target-dir alla riga di comando:
$ xtrabackup --backup --target-dir=/backups/
Oppure
$ mariabackup --backup --target-dir=/backups/
La directory di destinazione, in cui verrà archiviato il backup, può essere specificata nei file di configurazione di MySQL. Il processo di backup non sovrascriverà i file esistenti. Se il file esiste, il backup avrà esito negativo.
Transaction log of lsn (9755450) to (9755467) was copied.
181122 23:02:44 completed OK!
Se tutto è andato bene, l'ultima riga che vedi dovrebbe essere "completato OK!". Puoi annullare il backup in qualsiasi momento, poiché non modifica il contenuto del database.
[[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
Questo dovrebbe essere il contenuto del tuo backup. Potrebbe cambiare a seconda dei tuoi database.
Preparazione di un backup
Dopo aver creato il backup con XtraBackup o Mariabackup, è necessario prepararlo per il ripristino. I file di dati non sono coerenti finché non sono stati preparati, perché sono stati copiati in momenti diversi durante la durata del backup. Se provi a ripristinarlo e ad avviare il database, rileverà il danneggiamento e si arresterà in modo anomalo per impedirti di eseguire dati incoerenti.
Per preparare il backup, è necessario eseguire il comando xtrabackup o mariabackup con l'opzione --prepare e specificare la directory di destinazione in cui è archiviato il backup.
$ xtrabackup --prepare --target-dir=/backups/
Oppure
$ mariabackup --prepare --target-dir=/backups/
InnoDB: Shutdown completed; log sequence number 9757224
181122 23:05:29 completed OK!
L'ultima riga visualizzata dovrebbe essere "Spegnimento completato; registro numero di sequenza xxxxxxx" e "Completato OK!" se tutto è andato bene. Non è consigliabile annullare il processo di preparazione perché potrebbe causare il danneggiamento del file di dati e il backup diventerà inutilizzabile.
Se desideri utilizzare questo backup con un backup incrementale in un secondo momento, dovresti utilizzare l'opzione --apply-log-only durante la preparazione, altrimenti non sarai in grado di farlo.
Ripristino di un backup
Dopo aver preparato il backup, è possibile utilizzare l'opzione di ripristino con i parametri --copy-back o --move-back, per copiare o spostare il backup nella datadir. Se non hai abbastanza spazio su disco, probabilmente dovresti usare l'opzione di spostamento. Inoltre, è necessario specificare la directory di destinazione in cui è archiviato il backup. Tieni presente che la datadir deve essere vuota e il servizio database dovrebbe essere inattivo prima di ripristinare il backup.
$ xtrabackup --copy-back --target-dir=/backups/
Oppure
$ mariabackup --copy-back --target-dir=/backups/
Prima copierà/sposterà le tabelle e gli indici MyISAM, poi le tabelle e gli indici InnoDB e infine i file di registro. Conserverà gli attributi del file durante la copia, potrebbe essere necessario modificare la proprietà dei file in mysql prima di avviare il server del database, poiché saranno di proprietà dell'utente che ha creato il backup.
$ sudo chown -R mysql:mysql /var/lib/mysql
Ci sono diversi parametri da usare con Xtrabackup e Mariabackup. Puoi controllare questi parametri qui per XtraBackup e qui per Mariabackup.
ClusterControlSingle Console per l'intera infrastruttura di databaseScopri cos'altro c'è di nuovo in ClusterControlInstalla ClusterControl GRATISGestione dei backup su ClusterControl
Come abbiamo visto sopra, l'esecuzione di un backup non è scienza missilistica. Può anche essere programmato con cron (ma attenzione ai guasti silenziosi!). Tuttavia, uno script per creare backup regolarmente non è una soluzione di gestione dei backup. Hai bisogno di un modo per segnalare i tuoi backup e avvisare in caso di errori. Ora, configurare i backup nel tuo ambiente e vedere i backup funzionare senza errori non significa che tutto sia a posto. Potresti aver sentito parlare del backup di Schrödinger, che afferma che la condizione di qualsiasi backup è sconosciuta fino a quando non viene tentato un ripristino. Perché la cosa peggiore che può succedere è un disastro e ti rendi conto che i backup sono sbagliati per qualche motivo. Si tenta di ripristinare i file di cui è stato eseguito il backup e non viene ripristinato ciò che si ritiene di aver eseguito il backup o non viene ripristinato affatto! Poi ci sono cose come spostare i file di backup fuori sede, ad es. su cloud storage esterno, per il ripristino di emergenza. La crittografia e la gestione delle chiavi sono importanti per la sicurezza. È inoltre necessario gestire la conservazione dei backup locali ed esterni/archiviati.
Vediamo come ClusterControl può aiutare.
Se desideri utilizzare la funzione Backup ClusterControl, vai su ClusterControl -> Seleziona Cluster -> Backup e lì puoi vedere i tuoi backup correnti, crearne o pianificarne uno nuovo.
Sezione Backup ClusterControlUtilizzando l'opzione di creazione o pianificazione, possiamo scegliere entrambi i metodi, XtraBackup o Mariabackup. Nella stessa sezione possiamo scegliere il server da cui eseguire il backup, abilitare il backup parziale, scegliere dove archiviare il backup e se caricare il backup nel cloud (AWS, Azure o Google Cloud).
ClusterControl Crea backup 1Quindi, possiamo selezionare parametri di backup come compressione, crittografia e conservazione.
ClusterControl Crea backup 2E questi dovrebbero essere i comandi che ClusterControl eseguirà per te:
[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.
Oppure
[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.
Questo comando potrebbe essere diverso a seconda dei parametri che hai scelto.
Come abbiamo potuto vedere, ClusterControl è un buon amico se vogliamo usare XtraBackup o Mariabackup. Possiamo eseguire comandi di backup complessi in modo semplice, selezionando le opzioni dall'interfaccia utente di ClusterControl.
ClusterControl supporta il backup completo o incrementale, quindi possiamo configurare tutta la nostra strategia di backup da un'interfaccia utente intuitiva.
Conclusione
Quando si esegue il backup di un server MariaDB, si consiglia di utilizzare lo strumento Mariabackup. Tuttavia, se per qualche motivo preferisci utilizzare XtraBackup, puoi comunque farlo. Ma devi tenere a mente le restrizioni applicabili, come abbiamo notato in questo blog. Infine, abbiamo discusso di come uno script per il backup di un database non sia la stessa cosa di una soluzione di gestione del backup e abbiamo dato una rapida occhiata a ClusterControl.
Facci sapere se abbiamo perso delle differenze tra XtraBackup e MariaBackup.
I backup non bloccanti sono supportati per i motori di archiviazione InnoDB, XtraDB e HailDB. È possibile eseguire il backup dei seguenti motori di archiviazione sospendendo brevemente le scritture al termine del backup:MyISAM, Merge e Archive, comprese le tabelle partizionate, i trigger e le opzioni del database.