Depuis quelques jours l’un des mes serveurs WordPress fonctionnant sous un stack LAMP (Linux / Apache / MariaDB / PHP) connait des dysfonctionnements au niveau du service de base de données MariaDB. Tous les jours aléatoirement mon serveur est HS et une erreur de connexion à la base de donnée s’affiche lorsque je suis sur le site (Error establishing a database connexion)
Il y a de nombreuses raisons pour lesquelles un service MariaDB peut s’arrêter régulièrement sur un serveur Linux mais j’ai déjà ma petite idée sur la raison du problème.
- Erreur de configuration : Des erreurs de configuration dans le fichier my.cnf peuvent entraîner l’arrêt du service MariaDB. Cela peut inclure des paramètres incorrects ou conflictuels.
- Problèmes de ressources système : Si le serveur sur lequel MariaDB s’exécute manque de ressources telles que la mémoire, le CPU ou le stockage, cela peut entraîner l’arrêt du service.
- Erreurs d’application ou de requête : Des erreurs dans les applications utilisant MariaDB ou dans les requêtes exécutées peuvent entraîner des plantages ou des erreurs fatales qui provoquent l’arrêt du service.
- Problèmes de permissions : Si les permissions des fichiers ou répertoires liés à MariaDB sont incorrectes, cela peut empêcher le service de démarrer correctement.
- Problèmes de connectivité réseau : Si le serveur MariaDB ne peut pas se connecter au réseau, par exemple en raison d’un problème de configuration réseau ou d’une défaillance matérielle du réseau, cela peut entraîner l’arrêt du service.
- Problèmes de journalisation : Si les fichiers de journalisation de MariaDB sont corrompus, inaccessibles ou atteignent leur taille maximale, cela peut entraîner l’arrêt du service.
- Problèmes de compatibilité : Une incompatibilité entre la version de MariaDB, le système d’exploitation ou les bibliothèques système peut provoquer des erreurs et des plantages du service.
- Problèmes matériels : Des pannes matérielles telles que des défaillances du disque dur, de la mémoire ou de l’alimentation peuvent entraîner l’arrêt du service MariaDB.
Il s’agit d’un nouveau VPS que je viens de mettre en production pour un nouveau projet de site Web et ce VPS monte progressivement en charge. J’ai ajouté des extensions WordPress, je commence à publier des articles et donc j’ai une forte présomption sur un problème de ressources systèmes.
La majorité de mes sites Web sont hébergés chez IONOS depuis plus de 15 ans (Anciennement 1&1) c’est une boîte solide, les services sont de très bonne qualité, et j’apprécie de pouvoir parler à un technicien compétent en cas de besoin.
Lorsque je démarre un nouveau projet je commence par une petite machine de base, en l’occurrence pour ce nouveau projet j’ai simplement commandé un VPS S avec 1 vCore et 512 Mo de RAM. C’est largement suffisamment pour un site statique mais si vous souhaitez déployer un stack LAMP avec une base de données ça va être un peu juste car les services de base de données consomment beaucoup de RAM.
Donc avant toute chose j’ai ouvert une session PuTTY sur mon VPS et j’ai tapé la commande free -m afin de vérifier la consommation de la mémoire.
root@localhost:~# free -m
Je n’ai pas gardé le résultat de cette commande pour vous montrer mais ça rentre au chausse pied et il est évident que la moindre charge risque de poser problème.
Il est probable que je sois obligé de demander la migration de mon abonnement S vers du M afin de disposer de 2 vCore et 2 Go de RAM, c’est parfait pour un site WordPress de quelques milliers de visiteurs journaliers et c’est ma cible. L’avantage est que je ne perdrai pas la promotion IONOS.
Avant cela je vais d’abord analyser les logs MariaDB sur mon serveur Linux sous Debian 11.
Comment vérifiez les logs de MariaDB
Normalement les logs de MariaDB sont dans le dossier /var/log/mysql/ mais mon répertoire est vide. Donc soit les fichiers de log ont été déplacés vers un autre emplacement, soit ils n’ont pas été créés.
Je vais vérifier cela dans le fichier de configuration de MariaDB
root@localhost:~# nano /etc/mysql/mariadb.conf.d/50-server.cnfPour générer les logs il faut vérifier la présence de la ligne suivante sous la section [mysqld]
log_error = /var/log/mysql/error.logPuis redémarré le service MariaDB :
sudo systemctl restart mariadbAprès cela , vous devriez être en mesure de trouver les fichiers de log dans le répertoire que vous avez spécifié dans la configuration de MariaDB. Vous pouvez les visualiser avec la commande less ou tail :
sudo less /var/log/mysql/error.log
ou
sudo tail -f /var/log/mysql/error.log
Ces commandes affichent les dernières lignes du fichier en temps réel, ce qui vous permet de surveiller les messages d’erreur de MariaDB pendant le fonctionnement du service.
Dans mon cas le fichier de configuration 50-server.cnf contient l’information suivante:
When running under systemd, error logging goes via stdout/stderr to journaldCela qui signifie que les fichiers journaux d’erreurs sont dirigés vers journald, qui est utilisé par systemd pour la journalisation.
Donc les logs sont bien générés mais pas via la façon habituelle.
Pour visualiser les messages journalisés dans journald, il faut utiliser la commande journalctl.
Voici quelques exemples d’utilisation de cette commande :
Pour voir les messages système les plus récents :
journalctl -xe
Pour voir les messages de MariaDB uniquement :
journalctl -u mariadb
Pour voir les messages de MariaDB à partir d’une heure et date spécifiques :
journalctl -u mariadb --since "2023-05-01 10:00:00"
Pour voir les messages de MariaDB avec plus de détails :
journalctl -u mariadb -o verbose
Il est également possible d’ajouter l’option -f à la commande pour afficher les messages en temps réel, ce qui est utile pour surveiller le service MariaDB en temps réel :
journalctl -u mariadb -f
Attaques sur mon VPS !
Dès lors que vous allez publier des services en ligne sur Internet ils seront massivement attaqués.
En affichant mes logs avec les commandes précédentes je n’ai pas été déçu, voici juste un extrait mais j’ai des pages entières de tentatives d’accès à mon VPS via le service SSH. Pas de panique c’est normal et il faut juste savoir comment réagir.
May 09 20:32:57 localhost sshd[1804]: Received disconnect from 209.141.60.201 port 51814:11: Bye Bye [preauth]
May 09 20:32:57 localhost sshd[1804]: Disconnected from invalid user root 209.141.60.201 port 51814 [preauth]
May 09 20:32:57 localhost sshd[1802]: Received disconnect from 103.250.11.82 port 39720:11: Bye Bye [preauth]
May 09 20:32:57 localhost sshd[1802]: Disconnected from invalid user root 103.250.11.82 port 39720 [preauth]
May 09 20:33:09 localhost sshd[1819]: Invalid user yan from 119.202.128.28 port 33460
May 09 20:33:09 localhost sshd[1819]: pam_unix(sshd:auth): check pass; user unknown
May 09 20:33:09 localhost sshd[1819]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=119.202.128.28
May 09 20:33:11 localhost sshd[1819]: Failed password for invalid user yan from 119.202.128.28 port 33460 ssh2
May 09 20:33:11 localhost sshd[1821]: User root from 200.52.65.41 not allowed because not listed in AllowUsersMon VPS est bien protégé et j’ai même limité l’accès SSH à l’adresse IP de ma station de travail.
Néanmoins vu l’intensité des tentatives de connexions il est évident que cela impacte forcément les ressources de mon VPS et je rappelle que le but de cet article est régler mon problème sur le service MariaDB et que je suspecte fortement la consommation de ressources.
Je vais donc mettre une règle de filtrage au niveau du service Firewall proposé par IONOS. Ce service est inclus avec les VPS. Par défaut il autorise les accès sur les ports 22, 80 et 443. Je vais donc modifier la règle sur le port 22 utilisé pour les accès SSH et autoriser uniquement l’adresse IP de ma station d’administration personnelle. L’avantage est que les tentatives de connexions n’atteindront plus directement mon VPS et celui ci sera donc moins sollicité.
En affichant de nouveau le journal je constate qu’il ne fait plus état de demande de connexions intempestives 👌
Comment régler un problème de mémoire dans MariaDB
Je vais maintenant resserrer mon analyse sur MariaDB, comme le service plante tous les jours je vais juste afficher les logs de la dernière journée :
root@localhost:~# journalctl -u mariadb --since "2023-05-09 10:00:00"
Le journal système indique que le processus principal de MariaDB a été tué par le gestionnaire de mémoire OOM (out-of-memory killer) car il a consommé trop de mémoire. Ceci suggère que le serveur MariaDB a consommé plus de mémoire que le système ne pouvait en allouer.
-- Journal begins at Wed 2021-09-15 09:02:55 UTC, ends at Tue 2023-05-09 20:48:48 UTC.--
May 09 18:54:18 localhost systemd[1]: mariadb.service: A process of this unit has been killed by the OOM killer.
May 09 18:54:19 localhost systemd[1]: mariadb.service: Main process exited, code=killed, status=9/KILL
May 09 18:54:19 localhost systemd[1]: mariadb.service: Failed with result 'oom-kill'.
May 09 18:54:19 localhost systemd[1]: mariadb.service: Consumed 6min 39.469s CPU time.
-- Boot 278f2d53cbd64e9caa43d940319d6805 --Je vais donc limiter la consommation mémoire de MariaDB
Pour limiter la consommation mémoire de MariaDB, il est possible d’agir sur certains paramètres dans le fichier de configuration my.cnf.
Voici quelques options à considérer pour réduire la consommation mémoire de MariaDB :
innodb_buffer_pool_size: Cette option contrôle la quantité de mémoire allouée au buffer pool InnoDB qui est utilisé pour stocker les données et les index en mémoire.max_connections: Cette option définit le nombre maximum de connexions simultanées autorisées à la base de données.key_buffer_size: Cette option contrôle la quantité de mémoire allouée au cache d’index MyISAM.table_definition_cache: Cette option contrôle la taille du cache de définition de table utilisé pour stocker les informations de structure de table en mémoire.
Pour modifier ces options, j’édite le fichier my.cnf qui se trouve dans le répertoire /etc/mysql/. Vous pouvez utiliser un éditeur de texte pour ouvrir le fichier et modifier les options en conséquence mais vous pouvez aussi utiliser un outil graphique comme WinSCP pour vous faciliter la tâche.
Mon site WordPress va avoir moins de 1000 visiteurs par jour. Voici comment je vais modifier mon fichier my.cnf avec en gras la section que j’ai ajouté.
[client-server]
# Port or socket location where to connect
# port = 3306
socket = /run/mysqld/mysqld.sock
# Import all .cnf files from configuration directory
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/
[mysqld]
# Limit memory usage
key_buffer_size = 0
innodb_buffer_pool_size = 256M
query_cache_size = 0
table_open_cache = 64
Puis redémarrez MariaDB via la commande :
root@localhost:~# sudo systemctl restart mariadbVérifier l’état du service pour confirmer que MariaDB est en cours d’exécution :
root@localhost:~# sudo systemctl status mariadb
Si tout se passe bien vous devriez voir un message indiquant que le service est “active (running)”.
Conclusion
Dans cet article, je vous ai montré comment j’ai résolu le problème du service MariaDB qui s’arrêtait régulièrement sur mon serveur VPS. Vous avez appris comment vérifier l’état du service, comment analyser les logs, comment optimiser la configuration de MariaDB et comment redémarrer le service automatiquement en cas de crash.
J’espère que ces astuces vous seront utiles si vous rencontrez le même problème que moi. N’hésitez pas à me laisser un commentaire si vous avez des questions ou des suggestions. Et si vous avez aimé cet article, partagez le avec vos amis sur les réseaux sociaux !