[Résolu] Re: mariadb qui ne démarre plus
Sébastien Dinot a écrit :
> Bonjour Joël,
Bonjour Sébastien,
> BERTRAND Joël a écrit :
>
>> les seuls cas à peu près similaires indiquent que la base de données
>> était déjà corrompu (mais bizarrement, cela s'est aussi passé juste
>> avec une mise à jour entre les mêmes versions). Or dans mon cas, ce
>> n'est pas possible. J'ai réinstallé une version récente de la réplique
>> pas plus tard que ce matin et elle fonctionnait avant que je ne
>> redémarre la machine à la suite de sa mise à jour...
>
> « ce n'est pas possible », en informatique « ce n'est pas possible » ;)
Oui, bon. Mais en l'occurrence, je trouverais cela assez bizarre. La
base fonctionne, je redémarre le serveur et ça ne fonctionne plus après
une mise à jour de mariadb...
>> déc. 07 23:08:26 hilbert mysqld[3627]: 2021-12-07 23:08:26 0 [ERROR]
>> Fatal error: Can't open and lock privilege tables: 'mysql.user' is not
>> of type 'TABLE'
>
> Ce message d'erreur laisse pourtant bien supposer une corruption des
> données, à moins que ce message ne soit induit par l'impossibilité
> d'accéder au fichier et donc par un problème de permission sur le
> répertoire ou le fichier. As-tu vérifié ces permissions ?
Naturellement :
/var/lib/mysql:
drwxr-xr-x 29 mysql mysql 1024 7 déc. 23:08 mysql
/var/lib/mysql/mysql/user.frm:
-rw-rw---- 1 mysql mysql 13752 7 déc. 09:25 user.frm
> Utilises-tu
> SELinux ou AppArmor ?
Apparmor. Peut-être SElinux, mais je ne l'ai pas explicitement installé :
Root hilbert:[/var/lib/mysql/mysql] > dpkg-query -l | grep -i selinux
ii libselinux1:amd64 3.3-1+b1
amd64 SELinux runtime shared libraries
ii libselinux1-dev:amd64 3.3-1+b1
amd64 SELinux development headers
ii libsemanage-common 3.3-1
all Common files for SELinux policy
management libraries
ii libsemanage1:amd64 3.1-2
amd64 SELinux policy management library
ii libsemanage2:amd64 3.3-1+b1
amd64 SELinux policy management library
ii libsepol-dev:amd64 3.3-1
amd64 SELinux binary policy manipulation
library and development files
ii libsepol1:amd64 3.1-1
amd64 SELinux library for manipulating
binary security policies
ii libsepol2:amd64 3.3-1
amd64 SELinux library for manipulating
binary security policies
Root hilbert:[/var/lib/mysql/mysql] >
> Utilises-tu les répertoires standard du système ou
> as-tu déporté les fichiers ailleurs ?
Répertoires standards. Mais, et il y a un mais, ce serveur de test est
un serveur diskless. Tout est exporté depuis un serveur NetBSD (NFSv3).
> Sinon, le disque dur est-il récent ? L'as-tu contrôlé via un fsck ?
Le volume est exporté depuis NetBSD, la machine NetBSD ne se plaint pas
de ses disques. Aucune erreur smart, aucune erreur après un fsck (ffs2).
> Sur la page ci-dessous, on trouve une base de connaissance listant les
> différentes raisons pouvant conduire à l'échec du démarrage de MariaDB
> et ce qu'il faut faire pour y remédier :
>
> https://mariadb.com/kb/en/what-to-do-if-mariadb-doesnt-start/
Je connais, mais ça ne m'est pas d'un très grand secours. Le problème
est que le message d'erreur, le seul, est :
2021-12-07 23:07:49 0 [ERROR] Fatal error: Can't open and lock privilege
tables: 'mysql.user' is not of type 'TABLE'
et j'ai envie de dire "très certes, mon cher" !
Root hilbert:[/var/lib/mysql/mysql] > head user.frm
TYPE=VIEW
...
Visiblement, mysql.user n'est pas une table mais une vue. Côté
dysfonctionnel, j'ai une version 10.3.29 de mariadb (mais les libs sont
de 10.5.9 !), côté serveur fonctionnel, je m'aperçois que j'ai une
10.5.9. C'est assez étrange, le serveur n'est pas mis à jour (je sais,
ce n'est pas bien, mais vus les problèmes inhérents à systemd, je ne le
mets à jour que lorsque je suis physiquement devant lui).
Un apt install mariadb me propose aujourd'hui :
...
Les NOUVEAUX paquets suivants seront installés :
galera-4 mariadb-client-10.5 mariadb-client-core-10.5 mariadb-server
mariadb-server-10.5 mariadb-server-core-10.5
C'est assez étrange, la réplique est un testing à jour. Je suppose que
pour une raison x ou machin, mariadb a été downgradé et que je n'ai pas
fait attention.
Une fois ces paquets installés, je me suis tapé un :
2021-12-08 9:00:10 0 [ERROR] InnoDB: Upgrade after a crash is not
supported. The redo log was created with MariaDB 10.3.29.
2021-12-08 9:00:10 0 [ERROR] InnoDB: Plugin initialization aborted with
error Generic error
2021-12-08 9:00:10 0 [Note] InnoDB: Starting shutdown...
Forcément, l'initialisation de la base avec 10.3 s'est vautrée, mariadb
a laissé des bouts partout et râle. Mon côté vieux con me ferait presque
ajouter que c'est encore un chemin pas prévu par les concepteurs d'un
programme alors que c'est typiquement ce genre de chose qui en ferait un
outil fiable ! 10.3, en se vautrant, n'a aucune raison de laisser des
fichiers en vrac. Enfin, à partir du moment où une réplique peut se
vautrer lamentablement sur un problème réseau, on peut vraiment
s'attendre à tout de la part de mariadb/mysql.
Ceci étant dit, j'ai renommé ib_logfile0 et ib_logfile1 en
ib_logfile0.old et ib_logfile1.old, relancé mariadb puis passé un coup
de mysql_uprade -uroot -p qui s'est terminé normalement. Ça fonctionne,
le slave est reparti normalement.
Je ne sais pas si c'est moi qui aie toujours des problèmes avec
mariadb/mysql ou si cet outil de base de données n'est vraiment pas sec.
J'entretiens de grosses bases postgresql (plusieurs To de données de
cartographie) depuis des années sans jamais n'avoir eu ce genre de
problème. Je ne compte plus les problèmes aberrants mysql/mariadb...
Bien cordialement,
JKB
Reply to: