La conmutación por error automatizada es prácticamente imprescindible para muchas aplicaciones:el tiempo de actividad se da por sentado. Es bastante difícil aceptar que una aplicación esté inactiva durante 20 o 30 minutos porque alguien tiene que ser localizado para iniciar sesión e investigar la situación antes de tomar medidas.
En el mundo real, las configuraciones de replicación tienden a crecer con el tiempo para volverse complejas, a veces desordenadas. Y hay restricciones. Por ejemplo, no todos los nodos de una configuración son buenos candidatos a maestros. ¿Quizás el hardware es diferente y algunas de las réplicas tienen un hardware menos potente, ya que están dedicadas a manejar algunos tipos específicos de carga de trabajo? ¿Quizás está en medio de la migración a una nueva versión de MySQL y algunos de los esclavos ya se han actualizado? Preferiría no tener un maestro en una versión más reciente que se replique en réplicas antiguas, ya que esto puede interrumpir la replicación. Si tiene dos centros de datos, uno activo y otro para recuperación ante desastres, es posible que prefiera elegir candidatos maestros solo en el centro de datos activo, para mantener el maestro cerca de los hosts de aplicaciones. Esas son solo situaciones de ejemplo, en las que puede necesitar una intervención manual durante el proceso de conmutación por error. Afortunadamente, muchas herramientas de conmutación por error tienen la opción de tomar el control del proceso mediante el uso de listas blancas y listas negras. En esta publicación de blog, nos gustaría mostrarle algunos ejemplos de cómo puede influir en el algoritmo de ClusterControl para seleccionar candidatos maestros.
Configuración de lista blanca y lista negra
ClusterControl le ofrece la opción de definir tanto la lista blanca como la lista negra de réplicas. Una lista blanca es una lista de réplicas destinadas a convertirse en candidatas maestras. Si ninguno de ellos está disponible (ya sea porque está inactivo, hay transacciones erróneas o hay otros obstáculos que impiden que alguno de ellos se promueva), no se realizará la conmutación por error. De esta forma, puede definir qué hosts están disponibles para convertirse en un candidato maestro. Las listas negras, por otro lado, definen qué réplicas no son adecuadas para convertirse en candidatas maestras.
Ambas listas se pueden definir en el archivo de configuración cmon para un clúster determinado. Por ejemplo, si su clúster tiene una identificación de '1', desea editar '/etc/cmon.d/cmon_1.cnf'. Para la lista blanca, utilizará la variable 'replication_failover_whitelist', para la lista negra será una 'replication_failover_blacklist'. Ambos aceptan una lista separada por comas de 'host:port'.
Consideremos la siguiente configuración de replicación. Tenemos un maestro activo (10.0.0.141) que tiene dos réplicas (10.0.0.142 y 10.0.0.143), ambos actúan como maestros intermedios y tienen una réplica cada uno (10.0.0.144 y 10.0.0.147). También tenemos un maestro en espera en un centro de datos separado (10.0.0.145) que tiene una réplica (10.0.0.146). Esos hosts están destinados a ser utilizados en caso de desastre. Las réplicas 10.0.0.146 y 10.0.0.147 actúan como hosts de respaldo. Vea la siguiente captura de pantalla.
Dado que el segundo centro de datos solo está destinado a la recuperación ante desastres, no queremos que ninguno de esos hosts se promocione como maestro. En el peor de los casos, tomaremos medidas manuales. La infraestructura del segundo centro de datos no se adapta al tamaño del centro de datos de producción (hay tres réplicas menos en el centro de datos de DR), por lo que se necesitan acciones manuales de todos modos antes de que podamos promocionar un host en el centro de datos de DR. Tampoco nos gustaría que se promocionara una réplica de copia de seguridad (10.0.0.147). Tampoco queremos que se coja una tercera réplica de la cadena como master (aunque se podría hacer con GTID).
Configuración de lista blanca
Podemos configurar una lista blanca o una lista negra para asegurarnos de que la conmutación por error se manejará a nuestro gusto. En esta configuración particular, el uso de la lista blanca puede ser más adecuado:definiremos qué hosts se pueden usar para la conmutación por error y si alguien agrega un nuevo host a la configuración, no se considerará como candidato principal hasta que alguien decida manualmente que es ok para usarlo y agregarlo a la lista blanca. Si usamos la lista negra, agregar una nueva réplica en algún lugar de la cadena podría significar que, en teoría, dicha réplica podría usarse automáticamente para la conmutación por error, a menos que alguien diga explícitamente que no se puede usar. Mantengámonos seguros y definamos una lista blanca en nuestro archivo de configuración de clúster (en este caso es /etc/cmon.d/cmon_1.cnf ya que solo tenemos un clúster):
replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306Tenemos que asegurarnos de que el proceso cmon se haya reiniciado para aplicar los cambios:
service cmon restartSupongamos que nuestro maestro se bloqueó y ClusterControl no puede acceder a él. Se iniciará un trabajo de conmutación por error:
La topología se verá como a continuación:
Como puede ver, el antiguo maestro está deshabilitado y ClusterControl no intentará recuperarlo automáticamente. Depende del usuario comprobar lo que ha sucedido, copiar los datos que no se hayan replicado en el candidato maestro y reconstruir el maestro antiguo:
Luego, se trata de algunos cambios de topología y podemos llevar la topología al estado original, simplemente reemplazando 10.0.0.141 con 10.0.0.142:
Configuración de lista negra
Ahora vamos a ver cómo funciona la lista negra. Mencionamos que, en nuestro ejemplo, puede que no sea la mejor opción, pero lo intentaremos por el bien de la ilustración. Incluiremos en la lista negra todos los hosts, excepto 10.0.0.141, 10.0.0.142 y 10.0.0.143, ya que esos son los hosts que queremos ver como candidatos maestros.
replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306También reiniciaremos el proceso cmon para aplicar los cambios de configuración:
service cmon restartEl proceso de conmutación por error es similar. Nuevamente, una vez que se detecta el bloqueo principal, ClusterControl iniciará un trabajo de conmutación por error.
Cuando una réplica puede no ser un buen candidato a maestro
En esta breve sección, nos gustaría analizar con más detalle algunos de los casos en los que es posible que no desee promocionar una réplica determinada para que se convierta en un nuevo maestro. Con suerte, esto le dará algunas ideas de los casos en los que puede necesitar considerar inducir más control manual del proceso de conmutación por error.
Diferente versión de MySQL
Primero, si su réplica usa una versión de MySQL diferente a la maestra, no es una buena idea promocionarla. En términos generales, una versión más reciente siempre es imposible, ya que la replicación de la nueva versión de MySQL a la anterior no es compatible y es posible que no funcione correctamente. Esto es relevante principalmente para las versiones principales (por ejemplo, 8.0 replicando a 5.7), pero la buena práctica es evitar esta configuración por completo, incluso si estamos hablando de pequeñas diferencias de versión (5.7.x+1 -> 5.7.x). Se admite la replicación de una versión inferior a una superior/más nueva, ya que es imprescindible para el proceso de actualización, pero aún así, preferiría evitar esto (por ejemplo, si su maestro está en 5.7.x + 1, preferiría no reemplazarlo con una réplica en 5.7.x).
Roles diferentes
Puede asignar diferentes roles a sus réplicas. Puede elegir uno de ellos para que esté disponible para que los desarrolladores prueben sus consultas en un conjunto de datos de producción. Puede usar uno de ellos para la carga de trabajo de OLAP. Puede usar uno de ellos para copias de seguridad. No importa lo que sea, por lo general no querrás promocionar dicha réplica a maestra. Todas esas cargas de trabajo adicionales no estándar pueden causar problemas de rendimiento debido a la sobrecarga adicional. Una buena opción para un candidato a maestro es una réplica que maneje una carga "normal", más o menos el mismo tipo de carga que el maestro actual. Entonces puede estar seguro de que manejará la carga maestra después de la conmutación por error si la manejó antes.
Diferentes especificaciones de hardware
Mencionamos diferentes roles para las réplicas. No es raro ver también diferentes especificaciones de hardware, especialmente junto con diferentes roles. Por ejemplo, lo más probable es que un esclavo de copia de seguridad no tenga que ser tan potente como una réplica normal. Los desarrolladores también pueden probar sus consultas en una base de datos más lenta que la de producción (principalmente porque no esperaría el mismo nivel de simultaneidad en la base de datos de desarrollo y producción) y, por ejemplo, se puede reducir el número de núcleos de CPU. Las configuraciones de recuperación ante desastres también pueden reducirse en tamaño si su función principal es mantenerse al día con la replicación y se espera que la configuración de recuperación ante desastres deba escalarse (tanto verticalmente, aumentando el tamaño de la instancia como horizontalmente, agregando más réplicas). antes de que el tráfico pueda redirigirse a él.
Réplicas retrasadas
Algunas de las réplicas pueden retrasarse:es una muy buena forma de reducir el tiempo de recuperación si se han perdido datos, pero las convierte en muy malas candidatas maestras. Si una réplica se retrasa 30 minutos, perderá esos 30 minutos de transacciones o tendrá que esperar (probablemente no 30 minutos, ya que lo más probable es que la réplica pueda ponerse al día más rápido) para que la réplica aplique todas las transacciones retrasadas. ClusterControl le permite elegir si desea esperar o si desea realizar una conmutación por error de inmediato, pero esto funcionaría bien con un retraso muy pequeño:decenas de segundos como máximo. Si se supone que la conmutación por error demorará unos minutos, simplemente no tiene sentido usar una réplica de este tipo y, por lo tanto, es una buena idea incluirla en la lista negra.
Centro de datos diferente
Mencionamos configuraciones de DR reducidas, pero incluso si su segundo centro de datos se escala al tamaño de la producción, aún puede ser una buena idea mantener las conmutaciones por error dentro de un único DC solamente. Para empezar, sus hosts de aplicaciones activos pueden estar ubicados en el centro de datos principal, por lo que mover el maestro a un controlador de dominio en espera aumentaría significativamente la latencia para las consultas de escritura. Además, en caso de una división de la red, es posible que desee manejar esta situación manualmente. MySQL no tiene un mecanismo de quórum incorporado, por lo tanto, es un poco complicado manejar correctamente (de manera automática) la pérdida de red entre dos centros de datos.
