MySQL 101: Clasificación básica del servidor MySQL

Entonces tu servidor MySQL falla. Qué estás haciendo ahora ? Cuando un servidor falla, en mi opinión, hay dos pasos que son esenciales y ambos son extremadamente importantes y no deben pasarse por alto:

  1. Guarde la información de diagnóstico para la determinación del análisis de causa raíz (RCA).
  2. Restaure el servidor y funcionará.

Demasiadas personas se apresuran al paso n.° 2 y pierden los diagnósticos relevantes del paso n.° 1. Del mismo modo, demasiadas personas pasan demasiado tiempo en el paso n.º 1 y vuelven al paso n.º 2 y restablecen el servicio. El objetivo es realizar el diagnóstico lo antes posible para una revisión posterior mientras se restablece el servicio lo antes posible.

Como administrador técnico de cuentas (TAM) y ayudando con las llamadas de restauración del servidor, vi ambos problemas en juego. Los recursos técnicos tienden a colapsar, así que intente comprender la causa del tiempo de inactividad del servidor olvidando que el tiempo de inactividad cuesta dinero a la empresa. El deseo de rastrear los registros del servidor, las métricas de revisión, las métricas del sistema de vertido, etc., puede ser demasiado tentador para aquellos que están preocupados de que se pierdan datos de diagnóstico importantes cuando se restablezca el servicio. Esta es una preocupación válida, pero debe haber un término medio.

Por el contrario, muchos, especialmente los de gestión, requieren que el servicio se restablezca de inmediato para continuar con las funciones comerciales. Por supuesto, después de que se restablece el servicio, surge la demanda de un RCA. Desafortunadamente, muchas métricas y algunos registros se pierden cuando un servidor falla. A continuación se encuentran las pautas básicas sobre qué métricas incluir para MySQL. Los pasos no están en un orden particular.

  1. Guarde una copia del registro de errores de MySQL.

  2. Haga una copia del archivo de configuración de MySQL.

  3. Haga una copia de los registros de su sistema y guárdelos en algún lugar del almacenamiento persistente en un lugar que no se sobrescriba. Considere hacer algo como lo siguiente en Linux:

  4. Si MySQL siempre funciona y puede iniciar sesión, use algunas métricas de MySQL. Desea guardar la salida en archivos en algún lugar.

  5. Si se está ejecutando MySQL y tiene Percona Toolkit, debería obtener alguna salida de pt-stalk.

  6. Si tiene espacio y tiempo, una copia de los archivos de la base de datos (directorio de datos de MySQL) podría ser útil. Por supuesto, para muchas instalaciones será imposible obtener todos los archivos de datos. Si tiene una base de datos pequeña y el espacio y el tiempo lo permiten, puede ser mejor obtener todos los archivos por si acaso.

  7. Copie los registros de la base de datos y guárdelos en un lugar seguro para revisarlos más adelante. Los sistemas como Percona XtraDB Cluster (PXC) crean archivos GRA durante un problema que puede ser realmente útil para determinar la causa raíz. Al combinar el archivo de encabezado de GRA con el contenido de los archivos de registro de GRA, puede usar el comando mysqlbinlog para recuperar registros de transacciones que están causando problemas. Puede encontrar más información en uno de nuestros blogs más antiguos aquí
    Percona XtraDB Cluster (PXC): y los archivos GRA_*.Log?.

  8. Guarde las métricas del sistema relevantes para el uso de CPU, E/S y memoria:

  9. Guardar información del sistema.

  10. Si tienes un Toolkit de Percona, lo siguiente te será de gran utilidad:

  11. Obtenga diagnósticos de hardware.

No hace falta decir que sería mejor escribir lo anterior en un script bash útil que pueda ejecutar cuando haya un problema. Solo asegúrese de probar el script antes de que ocurra un problema.

Una vez más, el objetivo es conservar datos de diagnóstico útiles que puedan ser útiles para determinar la causa del problema más adelante después de que se restablezca el servicio. ¡Simplemente no se deje atrapar por los diagnósticos anteriores! Claro, más datos es mejor, pero lo anterior es un excelente punto de partida. A medida que pasa el tiempo, puede comprender que desea tener otras métricas y puede agregarlas a su script o al Procedimiento operativo estándar (SOP).

Por supuesto, agregar monitoreo es como Supervisión y Gestión de Percona (PMM) sería una excelente opción que puede ahorrar mucho tiempo y captar aún más tendencias con el tiempo, lo que puede ser extremadamente útil.

Con los diagnósticos anteriores, obtendrá mucha información en caso de que surja un problema para encontrar la causa raíz. Ahora, puede pasar por los diagnósticos. Por supuesto, si necesitas ayuda con esto, Percona también puede ayudarte aquí.

Percona Distribution for MySQL es la solución MySQL de código abierto más completa, estable, escalable y segura disponible, que proporciona entornos de base de datos de nivel empresarial para sus aplicaciones comerciales más críticas… ¡y es de uso gratuito!

Descarga Percona Distribution para MySQL hoy

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario