ProxySQL è un bilanciatore di carico dedicato per MySQL che viene fornito con una varietà di funzionalità tra cui, a titolo esemplificativo, reindirizzamento delle query, memorizzazione nella cache delle query o modellazione del traffico. Può essere utilizzato per impostare facilmente una suddivisione in lettura-scrittura e reindirizzare le query a nodi back-end separati. Di conseguenza, fornisce molti motivi convincenti per l'uso. D'altra parte, HAProxy è un ottimo sistema di bilanciamento del carico ma non è dedicato ai database e, sebbene possa essere utilizzato, non può essere confrontato in termini di funzionalità con ProxySQL. Questo potrebbe essere il motivo per cui gli ambienti che fanno ancora affidamento su HAProxy tentano di migrare a ProxySQL.
In questo breve post sul blog condivideremo un paio di suggerimenti sul processo di migrazione.
Pianificazione del tuo upgrade
Questo è abbastanza ovvio e dovrebbe essere ovvio, ma vorremmo comunque averlo per iscritto. Pianifica il tuo aggiornamento. Assicurati di avere familiarità con il processo, di aver testato tutto in modo approfondito. Configura un ambiente di test in cui puoi verificare diversi approcci all'aggiornamento e decidere quale funzionerebbe meglio per te.
Testa la suddivisione in lettura/scrittura in ProxySQL se ne consideri l'utilizzo
A seconda delle tue esigenze, potresti prendere in considerazione l'utilizzo della suddivisione in lettura/scrittura in ProxySQL. Questo è, probabilmente, uno dei motivi più convincenti per l'aggiornamento. Invece di implementarlo sul lato dell'applicazione (o non implementarlo affatto se non è possibile eseguirlo nell'applicazione), puoi fare affidamento su ProxySQL per eseguire la divisione di lettura/scrittura per te. L'installazione è molto semplice, soprattutto se si distribuisce ProxySQL utilizzando ClusterControl:avviene praticamente automaticamente.
Finché non si utilizzano transazioni implicite, ClusterControl imposterà il lettura/scrittura suddivisa per te utilizzando una serie di regole di query:
Anche se è molto semplice implementare la suddivisione in lettura/scrittura, dovresti fai attenzione quando prevedi di farlo. Le applicazioni possono fare affidamento su alcune funzionalità che in realtà non funzionano immediatamente in ProxySQL. Nella maggior parte dei casi, una configurazione aggiuntiva ti consentirà di beneficiare di questa funzionalità, ma è molto importante durante la fase di test per identificare se la tua app funzionerà o se è necessario aggiungere una configurazione personalizzata. Le parti particolarmente complicate sono i problemi di lettura dopo scrittura:in tal caso potrebbe essere necessario riconfigurare ProxySQL per disabilitare il multiplexing della connessione per alcune query.
Dimentica il file di configurazione in ProxySQL
Questa è una delle cose che sorprende i nuovi utenti di ProxySQL. Non utilizza realmente i file di configurazione. Ce n'è uno, sì, ma funziona praticamente come un modo per avviare ProxySQL durante il primo avvio. ProxySQL utilizza un database SQLite che ne contiene la configurazione e il modo corretto di apportare eventuali modifiche alla configurazione è tramite un client MySQL connesso alla porta amministrativa di ProxySQL. Da lì puoi apportare le modifiche alla configurazione in runtime, praticamente senza dover riavviare ProxySQL.
Ovviamente, ClusterControl UI consente anche di riconfigurare ProxySQL:
Modelli di distribuzione proxySQL
Ci sono due modi principali in cui vuoi distribuire ProxySQL. Puoi utilizzare un server dedicato per distribuire ProxySQL su:
Oppure puoi collocare ProxySQL con i server delle applicazioni:
Ciò consente all'applicazione di connettersi all'istanza ProxySQL locale utilizzando il socket Unix, che è migliore in termini di prestazioni rispetto all'utilizzo di una connessione TCP remota. Semplifica inoltre la configurazione:non è necessario implementare Keepalived o qualche altro provider di IP virtuale per bilanciare il carico tra le istanze ProxySQL. L'applicazione si connette solo al ProxySQL locale e basta.
Utilizzare i cluster ProxySQL per distribuzioni più grandi
Assicurarsi che le istanze ProxySQL contengano sempre la stessa configurazione potrebbe essere difficile, soprattutto se il loro numero è elevato. Esistono numerosi modi per affrontare tali sfide:Ansible/Chef/Puppet, script di shell e così via. Suggeriamo di fare affidamento sulla soluzione integrata - ProxySQL Cluster. Con solo un paio di modifiche alla configurazione puoi configurare i nodi ProxySQL in modo da formare un cluster in cui una modifica alla configurazione su uno dei nodi verrà propagata a tutti i membri del cluster.
Armeggiare con SO_REUSEPORT per la commutazione graziosa del bilanciamento del carico
Una delle parti più impegnative potrebbe consistere nell'assicurarsi di passare il traffico da HAProxy a ProxySQL in modo da ridurre al minimo l'impatto sull'applicazione. In genere dovresti modificare almeno un'impostazione:nome host o porta a cui l'applicazione deve connettersi. A seconda dell'ambiente, questo potrebbe non essere l'ideale, soprattutto se la configurazione della connettività del database è integrata nell'applicazione. Praticamente, richiederebbe di apportare una modifica alla base di codice e di inviare un nuovo codice alla produzione. Non è il più grande degli affari, ma puoi fare di meglio.
La parte interessante è che sia ProxySQL che le versioni recenti di HAProxy (a partire dalla 1.8) sono in grado di utilizzare SO_REUSEPORT. Questa opzione socket è disponibile in Linux a partire dal kernel 3.9 e consente a più processi di condividere la stessa porta. ProxySQL può usarlo per aggiornamenti graziosi tra versioni ProxySQL, HAProxy lo utilizza per ricaricare la configurazione senza alcun impatto sull'applicazione. La cosa interessante è che è possibile configurare ProxySQL per condividere la porta con HAProxy per la migrazione senza interruzioni tra questi due bilanciatori di carico.
Ci sono un paio di cose che devi considerare quando tenti di farlo:in primo luogo, ProxySQL non usa questa opzione per impostazione predefinita, devi aggiungere -r flag a ProxySQL all'avvio. Puoi farlo modificando il file dell'unità di sistema ProxySQL:
[email protected]:~# systemctl edit proxysql --fulle modifica della direttiva ExecStart in:
ExecStart=/usr/bin/proxysql -c /etc/proxysql.cnf -rUn'altra limitazione di cui dovresti essere a conoscenza in Linux è che solo i processi avviati dallo stesso ID utente possono condividere la porta. Ciò significa che dovrai riconfigurare ProxySQL per essere eseguito come utente "haproxy".
Come al solito, potresti voler eseguire dei test prima di tentare di eseguire questa operazione in un ambiente di produzione. È sicuramente possibile realizzare questa impresa, ma dovresti prestare attenzione e ricontrollare che non influirà sulla tua produzione a causa di una sorta di configurazione non standard relativa al tuo ambiente.
Ci auguriamo che questo breve blog ti fornisca informazioni sul processo di migrazione da HAProxy a ProxySQL. Per i backend del database questa modifica sarà molto vantaggiosa, anche se la parte di preparazione potrebbe richiedere molto tempo. Se esegui un test adeguato, la migrazione finale dovrebbe essere abbastanza semplice e sicura.
