MariaDB
 sql >> Base de données >  >> RDS >> MariaDB

Étapes à suivre en cas de panne de MySQL

Une panne de MySQL signifie simplement que votre service MySQL n'est pas accessible ou ne répond pas du point de vue de l'autre. Les pannes peuvent être causées par un tas de causes possibles..

  • Problème de réseau :problème de connectivité, commutateur, routage, résolveur, niveau d'équilibrage de charge.
  • Problème de ressources :si vous avez atteint la limite de ressources ou un goulot d'étranglement.
  • Mauvaise configuration :autorisation ou propriété erronée, variable inconnue, mot de passe erroné, privilège modifié.
  • Verrouillage :le verrouillage global ou de table empêche les autres d'accéder aux données.

Dans cet article de blog, nous examinerons quelques étapes à suivre si vous rencontrez une panne de MySQL (environnement Linux).

Première étape :obtenir le code d'erreur

Lorsque vous avez une panne, votre application génère des erreurs et des exceptions. Ces erreurs sont généralement accompagnées d'un code d'erreur, qui vous donnera une idée approximative de ce à quoi vous êtes confronté et de ce qu'il faut faire ensuite pour résoudre le problème et récupérer la panne.

Pour obtenir plus de détails sur l'erreur, consultez respectivement les pages Code d'erreur MySQL ou Code d'erreur MariaDB pour comprendre ce que signifie l'erreur.

Étape 2 :le serveur MySQL est-il en cours d'exécution ?

Connectez-vous au serveur via le terminal et voyez si le démon MySQL est en cours d'exécution et écoute le bon port. Sous Linux, on ferait ce qui suit :

Tout d'abord, vérifiez le processus MySQL :

$ ps -ef | grep -i mysql

Vous devriez obtenir quelque chose en retour. Sinon, MySQL ne fonctionne pas. Si MySQL n'est pas en cours d'exécution, essayez de le démarrer :

$ systemctl start mysql # systemd

$ service mysql start # sysvinit/upstart

$ mysqld_safe # manual

Si vous voyez une erreur à l'étape ci-dessus, vous devriez consulter le journal des erreurs MySQL, qui varie en fonction du système d'exploitation et de la configuration de la variable MySQL pour log_error dans le fichier de configuration MySQL. Pour les serveurs basés sur RedHat, le fichier se trouve généralement à :

$ cat /var/log/mysqld.log

Faites attention aux lignes les plus récentes avec le niveau de journal "[Error]". Certaines lignes étiquetées avec "[Avertissement]" peuvent indiquer des problèmes, mais ceux-ci sont assez rares. La plupart du temps, les erreurs de configuration et les problèmes de ressources peuvent être détectés à partir d'ici.

Si MySQL est en cours d'exécution, vérifiez s'il écoute le bon port :

$ netstat -tulpn | grep -i mysql

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

Vous obtiendrez le nom de processus "mysqld", écoutant sur toutes les interfaces (:::3306 ou 0.0.0.0:3306) sur le port 3306 avec le PID 1089 et l'état est "LISTEN". Si vous voyez que la ligne ci-dessus affiche 127.0.0.1:3306, MySQL n'écoute que localement. Vous devrez peut-être modifier la valeur bind_address dans le fichier de configuration MySQL pour écouter toutes les adresses IP, ou simplement commenter la ligne.

Étape 3 :Vérifiez les problèmes de connectivité

Si le serveur MySQL fonctionne correctement sans erreur dans le journal des erreurs MySQL, la probabilité que des problèmes de connectivité se produisent est assez élevée. Commencez par vérifier la connectivité à l'hôte via ping (si ICMP est activé) et telnet au serveur MySQL depuis le serveur d'application :

(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

Vous devriez voir quelques lignes dans la sortie telnet si vous pouvez vous connecter au port MySQL. Maintenant, réessayez en utilisant le client MySQL du serveur d'application :

(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)

Dans l'exemple ci-dessus, l'erreur nous donne un peu d'informations sur ce qu'il faut faire ensuite. Ce qui précède probablement parce que quelqu'un a changé le mot de passe pour "db_user" ou que le mot de passe de cet utilisateur a expiré. C'est un comportement plutôt normal de MySQL 5.7. 4 et versions ultérieures, où la politique d'expiration automatique des mots de passe est activée par défaut avec un seuil de 360 jours, ce qui signifie que tous les mots de passe expireront une fois par an.

Étape 4 :Vérifiez la liste des processus MySQL

Si MySQL fonctionne correctement sans problèmes de connectivité, consultez la liste des processus MySQL pour voir quels processus sont en cours d'exécution :

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)

Faites attention aux colonnes Info et Heure. Certaines opérations MySQL peuvent être suffisamment destructrices pour bloquer la base de données et ne plus répondre. Les instructions SQL suivantes, si elles sont exécutées, pourraient empêcher d'autres personnes d'accéder à la base de données ou à la table (ce qui pourrait entraîner une brève interruption du service MySQL du point de vue de l'application) :

  • FLUSH TABLES WITH READ LOCK
  • VERROUILLER LA TABLE...
  • ALTER TABLE ...

Certaines transactions de longue durée pourraient également en bloquer d'autres, ce qui finirait par entraîner des délais d'attente pour d'autres transactions en attente d'accéder aux mêmes ressources. Vous pouvez soit tuer la transaction offensive pour permettre aux autres d'accéder aux mêmes lignes, soit réessayer les transactions de mise en file d'attente une fois la longue transaction terminée.

Conclusion

La surveillance proactive est vraiment importante pour minimiser le risque de panne de MySQL. Si votre base de données est gérée par ClusterControl, tous les aspects mentionnés sont surveillés automatiquement sans aucune configuration supplémentaire de la part de l'utilisateur. Vous recevrez des alarmes dans votre boîte de réception pour les détections d'anomalies telles que les requêtes de longue durée, la mauvaise configuration du serveur, les ressources dépassant le seuil et bien d'autres. De plus, ClusterControl tentera automatiquement de récupérer votre service de base de données en cas de problème avec l'hôte ou le réseau.

Vous pouvez également en savoir plus sur MySQL et MariaDB Disaster Recovery en lisant notre livre blanc.