L'aggiornamento del database per cluster basati su Galera come Percona XtraDB Cluster (PXC) o MariaDB Galera Cluster può essere difficile, soprattutto per un ambiente basato sulla produzione. Non puoi permetterti di perdere lo stato della tua alta disponibilità e metterlo a rischio.
Una procedura di aggiornamento deve essere ben documentata e, idealmente, prima degli aggiornamenti dovrebbero essere eseguiti documentazione, test rigorosi e benchmarking. Soprattutto, la sicurezza e i miglioramenti devono essere identificati anche in base al registro delle modifiche dell'aggiornamento della versione del database.
Con tutte le preoccupazioni, l'automazione aiuta a ottenere un processo di aggiornamento più efficiente, aiuta a evitare l'errore umano e migliora l'RTO.
Come gestire il processo di aggiornamento del cluster PXC/MariaDB Galera
L'aggiornamento del cluster PXC/MariaDB Galera richiede una documentazione adeguata e un flusso di processo che elenchi le cose da fare e cosa fare nel caso le cose vadano male. Ciò significa che dovrebbe essere predisposto un piano di continuità operativa che copra anche il piano di ripristino di emergenza. Non puoi permetterti di perdere la tua attività in caso di problemi.
Il solito passo è iniziare prima con l'ambiente di test. L'ambiente di test dovrebbe avere esattamente le stesse impostazioni e configurazione dell'ambiente di produzione. Non è possibile procedere direttamente con l'aggiornamento dell'ambiente di produzione poiché non si è sicuri dell'effetto e dell'impatto che si verificheranno se le cose non corrispondono al piano.
Lavorare con un ambiente di produzione è estremamente delicato, quindi nella maggior parte dei casi è sempre presente un periodo di inattività e di manutenzione per evitare un impatto drastico.
Esistono due tipi di aggiornamento per PCX o MariaDB Galera Cluster di cui devi essere a conoscenza. Questi sono l'aggiornamento della versione principale e l'aggiornamento della versione minore o spesso indicati come aggiornamento sul posto. Un aggiornamento sul posto è dove puoi aggiornare la versione del tuo database alla sua versione minore più recente utilizzando gli stessi dati binari del tuo database. Non ci saranno modifiche fisiche ai dati stessi, ma solo al binario del database o ai pacchetti software sottostanti.
Aggiornamento del cluster PCX o MariaDB Galera a una versione principale
L'aggiornamento a una versione principale può essere impegnativo, soprattutto per un ambiente di produzione. Implica un tipo complesso di configurazione del database e speciali funzionalità integrate di PXC o MariaDB Galera Cluster. I dati spaziotemporali, con timestamp, dati macchina o qualsiasi dato multiforme sono molto prudenti e sensibili agli aggiornamenti. Non è possibile applicare un aggiornamento sul posto per questo processo perché sarebbero state apportate molte modifiche importanti. A meno che tu non abbia dati molto piccoli o dati costituiti da idempotenti o dati che possono essere generati facilmente può essere sicuro farlo purché tu sappia che l'impatto non influirà sui tuoi dati.
Se il tuo volume di dati è elevato, è meglio automatizzare il processo di aggiornamento. Tuttavia, potrebbe non essere una soluzione ideale per automatizzare tutta la sequenza nel processo di aggiornamento perché potrebbero verificarsi problemi imprevisti durante la fase di aggiornamento principale. È meglio automatizzare passaggi e processi ripetitivi con risultati noti in un aggiornamento importante. In qualsiasi momento, è necessaria una risorsa per valutare se il processo di automazione è sicuro per evitare interruzioni nel processo di aggiornamento. Il test automatizzato dopo l'aggiornamento è altrettanto importante e dovrebbe essere incluso come parte del processo successivo all'aggiornamento.
Aggiornamento del cluster PCX o MariaDB Galera a una versione minore
Un aggiornamento di versione minore denominato aggiornamento sul posto è solitamente un approccio più sicuro per eseguire un processo di aggiornamento. Questo perché le modifiche più comuni per questa versione sono la sicurezza e sfruttano patch o miglioramenti, bug (di solito gravi) o problemi di compatibilità che richiedono patch soprattutto se all'hardware o al sistema operativo corrente sono state applicate modifiche che possono impedire anche al database di funzionare correttamente. Sebbene l'impatto possa in genere essere recuperabile con un effetto minimo, è comunque necessario guardare e leggere il log delle modifiche che è stato inviato all'aggiornamento della versione minore specifica.
La distribuzione del lavoro per eseguire il processo di aggiornamento è un esempio ideale di automazione. Il solito flusso è molto ripetitivo e per lo più non causa danni al cluster PXC o MariaDB Galera esistente. Ciò che conta di più è che dopo l'aggiornamento, i test automatizzati procedano per determinare che l'installazione, la configurazione, l'efficienza e la funzionalità non sono interrotte.
Evita i fiasco! Preparati, fallo automatizzare!
Un nostro cliente ci ha contattato chiedendoci assistenza perché, dopo l'aggiornamento minore del database, una funzionalità che stanno utilizzando nel database non funziona correttamente. Hanno chiesto passaggi e processi su come eseguire il downgrade e quanto sarà sicuro. I loro clienti si sono lamentati del fatto che la loro applicazione non funzionasse completamente, generalizzando che non è utile.
Anche per un problema così piccolo, un cliente incazzato potrebbe dare una brutta osservazione al tuo prodotto. La lezione appresa da questo scenario è che il fallimento del test dopo un aggiornamento porta a presumere che tutte le funzioni in un database funzionino come previsto.
Supponiamo che tu abbia in programma di automatizzare il processo di aggiornamento, quindi prendi nota che il tipo di processo di automazione varia a seconda del tipo di aggiornamento che devi eseguire. Come accennato in precedenza, un aggiornamento maggiore rispetto a un aggiornamento minore ha approcci distinti diversi. Quindi la configurazione dell'automa potrebbe non essere applicabile a entrambi gli aggiornamenti del software del database.
Automatizzazione dopo il processo di aggiornamento
A questo punto, ci si aspetta che il processo di aggiornamento sia completato, idealmente, tramite l'automazione. Ora che il tuo database è pronto per ricevere le connessioni dei client, deve seguire una rigorosa fase di test.
Esegui mysql_upgrade
È molto importante ed estremamente consigliato eseguire mysql_upgrade una volta completato il processo di aggiornamento. mysql_upgrade cerca le incompatibilità con il server MySQL aggiornato eseguendo le seguenti operazioni:
-
Aggiorna le tabelle di sistema nello schema mysql in modo da poter sfruttare nuovi privilegi o capacità che potrebbero sono stati aggiunti.
-
Aggiorna lo schema delle prestazioni e lo schema di sistema.
-
Esamina gli schemi utente.
Mysql_upgrade determina se una tabella presenta problemi come incompatibilità dovute a modifiche nella versione più recente dopo l'aggiornamento e tenta di risolverlo riparando la tabella. Altrimenti, se fallisce, il test di automazione dovrà fallire e non deve procedere con qualcos'altro. Deve essere prima esaminato ed eseguire una riparazione manuale.
Controlla i registri degli errori
Una volta terminato il mysql_upgrade, è necessario controllare e verificare gli errori che si sono verificati. Puoi inserirlo in uno script e controllare eventuali etichette di "errore" o "avviso" nei registri degli errori. È molto importante determinare se esiste. Il tuo test automatizzato deve essere in grado di rilevare le trappole di errore può attendere che l'input dell'utente continui se l'errore è minimo o previsto, altrimenti interrompe il processo di aggiornamento.
Esegui un test unitario
Un ambiente di database TDD (Test Driven Development) è un approccio di sviluppo software in cui sono presenti una serie di casi di test da convalidare e determinare se la convalida è vera (superata) o falsa (non riuscita). Qualcosa di simile a quello che abbiamo nello screenshot qui sotto:
Immagine per gentile concessione di guru99.com
Questo è un tipo di unit test che aiuta a evitare bug indesiderati o errori logici nella tua applicazione e nel tuo database. Ricorda, se nel database sono archiviati dati non validi, ciò danneggerebbe tutte le analisi e le transazioni aziendali, soprattutto se si tratta di calcoli finanziari complessi o equazioni matematiche.
Se lo chiedi, è davvero necessario eseguire uno unit test dopo l'aggiornamento? Ovviamente è! Non è necessario eseguirlo nell'ambiente di produzione. Durante le fasi di test, ovvero l'aggiornamento prima del tuo QA, dell'ambiente di sviluppo/staging, deve essere applicato in quell'area. I dati devono essere una copia esatta almeno o quasi uguale al suo ambiente di produzione. Il tuo obiettivo qui è evitare risultati indesiderati e risultati logici decisamente sbagliati. Ovviamente devi prenderti cura dei tuoi dati e determinare se i risultati superano il test di convalida.
Se intendi eseguire la tua produzione, fallo. Tuttavia, non essere così rigido come la fase di test applicata nell'ambiente di controllo qualità, sviluppo o staging. È perché devi pianificare il tuo tempo in base alla finestra di manutenzione disponibile ed evitare ritardi e RTO più lunghi.
Secondo la mia esperienza, durante la fase di aggiornamento, i clienti scelgono un approccio più rapido che sarà importante per determinare se tale funzionalità fornisce il risultato corretto. Inoltre, puoi avere uno script per automatizzare il test di una serie di funzioni logiche di business o procedure memorizzate poiché aiuta a memorizzare nella cache le query e riscaldare il tuo database.
Quando ti prepari per Unit Test per il tuo database, evita di reinventare la ruota. Invece, dai un'occhiata agli strumenti disponibili che puoi scegliere se è adatto alle tue esigenze e necessità. Dai un'occhiata a Selenium o dai un'occhiata a questo blog.
Verifica l'identità delle query
Lo strumento più comune che puoi utilizzare è l'aggiornamento pt di Percona. Verifica che i risultati della query siano identici su server diversi. Esegue query in base ai registri forniti e alla connessione fornita (o denominata DSN), quindi confronta i risultati e segnala eventuali differenze significative. Offre più di questo come opzioni per raccogliere o analizzare le query, ad esempio tramite tcpdump.
Utilizzare pt-upgrade è facile. Ad esempio, puoi eseguire con il seguente comando:
## Comparing via slow log for the given hosts
pt-upgrade h=host1 h=host2 slow.log
## or use fingerprints, useful for debugging purposes
pt-upgrade --fingerprints --run-time=1h mysqld-slow.log h=127.0.0.1,P=5091 h=127.0.0.1,P=5517
## or with tcpdump,
tcpdump -i eth0 port 3306 -s 65535 -x -n -q -tttt \
| pt-query-digest --type tcpdump --no-report --print \
| pt-upgrade h=host1 h=host2È buona norma che una volta eseguito un aggiornamento, in particolare un aggiornamento della versione principale, pt-upgrade venga utilizzato per procedere ed eseguire l'analisi della query identificando le differenze in base ai risultati. È buona norma eseguire questa operazione durante la fase di test mentre lo si esegue sul proprio QA o ambiente di staging e sviluppo in modo da poter decidere se è più sicuro procedere. Puoi aggiungerlo al tuo strumento di automazione ed eseguirlo come playbook una volta che è pronto per svolgere il suo compito.
Come automatizzare il processo di test?
Nei nostri blog precedenti, abbiamo presentato diversi modi per automatizzare i tuoi database. Gli strumenti più comuni che sono in voga sono questi strumenti software di distribuzione IaC (Infrastructure as Code). Puoi usare Puppet, Chef, SaltStack o Ansible per fare il lavoro.
La mia preferenza è sempre stata Ansible per eseguire i miei test automatici, mi consente di creare playbook in base al suo ruolo lavorativo. Naturalmente, non posso creare un intero automa che farà tutte le cose perché la situazione e l'ambiente variano. In base ai tipi di aggiornamento forniti in precedenza (aggiornamento maggiore o minore), dovresti distinguere il suo processo. Anche se si tratta solo di un aggiornamento sul posto, devi comunque assicurarti che i tuoi playbook svolgano il lavoro corretto.
ClusterControl è il tuo amico dell'automazione del database!
ClusterControl è una buona opzione per eseguire test di base e automatizzati. ClusterControl non è un framework per il test; non è uno strumento per fornire unit test. Tuttavia, è uno strumento di gestione e monitoraggio del database che incorpora molte distribuzioni automatizzate basate sui trigger richiesti dall'utente o dall'amministratore del software.
ClusterControl offre aggiornamenti di versioni minori, che offrono comodità ai DBA durante l'esecuzione degli aggiornamenti. Fa anche mysql_upgrade al volo. Quindi non è necessario eseguirlo manualmente. ClusterControl rileva anche le nuove versioni da aggiornare e consiglia i passaggi successivi da eseguire. In caso di errore, l'aggiornamento non procederà.
Ecco un esempio del lavoro di aggiornamento minore:
Se guardi attentamente, mysql_upgrade viene eseguito correttamente. Anche se non consiglia ed esegue un aggiornamento automatico del master, è perché non è l'approccio giusto per procedere. In tal caso, devi promuovere il nuovo slave, quindi retrocedere il master come slave per eseguire l'aggiornamento.
Conclusione
Il vantaggio di ClusterControl è che puoi incorporare il controllo dei log degli errori, eseguire uno unit test, verificare l'identità delle query creando Advisor. Non è difficile farlo. Puoi fare riferimento al nostro blog precedente Utilizzo di ClusterControl Advisor per creare controlli per SELinux e Meltdown/Spectre:Part One. Questo esemplifica come puoi trarre vantaggio e attivare il lavoro successivo da eseguire una volta eseguito l'aggiornamento. ClusterControl dispone di avvisi o allarmi integrati che possono integrarsi nei tuoi sistemi di avviso di terze parti preferiti per informarti sullo stato corrente dei test automatizzati.
