Calquera proxecto grande comezou cun par de servidores. Ao principio había un servidor de base de datos, despois engadíronselle escravos para escalar a lectura. E entón - para! Hai un amo, pero hai moitos escravos; se un dos escravos sae, todo estará ben, pero se o mestre sae, será malo: tempo de inactividade, os administradores están tentando aumentar o servidor. Que facer? Reserva un mestre. O meu compañeiro Pavel xa escribiu sobre isto , non o repetirei. En vez diso, vouche dicir por que definitivamente necesitas Orchestrator para MySQL!
Comecemos coa pregunta principal: "Como cambiaremos o código a unha máquina nova cando o mestre marche?"
- Gústame máis o esquema con VIP (IP virtual), falaremos diso a continuación. É o máis sinxelo e evidente, aínda que ten unha limitación evidente: o mestre que imos reservar debe estar no segmento L2 coa nova máquina, é dicir, podemos esquecernos do segundo DC. E, dun xeito amigable, se segues a regra de que un L2 grande é malo, porque L2 é só por rack, e L3 está entre os bastidores, e tal esquema ten aínda máis restricións.
- Podes escribir un nome DNS no código e resolvelo a través de /etc/hosts. De feito, non haberá resolución. A vantaxe do esquema: non hai ningunha característica de limitación do primeiro método, é dicir, é posible organizar un cross-DC. Pero entón xorde a pregunta obvia: con que rapidez podemos entregar o cambio a /etc/hosts a través de Puppet-Ansible?
- Podes cambiar un pouco o segundo método: instalar DNS de caché en todos os servidores web, a través do cal o código irá á base de datos mestra. Podes establecer TTL 60 para esta entrada en DNS. Parece que se se implementa correctamente, o método é bo.
- Un esquema con descubrimento de servizos, que implica o uso de Consul e etcd.
- Unha opción interesante con . Debe encamiñar todo o tráfico a MySQL a través de ProxySQL; o propio ProxySQL pode determinar quen é o mestre. Por certo, podes ler sobre unha das opcións para usar este produto no meu .
O autor de Orchestrator, que traballa en Github, primeiro implementou o primeiro esquema con VIP e despois converteuno nun esquema con cónsul.
Disposición típica da infraestrutura:
Inmediatamente describirei as situacións obvias que hai que ter en conta:
- O enderezo VIP non debe rexistrarse na configuración de ningún dos servidores. Imaxinemos unha situación: o mestre reiniciouse e, mentres se estaba cargando, Orchestrator pasou ao modo de conmutación por fallo e converteu un dos escravos en mestre; entón levantouse o vello mestre, e agora o VIP está en dous coches. Isto é malo.
- Para o orquestrador, terás que escribir un guión para chamar ao mestre antigo e ao novo mestre. No mestre antigo cómpre executar ifdown, e no novo mestre - ifup vip. Sería bo incluír neste script tamén que, en caso de fallo, o porto do antigo conmutador mestre simplemente estea desactivado para evitar calquera splitbrain.
- Despois de que Orchestrator chame ao teu script para eliminar primeiro o VIP e/ou apague o porto do interruptor e despois chame ao script de aumento de VIP no novo mestre, non esquezas usar o comando arping para dicir a todos que o novo VIP é agora. aquí.
- Todos os escravos deberían ter read_only=1, e tan pronto como promoves o escravo ao mestre, debería ter read_only=0.
- Non esquezas que calquera escravo que escollemos para iso pode converterse nun mestre (Orquestrator ten todo un mecanismo de preferencia para cal escravo considerar como candidato a un novo mestre en primeiro lugar, cal en segundo lugar e cal escravo debe non ser seleccionado en ningún caso mestre). Se o escravo se converte nun mestre, entón a carga do escravo permanecerá nel e engadirase a carga do mestre, isto debe terse en conta.
Por que necesitas Orchestrator se non o tes?
- Orchestrator ten unha interface gráfica moi amigable que mostra a topoloxía completa (ver a captura de pantalla a continuación).
- Orchestrator pode rastrexar cales son os escravos que están atrasados e onde a replicación xeralmente se rompeu (temos scripts adxuntos a Orchestrator para enviar SMS).
- Orchestrator indícache que escravos teñen un GTID errante.
Interfaz do orquestrador:
Que é GTID errante?
Hai dous requisitos principais para que Orchestrator funcione:
- É necesario que o pseudo GTID estea activado en todas as máquinas do clúster de MySQL; temos GTID habilitado.
- É necesario que haxa un tipo de binlogs en todas partes, pode usar declaración. Tiñamos unha configuración na que o mestre e a maioría dos escravos tiñan Fila, e dous permaneceron historicamente no modo Mixto. Como resultado, Orchestrator simplemente non quería conectar estes escravos ao novo mestre.
Lembra que o máis importante nun escravo de produción é a súa coherencia co mestre! Se tes o ID de transacción global (GTID) activado tanto no teu mestre como no teu escravo, podes usar a función gtid_subset para saber se realmente se executaron as mesmas solicitudes de cambios de datos nestas máquinas. Podes ler máis sobre isto .
Así, Orchestrator móstralle a través do errante GTID que hai transaccións no escravo que non están no mestre. Por que está a suceder isto?
- Read_only=1 non está activado no escravo, alguén se conectou e completou unha solicitude para cambiar os datos.
- Super_read_only=1 non está habilitado no escravo, entón o administrador, tras confundir o servidor, entrou e executou alí a solicitude.
- Se tivo en conta os dous puntos anteriores, entón hai un truco máis: en MySQL, unha solicitude para limpar binlogs tamén vai ao binlog, polo que na primeira descarga aparecerá un errante GTID no mestre e en todos os escravos. Como evitar isto? Perona-5.7.25-28 introduciu o axuste binlog_skip_flush_commands=1, que prohibe escribir descargas en binlogs. Hai un establecido no sitio web mysql.com .
Permítanme resumir todo o anterior. Se aínda non queres usar Orchestrator en modo de conmutación por fallo, pon o modo de observación. Entón sempre terás ante os teus ollos un mapa da interacción das máquinas MySQL e información visual sobre que tipo de replicación hai en cada máquina, se os escravos están atrasados e, o máis importante, como son coherentes co mestre!
A pregunta obvia é: "Como debería funcionar Orchestrator?" Debe seleccionar un novo mestre entre os escravos actuais e, a continuación, conectar todos os escravos a el (para iso é necesario o GTID; se usa o mecanismo antigo con binlog_name e binlog_pos, entón cambiará un escravo do mestre actual a un novo). é simplemente imposible!). Antes de ter Orchestrator, unha vez tiven que facer todo isto manualmente. O vello mestre estaba colgado debido a un controlador Adaptec con erros; tiña uns 10 escravos. Necesitaba transferir VIP do mestre a un dos escravos e volver conectar a el todos os demais escravos. Cantas consolas tiven que abrir, cantos comandos simultáneos introducín... Tiven que esperar ata as 3 da mañá, quitar a carga de todos os escravos menos de dous, facer a primeira máquina de dous mestres, conectar inmediatamente a segunda máquina. a ela, así que achegue todos os demais escravos ao novo mestre e devolva a carga. En xeral, terrible...
Como funciona Orchestrator cando pasa ao modo de conmutación por fallo? Isto é máis facilmente ilustrado cun exemplo dunha situación na que queremos facer dun mestre unha máquina máis potente e máis moderna do que temos agora.
A figura mostra a metade do proceso. Que xa se fixo ata este momento? Dixemos que queriamos facer que algún escravo fose o novo mestre, Orchestrator comezou simplemente a conectar todos os demais escravos a el, co novo mestre actuando como unha máquina de tránsito. Con este esquema, non se producen erros, todos os escravos funcionan, Orchestrator elimina o VIP do antigo mestre, transfire ao novo, fai read_only=0 e esquécese do antigo mestre. Todo! O tempo de inactividade do noso servizo é o tempo de transferencia VIP, que é de 2-3 segundos.
Isto é todo por hoxe, grazas a todos. En breve haberá un segundo artigo sobre Orchestrator. Na famosa película soviética "Garage", un personaxe dixo: "Non iría de recoñecemento con el!" Entón, orquestrador, eu iría contigo no recoñecemento!
Fonte: www.habr.com