Nella prima parte della serie, ti abbiamo mostrato come distribuire una configurazione di replica MySQL con ProxySQL con WHM e cPanel. In questa parte illustreremo alcune operazioni post-distribuzione per la manutenzione, la gestione, il failover e i vantaggi rispetto alla configurazione standalone.
Gestione utenti MySQL
Con questa integrazione abilitata, la gestione degli utenti MySQL dovrà essere eseguita da WHM o cPanel. In caso contrario, la tabella mysql_users di ProxySQL non si sincronizzerebbe con ciò che è configurato per il nostro master di replica. Supponiamo di aver già creato un utente chiamato manyn_user1 (il nome utente MySQL è automaticamente preceduto da cPanel per rispettare le limitazioni di MySQL), e vorremmo assegnare al database diversin_db1 come di seguito:
Quanto sopra risulterà nel seguente output della tabella mysql_users in ProxySQL:
Se desideri creare risorse MySQL al di fuori di cPanel, puoi utilizzare ClusterControl -> Gestisci -> Schemi e utenti funzione e quindi importa l'utente del database in ProxySQL andando su ClusterControl -> Nodes -> seleziona il nodo ProxySQL -> Utenti -> Importa utenti .
Il modulo Proxysqlhook che utilizziamo per sincronizzare gli utenti ProxySQL invia i log di debug in /usr/local/cpanel/logs/error_log. Usa questo file per ispezionare e capire cosa succede dietro le quinte. Le seguenti righe apparirebbero nel file di registro di cPanel se avessimo installato un'applicazione Web chiamata Zikula utilizzando Softaculous:
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL database severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL virtual user severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [cpanel] **** Reading ProxySQL information: Host: 192.168.0.16, Port: 6032, User: proxysql-admin *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Inserting severaln_ziku703 into ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Updating severaln_ziku703 default schema in ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****Vedresti alcune righe ripetute come "Verifica se esiste {utente DB}" perché WHM crea più utenti/host MySQL per ogni richiesta utente di creazione del database. Nel nostro esempio, WHM creerebbe questi 3 utenti:
ProxySQL richiede solo il nome utente, la password e le informazioni sul gruppo host predefinito quando si aggiunge un utente. Pertanto, le linee di controllo sono lì per evitare inserimenti multipli dello stesso identico utente.
Se desideri modificare il modulo e apportare alcuni miglioramenti, non dimenticare di registrare nuovamente il modulo eseguendo il seguente comando sul server WHM:
(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHookMonitoraggio delle query e memorizzazione nella cache
Con ProxySQL è possibile monitorare tutte le query provenienti dall'applicazione che sono state passate o che la attraversano. Lo standard WHM non fornisce questo livello di dettaglio nel monitoraggio delle query MySQL. Quanto segue mostra tutte le query MySQL che sono state acquisite da ProxySQL:
Con ClusterControl, puoi facilmente cercare le query più ripetute e memorizzarle nella cache tramite la funzione di cache delle query ProxySQL. Utilizza il menu a discesa "Ordina per" per ordinare le query in base a "Count Star", passa alla query che desideri memorizzare nella cache e fai clic sul pulsante "Cache Query" sotto di essa. Apparirà la seguente finestra di dialogo:
Il set di risultati delle query memorizzate nella cache verrà archiviato e servito dallo stesso ProxySQL, riducendo il numero di accessi al back-end che scaricherà il cluster di replica MySQL nel suo insieme. L'implementazione della cache di query ProxySQL è fondamentalmente diversa dalla cache di query MySQL. È una cache basata sul tempo e scadrà dopo un timeout chiamato "Cache TTL". In questa configurazione, vorremmo memorizzare nella cache la query di cui sopra per 5 secondi (5000 ms) dal colpire il gruppo di lettori in cui il gruppo host di destinazione è 20.
Lettura/Scrittura suddivisione e bilanciamento
Ascoltando la porta predefinita di MySQL 3306, ProxySQL si comporta come il server MySQL stesso. Parla di protocolli MySQL sia sul frontend che sul backend. Le regole di query definite da ClusterControl durante l'impostazione di ProxySQL divideranno automaticamente tutte le letture (^SELECT .* in linguaggio Regex) nel gruppo host 20 che è il gruppo di lettori e il resto verrà inoltrato al gruppo host di scrittura 10, come mostrato nel seguente sezione delle regole di query:
Con questa architettura, non devi preoccuparti di dividere le query di lettura/scrittura poiché ProxySQL farà il lavoro per te. Gli utenti hanno modifiche minime o nulle al codice, consentendo agli utenti di hosting di utilizzare tutte le applicazioni e le funzionalità fornite da WHM e cPanel in modo nativo, in modo simile alla connessione a una configurazione MySQL autonoma.
In termini di bilanciamento delle connessioni, se hai più di un nodo attivo in un particolare hostgroup (come il reader hostgroup 20 in questo esempio), ProxySQL distribuirà automaticamente il carico tra di loro in base a una serie di criteri:pesi, ritardo di replica, connessioni utilizzate , carico e latenza complessivi. ProxySQL è noto per essere molto valido in ambienti ad alta concorrenza implementando un meccanismo avanzato di pool di connessioni. Citato dal post del blog di ProxySQL, ProxySQL non implementa solo la connessione persistente, ma anche il multiplexing della connessione. In effetti, ProxySQL può gestire centinaia di migliaia di client, ma inoltra tutto il loro traffico a poche connessioni al back-end. Quindi ProxySQL può gestire N connessioni client e M connessioni back-end, dove N> M (anche N migliaia di volte più grande di M).
Failover e ripristino di MySQL
Con ClusterControl che gestisce il cluster di replica, il failover viene eseguito automaticamente se è abilitato il ripristino automatico. In caso di guasto del master:
- ClusterControl rileverà e verificherà l'errore principale tramite client MySQL, SSH e ping.
- ClusterControl attende 3 secondi prima di avviare una procedura di failover.
- ClusterControl promuoverà lo slave più aggiornato per diventare il prossimo master.
- Se il vecchio master torna online, verrà avviato in sola lettura, senza partecipare alla replica attiva.
- Spetta agli utenti decidere cosa accadrà al vecchio maestro. Potrebbe essere reintrodotto nella catena di replica utilizzando la funzionalità "Rebuild Replication Slave" in ClusterControl.
- ClusterControl tenterà di eseguire il failover principale solo una volta. Se fallisce, è necessario l'intervento dell'utente.
Puoi monitorare l'intero processo di failover in ClusterControl -> Activity -> Jobs -> Failover to a new master come mostrato di seguito:
Durante il failover, tutte le connessioni ai server di database verranno accodate in ProxySQL. Non verranno interrotti fino al timeout, controllato da mysql-default_query_timeout variabile che è 86400000 millisecondi o 24 ore. Molto probabilmente le applicazioni non vedrebbero errori o errori nel database a questo punto, ma il compromesso è una maggiore latenza, entro una soglia configurabile.
A questo punto ClusterControl presenterà la topologia come di seguito:
Se desideriamo consentire al vecchio master di unirsi nuovamente alla replica dopo che è attivo e disponibile, dovremmo ricostruirlo come slave andando su ClusterControl -> Nodes -> scegli il vecchio master -> Ricostruisci replica Slave -> scegli il nuovo master -> Procedi . Una volta completata la ricostruzione, dovresti ottenere la seguente topologia (l'avviso 192.168.0.32 è ora il master):
Consolidamento del server e ridimensionamento del database
Con questa architettura, possiamo consolidare molti server MySQL che risiedono su ogni server WHM in un'unica configurazione di replica. Puoi ridimensionare più nodi di database man mano che cresci o disporre di più cluster di replica per supportarli tutti e gestiti da un unico server ClusterControl. Il diagramma dell'architettura seguente illustra se abbiamo due server WHM collegati a un singolo cluster di replica MySQL tramite file socket ProxySQL:
Quanto sopra ci consente di separare i due livelli più importanti nel nostro sistema di hosting:applicazione (front-end) e database (back-end). Come forse saprai, la co-localizzazione di MySQL nel server WHM provoca comunemente l'esaurimento delle risorse poiché MySQL ha bisogno di un'enorme allocazione di RAM anticipata per avviarsi e funzionare bene (principalmente a seconda di innodb_buffer_pool_size variabile). Considerando che lo spazio su disco è sufficiente, con la configurazione di cui sopra, puoi avere più account di hosting ospitati per server, dove tutte le risorse del server possono essere utilizzate dalle applicazioni di livello front-end.
Il ridimensionamento del cluster di replica MySQL sarà molto più semplice con un'architettura di livello separato. Se supponiamo che il master richieda una manutenzione su scale-up (aggiornamento di RAM, disco rigido, RAID, NIC), possiamo passare dal ruolo di master a un altro slave (ClusterControl -> Nodes -> pick a slave -> Promuovi slave ) e quindi eseguire l'attività di manutenzione senza influire sul servizio MySQL nel suo insieme. Per l'operazione di scalabilità orizzontale (aggiungendo più slave), è possibile eseguirla senza nemmeno influenzare il master eseguendo lo staging direttamente da qualsiasi slave attivo. Con ClusterControl, puoi persino organizzare un nuovo slave da un backup MySQL esistente (solo compatibile con PITR):
La ricostruzione di uno slave dal backup non comporterà oneri aggiuntivi per il master. ClusterControl copierà il file di backup selezionato dal server ClusterControl al nodo di destinazione ed eseguirà il ripristino lì. Una volta terminato, il nodo si connetterà al master e inizierà a recuperare tutte le transazioni mancanti dal tempo di ripristino e raggiungere il master. Quando è in ritardo, ProxySQL non includerà il nodo nel set di bilanciamento del carico fino a quando il ritardo di replica non sarà inferiore a 10 secondi (configurabile quando si aggiunge una tabella mysql_servers tramite l'interfaccia di amministrazione di ProxySQL).
Pensieri finali
ProxySQL estende le capacità di WHM cPanel nella gestione della replica MySQL. Con ClusterControl che gestisce il tuo cluster di replica, tutte le attività complesse coinvolte nella gestione del cluster di replica sono ora più semplici che mai.
