Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

MariaDB Crash signal=SEGV

Ghost67

Bonjour à tous,

Je viens a vous car je ne suis pas un expert en Bdd et je me retrouve avec mon serveur de DEV en rade.

Je m'explique, depuis quelques temps je me retrouve avec des arrêts impromptus de MariaDB pour cause "code=killed, signal=SEGV"

 Process: 6683 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=killed, signal=SEGV)

A chaque fois que j'ai eu le problème, un simple reboot corrigeait le problème.

Jusqu'à aujourd'hui.... Plus moyen de redémarrer le service... J'ai des données dessus et j'aimerais les récupérer si possible... Sinon, je me débrouillerais pour les recréer...
Mais j'aimerais surtout pouvoir le redémarrer... Si vous avez des infos sur une quelconque marche à suivre ou test à effectuer, je suis preneur...

Merci

noje

Ici ça parle de base de données corrompues, il donne une méthode de tentative de restauration.
Après le gars relançait aussi le service avec systemctl aussi comme vous.

https://mariadb.com/kb/en/mariadb-server-mysteriously-seems-to-be-crashing/

bruno

Quand on a un problème avec un service il faut examiner les logs.
Pour mariadb, par défaut c'est sous /var/log/mysql et avec journactl :

journalctl --no-pager -u mariadb

Ghost67

Merci,

En effet. Après suite d'investigation, je n'ai pas eus d'autre choix que de restaurer mes dump.
Visiblement, ce serais dut à une erreur de segmentation de mes fichiers de BDD, hors pour les restaurer, ou les supprimer il fallait pouvoir démarrer le service. J'ai donc dut déinstaller/purger mariadb-server puis le réinstaller avant de restaurer mes dump.

Méthode bourrin, mais efficace.
Par contre je n'ai pas trouvé la source de cette erreur de segmentation. Après test rapide, le disque est sain.

En attendant d'avoir à nouveau cette erreur on peut dire que le sujet est clos.
Merci

Ghost67

bruno a écritQuand on a un problème avec un service il faut examiner les logs.
Pour mariadb, par défaut c'est sous /var/log/mysql et avec journactl :

journalctl --no-pager -u mariadb

Les log n'indiquait que l'erreur de segmentation. Mais je n'ai pas réussi à identifier la cause de celle-ci.

noje

Ghost67 a écritMerci,
Méthode bourrin, mais efficace.
Par contre je n'ai pas trouvé la source de cette erreur de segmentation. Après test rapide, le disque est sain.
Merci

Possible que ce soit simplement lié à un souci d’écriture à un moment donné, après l’essentiel c’est d’avoir et de faire de backups « comme toujours ».