Orchestrator per MySQL: perché non è possibile creare un progetto tollerante agli errori senza di esso

Qualsiasi progetto di grandi dimensioni inizia con un paio di server. All'inizio c'era un server DB, poi gli sono stati aggiunti degli slave per scalare la lettura. E poi - fermati! C'è un padrone, ma ci sono molti schiavi; se uno degli schiavi se ne va, allora andrà tutto bene, ma se il master se ne va, andrà male: tempi di inattività, gli amministratori stanno cercando di rilanciare il server. Cosa fare? Prenota un maestro. Il mio collega Pavel ne ha già scritto Articolo, non lo ripeterò. Invece, ti dirò perché hai assolutamente bisogno di Orchestrator for MySQL!

Cominciamo con la domanda principale: "Come trasferiremo il codice su una nuova macchina quando il master se ne andrà?"

• Mi piace di più lo schema con VIP (IP virtuale), ne parleremo di seguito. È il più semplice e ovvio, anche se ha un limite evidente: il master che riserveremo dovrà essere nel segmento L2 con la nuova macchina, cioè possiamo dimenticarci del secondo DC. E, in modo amichevole, se segui la regola secondo cui L2 grande è malvagio, perché L2 è solo per rack e L3 è tra i rack, e un tale schema ha ancora più restrizioni.
• Puoi scrivere un nome DNS nel codice e risolverlo tramite /etc/hosts. In realtà non ci sarà alcuna soluzione. Il vantaggio dello schema: non esiste alcuna limitazione caratteristica del primo metodo, ovvero è possibile organizzare un DC incrociato. Ma allora sorge la domanda ovvia: quanto velocemente possiamo fornire la modifica a /etc/hosts tramite Puppet-Ansible?
• Puoi modificare leggermente il secondo metodo: installare il caching DNS su tutti i server Web, attraverso il quale il codice andrà al database principale. È possibile impostare TTL 60 per questa voce nel DNS. Sembra che se implementato correttamente, il metodo sia buono.
• Uno schema con service discovery, che implica l'uso di Consul e etcd.
• Un'opzione interessante con ProxySQL. È necessario instradare tutto il traffico a MySQL tramite ProxySQL; ProxySQL stesso può determinare chi è il master. A proposito, puoi leggere una delle opzioni per l'utilizzo di questo prodotto nel mio Articolo.

L'autore di Orchestrator, lavorando su Github, ha prima implementato il primo schema con VIP, quindi lo ha convertito in uno schema con console.

Layout tipico dell'infrastruttura:

Descriverò subito le situazioni ovvie di cui bisogna tenere conto:

• L'indirizzo VIP non deve essere registrato nella configurazione su nessuno dei server. Immaginiamo una situazione: il master si è riavviato e durante il caricamento Orchestrator è entrato in modalità failover e ha reso master uno degli slave; poi è salito il vecchio padrone, e ora il VIP è su due vetture. Questo non va bene.
• Per l'orchestratore, dovrai scrivere uno script per chiamare il vecchio master e il nuovo master. Sul vecchio master è necessario eseguire ifdown e sul nuovo master – ifup vip. Sarebbe bello includere in questo script anche che in caso di failover, la porta sullo switch del vecchio master venga semplicemente disattivata per evitare qualsiasi splitbrain.
• Dopo che Orchestrator ha richiamato lo script per rimuovere prima il VIP e/o spegnere la porta sullo switch e quindi richiamato lo script di raccolta VIP sul nuovo master, non dimenticare di utilizzare il comando arping per comunicare a tutti che il nuovo VIP è ora Qui.
• Tutti gli slave dovrebbero avere read_only=1 e non appena promuovi lo slave a master, dovrebbe avere read_only=0.
• Non dimenticare che qualsiasi schiavo che abbiamo scelto per questo può diventare un padrone (l'Orchestrator ha un intero meccanismo di preferenza per quale schiavo considerare come candidato per un nuovo padrone in primo luogo, quale in secondo luogo e quale schiavo dovrebbe non essere selezionato affatto, in nessun caso, maestro). Se lo slave diventa master, il carico dello slave rimarrà su di esso e verrà aggiunto il carico del master, questo deve essere preso in considerazione.

Perché hai bisogno di Orchestrator se non ne hai uno?

• Orchestrator ha un'interfaccia grafica molto intuitiva che visualizza l'intera topologia (vedi screenshot sotto).
• L'orchestrator può tenere traccia degli slave in ritardo e dei punti in cui la replica in genere si è interrotta (disponiamo di script allegati all'orchestrator per l'invio di SMS).
• L'orchestratore ti dice quali schiavi hanno un GTID errante.

Interfaccia dell'orchestratore:

Cos'è il GTID errante?

Esistono due requisiti principali affinché Orchestrator funzioni:

• È necessario che lo pseudo GTID sia abilitato su tutte le macchine nel cluster MySQL; noi abbiamo GTID abilitato.
• È necessario che ci sia un tipo di binlog ovunque, puoi usare istruzione. Avevamo una configurazione in cui il master e la maggior parte degli slave avevano Row, e due storicamente rimanevano nella modalità Mista. Di conseguenza, Orchestrator semplicemente non voleva connettere questi slave al nuovo master.

Ricorda che la cosa più importante in una produzione slave è la sua coerenza con il master! Se hai abilitato l'ID transazione globale (GTID) sia sul master che sullo slave, puoi utilizzare la funzione gtid_subset per scoprire se le stesse richieste di modifica dei dati sono state effettivamente eseguite su queste macchine. Puoi leggere di più a riguardo qui.

Pertanto, Orchestrator ti mostra attraverso il GTID errante che ci sono transazioni sullo slave che non sono sul master. Perché sta succedendo?

• Read_only=1 non è abilitato sullo slave, qualcuno si è connesso e ha completato una richiesta di modifica dei dati.
• Super_read_only=1 non è abilitato sullo slave, quindi l'amministratore, dopo aver confuso il server, è entrato ed ha eseguito lì la richiesta.
• Se hai preso in considerazione entrambi i punti precedenti, allora c'è un altro trucco: in MySQL, una richiesta di svuotamento dei binlog va anche al binlog, quindi al primo scaricamento apparirà un GTID errante sul master e su tutti gli slave. Come evitarlo? Perona-5.7.25-28 ha introdotto l'impostazione binlog_skip_flush_commands=1, che proibisce la scrittura di flush nei binlog. Ce n'è uno stabilito sul sito web mysql.com insetto.

Vorrei riassumere tutto quanto sopra. Se non desideri ancora utilizzare Orchestrator in modalità failover, impostalo in modalità di osservazione. Quindi avrai sempre davanti ai tuoi occhi una mappa dell'interazione delle macchine MySQL e informazioni visive su quale tipo di replica è su ciascuna macchina, se gli slave sono in ritardo e, soprattutto, quanto sono coerenti con il master!

La domanda ovvia è: “Come dovrebbe funzionare Orchestrator?” Deve selezionare un nuovo master dagli slave attuali e quindi ricollegare tutti gli slave ad esso (questo è ciò per cui è necessario il GTID; se usi il vecchio meccanismo con binlog_name e binlog_pos, quindi passare uno slave dall'attuale master a uno nuovo è semplicemente impossibile!). Prima di avere Orchestrator, una volta dovevo fare tutto questo manualmente. Il vecchio master era bloccato a causa di un controller Adaptec difettoso; aveva circa 10 slave. Avevo bisogno di trasferire VIP dal master a uno degli slave e ricollegare ad esso tutti gli altri slave. Quante console ho dovuto aprire, quanti comandi ho inserito contemporaneamente... ho dovuto aspettare fino alle 3 di notte, togliere il carico a tutte le slave tranne due, rendere master la prima macchina delle due, attaccare subito la seconda macchina ad esso, quindi collega tutti gli altri schiavi al nuovo master e restituisci il carico. Nel complesso, terribile...

Come funziona Orchestrator quando entra in modalità failover? Ciò è più facilmente illustrato da un esempio di una situazione in cui vogliamo rendere un maestro una macchina più potente e più moderna di quella che abbiamo adesso.

La figura mostra la metà del processo. Cosa è già stato fatto fino a questo punto? Abbiamo detto che volevamo rendere uno schiavo il nuovo master, Orchestrator ha iniziato semplicemente a ricollegare tutti gli altri slave ad esso, con il nuovo master che fungeva da 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, rende read_only=0 e si dimentica del vecchio master. Tutto! Il tempo di inattività del nostro servizio è il tempo di trasferimento VIP, che è di 2-3 secondi.

Per oggi è tutto, grazie a tutti. Presto ci sarà un secondo articolo su Orchestrator. Nel famoso film sovietico “Garage”, un personaggio disse: “Non andrei in ricognizione con lui!” Quindi, orchestratore, verrei con te in ricognizione!

Fonte: habr.com