Orchestrator per MySQL: perché non si può costruire un progetto ad alta disponibilità senza di lui

Qualsiasi progetto di grandi dimensioni inizia con un paio di server. Inizialmente c'era un server DB, poi sono stati aggiunti dei repliche per scalare la lettura. E qui — stop! C’è un solo master e molte repliche; se una delle repliche si guasta va bene, ma se si guasta il master — è un problema: downtime, gli amministratori si affannano a ripristinare il server. Cosa fare? Riservare il master. Il mio collega Pavel ne ha già parlato. articolo, non la ripeterò. Invece, vi dirò perché avete assolutamente bisogno di Orchestrator per MySQL!

Iniziamo con la domanda principale: «Come faremo a switchare il codice su una nuova macchina quando il master si guasta?».

• Mi piace di più lo schema con VIP (Virtual IP), di cui parleremo di seguito. È il più semplice e ovvio, anche se presenta un chiaro limite: il master che intendiamo riservare deve trovarsi nello stesso segmento L2 della nuova macchina, quindi possiamo dimenticare il secondo centro dati. D’altronde, se seguiamo la regola che un grande L2 è un male, perché l'L2 è solo su rack, mentre tra i rack c’è L3, e questo schema ha ancor più limitazioni.
• Possiamo inserire il nome DNS nel codice e risolverlo tramite /etc/hosts. In realtà non ci sarà una risoluzione. Il vantaggio di questo schema è che non ha il limite caratteristico del primo metodo, quindi possiamo anche organizzare cross-Datacenter. Ma allora sorge la domanda ovvia: quanto velocemente porteremo la modifica in /etc/hosts tramite Puppet-Ansible.
• Possiamo modificare un po' il secondo metodo: su tutti i server web possiamo installare un DNS caching, attraverso il quale il codice accederà al database master. Possiamo impostare un TTL di 60 per questa voce nel DNS. Sembra che, se implementato correttamente, sia un buon metodo.
• Schema con service discovery, che prevede l'uso di Consul e etcd.
• Un'opzione interessante con ProxySQL. Bisogna far passare tutto il traffico MySQL attraverso ProxySQL, che è in grado di determinare chi è attualmente il master. A proposito, su una delle modalità di utilizzo di questo prodotto è possibile leggere nel mio abbiamo chiarito il corretto completamento dei programmi che utilizzano il mediastreamer..

L'autore di Orchestrator, lavorando su Github, ha inizialmente implementato il primo schema con VIP, per poi cambiare a uno schema con consul.

Schema tipico dell'infrastruttura:

Descriverò subito le situazioni ovvie che devono essere considerate:

• L'indirizzo VIP non dovrebbe essere configurato in nessun file di configurazione su nessuno dei server. Immaginiamo la situazione: il master si è riavviato, e mentre si avvia, Orchestrator è passato alla modalità failover e ha fatto diventare master una delle repliche; poi è tornato in funzione il vecchio master, e ora il VIP è su due macchine. Questo è un problema.
• Per l'orchestratore sarà necessario scrivere uno script per interagire con il vecchio master e il nuovo master. Sul vecchio è necessario eseguire ifdown, mentre sul nuovo master — ifup vip. Sarebbe utile anche inserire in questo script che nel caso di failover la porta dello switch del vecchio master venga semplicemente spenta, per evitare qualsiasi split-brain.
• Dopo che l'Orchestratore ha chiamato il vostro script, per prima cosa per rimuovere il VIP e/o spegnere la porta dello switch, e poi ha chiamato il script per alzare il VIP sul nuovo master, non dimenticate di usare il comando arping per avvisare tutti che il nuovo VIP è ora qui.
• Tutti gli slave devono avere read_only=1 e non appena promuovete uno slave a master, deve diventare read_only=0.
• Non dimenticate che qualsiasi slave che abbiamo scelto può diventare master (l'Orchestratore ha un intero meccanismo di preferenza per decidere quale slave considerare come candidato a nuovo master in prima istanza, quale in seconda, e quale slave non deve mai essere scelto come master). Se uno slave diventa master, manterrà il carico dello slave e aggiungerà il carico del master, questo deve essere tenuto in considerazione.

Perché avete assolutamente bisogno dell'Orchestratore se non lo avete?

• L'Orchestratore ha un'interfaccia grafica molto comoda che mostra tutta la topologia (vedi screenshot qui sotto).
• L'Orchestratore può monitorare quali slave sono indietro e dove la replicazione si è interrotta del tutto (abbiamo script collegati all'Orchestratore per inviare SMS).
• L'Orchestratore ti dice su quali slave c'è un errore GTID errant.

Interfaccia dell'Orchestratore:

Cos'è GTID errant?

Ci sono due requisiti principali per il funzionamento dell'Orchestratore:

• È necessario che su tutte le macchine del cluster MySQL sia abilitato il pseudo GTID, noi abbiamo attivato GTID.
• È necessario che ci sia un solo tipo di binlog ovunque, si può usare statement. Avevamo una configurazione in cui sul master e sulla maggior parte degli slave era Row, mentre su due storicamente era rimasto il modo Mixed. Di conseguenza, questi slave l'Orchestratore non ha proprio voluto collegarli al nuovo master.

Ricorda che la cosa più importante in un production-slave è la sua coerenza con il master! Se sia sul master che sullo slave è abilitato il Global Transaction ID (GTID), allora attraverso la funzione gtid_subset puoi scoprire se davvero su queste macchine sono state eseguite le stesse query per modificare i dati. Puoi approfondire questo argomento. qui.

In questo modo, Orchestrator ti mostra tramite l'errore GTID errante che ci sono transazioni sullo slave che non sono presenti sul master. Perché succede questo?

• Lo slave non ha read_only=1 abilitato, qualcuno si è connesso ed ha eseguito una richiesta di modifica dei dati.
• Lo slave non ha super_read_only=1 abilitato, quindi un admin, confondendo il server, è entrato e ha eseguito una richiesta lì.
• Se hai considerato entrambi i punti precedenti, c'è un ulteriore trucco: in MySQL la richiesta di flush dei binlog finisce anch'essa nel binlog, quindi al primo flush sul master e su tutti gli slave apparirà GTID errante. Come evitarlo? Nella versione perona-5.7.25-28 è stata introdotta l'impostazione binlog_skip_flush_commands=1, che impedisce la scrittura di flush nei binlog. Sul sito mysql.com c'è documentata bug.

Riassumendo quanto detto. Se al momento non desideri utilizzare Orchestrator in modalità failover, impostalo in modalità monitoraggio. In questo modo avrai sempre sotto gli occhi una mappa delle interazioni tra le macchine MySQL e informazioni chiare sul tipo di replicazione su ciascuna macchina, se gli slave sono in ritardo e, soprattutto, quanto sono coerenti con il master!

Una domanda ovvia: «Come dovrebbe funzionare Orchestrator?». Dovrebbe selezionare un nuovo master tra gli attuali slave e poi ricollegare tutti gli slave a esso (questo è esattamente il motivo per cui è necessario il GTID; se si utilizzasse il vecchio meccanismo con binlog_name e binlog_pos, il passaggio dello slave dall'attuale master al nuovo sarebbe semplicemente impossibile!). Prima che avessimo Orchestrator, una volta mi è toccato fare tutto questo manualmente. Il vecchio master si bloccava a causa del controller Adaptec difettoso, e aveva circa 10 slave. Dovevo trasferire il VIP dal master a uno degli slave e ricollegare tutti gli altri slave a esse. Quante console ho dovuto aprire, quante comandi simultanei ho dovuto inserire… Ho dovuto aspettare fino alle 3 del mattino, ridurre il carico su tutti gli slave, tranne due, rendere la prima macchina delle due il master, connettere immediatamente la seconda macchina, quindi collegare tutti gli altri slave al nuovo master e ripristinare il carico. Insomma, un incubo…

Come funziona Orchestrator quando passa in modalità failover? È più facile mostrarlo con un esempio di situazione in cui vogliamo rendere master una macchina più potente e moderna di quella attuale.

L'immagine rappresenta la metà del processo. Cosa era già stato fatto fino a questo momento? Abbiamo detto che vogliamo rendere un qualche slave il nuovo master, Orchestrator ha iniziato semplicemente a riconnettere tutti gli altri slave a esso, mentre il nuovo master svolge il ruolo di macchina di transito. Con questo schema non si verificano errori, tutti gli slave funzionano, Orchestrator rimuove il VIP dal vecchio master, lo trasferisce al nuovo, imposta read_only=0 e dimentica il vecchio master. Tutto qui! Il downtime del nostro servizio è il tempo di trasferimento del VIP, che è di 2-3 secondi.

Tutto qui per oggi, grazie a tutti. Presto ci sarà un secondo articolo su Orchestrator. In un famoso film sovietico "Garage", un personaggio ha detto: "Non andrei con lui in missione di esplorazione!" Ecco, Orchestrator, io con te andrei in missione di esplorazione!

Fonte: habr.com