Cualquier proyecto grande comenzaba con un par de servidores. Al principio había un servidor de base de datos, luego se le agregaron esclavos para escalar la lectura. Y luego, ¡detente! Hay un amo, pero hay muchos esclavos; si uno de los esclavos se va, todo estará bien, pero si el maestro se va, será malo: tiempo de inactividad, los administradores están intentando levantar el servidor. ¿Qué hacer? Reserva un maestro. Mi colega Pavel ya escribió sobre esto. , No lo repetiré. En lugar de eso, te diré por qué definitivamente necesitas Orchestrator para MySQL.
Comencemos con la pregunta principal: "¿Cómo cambiaremos el código a una nueva máquina cuando el maestro se vaya?"
- Lo que más me gusta es el esquema con VIP (IP virtual), hablaremos de ello a continuación. Es el más sencillo y obvio, aunque tiene una limitación evidente: el máster que reservaremos debe estar en el segmento L2 con la nueva máquina, es decir, podemos olvidarnos del segundo DC. Y, de manera amistosa, si sigues la regla de que un L2 grande es malo, porque L2 está solo por bastidor y L3 está entre bastidores, ese esquema tiene aún más restricciones.
- Puede escribir un nombre DNS en el código y resolverlo a través de /etc/hosts. De hecho, no habrá resolución. La ventaja del esquema: no existe la limitación característica del primer método, es decir, es posible organizar un DC cruzado. Pero entonces surge la pregunta obvia: ¿qué tan rápido podemos entregar el cambio a /etc/hosts a través de Puppet-Ansible?
- Puede cambiar un poco el segundo método: instale DNS de caché en todos los servidores web, a través del cual el código irá a la base de datos maestra. Puede configurar TTL 60 para esta entrada en DNS. Parece que si se implementa correctamente, el método es bueno.
- Un esquema con descubrimiento de servicios, que implica el uso de Consul y etcd.
- Una opción interesante con . Debe enrutar todo el tráfico a MySQL a través de ProxySQL; el propio ProxySQL puede determinar quién es el maestro. Por cierto, puedes leer sobre una de las opciones para usar este producto en mi .
El autor de Orchestrator, trabajando en Github, primero implementó el primer esquema con VIP y luego lo convirtió en un esquema con cónsul.
Diseño típico de infraestructura:
Describiré inmediatamente las situaciones obvias que deben tenerse en cuenta:
- La dirección VIP no debe registrarse en la configuración de ninguno de los servidores. Imaginemos una situación: el maestro se reinició y, mientras se cargaba, Orchestrator entró en modo de conmutación por error y convirtió a uno de los esclavos en maestro; Luego se levantó el viejo maestro y ahora el VIP está en dos coches. Esto es malo.
- Para el orquestador, deberá escribir un guión para llamar al maestro antiguo y al nuevo maestro. En el antiguo maestro necesitas ejecutar ifdown, y en el nuevo maestro – ifup vip. Sería bueno incluir también en este script que, en caso de una conmutación por error, el puerto del antiguo conmutador maestro simplemente se apague para evitar cualquier división del cerebro.
- Después de que Orchestrator haya llamado a su secuencia de comandos para eliminar primero el VIP y/o apagar el puerto en el conmutador, y luego haya llamado la secuencia de comandos de aumento de VIP en el nuevo maestro, no olvide usar el comando arping para decirles a todos que el nuevo VIP ya está disponible. aquí.
- Todos los esclavos deberían tener read_only=1, y tan pronto como asciendas al esclavo a maestro, debería tener read_only=0.
- No olvide que cualquier esclavo que hayamos elegido para esto puede convertirse en maestro (el orquestador tiene todo un mecanismo de preferencia sobre qué esclavo considerar como candidato a nuevo maestro en primer lugar, cuál en segundo lugar y qué esclavo debe considerarse como candidato a nuevo maestro). no podrá ser seleccionado en ningún caso master). Si el esclavo se convierte en maestro, entonces la carga del esclavo permanecerá en él y se agregará la carga del maestro, esto debe tenerse en cuenta.
¿Por qué necesitas Orchestrator si no tienes uno?
- Orchestrator tiene una interfaz gráfica muy fácil de usar que muestra la topología completa (consulte la captura de pantalla a continuación).
- Orchestrator puede rastrear qué esclavos están rezagados y dónde generalmente se ha interrumpido la replicación (tenemos scripts adjuntos a Orchestrator para enviar SMS).
- Orchestrator le indica qué esclavos tienen un GTID errante.
Interfaz del orquestador:
¿Qué es GTID errante?
Hay dos requisitos principales para que Orchestrator funcione:
- Es necesario que el pseudo GTID esté habilitado en todas las máquinas del clúster MySQL; tenemos GTID habilitado.
- Es necesario que haya un tipo de binlogs en todas partes, puedes usar declaraciones. Teníamos una configuración en la que el maestro y la mayoría de los esclavos tenían Fila, y dos históricamente permanecían en el modo Mixto. Como resultado, Orchestrator simplemente no quería conectar estos esclavos al nuevo maestro.
¡Recuerda que lo más importante en un esclavo de producción es su coherencia con el maestro! Si tiene habilitado el ID de transacción global (GTID) tanto en su maestro como en su esclavo, puede usar la función gtid_subset para averiguar si las mismas solicitudes de cambios de datos realmente se han ejecutado en estas máquinas. Puedes leer más sobre esto. .
Por lo tanto, Orchestrator le muestra a través del GTID errante que hay transacciones en el esclavo que no están en el maestro. ¿Por qué está pasando esto?
- Read_only=1 no está habilitado en el esclavo, alguien se conectó y completó una solicitud para cambiar datos.
- Super_read_only=1 no está habilitado en el esclavo, entonces el administrador, después de confundir al servidor, entró y ejecutó la solicitud allí.
- Si tuvo en cuenta los dos puntos anteriores, entonces hay un truco más: en MySQL, una solicitud para vaciar binlogs también va al binlog, por lo que en el primer vaciado, aparecerá un GTID errante en el maestro y en todos los esclavos. ¿Cómo evitar esto? Perona-5.7.25-28 introdujo la configuración binlog_skip_flush_commands=1, que prohíbe escribir en binlogs. Hay uno establecido en el sitio web mysql.com. .
Permítanme resumir todo lo anterior. Si todavía no desea utilizar Orchestrator en modo de conmutación por error, póngalo en modo de observación. Entonces siempre tendrá ante sus ojos un mapa de la interacción de las máquinas MySQL e información visual sobre qué tipo de replicación hay en cada máquina, si los esclavos están rezagados y, lo más importante, ¡qué tan consistentes son con el maestro!
La pregunta obvia es: "¿Cómo debería funcionar Orchestrator?" Debe seleccionar un nuevo maestro de los esclavos actuales y luego volver a conectar todos los esclavos a él (para esto se necesita GTID; si usa el mecanismo antiguo con binlog_name y binlog_pos, entonces cambiar un esclavo del maestro actual a uno nuevo ¡Es simplemente imposible!). Antes de que tuviéramos Orchestrator, una vez tuve que hacer todo esto manualmente. El viejo maestro estaba colgado debido a un controlador Adaptec defectuoso; tenía alrededor de 10 esclavos. Necesitaba transferir VIP del maestro a uno de los esclavos y volver a conectar todos los demás esclavos. ¿Cuántas consolas tuve que abrir, cuántos comandos simultáneos ingresé... Tuve que esperar hasta las 3 am, quitar la carga de todos los esclavos excepto dos, hacer la primera máquina a partir de dos maestras, conectar inmediatamente la segunda máquina? a él, así que conecte todos los demás esclavos al nuevo maestro y devuelva la carga. En general, terrible...
¿Cómo funciona Orchestrator cuando entra en modo de conmutación por error? Esto se ilustra más fácilmente con un ejemplo de una situación en la que queremos convertir a un maestro en una máquina más poderosa y más moderna que la que tenemos ahora.
La figura muestra la mitad del proceso. ¿Qué se ha hecho ya hasta este momento? Dijimos que queríamos convertir a algún esclavo en el nuevo maestro, Orchestrator comenzó simplemente a reconectar a todos los demás esclavos, con el nuevo maestro actuando como una máquina de tránsito. Con este esquema, no se producen errores, todos los esclavos funcionan, Orchestrator elimina el VIP del antiguo maestro, lo transfiere al nuevo, hace read_only=0 y se olvida del antiguo maestro. ¡Todo! El tiempo de inactividad de nuestro servicio es el tiempo de transferencia VIP, que es de 2 a 3 segundos.
Eso es todo por hoy, gracias a todos. Pronto habrá un segundo artículo sobre Orchestrator. En la famosa película soviética "Garage", un personaje dijo: "¡No iría de reconocimiento con él!". Entonces, orquestador, ¡iría contigo en un reconocimiento!
Fuente: habr.com