Il backup del database è una parte fondamentale della gestione del database e deve essere pianificato con attenzione. La pianificazione di un backup non è sufficiente, anche i dati di backup devono essere verificati per coerenza e integrità. Ci sono altre considerazioni come la crittografia e l'archiviazione fuori sede. Un buon gestore di backup dovrebbe avere funzionalità che tengono conto di tutte queste diverse considerazioni.
In questo post del blog, esamineremo come pianificare i backup del database con ClusterControl.
Backup del database utilizzando ClusterControl
ClusterControl supporta diversi metodi di backup a seconda del tipo di cluster, come riepilogato nella tabella seguente:
| Tipo di cluster | Metodo di backup supportato |
|---|---|
| MySQL (replica, Galera, cluster NDB, replica di gruppo) |
|
| MongoDB (set di repliche, cluster frammentato) |
|
| PostgreSQL (replica in streaming) |
|
Quando si pianifica il backup con ClusterControl, ciascuno dei metodi di backup è configurabile con una serie di opzioni su come si desidera eseguire il backup. Diversi carichi di lavoro del database e strategie di backup richiederebbero il supporto per diverse funzionalità, ad esempio:
- Limitazione degli IOPS su disco
- Limitazione della rete
- Blocchi backup
- Crittografia
- Compressione
- Periodo di conservazione
- Verifica
ClusterControl imposterà automaticamente una serie di opzioni di backup, seguendo le migliori pratiche del particolare fornitore di database. Ad esempio, se il nodo del database di destinazione ha il log binario abilitato, aggiungerà un flag aggiuntivo, --master-data per includere le coordinate del log binario (nome file e posizione) del server di cui è stato eseguito il dump. Se è un nodo Galera e il metodo di backup è xtrabackup, ClusterControl aggiungerà un flag aggiuntivo, --galera-info che contiene lo stato del nodo locale al momento del backup.
Pianificazione di un backup
Prima di pianificare qualsiasi backup, dobbiamo pianificare come dovrebbe essere l'operazione di backup. Rispondere alle seguenti domande di esempio sarebbe utile prima di creare una pianificazione di backup:
- Quale metodo di backup vuoi utilizzare? Alcuni metodi di backup non sono bloccanti, ma richiedono molte risorse. Comprendi i compromessi, in modo da non essere sorpreso di come si comporta il processo in produzione.
- Con quale frequenza desideri eseguire il backup dei database? L'esecuzione di un backup completo potrebbe essere doloroso se l'intervallo di backup è troppo breve. Probabilmente hai bisogno di un mix di backup completi e incrementali.
- Quanto velocemente vuoi ripristinare i tuoi dati? Il backup fisico è generalmente molto più veloce del backup logico in termini di tempo di ripristino completo. D'altra parte, il backup logico è generalmente più veloce per il ripristino parziale.
- Quanto è grande la tua dimensione dei dati? In alcuni casi, il backup logico non è una buona scelta per database di grandi dimensioni e il backup binario è l'unico modo per farlo.
- Quanto spazio libero hai per archiviare il backup? I backup tendono a consumare molto spazio. Decidi se è necessaria la compressione e il livello di compressione che puoi permetterti. Una migliore compressione richiede un maggiore utilizzo della CPU.
- Cosa succede se il server di backup è inattivo durante il tempo di backup? Dovrebbe eseguire il failover del backup su un altro host disponibile? Saltare un backup a causa di una finestra di manutenzione di solito non è una buona idea.
- Come garantire l'integrità del backup creato? Ricorda, un backup non è un backup se non è ripristinabile.
- Ti fidi dell'archivio di backup? La crittografia potrebbe essere una buona idea per proteggere i tuoi dati.
In generale, rispondendo a queste domande, possiamo elaborare una strategia di backup appropriata. L'elenco delle domande potrebbe essere più lungo a seconda della tua politica di backup e ripristino.
Abbiamo trattato questo capitolo in dettaglio nel nostro whitepaper, The DevOps Guide to Database Backups for MySQL and MariaDB.
Pianificazione di un backup
Con ClusterControl, la pianificazione è piuttosto semplice. Vai direttamente su Backup -> Crea backup -> Pianifica backup e ti verrà presentata la seguente finestra di dialogo:
A seconda del tipo di cluster, le opzioni potrebbero essere diverse, come mostrato negli screenshot seguenti per PostgreSQL e MongoDB:
PostgreSQL 
MongoDB La maggior parte delle opzioni sono autoesplicative e sono trattate in dettaglio nella Guida per l'utente. Una volta creata la pianificazione, puoi modificare i backup di configurazione, abilitare/disabilitare il backup o eliminare la pianificazione nella scheda "Backup pianificati":
Tenere presente che quando si pianifica il backup con ClusterControl, è necessario pianificare tutte le ore nel fuso orario UTC del server ClusterControl. Il motivo alla base di ciò è eliminare la confusione del tempo di esecuzione del backup. Quando si lavora con un cluster, i server di database possono essere distribuiti in diversi fusi orari e diverse aree geografiche. L'utilizzo di un fuso orario di riferimento per gestirli tutti assicurerà che i backup vengano sempre eseguiti all'ora corretta.
Puoi monitorare lo stato di avanzamento di un backup guardando Attività -> Lavori una volta giunto il momento. Se il processo di backup non è riuscito, vedrai subito l'errore:
Il registro sopra è accessibile anche nella scheda Backup su ciascuna voce di backup:
Verifiche e verifiche post-backup
Una volta terminato il processo di backup, non significa che la tua responsabilità sia finita. Ci sono un paio di cose che devono essere seguite. Il più importante è lo stato del backup creato. ClusterControl fornisce notifiche e-mail e ti avviserà dello stato. Questo servizio di notifica è ovviamente configurabile in base alla gravità in Impostazioni -> Impostazioni generali -> Impostazioni notifiche e-mail -> Backup:
Consegna significa che ClusterControl invierà un'e-mail di notifica immediatamente dopo che è stato generato un allarme per questo componente. Puoi anche configurarlo come Ignora o Digest, dove ClusterControl invia un riepilogo giornaliero degli allarmi generati.
Se il backup viene creato correttamente, si consiglia vivamente di verificare se il backup è ripristinabile. Puoi utilizzare la funzione di verifica del backup facendo clic sul pulsante "Ripristina" dell'ID di backup scelto e ti verranno presentate due opzioni di ripristino:
"Ripristina e verifica su host autonomo" richiede un host separato, che non fa già parte della configurazione del database. ClusterControl distribuirà prima un'istanza MySQL sull'host di destinazione, avvierà il servizio, copierà il backup dal repository di backup e avvierà il ripristino. Una volta terminato, puoi avere un'opzione per spegnere il server una volta ripristinato o lasciarlo funzionare in modo da poter condurre ulteriori indagini sul server.
Anche le pulizie sono importanti per mantenere solo i backup utili nella tua memoria. Pertanto, configurare la conservazione del backup secondo necessità. Per impostazione predefinita, ClusterControl elimina i backup precedenti a 30 giorni. Puoi anche personalizzare ciascuna delle pianificazioni di backup con diversi periodi di conservazione.
Se lo spazio di archiviazione del backup si sta avvicinando a qualsiasi limite di spazio o desideri archiviare il backup fuorigioco, puoi scegliere di eliminare manualmente il file facendo clic sull'icona del cestino o caricarlo sul cloud, come evidenziato di seguito:
Al momento della scrittura, sono supportati AWS S3 e GCP Cloud Storage. Le credenziali cloud devono essere preconfigurate in Menu laterale -> Integrazioni -> Cloud Provider.
Questo è tutto, gente. Buon raggruppamento!
