Nei nostri blog precedenti, abbiamo discusso di MHA come strumento di failover utilizzato nelle configurazioni master-slave di MySQL. Il mese scorso, abbiamo anche scritto sul blog come gestire l'MHA in caso di arresto anomalo. Oggi vedremo i problemi principali che i DBA di solito incontrano con MHA e come risolverli.
Una breve introduzione all'MHA (Master High Availability)
MHA sta per (Master High Availability) è ancora rilevante e ampiamente utilizzato oggi, specialmente nelle configurazioni master-slave basate sulla replica non GTID. MHA esegue bene un failover o un interruttore principale, ma presenta alcune insidie e limitazioni. Una volta che MHA esegue un failover master e una promozione slave, può completare automaticamente l'operazione di failover del database entro circa 30 secondi, il che può essere accettabile in un ambiente di produzione. MHA può garantire la coerenza dei dati. Tutto questo con un degrado delle prestazioni pari a zero e non richiede ulteriori adeguamenti o modifiche alle implementazioni o alle impostazioni esistenti. Oltre a questo, MHA è basato su Perl ed è una soluzione HA open source, quindi è relativamente facile creare helper o estendere lo strumento in base alla configurazione desiderata. Dai un'occhiata a questa presentazione per ulteriori informazioni.
Il software MHA è costituito da due componenti, è necessario installare uno dei seguenti pacchetti in base al ruolo della topologia:
Nodo gestore MHA =Gestore MHA (gestore)/Nodo MHA (nodo dati)
Nodi master/slave =nodo MHA (nodo dati)
MHA Manager è il software che gestisce il failover (automatico o manuale), prende decisioni su quando e dove eseguire il failover e gestisce il ripristino dello slave durante la promozione del master candidato per l'applicazione dei log di relè differenziali. Se il database master si interrompe, MHA Manager si coordinerà con l'agente del nodo MHA poiché applica i log di inoltro differenziali agli slave che non hanno gli ultimi eventi binlog dal master. Il software MHA Node è un agente locale che monitorerà l'istanza MySQL e consentirà a MHA Manager di copiare i log di inoltro dagli slave. Lo scenario tipico è che quando il master candidato per il failover è attualmente in ritardo e MHA rileva che non ha i log di inoltro più recenti. Quindi, attenderà il suo mandato da MHA Manager mentre cerca l'ultimo slave che contiene gli eventi binlog e copia gli eventi mancanti dallo slave usando scp e li applica a se stesso.
Si noti tuttavia che MHA non è attualmente mantenuto attivamente, ma la versione corrente stessa è stabile e potrebbe essere "abbastanza buona" per la produzione. Puoi ancora fare eco alla tua voce tramite github per risolvere alcuni problemi o fornire patch al software.
Principali problemi comuni
Ora diamo un'occhiata ai problemi più comuni che un DBA incontrerà durante l'utilizzo di MHA.
Lo slave è in ritardo, failover non interattivo/automatico non riuscito!
Questo è un problema tipico che causa l'interruzione o il fallimento del failover automatico. Potrebbe sembrare semplice ma non indica solo un problema specifico. Il ritardo dello slave può avere diversi motivi:
- Problemi del disco sul master candidato che causano l'I/O del disco vincolato all'elaborazione di lettura e scrittura. Può anche portare al danneggiamento dei dati se non viene mitigato.
- Le query errate vengono replicate, in particolare le tabelle che non hanno chiavi primarie o indici cluster.
- elevato carico del server.
- Il server freddo e il server non si sono ancora riscaldati
- Risorse del server insufficienti. È possibile che il tuo slave abbia una memoria insufficiente o le risorse del server durante la replica di scritture o letture ad alta intensità.
Questi possono essere mitigati in anticipo se si dispone di un monitoraggio adeguato del database. Un esempio per quanto riguarda gli slave lag in MHA è la memoria insufficiente durante il dump di un file di registro binario di grandi dimensioni. Come esempio di seguito, un master è stato contrassegnato come morto e deve eseguire un failover non interattivo/automatico. Tuttavia, poiché il master candidato era in ritardo e deve applicare i log che non sono stati ancora eseguiti dai thread di replica, MHA individuerà lo slave più aggiornato o più recente poiché tenterà di recuperare uno slave rispetto al più vecchio quelli. Quindi, come puoi vedere di seguito, mentre stava eseguendo un ripristino dello slave, la memoria era troppo bassa:
[email protected]:~$ masterha_manager --conf=/etc/app1.cnf --remove_dead_master_conf --ignore_last_failover
Mon May 6 08:43:46 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Mon May 6 08:43:46 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Mon May 6 08:43:46 2019 - [info] Reading server configuration from /etc/app1.cnf..
…
Mon May 6 08:43:57 2019 - [info] Checking master reachability via MySQL(double check)...
Mon May 6 08:43:57 2019 - [info] ok.
Mon May 6 08:43:57 2019 - [info] Alive Servers:
Mon May 6 08:43:57 2019 - [info] 192.168.10.50(192.168.10.50:3306)
Mon May 6 08:43:57 2019 - [info] 192.168.10.70(192.168.10.70:3306)
Mon May 6 08:43:57 2019 - [info] Alive Slaves:
Mon May 6 08:43:57 2019 - [info] 192.168.10.50(192.168.10.50:3306) Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May 6 08:43:57 2019 - [info] Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May 6 08:43:57 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Mon May 6 08:43:57 2019 - [info] 192.168.10.70(192.168.10.70:3306) Version=5.7.23-23-log (oldest major version between slaves) log-bin:enabled
Mon May 6 08:43:57 2019 - [info] Replicating from 192.168.10.60(192.168.10.60:3306)
Mon May 6 08:43:57 2019 - [info] Not candidate for the new Master (no_master is set)
Mon May 6 08:43:57 2019 - [info] Starting Non-GTID based failover.
….
Mon May 6 08:43:59 2019 - [info] * Phase 3.4: New Master Diff Log Generation Phase..
Mon May 6 08:43:59 2019 - [info]
Mon May 6 08:43:59 2019 - [info] Server 192.168.10.50 received relay logs up to: binlog.000004:106167341
Mon May 6 08:43:59 2019 - [info] Need to get diffs from the latest slave(192.168.10.70) up to: binlog.000005:240412 (using the latest slave's relay logs)
Mon May 6 08:43:59 2019 - [info] Connecting to the latest slave host 192.168.10.70, generating diff relay log files..
Mon May 6 08:43:59 2019 - [info] Executing command: apply_diff_relay_logs --command=generate_and_send --scp_user=vagrant --scp_host=192.168.10.50 --latest_mlf=binlog.000005 --latest_rmlp=240412 --target_mlf=binlog.000004 --target_rmlp=106167341 --server_id=3 --diff_file_readtolatest=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog --workdir=/tmp --timestamp=20190506084355 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --relay_dir=/var/lib/mysql --current_relay_log=relay-bin.000007
Mon May 6 08:44:00 2019 - [info]
Relay log found at /var/lib/mysql, up to relay-bin.000007
Fast relay log position search failed. Reading relay logs to find..
Reading relay-bin.000007
Binlog Checksum enabled
Master Version is 5.7.23-23-log
Binlog Checksum enabled
…
…...
Target relay log file/position found. start_file:relay-bin.000004, start_pos:106167468.
Concat binary/relay logs from relay-bin.000004 pos 106167468 to relay-bin.000007 EOF into /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506084355.binlog ..
Binlog Checksum enabled
Binlog Checksum enabled
Dumping binlog format description event, from position 0 to 361.. ok.
Dumping effective binlog data from /var/lib/mysql/relay-bin.000004 position 106167468 to tail(1074342689)..Out of memory!
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1090] Generating diff files failed with return code 1:0.
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May 6 08:44:00 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR: at /usr/local/bin/masterha_manager line 65.
Mon May 6 08:44:00 2019 - [info]
----- Failover Report -----
app1: MySQL Master failover 192.168.10.60(192.168.10.60:3306)
Master 192.168.10.60(192.168.10.60:3306) is down!
Check MHA Manager logs at testnode20 for details.
Started automated(non-interactive) failover.
Invalidated master IP address on 192.168.10.60(192.168.10.60:3306)
The latest slave 192.168.10.70(192.168.10.70:3306) has all relay logs for recovery.
Selected 192.168.10.50(192.168.10.50:3306) as a new master.
Recovering master server failed.
Got Error so couldn't continue failover from here.Pertanto, il failover non è riuscito. Questo esempio sopra mostra che il nodo 192.168.10.70 contiene i log di inoltro più aggiornati. Tuttavia, in questo scenario di esempio, il nodo 192.168.10.70 è impostato come no_master perché ha una memoria insufficiente. Mentre tenta di recuperare lo slave 192.168.10.50, fallisce!
Correzioni/Risoluzione:
Questo scenario illustra qualcosa di molto importante. È necessario configurare un ambiente di monitoraggio avanzato! Ad esempio, puoi eseguire uno script in background o daemon che monitora l'integrità della replica. Puoi aggiungere come voce tramite un lavoro cron. Ad esempio, aggiungi una voce utilizzando lo script integrato masterha_check_repl :
/usr/local/bin/masterha_check_repl --conf=/etc/app1.cnfoppure creare uno script in background che richiami questo script e lo esegua in un intervallo. Puoi utilizzare l'opzione report_script per impostare una notifica di avviso nel caso in cui non sia conforme ai tuoi requisiti, ad esempio, lo slave è in ritardo di circa 100 secondi durante un carico di picco elevato. Puoi anche utilizzare piattaforme di monitoraggio come ClusterControl configurandolo per inviarti notifiche in base alle metriche che desideri monitorare.
Inoltre, tenere presente che, nello scenario di esempio, il failover non è riuscito a causa di un errore di memoria insufficiente. Potresti considerare di garantire che tutti i tuoi nodi dispongano di memoria sufficiente e la giusta dimensione dei log binari in quanto avrebbero bisogno di scaricare il binlog per una fase di ripristino dello slave.
Slave incoerente, applicazione delle differenze non riuscita!
Per quanto riguarda lo slave lag, poiché MHA proverà a sincronizzare i log di inoltro con un master candidato, assicurati che i tuoi dati siano sincronizzati. Dì per un esempio di seguito:
...
Concat succeeded.
Generating diff relay log succeeded. Saved at /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog .
scp testnode7:/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog to [email protected](22) succeeded.
Mon May 6 05:43:53 2019 - [info] Generating diff files succeeded.
Mon May 6 05:43:53 2019 - [info]
Mon May 6 05:43:53 2019 - [info] * Phase 3.5: Master Log Apply Phase..
Mon May 6 05:43:53 2019 - [info]
Mon May 6 05:43:53 2019 - [info] *NOTICE: If any error happens from this phase, manual recovery is needed.
Mon May 6 05:43:53 2019 - [info] Starting recovery on 192.168.10.50(192.168.10.50:3306)..
Mon May 6 05:43:53 2019 - [info] Generating diffs succeeded.
Mon May 6 05:43:53 2019 - [info] Waiting until all relay logs are applied.
Mon May 6 05:43:53 2019 - [info] done.
Mon May 6 05:43:53 2019 - [info] Getting slave status..
Mon May 6 05:43:53 2019 - [info] This slave(192.168.10.50)'s Exec_Master_Log_Pos equals to Read_Master_Log_Pos(binlog.000010:161813650). No need to recover from Exec_Master_Log_Pos.
Mon May 6 05:43:53 2019 - [info] Connecting to the target slave host 192.168.10.50, running recover script..
Mon May 6 05:43:53 2019 - [info] Executing command: apply_diff_relay_logs --command=apply --slave_user='cmon' --slave_host=192.168.10.50 --slave_ip=192.168.10.50 --slave_port=3306 --apply_files=/tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog --workdir=/tmp --target_version=5.7.23-23-log --timestamp=20190506054328 --handle_raw_binlog=1 --disable_log_bin=0 --manager_version=0.58 --slave_pass=xxx
Mon May 6 05:43:53 2019 - [info]
MySQL client version is 5.7.23. Using --binary-mode.
Applying differential binary/relay log files /tmp/relay_from_read_to_latest_192.168.10.50_3306_20190506054328.binlog on 192.168.10.50:3306. This may take long time...
mysqlbinlog: Error writing file 'UNOPENED' (Errcode: 32 - Broken pipe)
FATAL: applying log files failed with rc 1:0!
Error logs from testnode5:/tmp/relay_log_apply_for_192.168.10.50_3306_20190506054328_err.log (the last 200 lines)..
ICwgMmM5MmEwZjkzY2M5MTU3YzAxM2NkZTk4ZGQ1ODM0NDEgLCAyYzkyYTBmOTNjYzkxNTdjMDEz
….
…..
M2QxMzc5OWE1NTExOTggLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDc3NDIzNCAsIDJjOTJh
MGY5M2NmYjVhN2EwMTNkMTY3OGI0N2Q0MjMERROR 1062 (23000) at line 72: Duplicate entry '12583545' for key 'PRIMARY'
5ICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNjc4YjQ4
OTQyM2QgLCAyYzkyYTBmOTNjZmI1YTdhMDEzZDE2NzhiNDkxNDI1MSAsIDJjOTJhMGY5M2NmYjVh
N2EwMTNkMTczN2MzOWM3MDEzICwgMmM5MmEwZjkzY2ZiNWE3YTAxM2QxNzM3YzNhMzcwMTUgLCAy
…
--------------
Bye
at /usr/local/bin/apply_diff_relay_logs line 554.
eval {...} called at /usr/local/bin/apply_diff_relay_logs line 514
main::main() called at /usr/local/bin/apply_diff_relay_logs line 121
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1399] Applying diffs failed with return code 22:0.
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/MasterFailover.pm, ln1584] Recovering master server failed.
Mon May 6 05:43:53 2019 - [error][/usr/local/share/perl/5.26.1/MHA/ManagerUtil.pm, ln178] Got ERROR: at /usr/local/bin/masterha_manager line 65.
Mon May 6 05:43:53 2019 - [info]Un cluster incoerente è davvero dannoso soprattutto quando è abilitato il failover automatico. In questo caso, il failover non può procedere poiché rileva una voce duplicata per la chiave primaria "12583545 '.
Correzioni/Risoluzione:
Ci sono più cose che puoi fare qui per evitare uno stato incoerente del tuo cluster.
- Abilita la replica semisincrona senza perdita di dati. Dai un'occhiata a questo blog esterno che è un buon modo per scoprire perché dovresti considerare l'utilizzo della semi-sincronizzazione in una configurazione di replica MySQL standard.
- Esegui costantemente un checksum sul tuo cluster master-slave. Puoi utilizzare pt-table-checksum ed eseguirlo come una volta alla settimana o al mese a seconda della frequenza con cui viene aggiornata la tabella. Tieni presente che pt-table-checksum può aggiungere un sovraccarico al traffico del tuo database.
- Utilizza la replica basata su GTID. Anche se questo non influirà sul problema di per sé. Tuttavia, la replica basata su GTID consente di determinare le transazioni errate, in particolare quelle che sono state eseguite direttamente sullo slave. Un altro vantaggio di questo, è più facile gestire la replica basata su GTID quando è necessario cambiare host master nella replica.
Guasto hardware sul master ma gli schiavi non hanno ancora recuperato
Uno dei tanti motivi per cui investire nel failover automatico è un guasto hardware sul master. Per alcune configurazioni, potrebbe essere più ideale eseguire il failover automatico solo quando il master riscontra un errore hardware. L'approccio tipico è avvisare inviando un allarme, il che potrebbe significare svegliare l'operatore di guardia nel cuore della notte per lasciare che sia la persona a decidere cosa fare. Questo tipo di approccio viene eseguito su Github o anche su Facebook. Un guasto hardware, soprattutto se il volume in cui risiedono i binlog e la directory dei dati è interessato, può rovinare il failover soprattutto se i log binari sono archiviati su quel disco guasto. In base alla progettazione, MHA proverà a salvare i registri binari dal master in crash, ma ciò non sarà possibile se il disco si guasta. Uno scenario possibile è che il server non sia raggiungibile tramite SSH. MHA non può salvare i log binari e deve eseguire il failover senza applicare eventi di log binari che esistono solo sul master in crash. Ciò comporterà la perdita dei dati più recenti, soprattutto se nessuno slave ha raggiunto il master.
Correzioni/Risoluzione
Trattandosi di uno dei casi d'uso di MHA, si consiglia di utilizzare la replica semisincrona in quanto riduce notevolmente il rischio di tale perdita di dati. È importante notare che tutte le scritture che vanno al master devono garantire che gli slave abbiano ricevuto gli ultimi eventi di log binari prima della sincronizzazione su disco. MHA può applicare gli eventi a tutti gli altri slave in modo che possano essere coerenti tra loro.
Inoltre, è anche meglio eseguire un flusso di backup dei registri binari per il ripristino di emergenza nel caso in cui il volume del disco principale si sia guastato. Se il server è ancora accessibile tramite SSH, il puntamento del percorso del log binario al percorso di backup del log binario può ancora funzionare, quindi il failover e il ripristino dello slave possono ancora andare avanti. In questo modo puoi evitare la perdita di dati.
Failover VIP (IP virtuale) che causa il cervello diviso
MHA, per impostazione predefinita, non gestisce alcuna gestione VIP. Tuttavia, è facile incorporarlo nella configurazione di MHA e assegnare hook in base a ciò che si desidera che MHA esegua durante il failover. Puoi impostare il tuo script e collegarlo ai parametri master_ip_failover_script o master_ip_online_change_script. Esistono anche script di esempio che si trovano nella directory
Durante un failover automatico, una volta che lo script con la gestione VIP è stato richiamato ed eseguito, MHA eseguirà le seguenti operazioni:verifica lo stato, rimuove (o interrompe) il vecchio VIP, quindi riassegna il nuovo VIP al nuovo master. Un tipico esempio di split brain è quando un master viene identificato come morto a causa di un problema di rete ma in realtà i nodi slave sono ancora in grado di connettersi al master. Questo è un falso positivo e spesso porta a incoerenze dei dati tra i database nell'installazione. Le connessioni client in entrata che utilizzano il VIP verranno inviate al nuovo master. Mentre d'altra parte, possono esserci connessioni locali in esecuzione sul vecchio master, che dovrebbe essere morto. Le connessioni locali potrebbero utilizzare il socket unix o localhost per ridurre i salti di rete. Ciò può causare la deriva dei dati rispetto al nuovo master e al resto dei suoi slave, poiché i dati del vecchio master non verranno replicati negli slave.
Correzioni/Risoluzione:
Come affermato in precedenza, alcuni potrebbero preferire evitare il failover automatico a meno che i controlli non abbiano stabilito che il master è completamente inattivo (come un guasto hardware), ovvero anche i nodi slave non sono in grado di raggiungerlo. L'idea è che un falso positivo potrebbe essere causato da un problema tecnico di rete tra il controller del nodo MHA e il master, quindi in questo caso un essere umano potrebbe essere più adatto a decidere se eseguire il failover o meno.
Quando si tratta di falsi allarmi, MHA ha un parametro chiamato secondary_check_script. Il valore inserito qui può essere i tuoi script personalizzati oppure puoi utilizzare lo script integrato /usr/local/bin/masterha_secondary_check che viene spedito insieme al pacchetto MHA Manager. Questo aggiunge ulteriori controlli che è in realtà l'approccio consigliato per evitare falsi positivi. Nell'esempio seguente dalla mia configurazione, sto usando lo script integrato masterha_secondary_check :
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.10.50 --user=root --master_host=testnode6 --master_ip=192.168.10.60 --master_port=3306Nell'esempio sopra, MHA Manager eseguirà un ciclo basato sull'elenco dei nodi slave (specificati dall'argomento -s) che verificherà la connessione con l'host MySQL master (192.168.10.60). Tieni presente che questi nodi slave nell'esempio possono essere alcuni nodi remoti esterni che possono stabilire una connessione ai nodi del database all'interno del cluster. Questo è un approccio consigliato soprattutto per quelle configurazioni in cui MHA Manager è in esecuzione su un data center o una rete diversa rispetto ai nodi del database. La seguente sequenza illustra come si procede con i controlli:
- Dall'host MHA -> controlla la connessione TCP al 1° nodo slave (IP:192.168.10.50). Chiamiamo questa connessione A. Quindi dal nodo slave, controlla la connessione TCP al nodo master (192.168.10.60). Chiamiamo questo Collegamento B.
Se "Connessione A" ha avuto successo ma "Connessione B" non è riuscita in entrambi i percorsi, masterha_secondary_check lo script esce con il codice di ritorno 0 e MHA Manager decide che il master MySQL è davvero morto e avvierà il failover. Se "Connessione A" non è riuscita, masterha_secondary_check esce con il codice di ritorno 2 e MHA Manager suppone che si sia verificato un problema di rete e non avvia il failover. Se "Connessione B" ha avuto successo, masterha_secondary_check esce con il codice di ritorno 3 e MHA Manager comprende che il server master MySQL è effettivamente attivo e non avvia il failover.
Un esempio di come reagisce durante il failover in base al log,
Tue May 7 05:31:57 2019 - [info] OK.
Tue May 7 05:31:57 2019 - [warning] shutdown_script is not defined.
Tue May 7 05:31:57 2019 - [info] Set master ping interval 1 seconds.
Tue May 7 05:31:57 2019 - [info] Set secondary check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306
Tue May 7 05:31:57 2019 - [info] Starting ping health check on 192.168.10.60(192.168.10.60:3306)..
Tue May 7 05:31:58 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:31:58 2019 - [warning] Connection failed 1 time(s)..
Tue May 7 05:31:58 2019 - [info] Executing SSH check script: exit 0
Tue May 7 05:31:58 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --user=vagrant --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Master is reachable from 192.168.10.50!
Tue May 7 05:31:58 2019 - [warning] Master is reachable from at least one of other monitoring servers. Failover should not happen.
Tue May 7 05:31:59 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:31:59 2019 - [warning] Connection failed 2 time(s)..
Tue May 7 05:32:00 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:00 2019 - [warning] Connection failed 3 time(s)..
Tue May 7 05:32:01 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:01 2019 - [warning] Connection failed 4 time(s)..
Tue May 7 05:32:03 2019 - [warning] HealthCheck: Got timeout on checking SSH connection to 192.168.10.60! at /usr/local/share/perl/5.26.1/MHA/HealthCheck.pm line 343.
Tue May 7 05:32:03 2019 - [warning] Secondary network check script returned errors. Failover should not start so checking server status again. Check network settings for details.
Tue May 7 05:32:04 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.10.60' (110))
Tue May 7 05:32:04 2019 - [warning] Connection failed 1 time(s)..
Tue May 7 05:32:04 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 192.168.10.50 -s 192.168.10.60 -s 192.168.10.70 --user=root --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --user=vagrant --master_host=192.168.10.60 --master_ip=192.168.10.60 --master_port=3306 --master_user=cmon [email protected] --ping_type=SELECT
Tue May 7 05:32:04 2019 - [info] Executing SSH check script: exit 0Un'altra cosa da aggiungere è assegnare un valore al parametro shutdown_script. Questo script è particolarmente utile se devi implementare una corretta STONITH o una recinzione dei nodi in modo che non resuscita dai morti. Ciò può evitare l'incoerenza dei dati.
Infine, assicurati che MHA Manager risieda all'interno della stessa rete locale insieme ai nodi del cluster in quanto riduce la possibilità di interruzioni della rete, in particolare la connessione da MHA Manager ai nodi del database.
Evitare SPOF in MHA
MHA può arrestarsi in modo anomalo per vari motivi e, sfortunatamente, non esiste una funzionalità integrata per risolvere questo problema, ad esempio l'elevata disponibilità per MHA. Tuttavia, come abbiamo discusso nel nostro blog precedente "Master High Availability Manager (MHA) si è arrestato in modo anomalo! Cosa faccio adesso?", c'è un modo per evitare SPOF per MHA.
Correzioni/Risoluzione:
È possibile sfruttare Pacemaker per creare nodi attivi/in standby gestiti da Cluster Resource Manager (crm). In alternativa, puoi creare uno script per controllare lo stato del nodo gestore MHA. Ad esempio, puoi eseguire il provisioning di un nodo stand-by che controlla attivamente il nodo manager MHA eseguendo ssh'ing per eseguire lo script integrato masterha_check_status proprio come di seguito:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf
app1 is stopped(2:NOT_RUNNING).quindi esegui un fencing dei nodi se quel controller è bloccato. Puoi anche estendere lo strumento MHA con uno script di supporto che viene eseguito tramite cron job e monitora il processo di sistema dello script masterha_manager e lo rigenera se il processo è morto.
Perdita di dati durante il failover
MHA si basa sulla tradizionale replica asincrona. Sebbene supporti la semisincronizzazione, la semisincronizzazione si basa comunque sulla replica asincrona. In questo tipo di ambiente, può verificarsi una perdita di dati dopo un failover. Quando il database non è configurato correttamente e utilizza un approccio di replica vecchio stile, può essere un problema, soprattutto quando si ha a che fare con la coerenza dei dati e le transazioni perse.
Un'altra cosa importante da notare con la perdita di dati con MHA, è quando GTID viene utilizzato senza la semi-sincronizzazione abilitata. MHA con GTID non si connetterà tramite ssh al master ma proverà a sincronizzare prima i log binari per il ripristino del nodo con gli slave. Ciò potrebbe potenzialmente comportare una maggiore perdita di dati rispetto a MHA non GTID con semi-sincronizzazione non abilitata.
Correzioni/Risoluzione
Quando si esegue il failover automatico, creare un elenco di scenari in cui si prevede il failover dell'MHA. Poiché MHA si occupa della replica master-slave, i nostri consigli per evitare la perdita di dati sono i seguenti:
- Abilita la replica semi-sincronizzazione lossless (esiste nella versione MySQL 5.7)
- Utilizza la replica basata su GTID. Ovviamente puoi usare la replica tradizionale usando le coordinate x e y di binlog. Tuttavia, rende le cose più difficili e dispendiose in termini di tempo quando è necessario individuare una voce di registro binaria specifica che non è stata applicata allo slave. Quindi, con GTID in MySQL, è più facile rilevare le transazioni errate.
- Per la conformità ACID della replica master-slave MySQL, abilita queste variabili specifiche:sync_binlog =1, innodb_flush_log_at_trx_commit =1. Questo è costoso in quanto richiede più potenza di elaborazione quando MySQL chiama la funzione fsync() quando esegue il commit e prestazioni può essere legato al disco in caso di numero elevato di scritture. Tuttavia, l'utilizzo di RAID con la cache di backup della batteria consente di salvare l'I/O del disco. Inoltre, MySQL stesso è migliorato con il commit del gruppo di log binari, ma l'utilizzo ancora di una cache di backup può salvare alcune sincronizzazioni del disco.
- Sfrutta la replica parallela o la replica slave multi-thread. Questo può aiutare i tuoi schiavi a diventare più performanti ed evita i ritardi degli schiavi contro il padrone. Non vuoi che il tuo failover automatico si verifichi quando il master non è affatto raggiungibile tramite la connessione ssh o TCP, o se ha riscontrato un errore del disco e i tuoi slave sono in ritardo. Ciò potrebbe portare alla perdita di dati.
- Quando si esegue un failover online o manuale, è meglio eseguirlo durante i periodi non di punta per evitare incidenti imprevisti che potrebbero portare alla perdita di dati. O per evitare che le ricerche dispendiose in termini di tempo si insinuano nei log binari mentre sono in corso molte attività.
MHA afferma che l'APP non è in esecuzione o il failover non funziona. Cosa devo fare?
L'esecuzione dei controlli utilizzando lo script integrato masterha_check_status verificherà se lo script mastreha_manager è in esecuzione. In caso contrario, riceverai un errore come di seguito:
[email protected]:~$ /usr/local/bin/masterha_check_status --conf=/etc/app1.cnf app1 is stopped(2:NOT_RUNNING).Tuttavia, ci sono alcuni casi in cui potresti ottenere NOT_RUNNING anche quando masterha_manager è in esecuzione. Ciò può essere dovuto al privilegio di ssh_user che hai impostato, oppure esegui masterha_manager con un utente di sistema diverso o l'utente ssh ha riscontrato un'autorizzazione negata.
Correzioni/Risoluzione:
MHA utilizzerà ssh_user definito nella configurazione se specificato. In caso contrario, utilizzerà l'utente di sistema corrente utilizzato per richiamare i comandi MHA. Quando si esegue lo script masterha_check_status ad esempio, devi assicurarti che masterha_manager venga eseguito con lo stesso utente specificato in ssh_user nel file di configurazione o l'utente che si interfaccerà con gli altri nodi del database nel cluster. Devi assicurarti che disponga di chiavi SSH senza password e senza passphrase in modo che MHA non abbia problemi quando si stabilisce la connessione ai nodi che MHA sta monitorando.
Tieni presente che hai bisogno di ssh_user per avere accesso a quanto segue:
- Può leggere i log binari e di inoltro dei nodi MySQL monitorati da MHA
- Deve avere accesso ai log di monitoraggio MHA. Dai un'occhiata a questi parametri in MHA:master_binlog_dir, manager_workdir e manager_log
- Deve avere accesso al file di configurazione MHA. Anche questo è molto importante. Durante un failover, una volta terminato il failover, tenterà di aggiornare il file di configurazione e rimuovere la voce del dead master. Se il file di configurazione non consente ssh_user o l'utente del sistema operativo che stai attualmente utilizzando, non aggiornerà il file di configurazione, portando a un'escalation del problema se il disastro si verifica di nuovo.
Candidate Master Lag, come forzare ed evitare il failover non riuscito
In riferimento al wiki di MHA, per impostazione predefinita, se uno slave ha dietro al master più di 100 MB di log di inoltro (=deve applicare più di 100 MB di log di inoltro), MHA non sceglie lo slave come nuovo master perché impiega troppo tempo per il ripristino .
Correzioni/Risoluzione
In MHA, questo può essere ignorato impostando il parametro check_repl_delay=0. Durante un failover, MHA ignora il ritardo di replica quando seleziona un nuovo master ed eseguirà le transazioni mancanti. Questa opzione è utile quando imposti candidate_master=1 su un host specifico e vuoi assicurarti che l'host possa essere un nuovo master.
Puoi anche integrare con pt-heartbeat per ottenere la precisione dello slave lag (vedi questo post e questo). Ma questo può anche essere alleviato con la replica parallela o gli slave di replica multi-thread, presenti da MySQL 5.6 o, con MariaDB 10, che affermano di avere un miglioramento con un miglioramento di 10 volte nella replica parallela e slave multi-thread. Questo può aiutare i tuoi schiavi a replicarsi più velocemente.
Le password MHA vengono scoperte
La protezione o la crittografia delle password non è qualcosa che viene gestito da MHA. The parameters password or repl_password will be exposed via the configuration file. So your system administrator or security architect must evaluate the grants or privileges of this file as you don’t want to expose valuable database/SSH credentials.
Fixes/Resolution:
MHA has an optional parameter init_conf_load_script. This parameter can be used to have a custom script load your MHA config that will interface to e.g. a database, and retrieve the user/password credentials of your replication setup.
Of course, you can also limit the file attribute of the configuration and the user you are using, and limit the access to the specific Ops/DBA's/Engineers that will handle MHA.
MHA is Not My Choice, What Are the Alternatives for replication failover?
MHA is not a one-size-fits-all solution, it has its limitations and may not fit your desired setup. However, here's a list of variants that you can try.
- PRM
- Maxscale with Mariadb Monitor or MariaDB Replication Manager (MRM)
- Orchestrator
- ClusterControl
