En esta publicación, analizaré cómo mover VIP durante una conmutación por error con Orchestrator.
En nuestra publicación anterior, le mostramos cómo funciona Orchestrator. En esta publicación, le daré una prueba de concepto sobre cómo Orchestrator puede mover VIP en caso de falla. Para esta publicación, asumo que el orquestador ya está instalado y puede administrar la topología.
Manos
Orchestrator es un administrador de topología. Nada menos nada más. En caso de conmutación por error, reorganice la topología, promueva un nuevo maestro y conecte los esclavos a él. Pero no hará cambios de DNS y no moverá VIP (ni nada más).
Sin embargo, Orchestrator admite ganchos. Los ganchos son scripts externos que se pueden invocar a través del proceso de recuperación. Hay seis ganchos diferentes:
OnFailureDetectionProcessesPreFailoverProcessesPostIntermediateMasterFailoverProcessesPostMasterFailoverProcessesPostFailoverProcessesPostUnsuccessfulFailoverProcesses
Más detalles están en el manual del orquestador.
Con estos ganchos, podemos llamar a nuestros scripts externos, que se adaptan a nuestra arquitectura y pueden hacer cambios o dejar que la aplicación sepa quién es el nuevo maestro.
Hay varias maneras de hacer esto:
- Actualizar un CNAME: si un CNAME se lo indica al maestro, un script externo puede realizar fácilmente una actualización de DNS después de que falle.
- Transferir un VIP al nuevo profesor: esta solución es similar a un script MHA y MHA-helper (esta publicación discutirá esta solución).
Parámetros
Cuando Orchestrator llama a un script externo, también puede usar parámetros. Este es un ejemplo de la configuración disponible con «PostFailoverProcesses»:
{tipo de falla}, {Descripcion de falla}, {host fallido}, {Clúster de errores}, {failClusterAlias}, {fallaClusterDomain}, {puerto fallido}, {SucesorHost}, {puerto sucesor}, {sucesorAlias}, {cuentas esclavas}, {hosts esclavos}, {está inactivo}, {sucedió}, {esclavos perdidos}
Sin estos parámetros, no sabemos quién es el nuevo maestro y qué invitado está muerto.
movimientos VIP
Como mencioné anteriormente, en esta publicación le mostraré cómo puede mover VIP con Orchestrator. creo que mucha gente lo conoce MHA. Esta solución es algo similar a lo que es MHA ayudante de MHA tú haces.
El requisito principal es, al mismo tiempo, la principal desventaja. Esta solución requiere acceso SSH desde el nodo de Orchestrator a los servidores MySQL.
Agregar usuario
Primero, debemos agregar un usuario en los servidores MySQL y el nodo de Orchestrator (puede cambiar el nombre de usuario):
|
agregar usuario –metro orchista –s /compartimiento/bajo |
Agregar permisos de sudo:
|
Uds /etc/sudoers.D/orca valores predeterminados !necesitar orchista TODO=(TODO) SIN CONTRASEÑA: /usuario/sbin/arpeando,/sbin/ip,/compartimiento/silbido |
Agregaremos la clave pública del nodo de Orchestrator en los servidores MySQL al archivo «/home/orchur/.ssh/authorized_keys».
Ahora podemos SSH desde el servidor de Orchestrator a otros sin contraseña:
|
ssh orchista@192.168.56.106 |
Script de conmutación por error
Ahora necesitamos un script de conmutación por error. Escribí dos pequeños guiones bash ¿Qué puede hacer por nosotros?
la primera llamada orc_hook.sh. Orchestrator llama a este script:
|
Uds /etc/orquestador.conf.json ... «Procesos posteriores a la conmutación por error»: [ «echo ‘(for all types) Recovered from {failureType} on {failureCluster}. Failed: {failedHost}:{failedPort}; Successor: {successorHost}:{successorPort}’ >> /tmp/recovery.log», «/usr/local/bin/orch_hook.sh {failureType} {failureClusterAlias} {failedHost} {successorHost} >> /tmp/orch.log» ], ... |
Debido a que Orchestrator puede manejar múltiples clústeres, necesitamos definir algunos parámetros de clúster:
|
Uds /usuario/local/compartimiento/orch_hook.sh ... reps=( eth0 «192.168.56.121» orchista ) |
Donde «rep» es el nombre del clúster, «eth0» es el nombre de la interfaz donde se debe agregar el VIP, «192.168.56.121» es el VIP en este clúster y «orchur» es el usuario de SSH. Si tenemos varios clústeres, agregaremos más matrices como esta con los detalles del clúster.
Orchestrator ejecuta este script con parámetros:
|
/usuario/local/compartimiento/orch_hook.sh maestromuerto reps mysql1 mysql2 |
Después de que la secuencia de comandos reconozca el clúster, llame a la siguiente secuencia de comandos.
El siguiente script se llama orch_vip.sh. Esto se llama «orch_hook.sh» y transferirá el VIP al nuevo maestro. Se ejecuta de la siguiente manera:
|
/usuario/local/compartimiento/orch_vip.sh –D 1 –norte mysql2 –I eth0 –I 192.168.56.121 –tu orchista –o mysql1 |
-d 1el maestro esta muerto-n mysql2el es el nuevo maestro-i eth0la interfaz de red-I 192.168.56.121es el VIP-u orchuseres el usuario de SSH-o mysql1el es el viejo maestro
El script requiere los comandos «arping» y «mail».
Conclusiones
Con estos dos pequeños scripts, Orchestrator puede mover los VIP de maestro a nuevo maestro, y la aplicación puede volver a funcionar. Sin embargo, este script no está listo para la producción y puede ser casi imposible de manejar. Puedes intentarlo, pero úsalo bajo tu propio riesgo.
Agradezco cualquier comentario o solicitud de extracción para que podamos hacerlo mejor. Pero estad atentos: en la próxima entrada de mi blog, os mostraré cómo puede trabajar Orchestrator con ”ProxySQL. «
