En nuestro blog anterior sobre los paneles de SCUMM, analizamos el panel de información general de MySQL. La nueva versión de ClusterControl (ver. 1.7) ofrece una serie de gráficos de alta resolución de métricas útiles, y analizamos el significado de cada una de las métricas y cómo lo ayudan a solucionar problemas en su base de datos. En este blog, veremos el tablero de MySQL Replication. Procedamos con los detalles de este tablero sobre lo que tiene para ofrecer.
Panel de replicación de MySQL
El panel de replicación de MySQL ofrece conjuntos de gráficos muy sencillos que facilitan el monitoreo de su maestro y réplica (s) de MySQL. Comenzando desde arriba, muestra las variables e información más importantes para determinar el estado de la(s) réplica(s) o incluso del maestro. Este tablero ofrece una parte muy útil al inspeccionar la salud de los esclavos o un maestro en la configuración maestro-maestro. También se puede verificar en este tablero la creación del registro binario del maestro y determinar la dimensión general, en términos del tamaño generado, en un período de tiempo determinado.
Lo primero en este panel de control es presentarle la información más importante que podría necesitar con respecto al estado de su réplica. Vea el gráfico a continuación:
Básicamente, le mostrará el IO_Thread, SQL_Thread, el error de replicación del subproceso esclavo y si tiene habilitada la variable de solo lectura. De la captura de pantalla de muestra anterior, toda la información muestra que mi esclavo 192.168.70.20 está saludable y funcionando normalmente.
Además, ClusterControl también tiene información para recopilar si va a Clúster -> Descripción general. Desplácese hacia abajo y podrá ver el siguiente gráfico:
Otro lugar para ver la configuración de replicación es la vista de topología de la configuración de replicación, accesible en Clúster -> Topología. Brinda, de un vistazo rápido, una vista de los diferentes nodos en la configuración, sus funciones, el retraso de replicación, el GTID recuperado y más. Vea el gráfico a continuación:
Además de esto, la Vista de topología también muestra todos los diferentes nodos que forman parte de su clúster de base de datos, ya sean nodos de base de datos, balanceadores de carga (ProxySQL/MaxScale/HaProxy) o árbitros (garbd), así como las conexiones entre ellos. ClusterControl descubre los nodos, las conexiones y sus estados. Dado que ClusterControl monitorea continuamente los nodos y mantiene información de estado, cualquier cambio en la topología se refleja en la interfaz web. En caso de que se informe una falla de los nodos, puede usar esta vista junto con los paneles de SCUMM y ver qué impacto podría tener.
La Vista de topología tiene cierta similitud con Orchestrator en la que puede administrar los nodos, cambiar maestros arrastrando y soltando el objeto en el maestro deseado, reiniciar nodos y sincronizar datos. Para obtener más información sobre nuestra Vista de topología, le sugerimos que lea nuestro blog anterior:"Visualización de su topología de clúster en ClusterControl".
Procedamos ahora con los gráficos.
-
Retraso en la replicación de MySQL
Este gráfico es muy familiar para cualquiera que administre MySQL, especialmente para aquellos que trabajan diariamente en su configuración maestro-esclavo. Este gráfico tiene las tendencias de todos los retrasos registrados durante un intervalo de tiempo específico especificado en este tablero. Siempre que queramos verificar el tiempo de caída periódica que tiene nuestra réplica, entonces este gráfico es bueno para mirar. Hay ciertas ocasiones en las que una réplica puede retrasarse por razones extrañas, como que su RAID tiene un BBU degradado y necesita un reemplazo, una tabla no tiene una clave única pero no en el maestro, un escaneo de tabla completo no deseado o un escaneo de índice completo, o una consulta incorrecta fue dejado en ejecución por un desarrollador. Este también es un buen indicador para determinar si el retraso del esclavo es un problema clave, entonces es posible que desee aprovechar la replicación paralela. -
Tamaño de binlog
Estos gráficos están relacionados entre sí. El gráfico Tamaño del registro binario le muestra cómo su nodo genera el registro binario y ayuda a determinar su dimensión según el período de tiempo que está escaneando. -
Datos de Binlog escritos por hora
Los datos de Binlog escritos por hora son un gráfico basado en el día actual y el día anterior registrado. Esto puede ser útil siempre que desee identificar qué tan grande es su nodo que acepta escrituras, que luego puede usar para planificar la capacidad.
-
Binlogs Count
Supongamos que espera un alto tráfico para una semana determinada. Desea comparar la cantidad de escrituras que pasan a través de su maestro y esclavos con la semana anterior. Este gráfico es muy útil para este tipo de situación:para determinar qué tan altos fueron los registros binarios generados en el maestro o incluso en los esclavos si la variable log_slave_updates está habilitada. También puede usar este indicador para determinar los datos de registro binarios de maestro frente a esclavos generados, especialmente si está filtrando algunas tablas o esquemas (replicate_ignore_db, replicate_ignore_table, replicate_wild_do_table) en sus esclavos que se generaron mientras log_slave_updates estaba habilitado. -
Binlogs creados cada hora
Este gráfico es una descripción general rápida para comparar la creación de binlogs cada hora desde ayer y la fecha de hoy. -
Espacio de registro de retransmisión
Este gráfico sirve como base de los registros de retransmisión generados a partir de su réplica. Cuando se usa junto con el gráfico MySQL Replication Delay, ayuda a determinar qué tan grande es la cantidad de registros de retransmisión generados, lo que el administrador debe considerar en términos de disponibilidad de disco de la réplica actual. Puede causar problemas cuando su esclavo se está retrasando rigurosamente y está generando una gran cantidad de registros de retransmisión. Esto puede consumir su espacio en disco rápidamente. Hay ciertas situaciones en las que, debido a una gran cantidad de escrituras del maestro, el esclavo/réplica se retrasará enormemente, por lo que generar una gran cantidad de registros puede causar algunos problemas graves en esa réplica. Esto puede ayudar al equipo de operaciones cuando hable con su gerencia sobre la planificación de la capacidad. -
Registro de retransmisión escrito cada hora
Igual que el espacio de registro de retransmisión, pero agrega una descripción general rápida para comparar los registros de retransmisión escritos desde ayer y la fecha de hoy.
Conclusión
Aprendió que usar SCUMM para monitorear su replicación de MySQL agrega más productividad y eficiencia al equipo de operaciones. Usar las funciones que tenemos de versiones anteriores combinadas con los gráficos provistos con SCUMM es como ir al gimnasio y ver mejoras masivas en su productividad. Esto es lo que SCUMM puede ofrecer:¡monitoreo con esteroides! (ahora, ¡no estamos sugiriendo que debas tomar esteroides cuando vayas al gimnasio!)
En la Parte 3 de este blog, hablaré sobre las métricas de InnoDB y los paneles de esquema de rendimiento de MySQL.
