MySQL Replication es una forma muy popular de crear capas de bases de datos de alta disponibilidad. Es muy conocido, probado y robusto. Sin embargo, no está exento de limitaciones. Uno de ellos, definitivamente, es el hecho de que utiliza solo un "punto de entrada":tiene un servidor dedicado en la topología, el maestro, y es el único nodo en el clúster al que puede emitir escrituras. Esto conduce a graves consecuencias:el maestro es el único punto de falla y, si falla, la aplicación no puede ejecutar ninguna escritura. No sorprende que se haya trabajado mucho en el desarrollo de herramientas que reducirían el impacto de la pérdida de un maestro. Claro, hay discusiones sobre cómo abordar el tema, si la conmutación por error automatizada es mejor que la manual o no. Eventualmente, esta es una decisión comercial que debe tomar, pero si decide seguir el camino de la automatización, buscará las herramientas que lo ayuden a lograrlo. Una de las herramientas, que sigue siendo muy popular, es MHA (Master High Availability). Si bien tal vez ya no se mantiene activamente, todavía se encuentra en una forma estable y su gran popularidad aún lo convierte en la columna vertebral de las configuraciones de replicación MySQL de alta disponibilidad. Sin embargo, ¿qué pasaría si la propia MHA dejara de estar disponible? ¿Puede convertirse en un único punto de falla? ¿Hay alguna manera de evitar que suceda? En esta publicación de blog, veremos algunos de los escenarios.
Lo primero es lo primero, si planea usar MHA, asegúrese de usar la última versión del repositorio. No utilice versiones binarias ya que no contienen todas las correcciones. La instalación es bastante simple. MHA consta de dos partes, administrador y nodo. El nodo se implementará en sus servidores de base de datos. Manager se implementará en un host separado, junto con node. Entonces, servidores de base de datos:nodo, host de administración:administrador y nodo.
Es bastante fácil compilar MHA. Ve a GitHub y clona los repositorios.
https://github.com/yoshinorim/mha4mysql-manager
https://github.com/yoshinorim/mha4mysql-node
Entonces todo se trata de:
perl Makefile.PL
make
make installEs posible que deba instalar algunas dependencias de Perl si no tiene todos los paquetes necesarios ya instalados. En nuestro caso, en Ubuntu 16.04, tuvimos que instalar lo siguiente:
perl -MCPAN -e "install Config::Tiny"
perl -MCPAN -e "install Log::Dispatch"
perl -MCPAN -e "install Parallel::ForkManager"
perl -MCPAN -e "install Module::Install"Una vez que haya instalado MHA, debe configurarlo. No entraremos en detalles aquí, hay muchos recursos en Internet que cubren esta parte. Una configuración de muestra (definitivamente una que no sea de producción) puede verse así:
[email protected]:~# cat /etc/app1.cnf
[server default]
user=cmon
password=pass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
[server1]
hostname=node1
candidate_master=1
[server2]
hostname=node2
candidate_master=1
[server3]
hostname=node3
no_master=1El próximo paso será ver si todo funciona y cómo MHA ve la replicación:
[email protected]:~# masterha_check_repl --conf=/etc/app1.cnf
Tue Apr 9 08:17:04 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 08:17:04 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 08:17:04 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln427] Error happened on checking configurations. Redundant argument in sprintf at /usr/local/share/perl/5.22.1/MHA/NodeUtil.pm line 195.
Tue Apr 9 08:17:05 2019 - [error][/usr/local/share/perl/5.22.1/MHA/MasterMonitor.pm, ln525] Error happened on monitoring servers.
Tue Apr 9 08:17:05 2019 - [info] Got exit code 1 (Not master dead).Bueno, se estrelló. Esto se debe a que MHA intenta analizar la versión de MySQL y no espera guiones en ella. Afortunadamente, la solución es fácil de encontrar:https://github.com/yoshinorim/mha4mysql-manager/issues/116.
Ahora, tenemos MHA listo para trabajar.
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:00:00 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:00:00 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:00:00 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:00:01 2019 - [info] GTID failover mode = 1
Tue Apr 9 13:00:01 2019 - [info] Dead Servers:
Tue Apr 9 13:00:01 2019 - [info] Alive Servers:
Tue Apr 9 13:00:01 2019 - [info] node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306)
Tue Apr 9 13:00:01 2019 - [info] Alive Slaves:
Tue Apr 9 13:00:01 2019 - [info] node2(10.0.0.142:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Primary candidate for the new Master (candidate_master is set)
Tue Apr 9 13:00:01 2019 - [info] node3(10.0.0.143:3306) Version=5.7.25-28-log (oldest major version between slaves) log-bin:enabled
Tue Apr 9 13:00:01 2019 - [info] GTID ON
Tue Apr 9 13:00:01 2019 - [info] Replicating from 10.0.0.141(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Not candidate for the new Master (no_master is set)
Tue Apr 9 13:00:01 2019 - [info] Current Alive Master: node1(10.0.0.141:3306)
Tue Apr 9 13:00:01 2019 - [info] Checking slave configurations..
Tue Apr 9 13:00:01 2019 - [info] Checking replication filtering settings..
Tue Apr 9 13:00:01 2019 - [info] binlog_do_db= , binlog_ignore_db=
Tue Apr 9 13:00:01 2019 - [info] Replication filtering check ok.
Tue Apr 9 13:00:01 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Tue Apr 9 13:00:01 2019 - [info] Checking SSH publickey authentication settings on the current master..
Tue Apr 9 13:00:02 2019 - [info] HealthCheck: SSH to node1 is reachable.
Tue Apr 9 13:00:02 2019 - [info]
node1(10.0.0.141:3306) (current master)
+--node2(10.0.0.142:3306)
+--node3(10.0.0.143:3306)
Tue Apr 9 13:00:02 2019 - [warning] master_ip_failover_script is not defined.
Tue Apr 9 13:00:02 2019 - [warning] shutdown_script is not defined.
Tue Apr 9 13:00:02 2019 - [info] Set master ping interval 3 seconds.
Tue Apr 9 13:00:02 2019 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Tue Apr 9 13:00:02 2019 - [info] Starting ping health check on node1(10.0.0.141:3306)..
Tue Apr 9 13:00:02 2019 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..Como puede ver, MHA está monitoreando nuestra topología de replicación, verificando si el nodo maestro está disponible o no. Consideremos un par de escenarios.
Escenario 1:MHA colapsado
Supongamos que MHA no está disponible. ¿Cómo afecta esto al medio ambiente? Obviamente, como MHA es responsable de monitorear la salud del maestro y desencadenar la conmutación por error, esto no sucederá cuando MHA esté inactivo. No se detectará el bloqueo maestro, no se producirá la conmutación por error. El problema es que realmente no puede ejecutar varias instancias de MHA al mismo tiempo. Técnicamente, puede hacerlo, aunque MHA se quejará del archivo de bloqueo:
[email protected]:~# masterha_manager --conf=/etc/app1.cnf
Tue Apr 9 13:05:38 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Tue Apr 9 13:05:38 2019 - [info] Reading application default configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] Reading server configuration from /etc/app1.cnf..
Tue Apr 9 13:05:38 2019 - [info] MHA::MasterMonitor version 0.58.
Tue Apr 9 13:05:38 2019 - [warning] /var/log/masterha/app1/app1.master_status.health already exists. You might have killed manager with SIGKILL(-9), may run two or more monitoring process for the same application, or use the same working directory. Check for details, and consider setting --workdir separately.Sin embargo, se iniciará e intentará monitorear el entorno. El problema es cuando ambos comienzan a ejecutar acciones en el clúster. El peor de los casos sería si deciden usar diferentes esclavos como el candidato maestro y la conmutación por error se ejecutará al mismo tiempo (MHA usa un archivo de bloqueo que evita que ocurran las conmutaciones por error posteriores, pero si todo sucede al mismo tiempo, y sucedió en nuestro pruebas, esta medida de seguridad no es suficiente).
Desafortunadamente, no existe una forma integrada de ejecutar MHA de manera altamente disponible. La solución más simple será escribir un script que compruebe si MHA se está ejecutando y, si no, iniciarlo. Tal secuencia de comandos debería ejecutarse desde cron o escribirse en forma de demonio, si la granularidad de 1 minuto de cron no es suficiente.
Situación 2:el nodo del administrador de MHA perdió la conexión de red con el maestro
Seamos honestos, esta es una situación realmente mala. Tan pronto como MHA no pueda conectarse al maestro, intentará realizar una conmutación por error. La única excepción es si se define la secuencia de comandos de verificación secundaria y se verificó que el maestro está activo. Depende del usuario definir exactamente qué acciones debe realizar MHA para verificar el estado del maestro; todo depende del entorno y la configuración exacta. Otro script muy importante para definir es master_ip_failover_script:se ejecuta en caso de conmutación por error y debe usarse, entre otros, para garantizar que el antiguo maestro no aparezca. Si tiene acceso a formas adicionales de llegar y detener al viejo maestro, eso es realmente genial. Pueden ser herramientas de administración remota como Integrated Lights-out, puede ser acceso a tomas de corriente manejables (donde puede simplemente apagar el servidor), puede ser acceso a la CLI del proveedor de la nube, lo que permitirá detener la instancia virtual. . Es de suma importancia detener el antiguo maestro; de lo contrario, puede suceder que, después de que desaparezca el problema de la red, terminará con dos nodos grabables en el sistema, lo cual es una solución perfecta para el cerebro dividido, una condición en la que los datos divergieron entre dos partes del mismo grupo.
Como puede ver, MHA puede manejar bastante bien la conmutación por error de MySQL. Definitivamente requiere una configuración cuidadosa y tendrá que escribir scripts externos, que se utilizarán para matar al antiguo maestro y asegurarse de que el cerebro dividido no suceda. Habiendo dicho eso, aún recomendaríamos usar herramientas de administración de conmutación por error más avanzadas como Orchestrator o ClusterControl, que pueden realizar un análisis más avanzado del estado de la topología de replicación (por ejemplo, mediante el uso de esclavos o proxies para evaluar la disponibilidad del maestro) y cuáles son y se mantendrá en el futuro. Si está interesado en saber cómo ClusterControl realiza la conmutación por error, nos gustaría invitarlo a leer esta publicación de blog sobre el proceso de conmutación por error en ClusterControl. También puede aprender cómo interactúa ClusterControl con ProxySQL y ofrece una conmutación por error fluida y transparente para su aplicación. Siempre puedes probar ClusterControl descargándolo gratis.
