La maggior parte dei DBA esegue controlli sanitari sui propri database di tanto in tanto. Di solito, accadeva su base giornaliera o settimanale. In precedenza abbiamo discusso del motivo per cui tali controlli sono importanti e cosa dovrebbero includere.
Per assicurarti che i tuoi sistemi siano in buone condizioni, dovresti esaminare molte informazioni:statistiche sull'host, statistiche MySQL, statistiche sul carico di lavoro, stato dei backup, pacchetti di database, registri e così via. Tali dati dovrebbero essere disponibili in ogni ambiente adeguatamente monitorato, anche se a volte sono sparsi in più posizioni:potresti avere uno strumento per monitorare lo stato di MySQL, un altro strumento per raccogliere statistiche di sistema, forse una serie di script, ad esempio, per controllare lo stato di i tuoi backup Ciò rende i controlli dello stato molto più dispendiosi in termini di tempo di quanto dovrebbero:il DBA deve mettere insieme i diversi pezzi per comprendere lo stato del sistema.
Strumenti integrati come ClusterControl hanno il vantaggio che tutti i bit si trovano nella stessa posizione (o nella stessa applicazione). Ciò non significa ancora che si trovino uno accanto all'altro:potrebbero trovarsi in sezioni diverse dell'interfaccia utente e un DBA potrebbe dover dedicare del tempo a fare clic sull'interfaccia utente per raggiungere tutti i dati interessanti.
L'idea alla base della creazione di rapporti operativi è quella di mettere tutti i dati più importanti in un unico documento, che può essere rapidamente rivisto per comprendere lo stato dei database.
I Rapporti Operativi sono disponibili dal menu Menu Laterale -> Rapporti Operativi:
Una volta lì, ti verrà presentato un elenco di rapporti creati manualmente o automaticamente, in base a una pianificazione predefinita:
Se desideri creare un nuovo rapporto manualmente, utilizzerai l'opzione "Crea". Scegli il tipo di rapporto, il nome del cluster (per il rapporto per cluster), i destinatari dell'e-mail (facoltativo, se desideri che il rapporto ti venga recapitato) e il gioco è fatto:
I rapporti possono anche essere programmati per essere creati su base regolare:
Al momento sono disponibili 5 tipi di rapporti:
- Rapporto sulla disponibilità - Tutti i cluster.
- Rapporto di backup - Tutti i cluster.
- Rapporto di modifica dello schema - Solo cluster basato su MySQL/MariaDB.
- Rapporto di sistema giornaliero - Per cluster.
- Rapporto sull'aggiornamento del pacchetto - Per cluster.
Rapporto sulla disponibilità
I rapporti sulla disponibilità si concentrano, beh, sulla disponibilità. Comprende tre sezioni. Innanzitutto, riepilogo disponibilità:
Puoi visualizzare le informazioni sulle statistiche di disponibilità dei tuoi database, il tipo di cluster, i tempi di attività e di inattività totali, lo stato corrente del cluster e l'ultima modifica di tale stato.
Un'altra sezione fornisce maggiori dettagli sulla disponibilità per ogni cluster. Lo screenshot seguente mostra solo uno dei cluster di database:
Possiamo vedere quando un nodo ha cambiato stato e qual è stata la transizione. È un bel posto per verificare se ci sono stati problemi recenti con il cluster. Dati simili sono mostrati nella terza sezione di questo rapporto, dove puoi scorrere la cronologia delle modifiche nello stato del cluster.
Rapporto di backup
Il secondo tipo di report riguarda i backup di tutti i cluster. Contiene due sezioni:riepilogo del backup e dettagli del backup, in cui il primo fornisce sostanzialmente un breve riepilogo di quando è stato creato l'ultimo backup, se è stato completato correttamente o meno, stato di verifica del backup, percentuale di successo e periodo di conservazione:
ClusterControl fornisce anche esempi di criteri di backup se rileva uno qualsiasi dei cluster di database monitorati in esecuzione senza backup pianificato o slave ritardato configurato. I prossimi sono i dettagli del backup:
Puoi anche controllare l'elenco dei backup eseguiti sul cluster con il loro stato, tipo e dimensione entro l'intervallo specificato. Questo è il più vicino possibile per essere certi che i backup funzionino correttamente senza eseguire un test di ripristino completo. Raccomandiamo vivamente di eseguire tali test di tanto in tanto. La buona notizia è che ClusterControl supporta il ripristino e la verifica basati su MySQL su un host autonomo in Backup -> Ripristina backup.
Rapporto di sistema giornaliero
Questo tipo di report contiene informazioni dettagliate su un particolare cluster. Inizia con un riepilogo di diversi avvisi correlati al cluster:
La prossima sezione riguarda lo stato dei nodi che fanno parte del cluster:
Hai un elenco dei nodi nel cluster, il loro tipo, il ruolo (master o slave), lo stato del nodo, il tempo di attività e il sistema operativo.
Un'altra sezione del rapporto è il riepilogo del backup, lo stesso di cui abbiamo discusso sopra. Quello successivo presenta un riepilogo delle principali query nel cluster:
Infine, vediamo una "Panoramica dello stato del nodo" in cui ti verranno presentati grafici relativi alle metriche del sistema operativo e MySQL per ciascun nodo.
Come puoi vedere, abbiamo qui grafici che coprono tutti gli aspetti del carico sull'host:CPU, memoria, rete, disco, carico della CPU e disco libero. Questo è sufficiente per avere un'idea se qualcosa di strano è successo di recente o meno. Puoi anche vedere alcuni dettagli sul carico di lavoro MySQL:quante query sono state eseguite, quale tipo di query, come è stato effettuato l'accesso ai dati (tramite quale gestore)? Questo, d'altra parte, dovrebbe essere sufficiente per selezionare la maggior parte dei problemi sul lato MySQL. Quello che vuoi guardare sono tutti picchi e cali che non hai visto in passato. Forse è stata aggiunta una nuova query al mix e, di conseguenza, handler_read_rnd_next alle stelle? Forse c'è stato un aumento del carico della CPU e un numero elevato di connessioni potrebbe indicare un aumento del carico su MySQL, ma anche un qualche tipo di contesa. Potrebbe essere utile indagare su uno schema imprevisto, quindi sai cosa sta succedendo.
Rapporto sull'aggiornamento del pacchetto
Questo report fornisce un riepilogo dei pacchetti disponibili per l'aggiornamento da parte del gestore del repository sugli host monitorati. Per un reporting accurato, assicurati di utilizzare sempre repository stabili e affidabili su ogni host. In alcune occasioni indesiderate, gli host monitorati potrebbero essere configurati con un repository obsoleto dopo un aggiornamento (ad esempio, ogni versione principale di MariaDB utilizza un repository diverso), un repository interno incompleto (ad esempio, mirroring parziale dall'upstream) o un repository edge edge (comunemente per unstable pacchetti di build notturna).
La prima sezione è il riepilogo dell'aggiornamento:
Riepiloga il numero totale di pacchetti disponibili per l'aggiornamento, nonché il relativo servizio gestito per il cluster come il servizio di bilanciamento del carico, l'indirizzo IP virtuale e l'arbitro. Successivamente, ClusterControl fornisce un elenco dettagliato dei pacchetti, raggruppati per tipo di pacchetto per ogni host:
Questo rapporto fornisce la versione disponibile e può aiutarci notevolmente a pianificare in modo efficiente la nostra finestra di manutenzione. Per gli aggiornamenti critici come la sicurezza e i pacchetti di database, potremmo dare la priorità agli aggiornamenti non critici, che potrebbero essere consolidati con altre finestre di manutenzione con priorità meno importanti.
Rapporto di modifica dello schema
Questo report confronta le modifiche al database MySQL/MariaDB selezionate nella struttura della tabella che si sono verificate tra due diversi report generati. Nelle versioni precedenti di MySQL/MariaDB, l'operazione DDL è un'operazione non atomica (precedente alla 8.0) e richiede la copia completa della tabella (precedente alla 5.6 per la maggior parte delle operazioni), bloccando altre transazioni fino al completamento. Le modifiche allo schema potrebbero diventare un enorme problema una volta che le tue tabelle ottengono una quantità significativa di dati e devono essere pianificate attentamente, specialmente in una configurazione in cluster. In un ambiente di sviluppo a più livelli, abbiamo visto molti casi in cui gli sviluppatori modificano silenziosamente la struttura della tabella, con un impatto significativo sulle prestazioni delle query.
Affinché ClusterControl possa produrre un report accurato, è necessario configurare opzioni speciali all'interno del file di configurazione CMON per il rispettivo cluster:
- schema_change_detection_address - I controlli verranno eseguiti utilizzando SHOW TABLES/SHOW CREATE TABLE per determinare se lo schema è stato modificato. I controlli vengono eseguiti sull'indirizzo specificato ed è nel formato HOSTNAME:PORT. Gli database_di_rilevamento_di_modifica_schema deve anche essere impostato. Viene creato un differenziale di una tabella modificata (usando diff).
- schema_change_detection_databases - Elenco separato da virgole di database per monitorare le modifiche allo schema. Se vuoto, non vengono effettuati controlli.
In questo esempio, vorremmo monitorare le modifiche allo schema per il database "myapp" e "sbtest" sul nostro cluster MariaDB con ID cluster 27. Scegli uno dei nodi del database come valore di schema_change_detection_address . Per la replica MySQL, questo dovrebbe essere l'host master o qualsiasi host slave che contiene i database (nel caso in cui sia attiva la replica parziale). Quindi, all'interno di /etc/cmon.d/cmon_27.cnf, aggiungi le due righe seguenti:
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestRiavvia il servizio CMON per caricare la modifica:
$ systemctl restart cmonPer il primo e più importante report, ClusterControl restituisce solo il risultato della raccolta dei metadati, simile al seguente:
Con il primo rapporto come riferimento, i rapporti successivi restituiranno l'output previsto per:
Tenere presente che nel report vengono stampate solo le nuove tabelle o le tabelle modificate. Il primo rapporto serve solo per la raccolta di metadati per il confronto nei round successivi, quindi dobbiamo eseguirlo per almeno due volte per vedere la differenza.
Con questo rapporto, ora puoi raccogliere le impronte della struttura del database e capire come si è evoluto il tuo database nel tempo.
Pensieri finali
Il report operativo è un modo completo per comprendere lo stato dell'infrastruttura del database. È stato creato per il personale operativo o manageriale e può essere molto utile nell'analisi delle operazioni del database. I rapporti possono essere generati sul posto o possono essere consegnati via e-mail, il che rende le cose comodamente facili se disponi di un silo di rapporti.
Ci piacerebbe ricevere il tuo feedback su qualsiasi altra cosa che vorresti includere nel rapporto, cosa manca e cosa non è necessario.
