sql >> Base de Datos >  >> RDS >> MariaDB

Pasos a seguir si tiene una interrupción de MySQL

Una interrupción de MySQL simplemente significa que su servicio MySQL no es accesible o no responde desde la perspectiva del otro. Las interrupciones pueden ser originadas por un montón de causas posibles..

  • Problema de red:problema de conectividad, conmutador, enrutamiento, resolución, nivel de equilibrador de carga.
  • Problema de recursos:si ha alcanzado el límite de recursos o el cuello de botella.
  • Configuración incorrecta:permiso o propiedad incorrectos, variable desconocida, contraseña incorrecta, cambio de privilegio.
  • Bloqueo:el bloqueo global o de tabla evita que otros accedan a los datos.

En esta publicación de blog, veremos algunos pasos a seguir si tiene una interrupción de MySQL (entorno Linux).

Paso uno:obtener el código de error

Cuando tiene una interrupción, su aplicación arrojará algunos errores y excepciones. Estos errores suelen venir con un código de error, que le dará una idea aproximada de lo que está enfrentando y qué hacer a continuación para solucionar el problema y recuperar la interrupción.

Para obtener más detalles sobre el error, consulte las páginas Código de error de MySQL o Código de error de MariaDB respectivamente para averiguar qué significa el error.

Paso dos:¿Se está ejecutando el servidor MySQL?

Inicie sesión en el servidor a través de la terminal y vea si el demonio MySQL se está ejecutando y escuchando el puerto correcto. En Linux, uno haría lo siguiente:

En primer lugar, compruebe el proceso de MySQL:

$ ps -ef | grep -i mysql

Deberías recibir algo a cambio. De lo contrario, MySQL no se está ejecutando. Si MySQL no se está ejecutando, intente iniciarlo:

$ systemctl start mysql # systemd

$ service mysql start # sysvinit/upstart

$ mysqld_safe # manual

Si ve un error en el paso anterior, debe consultar el registro de errores de MySQL, que varía según el sistema operativo y la configuración de variables de MySQL para log_error en el archivo de configuración de MySQL. Para el servidor basado en RedHat, el archivo normalmente se encuentra en:

$ cat /var/log/mysqld.log

Preste atención a las líneas más recientes con nivel de registro "[Error]". Algunas líneas etiquetadas con "[Advertencia]" podrían indicar algunos problemas, pero son bastante poco comunes. La mayoría de las veces, los errores de configuración y los problemas de recursos se pueden detectar desde aquí.

Si MySQL se está ejecutando, verifique si está escuchando el puerto correcto:

$ netstat -tulpn | grep -i mysql

tcp6       0 0 :::3306                 :::* LISTEN   1089/mysqld

Obtendría el nombre de proceso "mysqld", escuchando en todas las interfaces (:::3306 o 0.0.0.0:3306) en el puerto 3306 con PID 1089 y el estado es "LISTEN". Si ve que la línea anterior muestra 127.0.0.1:3306, MySQL solo está escuchando localmente. Es posible que deba cambiar el valor de bind_address en el archivo de configuración de MySQL para escuchar todas las direcciones IP, o simplemente comentar en la línea.

Paso tres:compruebe si hay problemas de conectividad

Si el servidor MySQL está funcionando bien sin errores dentro del registro de errores de MySQL, la posibilidad de que ocurran problemas de conectividad es bastante alta. Comience comprobando la conectividad con el host a través de ping (si ICMP está habilitado) y telnet al servidor MySQL desde el servidor de aplicaciones:

(application-server)$ ping db1.mydomain.com

(application-server)$ telnet db1.mydomain.com 3306

Trying db1.mydomain.com...

Connected to 192.168.0.16.

Escape character is '^]'.

O

5.6.46-86.2sN&nz9NZ�32?&>H,EV`_;mysql_native_password

Debería ver algunas líneas en la salida de telnet si puede conectarse al puerto MySQL. Ahora, intente una vez más utilizando el cliente MySQL desde el servidor de aplicaciones:

(application-server)$ mysql -u db_user -p -h db1.mydomain.com -P3306

ERROR 1045 (28000): Access denied for user 'db_user'@'db1.mydomain.com' (using password: YES)

En el ejemplo anterior, el error nos brinda un poco de información sobre qué hacer a continuación. Lo anterior probablemente porque alguien ha cambiado la contraseña de "db_user" o la contraseña de este usuario ha caducado. Este es un comportamiento bastante normal de MySQL 5.7. 4 y posteriores, donde la política de caducidad automática de contraseñas está habilitada de forma predeterminada con un límite de 360 ​​días, lo que significa que todas las contraseñas caducan una vez al año.

Paso cuatro:verifique la lista de procesos de MySQL

Si MySQL funciona bien sin problemas de conectividad, consulte la lista de procesos de MySQL para ver qué procesos se están ejecutando actualmente:

mysql> SHOW FULL PROCESSLIST;

+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+

| Id  | User | Host      | db | Command | Time | State | Info                  | Rows_sent | Rows_examined |

+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+

| 117 | root | localhost | NULL | Query   | 0 | init | SHOW FULL PROCESSLIST |       0 | 0 |

+-----+------+-----------+------+---------+------+-------+-----------------------+-----------+---------------+

1 row in set (0.01 sec)

Preste atención a la columna Información y Hora. Algunas operaciones de MySQL pueden ser lo suficientemente destructivas como para que la base de datos se detenga y deje de responder. Las siguientes instrucciones SQL, si se ejecutan, podrían bloquear el acceso de otros a la base de datos o la tabla (lo que podría provocar una breve interrupción del servicio MySQL desde la perspectiva de la aplicación):

  • LIMPIAR TABLAS CON BLOQUEO DE LECTURA
  • TABLA DE BLOQUEO...
  • ALTERAR TABLA...

Algunas transacciones de ejecución prolongada también podrían detener otras, lo que eventualmente provocaría tiempos de espera para otras transacciones que esperan acceder a los mismos recursos. Puede eliminar la transacción ofensiva para permitir que otros accedan a las mismas filas o volver a intentar las transacciones en cola después de que finalice la transacción larga.

Conclusión

El monitoreo proactivo es realmente importante para minimizar el riesgo de interrupción de MySQL. Si su base de datos es administrada por ClusterControl, todos los aspectos mencionados se monitorean automáticamente sin ninguna configuración adicional por parte del usuario. Recibirá alarmas en su bandeja de entrada para detecciones de anomalías como consultas de ejecución prolongada, configuración incorrecta del servidor, recursos que exceden el umbral y muchos más. Además, ClusterControl intentará recuperar automáticamente su servicio de base de datos si algo sale mal con el host o la red.

También puede obtener más información sobre la recuperación ante desastres de MySQL y MariaDB leyendo nuestro documento técnico.