Una parte vitale della prevenzione di qualsiasi tipo di perdita di dati in qualsiasi situazione è disporre di politiche di backup e ripristino appropriate. È inoltre essenziale garantire il ripristino dei dati in qualsiasi momento del ciclo di vita del flusso di lavoro dell'applicazione. Sia MySQL che MariaDB offrono soluzioni per questi casi. Questo articolo esplorerà le opzioni e le procedure esistenti, nonché altre potenziali opzioni di backup per MySQL e MariaDB.
Strategie di backup
Poiché i dati sono la parte più importante di qualsiasi applicazione, proteggerne l'integrità è fondamentale per sopravvivere nella battaglia dell'esistenza. Qualsiasi interruzione dell'accessibilità o dell'integrità dei dati in qualsiasi momento può danneggiare gravemente l'applicazione e l'attività/servizio che sta fornendo.
Per garantire il corretto flusso di lavoro delle applicazioni e la continuità aziendale, è necessario implementare politiche di backup e ripristino adeguate con backup giornalieri, settimanali, mensili e annuali. Tali backup verranno eseguiti in periodi critici, ad esempio:
- prima di una finestra batch giornaliera;
- prima dell'importazione massiccia di dati;
- prima di qualsiasi aggiornamento dell'applicazione;
- backup settimanali, mensili e annuali per soddisfare i requisiti normativi;
- o altra manutenzione programmata giornaliera/settimanale.
Strumenti di backup
MySQL e MariaDB offrono diversi modi per impostare ed eseguire piani di backup e ripristino. Questi metodi includono backup fisici con strumento MySQL Enterprise mysqlbackup , Lo strumento mariabackup di MariaDB o strumento XtraBackup di Percona . Inoltre, i backup logici creati con lo strumento mysqldump di MySQL può tornare utile. Un'altra opzione è il ripristino point-in-time con i bin-log dei database (i registri delle transazioni) in combinazione con gli strumenti menzionati in precedenza.
Puoi assimilare metodi adeguati alla tua strategia di backup per massimizzare la recuperabilità del database in caso di guasto o disastro.
Nota:nella versione 10.4.6 di MariaDB, link simbolico di mysqldump si chiama mariadb-dump . Nelle versioni successive, inclusa la 10.5.2, i nomi sono cambiati di nuovo:mysqldump è diventato link simbolico .
Per illustrare le procedure, utilizzerò lo strumento mariabackup per creare backup fisici. La funzionalità di base dello strumento è la stessa degli strumenti sopra menzionati, sebbene vi siano alcune lievi differenze uniche per ciascuno strumento.
Backup di database fisici
I backup fisici sono backup a livello di file che forniscono metodi di copia dei file rapidi. Tali backup sono preferibili in scenari di ripristino di emergenza, clonazione di database e/o creazione di database slave.
Quando si eseguono backup fisici, è possibile scegliere di creare backup completi o incrementali. I backup completi includono un backup completo del server di database. I backup incrementali salvano solo le modifiche dell'ultimo backup completo o incrementale.
Importante:la dimensione del database regola l'ora del backup. Per questo motivo, una buona strategia per eseguire il backup di un database molto grande potrebbe essere quella di combinare backup completi e incrementali. In questo modo risparmi sia lo spazio di archiviazione dei backup che il tempo totale di backup e ripristino.
Un altro momento che dovresti notare è che quando ripristini i dati da un backup fisico, devi interrompere il processo dell'istanza del database MySQL/MariaDB fino al completamento dei passaggi finali di ripristino.
Puoi eseguire l'esecuzione di un semplice backup fisico completo come segue:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220 \
--user=backupuser --password=backuppasswd
La –target-dir opzione indica allo strumento di backup dove posizionare il backup.
In questo esempio, ho organizzato il mio backup nella directory denominata AAAAMMGG dove viene archiviato ogni backup completo (D sta per Daily). In tal modo, abbiamo una linea d'azione semplice per ripristinare il database dal backup eseguito in una data specifica.
L'esempio successivo mostra l'esecuzione di un semplice backup incrementale:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc1/ \
--incremental-basedir=/data/backups/mariadb/D20210220/ \
--user=backupuser --password=backuppasswd
Il successivo backup incrementale apparirà in questo modo:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc2/ \
--incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
--user=backupuser --password=backuppasswd
Il –incremental-basedir l'opzione indica allo strumento di backup di utilizzare il backup completo o incrementale precedentemente eseguito come punto di partenza per la creazione di file delta incrementali per il backup corrente. In questo modo, crea una catena di un backup completo con successivi backup incrementali. Insieme, formano un unico backup da ripristinare quando necessario.
Ora, scopriamo qual è il nome del file di database fisico in cui sono archiviati tutti i dati della directory. Il database che si trova sui controller di dominio è un Active Directory. Questa directory viene utilizzata per gestire utenti, dati, ecc. Il nucleo di una Active Directory è il file di database NTDS.DIT che consiste in collegamento, descrittore di sicurezza e tabelle di dati. Tutti i dati della directory sono conservati in questo file di database fisico.
È necessario distinguere tra file fisici e logici. I dati di sistema effettivi si trovano in file fisici, mentre i file logici contengono la descrizione dei record archiviati in file fisici.
Il compito di ripristinare il database MySQL da file fisici potrebbe essere a volte difficile. Il mysqldump comando potrebbe essere utile in questo caso. Tratteremo ulteriormente questo argomento.
Backup del database logico
I backup logici vengono creati con mysqldump attrezzo. Questo metodo di backup è più flessibile del backup fisico. È costituito da tutte le istruzioni SQL DML e/o DDL necessarie per formare un backup coerente, combinando tutti i dati vincolati e le modifiche apportate prima e durante il backup. Se vuoi saperne di più su come eseguire il backup e il ripristino di tutti i database, puoi leggere questo articolo.
Il backup logico può essere un singolo file o più file (creati con uno script specifico). Inoltre, puoi ripristinare la struttura e/o i dati senza arrestare l'istanza (processo) MySQL/MariaDB. Di conseguenza, i backup logici vengono eseguiti a livello di database e/o tabella, mentre i backup fisici sono a livello di filesystem (directory e file).
Si noti inoltre che i backup logici sono esclusivamente immagini di backup complete dei database e/o delle tabelle previsti.
La creazione di un backup logico dell'intera istanza MySQL/MariaDB è la seguente:
mysqldump --all-databases --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/full-backup-$(date +'%Y%m%d_%H%M%S').sql
Si noti che i backup fisici e logici sono specificamente distinti nel filesystem ai fini della gestione dei backup.
A differenza dell'esempio precedente, un backup logico di un singolo database (schema) viene creato nel modo seguente:
mysqldump empdb --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-full-backup-$(date +'%Y%m%d_%H%M%S').sql
Infine, per creare un backup logico di una singola tabella in un database, aggiungi il nome della tabella dopo il database:
mysqldump empdb departments --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-departments-full-backup-$(date +'%Y%m%d_%H%M%S').sql
Quando è necessario modificare e aggiungere le istruzioni DROP DATABASE o DROP TABLE allo scenario di ripristino, l'utilizzo di file di backup di grandi dimensioni può avere effetti restrittivi sugli editor di testo al punto da soffocarli.
In questi casi, considera l'aggiunta di altre opzioni, come –add-drop-database e/o –add-drop-table per includere queste istruzioni DROP nel backup. In altri scenari, potresti voler escludere queste istruzioni e sostituirle con la –skip-add-drop-table opzione al comando.
Tuttavia, puoi anche creare backup di soli dati o solo DDL utilizzando –no-create-info o –nessun dato opzioni. I backup separati di dati e strutture possono essere una buona scelta in alcuni scenari di ripristino, soprattutto quando è necessaria solo la struttura DDL per creare un database clonato vuoto e/o le relative tabelle.
Backup del database utilizzando le istantanee del disco
Man mano che i dati crescono, potrebbe diventare necessario organizzarli su diversi dischi e/o filesystem. Oltre ai motivi per le prestazioni, poiché l'I/O è distribuito su più dischi/filesystem, devi assicurarti che strategie di backup e ripristino efficienti includano le capacità di snapshot del disco e del filesystem.
Inizia progettando e costruendo i layout del filesystem in cui risiedono ciascun database, gruppo di tabelle e indici. Quindi, organizza le tue tabelle e configura il sistema di database. Dovrebbero risiedere tutti in un'unica directory:
innodb_home_dir = /<path where your InnoDB tables will reside>Oppure puoi utilizzare la DATA_DIRECTORY e INDEX_DIRECTORY opzioni in CREA tabella per distribuirli separatamente in diverse posizioni del filesystem.
Per InnoDB, assicurati di utilizzare file_per_table =ON (impostazione predefinita ON nelle versioni più recenti). Scegli attentamente il percorso per le tabelle InnoDB quando le crei. È impossibile modificare il percorso senza eliminare e ricreare la tabella.
È utile disporre di filesystem adeguati con funzionalità di snapshot integrate, ad es. XFS e ZFS su Linux. Si noti che la creazione dei backup di snapshot è simile alla creazione di backup fisici, ma presenta delle specificità. Richiede l'arresto del processo di scrittura (FLUSH with READ LOCK o simili:consulta la FASE DI BACKUP comando nella documentazione in linea di MariaDB) prima di acquisire lo snapshot e rilasciare LOCKS subito dopo il completamento dello snapshot. È necessario garantire la coerenza dei dati.
È necessario considerare e utilizzare i backup di snapshot negli scenari di ripristino di emergenza. Tuttavia, sono adatti anche per la clonazione di istanze di database.
Strategie di ripristino
Recupero da backup fisici
In precedenza, abbiamo descritto i passaggi del backup fisico. In questo modo, puoi creare una catena di backup completi o una catena di backup completi e incrementali. Quest'ultima opzione significa che un backup completo seguito da un backup incrementale successivo è pari a zero se si verifica un errore.
Ad esempio, un DBA esegue backup completi la domenica e backup incrementali negli altri giorni. Si verifica un errore dopo aver eseguito un backup incrementale mercoledì. Pertanto, devono ripristinare il database. In tali circostanze, il nostro DBA deve utilizzare il backup completo eseguito la domenica e i backup incrementali eseguiti il lunedì, il martedì e il mercoledì. Se ci fossero backup completi giornalieri, sarebbe sufficiente ripristinare il backup di mercoledì.
Per ripristinare il backup "più vicino" dopo un errore, che si tratti di un backup completo o incrementale, è necessario assicurarsi che TUTTI i file di backup siano coerenti nel tempo con l'ora della fine del backup più vicina. In caso contrario, il motore InnoDB rifiuterà i dati ritenendoli corrotti.
Un altro punto chiave è che, quando prepari i backup, copia i backup completi coinvolti in un'altra posizione prima di applicare i passaggi per garantire la coerenza temporale. In questo modo, mantieni lo stato di backup originale, che potrebbe essere utile in seguito. Consiglio vivamente di utilizzare questo approccio.
Per preparare un backup completo, scegli quello più vicino all'errore, copialo nella posizione preferita ed esegui il comando seguente:
mariabackup --prepare \
--target-dir=data/backups/mariadb/COPY_D20210220
Per ripristinare il backup incrementale più vicino, prepara una copia del backup completo più vicino e aggiungi tutti i backup incrementali pertinenti in un ordine successivo . L'immagine del database ripristinata dovrebbe essere la seguente:
Otteniamo questo eseguendo il prepara comando per ogni backup incrementale come mostrato di seguito:
mariabackup --prepare \
--target-dir=/data/backups/mariadb/COPY_D20210220 \
--incremental-dir=/data/backups/mariadb/D20210220_INC#
Dopo aver preparato la copia di backup, è necessario chiudere l'istanza del database (processi). Inoltre, dobbiamo svuotare il directory database prima di terminare il processo di ripristino. Puoi emettere il comando con il –copy-back opzione
mariabackup --copy-back \
--target-dir=data/backups/mariadb/COPY_D20210220
o con il –ritorno indietro opzione:
mariabackup --move-back \
--target-dir=data/backups/mariadb/COPY_D20210220
Quest'ultimo comando sposta la directory copiata nella directory del database. Copiare il backup originale in un'altra posizione è una scelta saggia. In caso contrario, il backup andrà perso, poiché non sarà possibile utilizzarlo per altre situazioni e scenari.
L'ultimo passaggio prima di avviare l'istanza del database consiste nell'adattare la proprietà dei file in modo che corrisponda all'utente e al gruppo del proprietario del processo. In genere è MySQL.
Recupero da backup logici
Abbastanza spesso, trascuriamo un punto chiave durante il ripristino di database e/o tabelle utilizzando backup logici. Questo punto sta impostando il max_allowed_packet dimensione della sessione (potrebbe essere più saggio impostarla a livello globale) al valore massimo di 1073741824. È necessario assicurarsi che buffer di grandi dimensioni e istruzioni INSERT rientrino in un unico pacchetto tra il client e il server. Questo dovrebbe ridurre i tempi di recupero.
Un altro aspetto chiave quando si esegue un backup è includere o escludere le istruzioni DROP come menzionato in precedenza. Ne abbiamo bisogno per garantire l'esecuzione del processo di ripristino del backup nel modo più fluido possibile. Tenendo presente ciò, utilizza il codice seguente per eseguire il ripristino del backup:
mysql -u backupuser -p backuppasswd < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlSe non disponi di alcun database incluso nel backup, come per i singoli backup di database, o devi reindirizzare il ripristino a un altro database, utilizza un codice diverso:
mysql -u backupuser -p backuppasswd newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlRipristino con snapshot del disco
Per ripristinare dallo snapshot del disco sempre inizia con assicurando che il sistema di database sia stato spento prima il processo di ripristino viene eseguito . Qualsiasi tentativo di recuperare un database attivo utilizzando lo snapshot del disco comporterà incoerenze dei dati e, più probabilmente, il danneggiamento dei dati.
Recupero puntuale
Il ripristino point in time (PITR) è, come suggerisce il nome, un metodo per recuperare database e tabelle il più vicino possibile al momento prima dell'errore. Oppure, se il processo batch giornaliero non è riuscito e deve essere rieseguito, hai anche l'unica opzione:eseguire il ripristino del backup PITR.
È fondamentale abilitare il registro bin del database e impostare il formato del registro bin sulla registrazione basata su istruzioni, basata su riga o mista, a seconda del tipo di carico di lavoro in esecuzione nel database. Inoltre, potrebbe essere necessario abilitare la compressione utilizzando log_bin_compress =ON (impostazione predefinita OFF) per risparmiare spazio su disco.
Poiché bin-log è un registro delle transazioni creato in sequenza, è fondamentale eseguire un backup di tutti i file di registro. Per quanto riguarda il processo PITR, è impossibile senza file di registro. Inoltre, la manutenzione e il ciclo di vita del bin-log dovrebbero seguire il ciclo di vita di qualsiasi backup completo e incrementale. Pertanto, assicurati di eliminare solo i registri che sono più vecchi del backup più vecchio nel criterio di backup.
Puoi eliminare i log binari in due modi. Innanzitutto, è dichiarando il nome bin-log più vicino al backup più vecchio, come mostrato nel comando di eliminazione seguente:
PURGE BINARY LOGS TO 'mariadb-bin.000063';In secondo luogo, è dichiarando la data del backup più vecchio conservato nel comando di eliminazione:
PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';Per prepararci al recupero, dobbiamo recuperare tutte le istruzioni necessarie per replicare al momento necessario. Raccogli tutti i bin-log disponibili dall'inizio del backup al momento in cui stai eseguendo il ripristino.
Inizia esaminando l'elenco dei registri dal momento in cui il backup è terminato fino all'ora PITR:
mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql
Quindi, esamina i file temporanei per trovare le posizioni esatte del registro che desideri applicare e utilizzare. Queste sono –posizione iniziale e –posizione di stop che imposta le posizioni esatte nel comando ed esegue nuovamente il mysqlbinlog comando:
mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql
A questo punto, il processo di recupero è iniziato. Utilizza backup fisici o logici, completi o incrementali.
Completa il ripristino applicando il final_temporary_PITR_file.sql utilizzando il client MySQL come mostrato di seguito:
mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sqlAbbiamo completato il ripristino PITR ripristinando il backup e le transazioni ripetute dal registro al punto più vicino al momento in cui si è verificato l'errore.
Banco di lavoro
Per la progettazione e lo sviluppo di database, il test e la manutenzione in MySQL e MariaDB, possiamo utilizzare un'applicazione Windows Workbench. Funziona anche su Linux. Con questa applicazione, gli utenti possono progettare database, visualizzare e modificare metadati, trasferire dati e metadati e molto altro. Vale la pena aggiungere che è possibile utilizzare dbForge Studio per MySQL invece di Workbench.
Conclusione
Nel complesso, abbiamo discusso e illustrato brevemente le tecniche di backup e ripristino del database con strumenti e metodi disponibili in MySQL e MariaDB.
Per ripristinare correttamente il sistema di database da qualsiasi errore, dobbiamo implementare backup sia fisico che logico metodi sopra menzionati nelle politiche e nei piani, dall'intero sistema fino alle singole tabelle.
Per eseguire correttamente un PITR, abbiamo bisogno del bin-log abilitato e di una corretta gestione dei log a posto.
Tuttavia, l'utilizzo di un solo metodo di backup e dei log bin mancanti sarebbe l'approccio sbagliato. Può causare la perdita di dati e danneggiare la continuità operativa dell'applicazione. Pertanto, combina diversi metodi e includi sempre i file di registro nelle politiche di backup e ripristino!
