La mayoría de los DBA realizan controles de salud en sus bases de datos de vez en cuando. Por lo general, sucedería diariamente o semanalmente. Anteriormente discutimos por qué tales controles son importantes y qué deben incluir.
Para asegurarse de que sus sistemas estén en buenas condiciones, necesitará revisar mucha información:estadísticas de host, estadísticas de MySQL, estadísticas de carga de trabajo, estado de las copias de seguridad, paquetes de base de datos, registros, etc. Dichos datos deben estar disponibles en todos los entornos monitoreados adecuadamente, aunque a veces se encuentran dispersos en varias ubicaciones:puede tener una herramienta para monitorear el estado de MySQL, otra herramienta para recopilar estadísticas del sistema, tal vez un conjunto de scripts, por ejemplo, para verificar el estado de MySQL. tus copias de seguridad. Esto hace que las comprobaciones de estado lleven mucho más tiempo del que deberían:el DBA tiene que unir las diferentes piezas para comprender el estado del sistema.
Las herramientas integradas como ClusterControl tienen la ventaja de que todos los bits están ubicados en el mismo lugar (o en la misma aplicación). Todavía no significa que estén ubicados uno al lado del otro:pueden estar ubicados en diferentes secciones de la interfaz de usuario y es posible que un DBA deba pasar algún tiempo haciendo clic en la interfaz de usuario para llegar a todos los datos interesantes.
La idea detrás de la creación de informes operativos es colocar todos los datos más importantes en un solo documento, que se puede revisar rápidamente para comprender el estado de las bases de datos.
Los informes operativos están disponibles en el menú Menú lateral -> Informes operativos:
Una vez que vaya allí, se le presentará una lista de informes creados de forma manual o automática, según un programa predefinido:
Si desea crear un nuevo informe manualmente, utilizará la opción 'Crear'. Elija el tipo de informe, el nombre del clúster (para el informe por clúster), los destinatarios del correo electrónico (opcional, si desea que se le envíe el informe) y ya casi ha terminado:
Los informes también se pueden programar para que se creen periódicamente:
En este momento, hay 5 tipos de informes disponibles:
- Informe de disponibilidad:todos los clústeres.
- Informe de copia de seguridad:todos los clústeres.
- Informe de cambio de esquema:solo clúster basado en MySQL/MariaDB.
- Informe diario del sistema:por grupo.
- Informe de actualización de paquetes:por clúster.
Informe de disponibilidad
Los informes de disponibilidad se centran en la disponibilidad. Incluye tres secciones. Primero, resumen de disponibilidad:
Puede ver información sobre las estadísticas de disponibilidad de sus bases de datos, el tipo de clúster, el tiempo total de actividad y de inactividad, el estado actual del clúster y cuándo cambió ese estado por última vez.
Otra sección brinda más detalles sobre la disponibilidad de cada clúster. La siguiente captura de pantalla solo muestra uno de los clústeres de la base de datos:
Podemos ver cuándo un nodo cambió de estado y cuál fue la transición. Es un buen lugar para verificar si hubo algún problema reciente con el clúster. Se muestran datos similares en la tercera sección de este informe, donde puede revisar el historial de cambios en el estado del clúster.
Informe de copia de seguridad
El segundo tipo de informe cubre las copias de seguridad de todos los clústeres. Contiene dos secciones:resumen de la copia de seguridad y detalles de la copia de seguridad, donde la primera básicamente le brinda un breve resumen de cuándo se creó la última copia de seguridad, si se completó con éxito o falló, el estado de verificación de la copia de seguridad, la tasa de éxito y el período de retención:
ClusterControl también proporciona ejemplos de políticas de copia de seguridad si encuentra algún clúster de base de datos supervisado ejecutándose sin ninguna copia de seguridad programada o esclavo retrasado configurado. Los siguientes son los detalles de la copia de seguridad:
También puede consultar la lista de copias de seguridad ejecutadas en el clúster con su estado, tipo y tamaño dentro del intervalo especificado. Esto es lo más cerca que puede llegar a estar seguro de que las copias de seguridad funcionan correctamente sin ejecutar una prueba de recuperación completa. Definitivamente recomendamos que dichas pruebas se realicen de vez en cuando. La buena noticia es que ClusterControl admite la restauración y verificación basadas en MySQL en un host independiente en Copia de seguridad -> Restaurar copia de seguridad.
Informe diario del sistema
Este tipo de informe contiene información detallada sobre un clúster en particular. Comienza con un resumen de diferentes alertas relacionadas con el clúster:
La siguiente sección trata sobre el estado de los nodos que forman parte del clúster:
Tiene una lista de los nodos en el clúster, su tipo, rol (maestro o esclavo), estado del nodo, tiempo de actividad y el sistema operativo.
Otra sección del informe es el resumen de la copia de seguridad, igual que discutimos anteriormente. El siguiente presenta un resumen de las principales consultas en el clúster:
Finalmente, vemos una "Descripción general del estado del nodo" en la que se le presentarán gráficos relacionados con las métricas del sistema operativo y MySQL para cada nodo.
Como puede ver, aquí tenemos gráficos que cubren todos los aspectos de la carga en el host:CPU, memoria, red, disco, carga de CPU y disco libre. Esto es suficiente para tener una idea de si algo extraño sucedió recientemente o no. También puede ver algunos detalles sobre la carga de trabajo de MySQL:¿cuántas consultas se ejecutaron, qué tipo de consulta, cómo se accedió a los datos (a través de qué controlador)? Esto, por otro lado, debería ser suficiente para detectar la mayoría de los problemas en el lado de MySQL. Lo que desea ver son todos los picos y depresiones que no ha visto en el pasado. Tal vez se haya agregado una nueva consulta a la mezcla y, como resultado, handler_read_rnd_next se disparó? Tal vez hubo un aumento en la carga de la CPU y una gran cantidad de conexiones podría indicar una mayor carga en MySQL, pero también algún tipo de contención. Un patrón inesperado podría ser bueno para investigar, para que sepa lo que está pasando.
Informe de actualización del paquete
Este informe brinda un resumen de los paquetes disponibles para que el administrador del repositorio los actualice en los hosts monitoreados. Para obtener informes precisos, asegúrese de usar siempre repositorios estables y confiables en cada host. En algunas ocasiones no deseadas, los hosts monitoreados podrían configurarse con un repositorio desactualizado después de una actualización (p. ej., cada versión principal de MariaDB usa un repositorio diferente), un repositorio interno incompleto (p. paquetes de creación nocturna).
La primera sección es el resumen de la actualización:
Resume la cantidad total de paquetes disponibles para la actualización, así como el servicio administrado relacionado para el clúster, como el equilibrador de carga, la dirección IP virtual y el árbitro. A continuación, ClusterControl proporciona una lista detallada de paquetes, agrupados por tipo de paquete para cada host:
Este informe proporciona la versión disponible y puede ayudarnos mucho a planificar nuestra ventana de mantenimiento de manera eficiente. Para actualizaciones críticas como paquetes de seguridad y bases de datos, podríamos priorizarlas sobre actualizaciones no críticas, que podrían consolidarse con otras ventanas de mantenimiento menos prioritarias.
Informe de cambio de esquema
Este informe compara los cambios de la base de datos MySQL/MariaDB seleccionados en la estructura de la tabla que ocurrieron entre dos informes generados diferentes. En las versiones anteriores de MySQL/MariaDB, la operación DDL es una operación no atómica (anterior a 8.0) y requiere una copia completa de la tabla (anterior a 5.6 para la mayoría de las operaciones), bloqueando otras transacciones hasta que se complete. Los cambios de esquema pueden convertirse en un gran dolor una vez que sus tablas obtienen una cantidad significativa de datos y deben planificarse cuidadosamente, especialmente en una configuración en clúster. En un entorno de desarrollo de varios niveles, hemos visto muchos casos en los que los desarrolladores modifican silenciosamente la estructura de la tabla, lo que tiene un impacto significativo en el rendimiento de las consultas.
Para que ClusterControl produzca un informe preciso, se deben configurar opciones especiales dentro del archivo de configuración de CMON para el clúster respectivo:
- dirección_detección_de_cambio_de_esquema - Las comprobaciones se ejecutarán usando SHOW TABLES/SHOW CREATE TABLE para determinar si el esquema ha cambiado. Las comprobaciones se ejecutan en la dirección especificada y tienen el formato HOSTNAME:PORT. Las schema_change_detection_databases también debe establecerse. Se crea un diferencial de una tabla modificada (usando diff).
- esquema_cambio_detección_bases de datos - Lista separada por comas de bases de datos para monitorear los cambios de esquema. Si está vacío, no se realizan comprobaciones.
En este ejemplo, nos gustaría monitorear los cambios de esquema para la base de datos "myapp" y "sbtest" en nuestro clúster de MariaDB con ID de clúster 27. Elija uno de los nodos de la base de datos como el valor de schema_change_detection_address . Para la replicación de MySQL, este debe ser el host maestro o cualquier host esclavo que contenga las bases de datos (en caso de que la replicación parcial esté activa). Luego, dentro de /etc/cmon.d/cmon_27.cnf, agregue las dos líneas siguientes:
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestReinicie el servicio CMON para cargar el cambio:
$ systemctl restart cmonPara el primer y principal informe, ClusterControl solo devuelve el resultado de la recopilación de metadatos, similar al siguiente:
Con el primer informe como referencia, los informes posteriores devolverán el resultado que esperamos:
Tenga en cuenta que solo las tablas nuevas o las tablas modificadas se imprimen en el informe. El primer informe es solo para la recopilación de metadatos para la comparación en las rondas posteriores, por lo que debemos ejecutarlo al menos dos veces para ver la diferencia.
Con este informe, ahora puede recopilar las huellas de la estructura de la base de datos y comprender cómo ha evolucionado su base de datos a lo largo del tiempo.
Reflexiones finales
El informe operativo es una forma integral de comprender el estado de la infraestructura de su base de datos. Está diseñado tanto para el personal operativo como para el gerencial, y puede ser muy útil para analizar las operaciones de su base de datos. Los informes se pueden generar en el lugar o se le pueden enviar por correo electrónico, lo que facilita las cosas si tiene un silo de informes.
Nos encantaría escuchar sus comentarios sobre cualquier otra cosa que le gustaría que se incluyera en el informe, lo que falta y lo que no se necesita.
