Negli ultimi quattro post della serie di blog, abbiamo trattato l'implementazione di clustering/replica (MySQL/Galera, MySQL Replication, MongoDB e PostgreSQL), la gestione e il monitoraggio dei database e dei cluster esistenti, il monitoraggio delle prestazioni e l'integrità e nell'ultimo post, come rendere la tua configurazione altamente disponibile tramite HAProxy e ProxySQL.
Quindi ora che hai i tuoi database attivi e funzionanti e altamente disponibili, come ti assicuri di avere backup dei tuoi dati?
È possibile utilizzare i backup per molteplici scopi:ripristino di emergenza, per fornire dati di produzione da testare rispetto allo sviluppo o anche per eseguire il provisioning di un nodo slave. Quest'ultimo caso è già coperto da ClusterControl. Quando si aggiunge un nuovo nodo (replica) alla configurazione della replica, ClusterControl eseguirà un backup/snapshot del nodo master e lo utilizzerà per creare la replica. Può anche utilizzare un backup esistente per organizzare la replica, nel caso in cui si desideri evitare quel carico aggiuntivo sul master. Dopo che il backup è stato estratto, preparato e il database è attivo e funzionante, ClusterControl imposterà automaticamente la replica.
Creazione di un backup istantaneo
In sostanza, la creazione di un backup è la stessa per Galera, replica MySQL, PostgreSQL e MongoDB. Puoi trovare la sezione di backup in ClusterControl> Backup e per impostazione predefinita vedresti un elenco di backup creati del cluster (se presente). In caso contrario, vedresti un segnaposto per creare un backup:
Da qui puoi fare clic sul pulsante "Crea backup" per eseguire un backup istantaneo o pianificare un nuovo backup:
Tutti i backup creati possono anche essere caricati su cloud attivando "Carica backup su cloud", a condizione che tu fornisca credenziali cloud funzionanti. Per impostazione predefinita, tutti i backup più vecchi di 31 giorni verranno eliminati (configurabile tramite le impostazioni di conservazione del backup) oppure puoi scegliere di mantenerlo per sempre o definire un periodo personalizzato.
"Crea backup" e "Pianifica backup" condividono opzioni simili tranne la parte di pianificazione e le opzioni di backup incrementale per quest'ultima. Pertanto, esamineremo in modo più approfondito la funzione Crea backup (nota anche come backup istantaneo).
Poiché tutti questi vari database hanno diversi strumenti di backup, c'è ovviamente una certa differenza nelle opzioni che puoi scegliere. Ad esempio, con MySQL puoi scegliere tra mysqldump e xtrabackup (completo e incrementale). Per MongoDB, ClusterControl supporta mongodump e mongodb-consistent-backup (beta), mentre sono supportati PostgreSQL, pg_dump e pg_basebackup. In caso di dubbi su quale scegliere per MySQL, dai un'occhiata a questo blog sulle differenze e sui casi d'uso per mysqldump e xtrabackup.
Backup di MySQL e Galera
Come accennato nel paragrafo precedente, puoi eseguire backup MySQL utilizzando mysqldump o xtrabackup (completo o incrementale). Nella procedura guidata "Crea backup", puoi scegliere su quale host eseguire il backup, la posizione in cui archiviare i file di backup e la relativa directory e schemi specifici (xtrabackup) o schemi e tabelle (mysqldump).
Se il nodo di cui si esegue il backup sta ricevendo traffico (di produzione) e si teme che le scritture extra del disco diventino invadenti, si consiglia di inviare i backup all'host ClusterControl scegliendo l'opzione "Store on Controller". In questo modo il backup trasmetterà i file in streaming sulla rete all'host ClusterControl e dovrai assicurarti che sia disponibile spazio sufficiente su questo nodo e che la porta di streaming sia aperta sull'host ClusterControl.
Ci sono anche molte altre opzioni se si desidera utilizzare la compressione e il livello di compressione. Maggiore è il livello di compressione, minore sarà la dimensione del backup. Tuttavia, richiede un maggiore utilizzo della CPU per il processo di compressione e decompressione.
Se dovessi scegliere xtrabackup come metodo per il backup, si aprirebbero opzioni extra:desync, backup locks, compression e xtrabackup thread paralleli/gzip. L'opzione desync è applicabile solo per desincronizzare un nodo da un cluster Galera. I blocchi di backup utilizzano un nuovo tipo di blocco MDL per bloccare gli aggiornamenti alle tabelle non transazionali e alle istruzioni DDL per tutte le tabelle, il che è più efficiente per il carico di lavoro specifico di InnoDB. Se stai utilizzando Galera Cluster, si consiglia di abilitare questa opzione.
Dopo aver pianificato un backup istantaneo, puoi tenere traccia dell'avanzamento del processo di backup in Attività> Lavori :
Al termine, dovresti essere in grado di vedere una nuova voce nell'elenco di backup.
Backup di PostgreSQL
Simile ai backup istantanei di MySQL, puoi eseguire un backup sul tuo database Postgres. Con i backup di Postgres sono supportati due metodi di backup:pg_dumpall o pg_basebackup. Tieni presente che ClusterControl eseguirà sempre un backup completo indipendentemente dal metodo di backup scelto.
Abbiamo trattato questo aspetto in questi dettagli in Diventa un DBA PostgreSQL - Backup logici e fisici di PostgreSQL.
Backup di MongoDB
Per MongoDB, ClusterControl supporta lo standard mongodump e mongodb-consistent-backup sviluppato da Percona. Quest'ultimo è ancora in versione beta che fornisce backup point-in-time coerenti con i cluster di MongoDB adatti per configurazioni di cluster partizionati. Poiché il cluster MongoDB suddiviso è costituito da più set di repliche, un set di repliche di configurazione e server shard, è molto difficile eseguire un backup coerente utilizzando solo mongodump.
Si noti che nella procedura guidata non è necessario selezionare un nodo di database di cui eseguire il backup. ClusterControl sceglierà automaticamente la replica secondaria più sana come nodo di backup. In caso contrario, verrà selezionato il primario. Quando il backup è in esecuzione, il nodo di backup selezionato sarà bloccato fino al completamento del processo di backup.
Pianificazione dei backup
Ora che abbiamo giocato con la creazione di backup istantanei, ora possiamo estenderlo pianificando i backup.
La pianificazione è molto semplice:puoi selezionare in quali giorni deve essere eseguito il backup ea che ora deve essere eseguito.
Per xtrabackup c'è una funzionalità aggiuntiva:i backup incrementali. Un backup incrementale eseguirà il backup solo dei dati modificati dall'ultimo backup. Naturalmente, i backup incrementali sono inutili se non ci sarebbe il backup completo come punto di partenza. Tra due backup completi, puoi avere tutti i backup incrementali che desideri. Ma il ripristino richiederà più tempo.
Una volta pianificato, i lavori dovrebbero diventare visibili nella scheda "Backup pianificato" e puoi modificarli facendo clic sul pulsante "Modifica". Come con i backup istantanei, questi processi pianificheranno la creazione di un backup e potrai tenere traccia dell'avanzamento tramite la scheda Attività.
Elenco backup
Puoi trovare l'elenco di backup in ClusterControl> Backup e questo ti darà una panoramica a livello di cluster di tutti i backup effettuati. Facendo clic su ciascuna voce si espanderà la riga ed esporrà ulteriori informazioni sul backup:
Ogni backup è accompagnato da un registro di backup quando ClusterControl ha eseguito il lavoro, disponibile sotto il pulsante "Altre azioni".
Backup fuori sede nel cloud
Dal momento che ora abbiamo molti backup archiviati sugli host del database o sull'host ClusterControl, vogliamo anche assicurarci che non vadano persi nel caso in cui dovessimo affrontare un'interruzione totale dell'infrastruttura. (es. DC on fire o flooded) Pertanto ClusterControl consente di archiviare o copiare i backup fuori sede su cloud. Le piattaforme cloud supportate sono Amazon S3, Google Cloud Storage e Azure Cloud Storage.
Il processo di caricamento avviene subito dopo la creazione del backup (se attivi "Carica backup sul cloud") oppure puoi fare clic manualmente sul pulsante dell'icona del cloud nell'elenco dei backup:
Scegli la credenziale cloud e specifica di conseguenza la posizione del backup:
Ripristina e/o verifica backup
Dall'interfaccia dell'elenco di backup, puoi ripristinare direttamente un backup su un host nel cluster facendo clic sul pulsante "Ripristina" per il backup specifico o facendo clic sul pulsante "Ripristina backup":
Una caratteristica interessante è che è in grado di ripristinare un nodo o un cluster utilizzando i backup completi e incrementali poiché terrà traccia dell'ultimo backup completo eseguito e avvierà il backup incrementale da lì. Quindi raggrupperà un backup completo insieme a tutti i backup incrementali fino al backup completo successivo. Ciò ti consente di ripristinare partendo dal backup completo e applicando i backup incrementali su di esso.
ClusterControl supporta il ripristino su un nodo di database esistente o il ripristino e la verifica su un nuovo host autonomo:
Queste due opzioni sono abbastanza simili, tranne per il fatto che quella di verifica ha opzioni extra per le nuove informazioni sull'host. Se segui la procedura guidata di ripristino, dovrai specificare un nuovo host. Se "Installa software database" è abilitato, ClusterControl rimuoverà qualsiasi installazione MySQL esistente sull'host di destinazione e reinstallerà il software del database con la stessa versione del server MySQL esistente.
Una volta ripristinato e verificato il backup, riceverai una notifica sullo stato di ripristino e il nodo verrà spento automaticamente.
Recupero puntuale
Per MySQL, sia xtrabackup che mysqldump possono essere utilizzati per eseguire il ripristino point-in-time e anche per fornire un nuovo slave di replica per la replica master-slave o Galera Cluster. Un backup compatibile con mysqldump PITR contiene un singolo file dump, con informazioni GTID, file binlog e posizione. Pertanto, solo il nodo del database che produce il log binario avrà l'opzione "compatibile PITR" disponibile:
Quando l'opzione compatibile PITR è attivata, i campi del database e della tabella sono disattivati poiché ClusterControl eseguirà sempre un backup completo su tutti i database, eventi, trigger e routine del server MySQL di destinazione.
Ora ripristinando il backup. Se il backup è compatibile con PITR, verrà presentata un'opzione per eseguire un ripristino point-in-time. Avrai due opzioni per questo:"In base al tempo" e "In base alla posizione". Per "Time Based", puoi semplicemente passare il giorno e l'ora. Per "Basato sulla posizione", puoi passare la posizione esatta a dove desideri ripristinare. È un modo più preciso per ripristinare, anche se potrebbe essere necessario ottenere la posizione binlog utilizzando l'utilità mysqlbinlog. Maggiori dettagli sul recupero temporizzato sono disponibili in questo blog.
Crittografia backup
Universalmente, ClusterControl supporta la crittografia di backup per MySQL, MongoDB e PostgreSQL. I backup vengono crittografati a riposo utilizzando l'algoritmo AES-256 CBC. Una chiave generata automaticamente verrà archiviata nel file di configurazione del cluster in /etc/cmon.d/cmon_X.cnf (dove X è l'ID del cluster):
$ sudo grep backup_encryption_key /etc/cmon.d/cmon_1.cnf
backup_encryption_key='JevKc23MUIsiWLf2gJWq/IQ1BssGSM9wdVLb+gRGUv0='Se la destinazione del backup non è locale, i file di backup vengono trasferiti in formato crittografato. Questa funzionalità integra il backup fuori sede su cloud, dove non abbiamo pieno accesso al sistema di archiviazione sottostante.
Pensieri finali
Ti abbiamo mostrato come eseguire il backup dei tuoi dati e come archiviarli in modo sicuro fuori sede. Il recupero è sempre una cosa diversa. ClusterControl può ripristinare automaticamente i tuoi database dai backup effettuati in passato che sono archiviati in locale o copiati dal cloud.
Ovviamente c'è di più per proteggere i tuoi dati, specialmente per quanto riguarda la protezione delle tue connessioni. Ne parleremo nel prossimo post del blog!
