Erreur MariaDB

Support Debian
#1

Bonjour,

Mon système: Linux Debian 11.7
mysql Ver 15.1 Distrib 10.5.19-MariaDB
Serveur Apache/2.4.56

J’ai une erreur subite durant l’utilisation de GLPI sur mon serveur:
Un lien vers le serveur SQL n’a pas pu être établi. Veuillez vérifier votre configuration.
Le serveur Mysql est inaccessible. Vérifiez votre configuration.

J’ai constaté l’erreur ci-dessous sur Mariadb:

systemctl status mysql.service
● mariadb.service - MariaDB 10.5.19 database server
    Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
    Active: failed (Result: exit-code) since Tue 2023-09-26 11:56:42 CEST; 1h 9min ago
      Docs: man:mariadbd(8)
            https://mariadb.com/kb/en/library/systemd/
  Main PID: 532 (code=exited, status=1/FAILURE)
    Status: "MariaDB server is down"
       CPU: 211ms

sept. 26 11:56:41 debian11ocs mariadbd[532]: 2023-09-26 11:56:41 0 [Note] InnoDB: Starting shutdown...
sept. 26 11:56:42 debian11ocs mariadbd[532]: 2023-09-26 11:56:42 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
sept. 26 11:56:42 debian11ocs mariadbd[532]: 2023-09-26 11:56:42 0 [ERROR] Plugin 'InnoDB' init function returned error.
sept. 26 11:56:42 debian11ocs mariadbd[532]: 2023-09-26 11:56:42 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
sept. 26 11:56:42 debian11ocs mariadbd[532]: 2023-09-26 11:56:42 0 [Note] Plugin 'FEEDBACK' is disabled.
sept. 26 11:56:42 debian11ocs mariadbd[532]: 2023-09-26 11:56:42 0 [ERROR] Unknown/unsupported storage engine: InnoDB
sept. 26 11:56:42 debian11ocs mariadbd[532]: 2023-09-26 11:56:42 0 [ERROR] Aborting
sept. 26 11:56:42 debian11ocs systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
sept. 26 11:56:42 debian11ocs systemd[1]: mariadb.service: Failed with result 'exit-code'.
sept. 26 11:56:42 debian11ocs systemd[1]: Failed to start MariaDB 10.5.19 database server.

En voulant démarrer Mariadb, j’ai le message ci-dessous:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/run/mysqld/mysqld.so

Je suppose que le système n’a plus assez de place pour lancer les processus…
Ci-dessous les volumes utilisés:

df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev               3,9G       0  3,9G   0% /dev
tmpfs              788M    764K  787M   1% /run
/dev/sda1           23G    5,5G   17G  26% /
tmpfs              3,9G       0  3,9G   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
/dev/sda7          1,8G     52K  1,7G   1% /tmp
/dev/sda5          9,1G    8,6G  3,3M 100% /var
/dev/sda8          423G     80K  401G   1% /home
tmpfs              788M       0  788M   0% /run/user/1000

Si c’est le cas, que faut-il supprimer pour récupérer de l’espace libre… Sans KC le système…
si autre chose, merci de m’indiquer ou chercher…

Merci d’avance

#2

Bonjour

D’apres ce que je vois c’est que le probleme peut venir du répertoire/partition /var .

Que vous disent les logs?

ps: error 2002

#3

c’est effectivement un problème d’espace dans la partition /var contenant /var/lib/mysql.

Il faut soit faire de la place, soit au vue du partitionnement revoir l’installation ou dans un premier temps recréer une partition sur laquelle vous monterez le point de montage /var/lib/mysql (pensez à déplacer les données dessus avant de le monter en lieu et place.

#4

Bonjour Clochette,

oui, j’ai vu cela, en attendant un retour, j’ai supprimer une ancienne sauvegarde de GLPI, et j’ai récupérer un peut d’espace, de ce fait les processus ont été lancées…
mon serveur est reparti…

Ma question:
Est-il possible, si je mets le DD de mon linux en esclave sur un autre système, et que je boot via un PQ Magic, ou un Gparted, afin de redimensionner les partissions, cela risque d’avoir un impact négatif sur mon système…? en provoquant une instabilité…? voir rendre le serveur inutilisable…?

Merci d’avance…

#5

Bonjour Loicmtp,

Oui, c’est bien le répertoire …/var/… qui pose problème…
Comment récupérer les logs, si tu peux me laisser la commande…

Merci d’avance…

#6

C’est possible de faire ainsi, mais je recommande pas de déplacer les partitions de cette manière sans sauvegarde.
Maintenant ce que j’entend par revoir l’installation s’est de s’appuyer sur du LVM pour la partie partitionnement et pourquoi pas de séparer un poil plus certaines partie du système.
J’aurai bien vu un volume logique pour /var, ainsi que deux autres pour isolé /var/lib/mysql et /var/log.

surtout que pour un serveur (si s’en ai bien un une partition /home de plus de 400G c’est … :face_with_raised_eyebrow:

#7

Les logs:

 ls -lrt /var/log
total 612
drwxrwxrwx  3 root     root              4096 13 juin   2022 installer
drwxr-sr-x+ 3 root     systemd-journal   4096 13 juin   2022 journal
drwx------  2 root     root              4096 13 juin   2022 private
drwxrwxrwx  3 root     root              4096 14 juin   2022 runit
drwxr-s---  2 mysql    adm               4096 16 juin   2022 mysql
drwxrwxrwx  2 root     root              4096 19 juin   2022 proftpd
drwxrwxr-x  2 www-data www-data          4096 20 juin   2022 ocsinventory-server
drwxrwxrwx  2 root     adm               4096 11 juil.  2022 apache2
drwxrwxrwx  2 root     root              4096 26 sept. 12:26 apt
-rw-r-----  1 root     adm              81136 26 sept. 17:03 kern.log
-rw-r-----  1 root     adm               6289 26 sept. 17:03 debug.1
-rw-rw----  1 root     utmp               384 26 sept. 17:03 btmp
-rw-r-----  1 root     adm                  0 27 sept. 00:00 debug
-rw-r-----  1 root     adm              74727 27 sept. 00:10 messages
-rw-r-----  1 root     adm             236940 27 sept. 10:05 syslog
-rw-r-----  1 root     adm             147750 27 sept. 10:05 daemon.log
-rw-rw-r--  1 root     utmp              2688 27 sept. 10:05 wtmp
-rw-rw-r--  1 root     utmp            292292 27 sept. 10:05 lastlog
-rw-r-----  1 root     adm              12969 27 sept. 10:05 auth.log
#8

Merci du retour…
En fait, j’ai suivi le système de partition logique de Linux…
Je n’ai pas été assez vigilent la dessus… :thinking:

Je vais essayer de porter une attention quotidienne sur la chose… :face_with_raised_eyebrow:

Encore Merci…

#9

Hello
Installez ncdu et regardez les gros volumes dans le repertoire /var concerné. Ensuite instaurez un logrotate drastique ou faites des « truncate » sur les fichiers (edit: de log bien sur) les plus gros

Peut etre serait ce suffisant pour que mysql puisse se relancer

Ou alors:

Si vous avez de la place et que vous utilisez LVM (regardez lsblk) vous pouvez faire soit un redimensionnement soit un déport d’un répertoire vers une autre partition

#10

9G c’est trop petit pour un /var.
Les logs c’est minima 3 à 4G dans une configuration serveur pour être certain de ne pas être impacté avec une bonne gestion des rotations.
Sachant que la base de données est dans /var/lib/mysql il faut avoir une estimation du volume de données pour le dimensionner et en faire une partition spécifique.
La place utilisée par /home est abherante, et une partie devrait être utilisée par les autres besoins.
LVM est à utiliser, il peut y avoir un volume group par disque ou grouper les deux disque dans un seul (mais plus risqué en cas de dégât sur un disque).

#11

Ho… du travail en perspective… :thinking:
je vais cloner mon DD, et travailler sur le clone afin de ne pas impacter le serveur… :wink:

Merci pour le retour…

#12

Je maintient le plus simple serait de travailler sur un déploiement neuf et le rapatriement des données dessus, qualification et finalement mise en production du nouveau serveur.
Cela te permettra d’être à jour, de maîtriser ton partitionnement, et pourquoi pas revoir et optimiser le système et les applicatifs.

En attendant réduit le /home sur ton serveur (d’abord le système de fichier, puis la partition) et profit-en pour recréer une partition avec un système de fichier propre de 15Go , monte la sur /tmp et copie l’intégralité des données dans /var.
Une fois fait tu peux envisager de démonter la partition /var et la remplacer (création d’un point de montage dans le fichier fstab) par la nouvelle partition /var.

#13

C’est sûr mais en meme temps des manipulations sur un serveur peuvent etre instructives

#14

Bonjour,

pour le retour merci…
j’ai du pain sur la planche…
je vais travailler la chose…

encore merci

1 J'aime
#15

salut
tu peux tenter ça :

rm /var/lib/mysql/ib_logfile*
Evidemment pour plus de sureté tu peux toujours les copier plutot que les effacer, mais ça a marché chez moi

#16

pour cette ligne , il y a parfois une ereur de configuration entre
unix_socket ( ou auth_socket ) et mysql_native_password

donnes nous le résultat de

egrep "port =|socket =" /etc/mysql/my.cnf

#17

L’avantage de truncate c’est que n’efface que le contenu en MO, GO que vous lui demandez d’effacer et laisse le fichier

#18

Bonjour,

j’ai appliqué, et j’ai récupérer quelques Mo…
merci, je garde la commande…

:facepunch: :+1:

#19

Bonjour,

Merci du retour…
Je vais refaire un serveur sur une nouvelle machine…en prenant en compte tout ce qui à été dit…

Juste pour donner des infos sur mon univers de travail:
Je m’occupe d’un parc de 300 PC (Fixes, portables) globalement…
Et au moment de changer la machine d’un utilisateur, soit pour désastre, ou obsolescence OS, je récupère le PC (qui est encore très fiable), je le gonfle en RAM, je le nettoie correctement, je lui mets un DD, et je lui donne une seconde vie comme serveur Linux…
De ce fait, je patiente juste pour une occasion de récupérer une machine, et me mettre dessus…
Cela me prendra un certain temps…
J’installe dessus le couple GLPI/OCS, et le tour est joué, avec les même paramètres réseau NetBIOS, IP afin que les agents déjà déployés soient tous fonctionnels, et au bout de 3/4 jours, la base de données est reconstituée…

…/…

Et voila…
Pour l’heur, je me ferai la min sur un VM pour gérer le partitionnement Linux…
Merci à tous, je vous tiendrai informé…