I test di rilascio sono in genere uno dei passaggi dell'intero processo di distribuzione. Si scrive il codice, quindi si verifica come si comporta in un ambiente di staging e infine si distribuisce il nuovo codice nella produzione. I database sono interni a qualsiasi tipo di applicazione e, pertanto, è importante verificare in che modo le modifiche relative al database alterano l'applicazione. È possibile verificarlo in un paio di modi; uno di questi sarebbe quello di utilizzare una replica dedicata. Diamo un'occhiata a come si può fare.
Ovviamente, non vuoi che questo processo sia manuale:dovrebbe far parte dei processi CI/CD della tua azienda. A seconda dell'applicazione, dell'ambiente e dei processi esatti in atto, è possibile utilizzare repliche create ad hoc o repliche che fanno sempre parte dell'ambiente del database.
Il modo in cui Galera Cluster funziona è che gestisce le modifiche allo schema in un modo specifico. È possibile eseguire una modifica dello schema su un singolo nodo del cluster, ma è complicato, poiché non supporta tutte le possibili modifiche allo schema e influirà sulla produzione se qualcosa va storto. Tale nodo dovrebbe essere completamente ricostruito utilizzando SST, il che significa che uno dei nodi Galera rimanenti dovrà fungere da donatore e trasferire tutti i suoi dati sulla rete.
Un'alternativa sarà utilizzare una replica o anche un intero cluster Galera aggiuntivo che funge da replica. Ovviamente, il processo deve essere automatizzato per inserirlo nella pipeline di sviluppo. Esistono molti modi per farlo:script o numerosi strumenti di orchestrazione dell'infrastruttura come Ansible, Chef, Puppet o Salt Stack. Non li descriveremo in dettaglio, ma vorremmo che tu mostrassi i passaggi necessari per il corretto funzionamento dell'intero processo e lasceremo a te l'implementazione in uno degli strumenti.
Automatizzazione dei test di rilascio
Prima di tutto, vogliamo essere in grado di distribuire facilmente un nuovo database. Dovrebbe essere fornito con i dati recenti e questo può essere fatto in molti modi:puoi copiare i dati dal database di produzione nel server di test; questa è la cosa più semplice da fare. In alternativa, puoi utilizzare il backup più recente:un tale approccio offre ulteriori vantaggi nel testare il ripristino del backup. La verifica del backup è un must in qualsiasi tipo di distribuzione seria e la ricostruzione delle configurazioni di prova è un ottimo modo per ricontrollare il funzionamento del processo di ripristino. Ti aiuta anche a programmare il processo di ripristino:sapere quanto tempo ci vuole per ripristinare il backup aiuta a valutare correttamente la situazione in uno scenario di ripristino di emergenza.
Una volta eseguito il provisioning dei dati nel database, potresti voler configurare quel nodo come una replica del tuo cluster primario. Ha i suoi pro e contro. Se potessi rieseguire tutto il traffico verso il nodo autonomo, sarebbe perfetto:in tal caso, non è necessario impostare la replica. Alcuni dei sistemi di bilanciamento del carico, come ProxySQL, consentono di eseguire il mirroring del traffico e di inviarne la copia in un'altra posizione. D'altra parte, la replica è la cosa migliore. Sì, non puoi eseguire scritture direttamente su quel nodo che ti costringe a pianificare come rieseguire le query poiché l'approccio più semplice di rispondere semplicemente non funzionerà. D'altra parte, tutte le scritture verranno eventualmente eseguite tramite il thread SQL, quindi devi solo pianificare come gestire le query SELECT.
A seconda della modifica esatta, potresti voler testare il processo di modifica dello schema. Le modifiche allo schema sono abbastanza comuni da eseguire e possono avere un impatto anche grave sulle prestazioni del database. Pertanto è importante verificarli prima di applicarli alla produzione. Vogliamo esaminare il tempo necessario per eseguire la modifica e verificare se la modifica può essere applicata sui nodi separatamente o se è necessario eseguire la modifica sull'intera topologia contemporaneamente. Questo ci dirà quale processo dovremmo usare per una determinata modifica dello schema.
Utilizzo di ClusterControl per migliorare l'automazione dei test di rilascio
ClusterControl viene fornito con una serie di funzionalità che possono essere utilizzate per aiutarti ad automatizzare i test di rilascio. Diamo un'occhiata a cosa offre. Per chiarire, le funzionalità che mostreremo sono disponibili in un paio di modi. Il modo più semplice è utilizzare l'interfaccia utente, ma non è necessario ciò che si desidera fare se si ha in mente l'automazione. Ci sono altri due modi per farlo:Command Line Interface a ClusterControl e API RPC. In entrambi i casi, i lavori possono essere attivati da script esterni, consentendo di collegarli ai processi CI/CD esistenti. Ti farà anche risparmiare un sacco di tempo, poiché la distribuzione del cluster può essere solo questione di eseguire un comando invece di configurarlo manualmente.
Distribuzione del cluster di test
In primo luogo, ClusterControl offre un'opzione per distribuire un nuovo cluster e fornirlo con i dati del database esistente. Questa funzionalità da sola consente di implementare facilmente il provisioning del server di staging.
Come puoi vedere, finché hai creato un backup, può creare un nuovo cluster ed eseguirne il provisioning utilizzando i dati del backup:
Come possiamo vedere, c'è un breve riassunto di ciò che accadrà. Se fai clic su Continua, prosegui ulteriormente.
Come passaggio successivo, dovresti definire la connettività SSH:deve essere attiva prima che ClusterControl sia in grado di distribuire i nodi.
Infine, devi scegliere (tra gli altri) il fornitore, la versione e i nomi host dei nodi che vuoi utilizzare nel cluster. Questo è tutto.
Il comando CLI che eseguirebbe la stessa cosa è simile al seguente:
s9s cluster --create --cluster-type=galera --nodes="10.0.0.156;10.0.0.157;10.0.0.158" --vendor=percona --cluster-name=PXC --provider-version=8.0 --os-user=root --os-key-file=/root/.ssh/id_rsa --backup-id=6Configurazione di ProxySQL per rispecchiare il traffico
Se abbiamo un cluster distribuito, potremmo voler inviare il traffico di produzione ad esso per verificare come il nuovo schema gestisce il traffico esistente. Un modo per farlo è usare ProxySQL.
Il processo è semplice. Innanzitutto, dovresti aggiungere i nodi a ProxySQL. Dovrebbero appartenere a un gruppo host separato che non è ancora in uso. Assicurati che l'utente del monitor ProxySQL possa accedervi.
Una volta fatto questo e aver configurato tutti (o alcuni) dei nodi nell'hostgroup, è possibile modificare le regole di query e definire il Mirror Hostgroup (è disponibile nelle opzioni avanzate). Se vuoi farlo per tutto il traffico, probabilmente vorrai modificare tutte le tue regole di query in questo modo. Se si desidera eseguire il mirroring solo delle query SELECT, è necessario modificare le regole di query appropriate. Al termine, il tuo cluster di staging dovrebbe iniziare a ricevere traffico di produzione.
Distribuzione del cluster come slave
Come discusso in precedenza, una soluzione alternativa sarebbe quella di creare un nuovo cluster che agirà come una replica della configurazione esistente. Con tale approccio possiamo far testare automaticamente tutte le scritture, utilizzando la replica. I SELECT possono essere testati utilizzando l'approccio descritto sopra, il mirroring tramite ProxySQL.
La distribuzione di un cluster slave è piuttosto semplice.
Scegli il lavoro Crea cluster slave.
Devi decidere come vuoi che la replica sia impostata. Puoi trasferire tutti i dati dal master ai nuovi nodi.
In alternativa, puoi utilizzare il backup esistente per eseguire il provisioning del nuovo cluster. Ciò contribuirà a ridurre il carico di lavoro sul nodo master:invece di trasferire tutti i dati, dovranno essere trasferite solo le transazioni eseguite tra il momento in cui è stato creato il backup e il momento in cui è stata impostata la replica.
Il resto è seguire la procedura guidata di distribuzione standard, definendo connettività SSH, versione, fornitore, host e così via. Una volta distribuito, vedrai il cluster nell'elenco.
Una soluzione alternativa all'interfaccia utente è eseguire questa operazione tramite RPC.
{
"command": "create_cluster",
"job_data": {
"cluster_name": "",
"cluster_type": "galera",
"company_id": null,
"config_template": "my.cnf.80-pxc",
"data_center": 0,
"datadir": "/var/lib/mysql",
"db_password": "pass",
"db_user": "root",
"disable_firewall": true,
"disable_selinux": true,
"enable_mysql_uninstall": true,
"generate_token": true,
"install_software": true,
"port": "3306",
"remote_cluster_id": 6,
"software_package": "",
"ssh_keyfile": "/root/.ssh/id_rsa",
"ssh_port": "22",
"ssh_user": "root",
"sudo_password": "",
"type": "mysql",
"user_id": 5,
"vendor": "percona",
"version": "8.0",
"nodes": [
{
"hostname": "10.0.0.155",
"hostname_data": "10.0.0.155",
"hostname_internal": "",
"port": "3306"
},
{
"hostname": "10.0.0.159",
"hostname_data": "10.0.0.159",
"hostname_internal": "",
"port": "3306"
},
{
"hostname": "10.0.0.160",
"hostname_data": "10.0.0.160",
"hostname_internal": "",
"port": "3306"
}
],
"with_tags": []
}
}Andare avanti
Se sei interessato a saperne di più sui modi in cui puoi integrare i tuoi processi con ClusterControl, vorremmo indirizzarti verso la documentazione, dove abbiamo un'intera sezione sullo sviluppo di soluzioni in cui ClusterControl gioca un ruolo ruolo significativo:
https://docs.severalnines.com/docs/clustercontrol/developer-guide/cmon-rpc/
https://docs.severalnines.com/docs/clustercontrol/user-guide-cli/
Ci auguriamo che tu abbia trovato questo breve blog informativo e utile. In caso di domande relative all'integrazione di ClusterControl nel tuo ambiente, contattaci e faremo del nostro meglio per aiutarti.
