Orchestrator for MySQL: por qué no se puede construir un proyecto a prueba de fallas sin él

Cualquier proyecto importante comenzó con un par de servidores. Primero, había un servidor de base de datos, luego se agregaron esclavos para escalar la lectura. Y aquí, ¡para! Un amo, pero muchos esclavos; si uno de los esclavos se va, entonces todo estará bien, pero si el maestro se va, será malo: el tiempo de inactividad, los administradores en el jabón levantan el servidor. ¿Qué hacer? Reserva al maestro. Mi colega Pavel ya ha escrito un artículo sobre esto , no lo repetiré. En cambio, ¡te diré por qué definitivamente necesitas un orquestador para MySQL!

Comencemos con la pregunta principal: "¿Cómo cambiaremos el código a una nueva máquina cuando el asistente se vaya?"

• El esquema con VIP (IP virtual) que más me gusta, lo hablaremos a continuación. Es el más simple y obvio, aunque tiene una limitación obvia: el maestro, que reservaremos, debe estar en el segmento L2 con una nueva máquina, es decir, puede olvidarse del segundo DC. Y, en el buen sentido, si sigue la regla de que L2 grande es malo, porque L2 solo está en el rack, y entre los racks L3, y dicho esquema tiene aún más restricciones.
• Puede registrar un nombre DNS en el código y resolverlo a través de / etc / hosts. De hecho, no habrá resolución. Ventaja del esquema: no hay ninguna característica de restricción del primer método, es decir, también es posible organizar CD cruzados. Pero entonces surge la pregunta obvia, qué tan rápido a través de Puppet-Ansible podemos entregar el cambio a / etc / hosts.
• Puede cambiar un poco el segundo método: en todos los servidores web colocamos DNS en caché, a través del cual el código irá a la base de datos maestra. Puede registrar TTL 60 para esta entrada de DNS. Parece que con una implementación adecuada, el método es bueno.
• Esquema con descubrimiento de servicio que involucra Cónsul y etc.
• Una opción interesante con ProxySQL . Es necesario ajustar todo el tráfico a MySQL a través de ProxySQL, ProxySQL puede determinar quién es el maestro ahora. Por cierto, una de las opciones para usar este producto se puede encontrar en mi artículo .

El autor de Orchestrator, mientras trabajaba en Github, primero implementó el primer esquema con VIP y luego lo rediseñó con c cónsul.

Esquema típico de infraestructura:

Describiré de inmediato las situaciones obvias a considerar:

• VIP- . : , , Orchestrator failover ; , VIP . .
• . ifdown, — ifup vip. , failover , splitbrain.
• , Orchestrator , VIP / , VIP, arping , VIP .
• Todos los esclavos deberían tener read_only = 1, y tan pronto como promuevas el esclavo al maestro, debería tener read_only = 0.
• No olvide que cualquier esclavo que hayamos elegido para esto puede convertirse en un maestro (el orquestador tiene todo un mecanismo de preferencia, qué esclavo debe considerarse como candidato para un nuevo maestro en primer lugar, cuál en el segundo y qué esclavo no debe seleccionarse bajo ninguna circunstancia Maestro). Si el esclavo se convierte en maestro, entonces la carga del esclavo permanecerá en él y se agregará la carga maestra, esto debe tenerse en cuenta.

¿Por qué necesitas absolutamente Orchestrator si no tienes uno?

• Orchestrator tiene una interfaz gráfica muy fácil de usar que muestra toda la topología (vea la captura de pantalla a continuación).
• Orchestrator puede rastrear qué esclavos están detrás y dónde generalmente se interrumpe la replicación (tenemos scripts para enviar SMS a Orchestrator).
• Orchestrator le dice qué diapositivas tienen un error errante GTID.

Interfaz del orquestador:

¿Qué es un errante GTID?

Hay dos requisitos básicos para que Orchestrator funcione:

• Es necesario que el pseudo GTID esté habilitado en todas las máquinas en el clúster MySQL, tenemos GTID habilitado.
• Es necesario que en todas partes haya un tipo de binlogs, puede hacer una declaración. Teníamos una configuración en la que Row estaba en el maestro y en la mayoría de los esclavos, y el modo Mixto permaneció históricamente en dos. Como resultado, Orchestrator simplemente no quería conectar a estos esclavos al nuevo maestro.

¡Recuerde que lo más importante en un esclavo de producción es su consistencia con el maestro! Si tiene habilitado el ID de transacción global (GTID) en el maestro y el esclavo, puede usar la función gtid_subset para averiguar si las mismas solicitudes de cambio de datos se ejecutan realmente en estas máquinas. Lea más sobre esto aquí .

Por lo tanto, Orchestrator le muestra a través de un error errante de GTID que hay transacciones en el esclavo que no están en el asistente. ¿Por qué sucede?

• Read_only = 1 no está habilitado en el esclavo, alguien se conectó y ejecutó una solicitud de cambio de datos.
• Super_read_only = 1 no está habilitado en el esclavo, luego el administrador, después de haber mezclado el servidor, entró y ejecutó una solicitud allí.
• Si tuvo en cuenta los dos párrafos anteriores, hay un truco más: en MySQL, una solicitud de binlogs de descarga también cae en el binlog, por lo que cuando lave por primera vez, aparecerá un error GTID en el asistente y en todos los esclavos. ¿Cómo evitar esto? En perona-5.7.25-28, apareció la configuración binlog_skip_flush_commands = 1, que prohíbe escribir el vaciado en binlogs. Hay un error en mysql.com .

Resumo todo lo anterior. Si aún no desea utilizar Orchestrator en modo de conmutación por error, póngalo en modo de vigilancia. Entonces siempre tendrá ante sus ojos un mapa de la interacción de las máquinas MySQL e información clara sobre qué tipo de replicación en cada máquina, si los esclavos están detrás y lo más importante: ¡cuánta consistencia tienen con el maestro!

La pregunta obvia es: "¿Cómo debería funcionar el orquestador?" Debe seleccionar un nuevo maestro de los esclavos actuales, y luego volver a conectar a todos los esclavos (para eso es GTID; si usa el mecanismo antiguo con binlog_name y binlog_pos, ¡cambiar el esclavo del maestro actual al nuevo es simplemente imposible!). Antes de que Orchestrator viniera a nosotros, una vez tuve que hacer todo esto manualmente. El viejo maestro se estrelló debido a un controlador Adaptec defectuoso, tenía unos 10 esclavos. Necesitaba transferir el VIP del maestro a uno de los esclavos y volver a conectar a todos los demás esclavos. Cuántas consolas tuve que abrir, cuántos comandos simultáneos para ingresar ... Tuve que esperar hasta las 3 a.m., quitar la carga de todos los esclavos, excepto dos, hacer el primer auto de dos amos, conectar inmediatamente el segundo auto,por lo tanto, recoja todos los demás esclavos del nuevo maestro y devuelva la carga. En general, el horror ...

¿Cómo funciona Orchestrator cuando entra en modo de conmutación por error? Esto se muestra más fácilmente con el ejemplo de una situación en la que queremos hacer de un maestro una máquina más poderosa y moderna que ahora.

La figura muestra la mitad del proceso. ¿Qué se ha hecho hasta este momento? Dijimos que queremos hacer que algún tipo de esclavo sea un nuevo maestro, Orchestrator acaba de comenzar a reconectar a todos los demás esclavos y el nuevo maestro actúa 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 viejo maestro. ¡Todas! El tiempo de inactividad de nuestro servicio es el tiempo de transferencia VIP, es de 2-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 "The Garage", un héroe dijo: "¡No haría un reconocimiento con él!" ¡Entonces, Orquestador, iría contigo a explorar!