Qualsevol projecte gran va començar amb un parell de servidors. Al principi hi havia un servidor de base de dades, després s'hi van afegir esclaus per escalar la lectura. I després - para! Hi ha un amo, però hi ha molts esclaus; si un dels esclaus marxa, aleshores tot anirà bé, però si el mestre marxa, serà dolent: temps d'inactivitat, els administradors estan intentant augmentar el servidor. Què fer? Reserva un màster. El meu company Pavel ja va escriure sobre això , no ho repetiré. En lloc d'això, us diré per què definitivament necessiteu Orchestrator per a MySQL!
Comencem amb la pregunta principal: "Com canviarem el codi a una màquina nova quan el mestre marxi?"
- M'agrada més l'esquema amb VIP (IP virtual), en parlarem a continuació. És el més senzill i evident, tot i que té una limitació evident: el mestre que reservarem ha d'estar al segment L2 amb la màquina nova, és a dir, ens podem oblidar del segon DC. I, d'una manera amistosa, si seguiu la regla que un L2 gran és dolent, perquè L2 només és per bastidor i L3 es troba entre els bastidors, i aquest esquema té encara més restriccions.
- Podeu escriure un nom DNS al codi i resoldre'l mitjançant /etc/hosts. De fet, no hi haurà resolució. L'avantatge de l'esquema: no hi ha cap característica de limitació del primer mètode, és a dir, és possible organitzar un cross-DC. Però aleshores sorgeix la pregunta òbvia: amb quina rapidesa podem lliurar el canvi a /etc/hosts mitjançant Puppet-Ansible?
- Podeu canviar una mica el segon mètode: instal·leu la memòria cau DNS a tots els servidors web, a través del qual el codi anirà a la base de dades mestra. Podeu establir TTL 60 per a aquesta entrada al DNS. Sembla que si s'implementa correctament, el mètode és bo.
- Un esquema amb descobriment de serveis, que implica l'ús de Consul i etcd.
- Una opció interessant amb . Heu d'encaminar tot el trànsit a MySQL mitjançant ProxySQL; ProxySQL pot determinar qui és el mestre. Per cert, podeu llegir sobre una de les opcions per utilitzar aquest producte al meu .
L'autor d'Orchestrator, que treballava a Github, primer va implementar el primer esquema amb VIP i després el va convertir en un esquema amb cònsol.
Disposició típica de la infraestructura:
De seguida descriuré les situacions òbvies que cal tenir en compte:
- L'adreça VIP no s'ha de registrar a la configuració de cap dels servidors. Imaginem una situació: el mestre es va reiniciar i, mentre s'estava carregant, Orchestrator va entrar en mode de failover i va convertir un dels esclaus en mestre; llavors el vell mestre es va aixecar, i ara el VIP està en dos cotxes. Això és dolent.
- Per a l'orquestrador, haureu d'escriure un script per trucar al mestre antic i al nou mestre. Al mestre antic, heu d'executar ifdown, i al nou mestre: ifup vip. Seria bo incloure també en aquest script que, en cas de fallada, el port de l'interruptor de l'antic mestre simplement s'apaga per evitar qualsevol splitbrain.
- Després que l'Orchestrator hagi trucat al vostre script per eliminar primer el VIP i/o apagar el port de l'interruptor i després cridar l'script de pujada VIP al nou mestre, no us oblideu d'utilitzar l'ordre arping per dir a tothom que el nou VIP és ara. aquí.
- Tots els esclaus haurien de tenir read_only=1, i tan aviat com promocioneu l'esclau al mestre, hauria de tenir read_only=0.
- No oblideu que qualsevol esclau que hem escollit per a això pot convertir-se en mestre (l'orquestrador té tot un mecanisme de preferència per quin esclau ha de considerar com a candidat a un nou mestre en primer lloc, quin en segon lloc i quin esclau hauria de considerar no ser seleccionat en cap cas mestre). Si l'esclau es converteix en mestre, llavors la càrrega de l'esclau romandrà sobre ell i s'afegirà la càrrega del mestre, això s'ha de tenir en compte.
Per què necessiteu Orchestrator si no en teniu?
- Orchestrator té una interfície gràfica molt fàcil d'utilitzar que mostra tota la topologia (vegeu la captura de pantalla a continuació).
- Orchestrator pot fer un seguiment de quins esclaus estan endarrerits i on la rèplica generalment s'ha trencat (tenim scripts adjunts a Orchestrator per enviar SMS).
- L'orquestrator us indica quins esclaus tenen un error GTID.
Interfície de l'orquestrador:
Què és GTID errant?
Hi ha dos requisits principals perquè Orchestrator funcioni:
- És necessari que el pseudo GTID estigui habilitat a totes les màquines del clúster MySQL; tenim GTID habilitat.
- És necessari que hi hagi un tipus de binlogs a tot arreu, podeu utilitzar declaració. Teníem una configuració en què el mestre i la majoria d'esclaus tenien fila, i dos es van mantenir històricament en el mode mixt. Com a resultat, Orchestrator simplement no volia connectar aquests esclaus al nou mestre.
Recordeu que el més important en un esclau de producció és la seva coherència amb el mestre! Si teniu l'identificador de transacció global (GTID) activat tant al vostre mestre com al vostre esclau, podeu utilitzar la funció gtid_subset per esbrinar si realment s'han executat les mateixes sol·licituds de canvis de dades en aquestes màquines. Podeu llegir més sobre això .
Així, Orchestrator us mostra a través de l'errant GTID que hi ha transaccions a l'esclau que no es troben al mestre. Per què passa això?
- Read_only=1 no està habilitat a l'esclau, algú s'ha connectat i ha completat una sol·licitud per canviar les dades.
- Super_read_only=1 no està habilitat a l'esclau, llavors l'administrador, havent confós el servidor, va entrar i va executar la sol·licitud allà.
- Si heu tingut en compte els dos punts anteriors, aleshores hi ha un truc més: a MySQL, una sol·licitud per esborrar els binlogs també va al binlog, de manera que en el primer escàs, apareixerà un error GTID al mestre i a tots els esclaus. Com evitar això? Perona-5.7.25-28 va introduir el paràmetre binlog_skip_flush_commands=1, que prohibeix escriure flush als binlogs. N'hi ha un establert al lloc web mysql.com .
Permeteu-me que resumeixi tot l'anterior. Si encara no voleu utilitzar Orchestrator en mode de migració per error, poseu-lo en mode d'observació. Aleshores sempre tindreu davant dels vostres ulls un mapa de la interacció de les màquines MySQL i informació visual sobre quin tipus de rèplica hi ha a cada màquina, si els esclaus estan endarrerits i, el més important, com de coherents són amb el mestre!
La pregunta òbvia és: "Com ha de funcionar Orchestrator?" Ha de seleccionar un nou mestre dels esclaus actuals i, a continuació, tornar-hi a connectar tots els esclaus (per això es necessita GTID; si utilitzeu el mecanisme antic amb binlog_name i binlog_pos, canvieu un esclau del mestre actual a un de nou). és simplement impossible!). Abans de tenir Orchestrator, una vegada vaig haver de fer tot això manualment. L'antic mestre estava penjat a causa d'un controlador Adaptec amb errors; tenia uns 10 esclaus. Necessitava transferir VIP del mestre a un dels esclaus i tornar a connectar-hi tots els altres esclaus. Quantes consoles he hagut d'obrir, quantes ordres simultànies he introduït... Vaig haver d'esperar fins a les 3 de la matinada, treure la càrrega de tots els esclaus excepte dos, fer la primera màquina de dos mestres, connectar immediatament la segona màquina a ell, així que connecteu tots els altres esclaus al nou mestre i torneu la càrrega. En general, terrible...
Com funciona Orchestrator quan entra en mode de migració per error? Això s'il·lustra més fàcilment amb un exemple d'una situació en què volem fer d'un mestre una màquina més potent i més moderna que la que tenim ara.
La figura mostra la meitat del procés. Què s'ha fet ja fins a aquest moment? Vam dir que volíem fer d'algun esclau el nou mestre, Orchestrator va començar a connectar-hi simplement tots els altres esclaus, amb el nou mestre actuant com a màquina de trànsit. Amb aquest esquema, no es produeixen errors, tots els esclaus funcionen, Orchestrator elimina el VIP del mestre antic, el transfereix al nou, fa que read_only=0 i s'oblida del mestre antic. Tot! El temps d'inactivitat del nostre servei és el temps de transferència VIP, que és de 2-3 segons.
Això és tot per avui, gràcies a tots. Aviat hi haurà un segon article sobre Orchestrator. A la famosa pel·lícula soviètica "Garage", un personatge va dir: "No faria reconeixement amb ell!" Per tant, orquestrador, aniria amb tu a reconeixement!
Font: www.habr.com