Al centro di ClusterControl c'è la sua automazione, così come la garanzia che i dati siano sottoposti a backup sicuro e pronti per il ripristino ogni volta che qualcosa va storto. Avere una strategia di backup e un piano di ripristino di emergenza efficaci è la chiave del successo di qualsiasi applicazione o ambiente.
Nella nostra ultima versione, ClusterControl 1.5, abbiamo introdotto una serie di miglioramenti per il backup di sistemi basati su MySQL e MariaDB.
Uno dei miglioramenti chiave è la possibilità di eseguire il backup da ClusterControl al provider cloud di tua scelta. I provider cloud come Google Cloud Services e Amazon S3 offrono ciascuno spazio di archiviazione praticamente illimitato, riducendo le esigenze di spazio locale. Ciò ti consente di conservare i tuoi file di backup più a lungo, per tutto il tempo che desideri e non hai problemi di spazio su disco locale.
Esploriamo tutte le nuove entusiasmanti funzionalità di backup per ClusterControl 1.5...
Riprogettazione guidata di backup/ripristino
Prima di tutto, noterai che le procedure guidate di backup e ripristino sono state rinnovate per migliorare l'esperienza dell'utente. Ora verrà caricato come menu laterale sulla destra dello schermo:
Anche l'elenco di backup sta subendo una piccola modifica in cui vengono visualizzati i dettagli del backup quando si fa clic sul backup particolare:
Sarai in grado di visualizzare la posizione del backup e quali database si trovano all'interno del backup. Ci sono anche opzioni per ripristinare il backup o caricarlo nel cloud.
Backup compatibile con PITR
ClusterControl esegue il backup mysqldump standard con schemi separati e dump dei dati. Ciò semplifica il ripristino di backup parziali. Tuttavia, interrompe la coerenza del backup (lo schema e i dati vengono scaricati in due sessioni separate), quindi non può essere utilizzato per eseguire il provisioning di un ripristino slave o point-in-time.
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 "PiTR compatibile", come evidenziato nello screenshot seguente:
Quando l'opzione PITR compatibile è attivata, i campi del database e della tabella sono disattivati poiché ClusterControl eseguirà sempre il backup su tutti i database, eventi, trigger e routine del server MySQL di destinazione.
Le seguenti righe appariranno nelle prime ~50 righe del file dump completato:
$ head -50 mysqldump_2017-11-07_072250_complete.sql
...
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='20dc5247-4a98-ee18-73af-5c79373388ee:1-1681';
--
-- Position to start replication or point-in-time recovery from
--
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=2457790;
...Le informazioni possono essere utilizzate per creare slave dal backup o eseguire il ripristino point-in-time insieme ai log binari, in cui è possibile avviare il ripristino da MASTER_LOG_FILE e MASTER_LOG_POS riportati nel file dump utilizzando l'utilità "mysqlbinlog". Tieni presente che ClusterControl non esegue il backup dei registri binari.
Crea slave dal backup Un'altra funzionalità è la possibilità di creare uno slave direttamente da un backup compatibile con PITR, invece di farlo da un master scelto. Questo è un enorme vantaggio in quanto scarica il server master. Questa opzione può essere utilizzata con MySQL Replication o Galera Cluster. Un backup esistente può essere utilizzato per ricostruire uno slave di replica esistente o aggiungere un nuovo slave di replica durante la fase di staging, come mostrato nella schermata seguente:
Una volta completata la messa in scena, lo slave si collegherà al master scelto e inizierà a recuperare. In precedenza, ClusterControl eseguiva un backup in streaming direttamente dal master scelto utilizzando Percona Xtrabackup. Ciò potrebbe influire sulle prestazioni del master durante la scalabilità orizzontale di un set di dati di grandi dimensioni, nonostante l'operazione non blocchi il master. Con la nuova opzione, se il backup è archiviato su ClusterControl, solo questi host (ClusterControl + lo slave) saranno occupati durante lo staging dei dati sullo slave.
Backup su Cloud
I backup ora possono essere caricati automaticamente nel cloud. Ciò richiede l'installazione di un modulo ClusterControl, chiamato clustercontrol-cloud (modulo di integrazione cloud) e clustercontrol-clud (Cloud download/upload CLI) che sono disponibili in v1.5 e versioni successive. Le istruzioni di aggiornamento sono state incluse con questi pacchetti e vengono fornite senza alcuna configurazione aggiuntiva. Al momento, le piattaforme cloud supportate sono Amazon Web Services e Google Cloud Platform. Le credenziali cloud sono configurate in ClusterControl -> Impostazioni -> Integrazioni -> Provider cloud.
Quando crei o pianifichi un backup, dovresti vedere le seguenti opzioni aggiuntive quando "Carica backup nel cloud" è attivato:
La funzione consente un caricamento una tantum o di pianificare i backup da caricare dopo il completamento (Amazon S3 o Google Cloud Storage). È quindi possibile scaricare e ripristinare i backup come richiesto.
Compressione personalizzata per mysqldump
Questa funzionalità è stata infatti introdotta per la prima volta con ClusterControl v1.4.2 dopo il suo rilascio. Abbiamo aggiunto un livello di compressione di backup basato su gzip. In precedenza, ClusterControl utilizzava la compressione di backup predefinita (livello 6) se la destinazione di backup era sul nodo del controller. La compressione più bassa (livello 1 - più veloce, meno compressione) è stata utilizzata se la destinazione di backup era sull'host del database stesso, per garantire un impatto minimo sul database durante l'operazione di compressione.
In questa versione, abbiamo perfezionato l'aspetto della compressione e ora puoi personalizzare il livello di compressione, indipendentemente dalla destinazione del backup. Quando aggiorni la tua istanza ClusterControl, tutti i backup pianificati verranno automaticamente convertiti per utilizzare il livello 6, a meno che non li modifichi esplicitamente nella v1.5.
La compressione del backup è fondamentale quando il set di dati è di grandi dimensioni, unita a una lunga politica di conservazione del backup, mentre lo spazio di archiviazione è limitato. Mysqldump, che è basato su testo, può trarre vantaggio dalla compressione con risparmi fino al 60% di spazio su disco rispetto alle dimensioni del file originale. In alcune occasioni, il rapporto di compressione più alto è l'opzione migliore, anche se ha il prezzo di una decompressione più lunga durante il ripristino.
Funzione bonus:verifica automatica del backup
Come dicono i vecchi amministratori di sistema:un backup non è un backup se non è ripristinabile. La verifica del backup è qualcosa che di solito viene trascurato da molti. Alcuni amministratori di sistema hanno sviluppato routine interne per questo, di solito più manuali che automatizzate. L'automazione è difficile, principalmente a causa della complessità dell'operazione nel suo insieme:a partire dal provisioning dell'host, all'installazione e preparazione di MySQL, al trasferimento dei file di backup, alla decompressione, all'operazione di ripristino, alle procedure di verifica e infine alla pulizia del sistema dopo il processo. Tutti questi problemi fanno sì che le persone trascurino un aspetto così importante di un backup affidabile. In generale, un test di ripristino del backup dovrebbe essere eseguito almeno una volta al mese o in caso di modifiche significative nella dimensione dei dati o nella struttura del database. Trova un programma che funzioni per te e formalizzalo con un evento programmato.
ClusterControl può automatizzare la verifica del backup eseguendo il ripristino su un nuovo host, senza compromettere nessuna delle procedure di verifica sopra menzionate. Questo può essere fatto dopo un certo ritardo o subito dopo il completamento del backup. Riporterà lo stato del backup in base al codice di uscita dell'operazione di ripristino, eseguirà lo spegnimento automatico se il backup è verificato o semplicemente farà funzionare l'host ripristinato in modo da eseguire ulteriori verifiche manuali sui dati.
Quando crei o pianifichi un backup, avrai opzioni aggiuntive se "Verifica backup" è attivato:
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. Altrimenti, se hai una configurazione specifica per l'host ripristinato, puoi saltare questa opzione. Il resto delle opzioni è autoesplicativo.
Funzione bonus:non dimenticare PostgreSQL
Oltre a tutte queste fantastiche funzionalità per MySQL e MariaDB, ClusterControl 1.5 ora fornisce a PostgreSQL anche un metodo di backup aggiuntivo (pg_basebackup) che può essere utilizzato per i backup binari online. I backup eseguiti con pg_basebackup possono essere utilizzati in un secondo momento per il ripristino point-in-time e come punto di partenza per un server di log shipping o standby di replica streaming.
Per ora è tutto. Prova ClusterControl v1.5, gioca con le nuove funzionalità e facci sapere cosa ne pensi.
