Guide de dépannage des paquets ServBay MariaDB/MySQL
Présentation
MariaDB et MySQL sont les systèmes de gestion de bases de données relationnelles open source les plus populaires, largement utilisés pour de nombreux sites Web et applications métier. ServBay intègre plusieurs versions des paquets MariaDB/MySQL sur macOS et Windows, offrant aux développeurs un environnement local de base de données pratique et efficace. Malgré leur stabilité reconnue, des problèmes de démarrage, d’échec de connexion ou de baisse de performance peuvent survenir lors du développement et de l’exécution.
Ce guide a pour but d'aider les utilisateurs de ServBay à diagnostiquer et à résoudre les pannes courantes des paquets MariaDB/MySQL. Vous trouverez une liste des problèmes fréquents, des étapes de diagnostic et des solutions concrètes, avec des indications spécifiques à l'environnement ServBay (chemins et commandes).
Points importants :
- Avant toute opération susceptible de modifier vos données ou configurations, pensez à sauvegarder votre base de données ! ServBay propose une fonctionnalité intégrée de sauvegarde, fortement recommandée en usage régulier.
- Les exemples de commandes et chemins utilisent des numéros de version spécifiques (comme
11.3
ou11.5
). Remplacez-les par la version réellement installée/utilisée dans ServBay. Consultez l’interface ServBay pour vérifier les versions actives. - Dans les exemples de commande, remplacez les espaces réservés (
<username>
,<database>
,<your_backup.sql>
, etc.) par vos valeurs réelles (nom d’utilisateur, base de données, fichier de sauvegarde). - Ce guide s’applique à macOS et Windows, avec des exemples adaptés dans chaque section.
Étapes de diagnostic générales
Avant d’entrer dans les causes spécifiques, effectuez les vérifications suivantes :
Vérifier le statut des paquets ServBay : Ouvrez ServBay et confirmez que la version MariaDB/MySQL que vous voulez utiliser est activée et affichée comme « En cours d’exécution ». Vous pouvez aussi vérifier en ligne de commande :
bashservbayctl status mariadb <version> # Exemple : pour vérifier MariaDB 11.3 : servbayctl status mariadb 11.3
1
2
3Consulter les journaux ServBay : ServBay peut enregistrer des erreurs lors du lancement ou de la gestion des paquets. Consultez la zone dédiée aux journaux ou le fichier principal de log de ServBay.
Consulter les logs d’erreur de MariaDB/MySQL : Pour identifier les échecs de démarrage ou les erreurs critiques. Chemins typiques :
macOS :
bash/Applications/ServBay/logs/mariadb/<version>/<version>.err # Exemple : Lire les 50 dernières lignes du journal d’erreurs MariaDB 11.3 : tail -n 50 /Applications/ServBay/logs/mariadb/11.3/11.3.err
1
2
3Windows :
cmdC:\ServBay\logs\mariadb\<version>\<version>.err # Exemple : Lire les 50 dernières lignes du journal d’erreurs MariaDB 11.3 : powershell "Get-Content -Path 'C:\ServBay\logs\mariadb\11.3\11.3.err' -Tail 50"
1
2
3Examinez avec attention les messages d’erreur en fin de fichier, souvent révélateurs du problème.
Problèmes courants et solutions
1. Erreur de connexion : SQLSTATE[HY000] [2002] No such file or directory
Cette erreur indique généralement que le client ne trouve pas le socket Unix pour se connecter au serveur MariaDB/MySQL. Sur macOS, le socket Unix est un moyen de communication inter-processus local, privilégié pour les accès locaux car il est plus performant que TCP/IP. Si le chemin du socket configuré ne correspond pas à celui du serveur, cette erreur peut apparaître.
Causes et solutions possibles :
- Paquet MariaDB/MySQL non démarré :
- Vérifiez dans ServBay ou avec
servbayctl status mariadb <version>
si le service est actif. - S’il n’est pas démarré, lancez-le :
servbayctl start mariadb <version>
puis consultez le journal d’erreur (.err
) pour connaître la cause du blocage.
- Vérifiez dans ServBay ou avec
- Chemin du socket incorrect (macOS/Linux uniquement) :
- Le client utilise un chemin de socket différent de celui configuré dans le serveur (
my.cnf
). - macOS : Vérifiez le paramètre
socket
dans le fichier de configuration/Applications/ServBay/etc/mariadb/<version>/my.cnf
. - Windows : Windows n’utilise pas de socket Unix, mais les connexions se font via canal nommé ou TCP/IP.
- macOS : Assurez-vous que vos outils ou applications utilisent bien le chemin de socket ServBay, généralement sous
/Applications/ServBay/tmp/
ou/tmp/
selon la configuration, par exemple/Applications/ServBay/tmp/mysql.sock
.
- Le client utilise un chemin de socket différent de celui configuré dans le serveur (
- Paramètres par défaut ServBay :
- Dans les paramètres ServBay (« Serveur SQL par défaut »), confirmez que la bonne version MariaDB/MySQL est sélectionnée. Des outils comme
mysql
peuvent essayer de se connecter au socket du serveur SQL par défaut s’ils ne reçoivent pas l’option-S
ou-h
.
- Dans les paramètres ServBay (« Serveur SQL par défaut »), confirmez que la bonne version MariaDB/MySQL est sélectionnée. Des outils comme
- Problème de droits :
- macOS : Vérifiez que l’utilisateur MariaDB/MySQL peut écrire dans le dossier du socket, et que l’utilisateur client peut lire le fichier socket. ServBay gère en principe ces droits, sauf modification manuelle des permissions des dossiers
/Applications/ServBay/tmp/
ou/tmp/
. - Windows : Vérifiez que le compte utilisateur gérant ServBay a les droits nécessaires en écoute sur les ports ou la création de canaux nommés.
- macOS : Vérifiez que l’utilisateur MariaDB/MySQL peut écrire dans le dossier du socket, et que l’utilisateur client peut lire le fichier socket. ServBay gère en principe ces droits, sauf modification manuelle des permissions des dossiers
Alternative (forcer la connexion réseau) :
- Tentez de vous connecter en indiquant l’IP
127.0.0.1
plutôt quelocalhost
, ce qui forcera l’utilisation de TCP/IP au lieu du socket Unix. Si cela fonctionne, le souci vient du socket.bashmysql -u <username> -p -h 127.0.0.1 -P 3306
1
2. Erreur de connexion : réseau (Connection refused
, Can't connect to MySQL server
...)
Ces messages signifient que le client ne parvient pas à se connecter au serveur MariaDB/MySQL via TCP/IP.
Causes et solutions possibles :
Paquet MariaDB/MySQL non démarré : (Vérifiez comme ci-dessus, l’état et les journaux
.err
)Port déjà utilisé :
- Assurez-vous que le port (par défaut 3306) n’est pas occupé par un autre programme.
macOS :
bashlsof -i :3306 # ou netstat -anv | grep LISTEN | grep 3306
1
2
3Windows :
cmdnetstat -an | findstr :3306 # ou PowerShell Get-NetTCPConnection -LocalPort 3306
1
2
3Si le port est occupé, fermez le processus concerné ou modifiez le port dans
my.cnf
, puis redémarrez.- macOS :
/Applications/ServBay/etc/mariadb/<version>/my.cnf
- Windows :
C:\ServBay\etc\mariadb\<version>\my.cnf
Pare-feu bloque la connexion :
macOS :
- Vérifiez le pare-feu dans « Réseau » des préférences système.
- Pour autoriser temporairement
mysqld
:bash# Exemple à adapter selon le chemin réel sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/ServBay/bin/mariadb/<version>/bin/mysqld sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /Applications/ServBay/bin/mariadb/<version>/bin/mysqld
1
2
3
Windows :
- Contrôlez les règles dans le pare-feu Windows Defender ou tout autre pare-feu.
- Pour autoriser le programme ou le port :cmd
netsh advfirewall firewall add rule name="ServBay MariaDB" dir=in action=allow program="C:\ServBay\bin\mariadb\<version>\bin\mysqld.exe"
1
Problème de configuration (
bind-address
) :- Examinez la valeur de
bind-address
dansmy.cnf
. S’il est réglé sur127.0.0.1
oulocalhost
, seuls les accès locaux seront permis. Pour une connexion externe, utilisez0.0.0.0
ou une IP spécifique et autorisez les accès dans le pare-feu.
- Examinez la valeur de
Problème de résolution réseau (
localhost
) :- Vérifiez que
localhost
se résout bien en127.0.0.1
(IPv4) et::1
(IPv6).
macOS :
bashping localhost cat /etc/hosts
1
2Windows :
cmdping localhost type C:\Windows\System32\drivers\etc\hosts
1
2Assurez-vous que
localhost
figure correctement dans le fichier hosts. Désactivez tout proxy local susceptible d’interférer avec le trafic TCP/IP local.- Vérifiez que
3. Impossible de démarrer MariaDB/MySQL
Causes et solutions possibles :
Consulter le journal d’erreur : Voir la section logs ci-dessus pour identifier la cause exacte (emplacement :
/Applications/ServBay/logs/mariadb/<version>/<version>.err
sur macOS,C:\ServBay\logs\mariadb\<version>\<version>.err
sur Windows).Erreur dans le fichier de configuration : Erreur de syntaxe, option invalide ou chemin incorrect dans
my.cnf
.Emplacement du fichier :
- macOS :
/Applications/ServBay/etc/mariadb/<version>/my.cnf
- Windows :
C:\ServBay\etc\mariadb\<version>\my.cnf
Validation de la syntaxe :
bash/Applications/ServBay/bin/mariadb/<version>/bin/mysqld --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf --validate-config # Windows C:\ServBay\bin\mariadb\<version>\bin\mysqld.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf --validate-config
1
2
3
4- macOS :
Port occupé : (voir plus haut, vérification avec
lsof
ounetstat
)Espace disque insuffisant : Pas assez d'espace disponible sur le disque contenant le répertoire de données ou de logs.
Emplacement :
- macOS : données
/Applications/ServBay/db/mariadb/<version>/
; logs/Applications/ServBay/logs/mariadb/<version>/
- Windows : données
C:\ServBay\db\mariadb\<version>\
; logsC:\ServBay\logs\mariadb\<version>\
- macOS : données
Problèmes de droits : L'utilisateur lançant MariaDB/MySQL n’a pas les droits de lecture/écriture sur le dossier de données ou le fichier de configuration. ServBay ajuste normalement ces droits, sauf modification manuelle.
macOS :
bashls -ld /Applications/ServBay/db/mariadb/<version> ls -l /Applications/ServBay/etc/mariadb/<version>/my.cnf ls -ld /Applications/ServBay/logs/mariadb/<version>
1
2
3Vérifiez que l'utilisateur du processus (souvent
_mysql
) a les droits nécessaires.Windows : Contrôlez les propriétés du dossier/fichier via l’explorateur Windows, et vérifiez les autorisations du compte utilisateur utilisé par ServBay.
Fichiers de données corrompus : Voir la section « Plantage ou corruption de données » ci-dessous. Les arrêts brutaux ou autres erreurs peuvent endommager les fichiers et empêcher le démarrage.
Après correction :
- Essayez de redémarrer le paquet :
servbayctl restart mariadb <version>
4. Problèmes de droits ou d’authentification utilisateur
Vous pouvez recevoir des erreurs comme Access denied
si le nom d'utilisateur, le mot de passe ou les autorisations ne sont pas corrects.
Causes et solutions possibles :
- Nom d’utilisateur ou mot de passe incorrect : Vérifiez que les identifiants utilisés sont exacts. ServBay permet une réinitialisation facile du mot de passe root en cas d’oubli.
- Restrictions d’hôte : Un utilisateur peut être limité à une source spécifique d’accès (par exemple
'webapp'@'localhost'
vs'webapp'@'127.0.0.1'
).'%'
autorise tout hôte. - Manque d’autorisations : L’utilisateur peut manquer de droits sur la base visée ou sur certaines actions (SELECT, INSERT, UPDATE, DELETE, CREATE, DROP...).
- Vérification des droits :
- Connectez-vous avec un compte ayant suffisamment de droits, comme root :bash
mysql -u root -p
1 - Vérifiez les autorisations en SQL :sql
SHOW GRANTS FOR '<username>'@'<hostname>'; -- Exemple : droits de 'webapp' sur 'localhost' SHOW GRANTS FOR 'webapp'@'localhost'; -- Droits de 'admin' sur tout hôte SHOW GRANTS FOR 'admin'@'%';
1
2
3
4
5 - Modifiez les droits avec
GRANT
ouREVOKE
, ou créez un nouvel utilisateur selon le besoin.
- Connectez-vous avec un compte ayant suffisamment de droits, comme root :
5. Problèmes de performance
Des lenteurs de la base de données dégradent l'expérience globale des applications.
Causes et solutions possibles :
- Requêtes lentes : Les requêtes sont sous-optimales ou les index manquent.
- Activer le log des requêtes lentes : Configurez
slow_query_log = 1
etlong_query_time = 1
(requêtes de plus d’une seconde) dansmy.cnf
, puis analysez le journal résultant. - Utilisez
EXPLAIN
: Pour décomposer le plan d'exécution de la requête et identifier les goulots d’étranglement.sqlEXPLAIN SELECT * FROM your_table_name WHERE column_name = 'value';
1 - Optimiser la requête : Évitez
SELECT *
, les fonctions dans les clauses WHERE, optimisez pour l’utilisation des index.
- Activer le log des requêtes lentes : Configurez
- Absence ou mauvais usage d’index : Les colonnes utilisées pour les filtres, tri (
ORDER BY
) ou regroupement (GROUP BY
) doivent avoir des index adaptés.- Analysez la structure des tables et les requêtes courantes pour créer des index pertinents.sqlNote : La création d’index alourdit l’écriture et consomme du stockage, à équilibrer selon le besoin.
CREATE INDEX idx_column_name ON your_table_name(column_name);
1
- Analysez la structure des tables et les requêtes courantes pour créer des index pertinents.
- Configuration du cache inadéquate : Taille hors propos des paramètres comme
innodb_buffer_pool_size
,key_buffer_size
, etc.- Ajustez ces paramètres selon la RAM disponible et l’usage du serveur. Pour InnoDB, le pool mémoire doit représenter 50% à 70% de la RAM si le serveur est dédié.ini
[mysqld] # Exemple, à ajuster. Unités : bytes ou K/M/G. innodb_buffer_pool_size = 2G # Si beaucoup de tables MyISAM : # key_buffer_size = 256M
1
2
3
4
5
- Ajustez ces paramètres selon la RAM disponible et l’usage du serveur. Pour InnoDB, le pool mémoire doit représenter 50% à 70% de la RAM si le serveur est dédié.
- Limite matérielle : Charge CPU excessive, manque de RAM, goulot d’étranglement sur le disque ou le réseau. Utilisez le moniteur d’activité macOS ou les commandes
top
/htop
pour diagnostiquer.
6. Plantage ou corruption de la base de données
Problèmes de démarrage, plantages répétés ou erreurs de lecture/écriture liés à la corruption des fichiers.
Causes et solutions possibles :
- Consultez le log d’erreur : C’est l’étape clé, notamment pour des messages relatifs à InnoDB, au système de fichiers ou à la mémoire.
- macOS :
/Applications/ServBay/logs/mariadb/<version>/<version>.err
- Windows :
C:\ServBay\logs\mariadb\<version>\<version>.err
- macOS :
- Défaillances matérielles : Problèmes de disque dur ou de RAM. Contrôlez les journaux systèmes et faites un diagnostic matériel.
- Bugs logiciels ou conflits : Certains bugs MariaDB/MySQL, ou conflits avec d’autres logiciels.
- Erreur de configuration : Un paramètre incorrect dans
my.cnf
peut déstabiliser le serveur. - Arrêt forcé ou interruption : Un arrêt brutal du service ou du PC peut laisser les fichiers de données dans un état incohérent.
Solutions possibles :
Essayez un redémarrage sécurisé : Relancez via ServBay ou la ligne de commande :
servbayctl restart mariadb <version>
. Parfois, ceci enclenche une auto-réparation côté MariaDB/MySQL.Utilisez
mysqlcheck
pour vérifier et réparer : Cet utilitaire contrôle l’intégrité des tables, principalement efficace pour MyISAM.bashmysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --check --all-databases # Pour MyISAM, la réparation automatique : # mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --auto-repair --check --all-databases
1
2
3Note :
--auto-repair
fonctionne surtout pour MyISAM. Pour InnoDB, la réparation est plus complexe (voir ci-dessous).Forcer la récupération InnoDB (
innodb_force_recovery
) : Si InnoDB refuse de démarrer (erreur InnoDB dans le log), tentez une récupération forcée. Attention, cette opération est risquée et peut entraîner des pertes ou incohérences ! Utilisez-la uniquement pour extraire et sauvegarder les données.- Sauvegardez le dossier de données (même corrompu) avant toute opération.
- Éditez le
my.cnf
du paquet concerné et ajoutez sous[mysqld]
:innodb_force_recovery = N
. Commencez à1
, augmentez progressivement à6
si le démarrage échoue à chaque palier. - Essayez de démarrer MariaDB/MySQL.
- Si cela fonctionne (même en mode dégradé), sauvegardez immédiatement la totalité des bases avec
mysqldump
:bashVérifiez bien la taille et l’intégrité du fichier de sauvegarde.mysqldump --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --all-databases --routines --triggers --events > /path/to/your_emergency_backup.sql
1 - Arrêtez le service dès la sauvegarde terminée.
- Retirez ou commentez la ligne
innodb_force_recovery = N
du fichiermy.cnf
. - Procédez à la restauration : Généralement, cela implique l’initialisation d’un nouveau répertoire de données, puis d’importer le dump sauvegardé.
Restaurer à partir d’une sauvegarde fiable : Si la réparation échoue ou que les données sont incohérentes, vous pouvez restaurer une sauvegarde réalisée récemment. Les sauvegardes ServBay sont généralement stockées sous
/Applications/ServBay/backup/mariadb/<version>/
.- Exemple de restauration vers une base
<target_database_name>
:bashRemarque : Remplacez# Créez d'abord la base si nécessaire : # mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;" # Importez le fichier de sauvegarde : mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>
1
2
3
4
5<version>
par la version cible.
- Exemple de restauration vers une base
7. Problèmes de sauvegarde et de restauration
Des difficultés peuvent survenir lors de l’utilisation de la fonction de sauvegarde ServBay ou d’une sauvegarde manuelle via mysqldump
.
Causes et solutions possibles :
- Fichier de sauvegarde incomplet/corrompu :
- Vérifiez la taille (
ls -lh /path/to/your_backup.sql
) et ouvrez-le dans un éditeur ou vialess
pour confirmer qu'il s'agit bien d’un fichier SQL valide. - Contrôlez l’exécution des commandes de sauvegarde pour d’éventuelles erreurs.
- Pour sauvegardes ServBay, consultez les logs pour les détails.
- Vérifiez la taille (
- Erreur de commande de restauration :
- Nom d’utilisateur, mot de passe ou base cible incorrect.
- Droits insuffisants à l’import.
- Erreur de syntaxe SQL due à des incompatibilités entre versions ou types de bases (ex : import de MySQL vers MariaDB).
- Problèmes de contraintes de clé étrangère : Lors de l’import, l’ordre des tables peut faire échouer les références. Vous pouvez temporairement désactiver les contrôles de clé étrangère :sqlAttention, n’utilisez cette désactivation que pour l’import, la cohérence des données peut être affectée.
-- Avant l’import SET foreign_key_checks = 0; -- Importer avec : source /path/to/your_backup.sql; -- ou mysql ... < /path/to/your_backup.sql -- Après import SET foreign_key_checks = 1;
1
2
3
4
5
6
7 - Problème de charset ou collation : Des différences de jeu de caractères ou de collation entre la sauvegarde et la base cible peuvent causer des erreurs ou des données illisibles. Veillez à la compatibilité, typiquement vers
utf8mb4
.
Procédure correcte de restauration en ligne de commande :
macOS :
bash
# Supposons une sauvegarde d’une base donnée spécifique
# Créez la base cible si nécessaire :
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"
# Importez avec le bon fichier de configuration, l’utilisateur, le mot de passe et la base cible :
mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>
# Si la sauvegarde concerne toutes les bases (--all-databases), ne précisez pas le nom de la base :
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
Windows :
cmd
REM Fichier de sauvegarde pour une base précise
REM Créez la base cible si besoin :
REM C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"
REM Importez avec le bon fichier de configuration, utilisateur, mot de passe, base cible :
C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u <username> -p <target_database_name> < C:\ServBay\backup\mariadb\<version>\<your_backup.sql>
REM Pour une sauvegarde de toutes les bases :
REM C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u <username> -p < C:\ServBay\backup\mariadb\<version>\<your_backup.sql>
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
Remarque : Adaptez <version>
selon le contexte. Les sauvegardes ServBay sont conçues pour une restauration aisée, avec options adaptées dans l’interface.
8. Bug spécifique : Échec du démarrage InnoDB MariaDB 11.5.1 (ib_logfile0 was not found
/ Missing FILE_CHECKPOINT
)
Ce bug grave touche MariaDB 11.5.1 : InnoDB ne parvient pas à initialiser ses fichiers de log et ne démarre plus.
Caractéristiques dans les logs d’erreur :
Exemple macOS (/Applications/ServBay/logs/mariadb/11.5/11.5.err
) :
[ERROR] InnoDB: File /Applications/ServBay/db/mariadb/11.5/ib_logfile0 was not found
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB
1
2
3
4
2
3
4
Exemple Windows (C:\ServBay\logs\mariadb\11.5\11.5.err
) :
[ERROR] InnoDB: File C:\ServBay\db\mariadb\11.5\ib_logfile0 was not found
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB
1
2
3
4
2
3
4
Ou encore :
[ERROR] InnoDB: Missing FILE_CHECKPOINT(xxxxx) at xxxxx
[ERROR] InnoDB: Log scan aborted at LSN xxxxx
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB
1
2
3
4
5
2
3
4
5
Ces messages indiquent qu’InnoDB ne trouve ou ne parvient pas à traiter ses fichiers de log.
Solution (migration de données, sauvegarde impérative !)
Ce bug est complexe et très difficile à résoudre de façon classique. La meilleure option est un démarrage forcé afin d’exporter les données, puis migration vers une version stable de MariaDB.
Essayer de forcer la récupération pour extraire une sauvegarde (risqué !) :
Modifier la configuration :
- macOS :
/Applications/ServBay/etc/mariadb/11.5/my.cnf
- Windows :
C:\ServBay\etc\mariadb\11.5\my.cnf
Ajoutez sous
[mysqld]
:innodb_force_recovery = 6
Démarrer le service :
bashservbayctl start mariadb 11.5
1Si le démarrage fonctionne, sauvegardez immédiatement les données :
macOS :
bashmysqldump --defaults-file=/Applications/ServBay/etc/mariadb/11.5/my.cnf -u root -p --all-databases --routines --triggers --events > /Applications/ServBay/backup/mariadb/11.5/mariadb_11.5_emergency_backup.sql
1Windows :
cmdC:\ServBay\bin\mariadb\11.5\bin\mysqldump.exe --defaults-file=C:\ServBay\etc\mariadb\11.5\my.cnf -u root -p --all-databases --routines --triggers --events > C:\ServBay\backup\mariadb\11.5\mariadb_11.5_emergency_backup.sql
1Vérifiez absolument la validité et la taille du fichier de sauvegarde.
- macOS :
Arrêtez et traitez le dossier de données de la version concernée :
- Arrêtez MariaDB 11.5 :
servbayctl stop mariadb 11.5
- Modifiez le fichier
my.cnf
pour retirer ou commenter la ligneinnodb_force_recovery
...
- Arrêtez MariaDB 11.5 :