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 ou 11.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 :
bash
```
servbayctl status mariadb <version>
# Exemple : pour vérifier MariaDB 11.3 :
servbayctl status mariadb 11.3
```
1
2
3
Consulter 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

Windows :

cmd

C:\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"

Examinez 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.
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.
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.
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.

Alternative (forcer la connexion réseau) :

Tentez de vous connecter en indiquant l’IP 127.0.0.1 plutôt que localhost, ce qui forcera l’utilisation de TCP/IP au lieu du socket Unix. Si cela fonctionne, le souci vient du socket.
bash
```
mysql -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 :
bash
```
lsof -i :3306
# ou
netstat -anv | grep LISTEN | grep 3306
```
1
2
3
Windows :
cmd
```
netstat -an | findstr :3306
# ou PowerShell
Get-NetTCPConnection -LocalPort 3306
```
1
2
3
Si 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

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"

Problème de configuration (bind-address) :
- Examinez la valeur de bind-address dans my.cnf. S’il est réglé sur 127.0.0.1 ou localhost, seuls les accès locaux seront permis. Pour une connexion externe, utilisez 0.0.0.0 ou une IP spécifique et autorisez les accès dans le pare-feu.
Problème de résolution réseau (localhost) :
- Vérifiez que localhost se résout bien en 127.0.0.1 (IPv4) et ::1 (IPv6).
macOS :
bash
```
ping localhost
cat /etc/hosts
```
1
2
Windows :
cmd
```
ping localhost
type C:\Windows\System32\drivers\etc\hosts
```
1
2
Assurez-vous que localhost figure correctement dans le fichier hosts. Désactivez tout proxy local susceptible d’interférer avec le trafic TCP/IP local.

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

Port occupé : (voir plus haut, vérification avec lsof ou netstat)
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>\ ; logs C:\ServBay\logs\mariadb\<version>\
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 :
bash
```
ls -ld /Applications/ServBay/db/mariadb/<version>
ls -l /Applications/ServBay/etc/mariadb/<version>/my.cnf
ls -ld /Applications/ServBay/logs/mariadb/<version>
```
1
2
3
Vé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 ou REVOKE, ou créez un nouvel utilisateur selon le besoin.

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 et long_query_time = 1 (requêtes de plus d’une seconde) dans my.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.
  sql
```
EXPLAIN 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.
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.
  sql
```
CREATE INDEX idx_column_name ON your_table_name(column_name);
```
  1
  Note : La création d’index alourdit l’écriture et consomme du stockage, à équilibrer selon le besoin.
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
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
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.

bash

mysqlcheck --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

Note : --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.
1. Sauvegardez le dossier de données (même corrompu) avant toute opération.
2. É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.
3. Essayez de démarrer MariaDB/MySQL.
4. Si cela fonctionne (même en mode dégradé), sauvegardez immédiatement la totalité des bases avec mysqldump :
  bash
```
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
  Vérifiez bien la taille et l’intégrité du fichier de sauvegarde.
5. Arrêtez le service dès la sauvegarde terminée.
6. Retirez ou commentez la ligne innodb_force_recovery = N du fichier my.cnf.
7. 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> :

bash

# 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>

Remarque : Remplacez <version> par la version cible.

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 via less 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.
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 :
sql
```
-- 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
Attention, n’utilisez cette désactivation que pour l’import, la cohérence des données peut être affectée.
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>

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>

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

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

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

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 :

bash

servbayctl start mariadb 11.5

Si le démarrage fonctionne, sauvegardez immédiatement les données :

macOS :

bash

mysqldump --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

Windows :

cmd

C:\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

Vérifiez absolument la validité et la taille du fichier de sauvegarde.

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 ligne innodb_force_recovery...

Guide de dépannage des paquets ServBay MariaDB/MySQL ​

Présentation ​

Étapes de diagnostic générales ​

Problèmes courants et solutions ​

1. Erreur de connexion : SQLSTATE[HY000] [2002] No such file or directory ​

2. Erreur de connexion : réseau (Connection refused, Can't connect to MySQL server...) ​

3. Impossible de démarrer MariaDB/MySQL ​

4. Problèmes de droits ou d’authentification utilisateur ​

5. Problèmes de performance ​

6. Plantage ou corruption de la base de données ​

7. Problèmes de sauvegarde et de restauration ​

8. Bug spécifique : Échec du démarrage InnoDB MariaDB 11.5.1 (ib_logfile0 was not found / Missing FILE_CHECKPOINT) ​

Guide de dépannage des paquets ServBay MariaDB/MySQL

Présentation

Étapes de diagnostic générales

Problèmes courants et solutions

1. Erreur de connexion : `SQLSTATE[HY000] [2002] No such file or directory`

2. Erreur de connexion : réseau (`Connection refused`, `Can't connect to MySQL server`...)

3. Impossible de démarrer MariaDB/MySQL

4. Problèmes de droits ou d’authentification utilisateur

5. Problèmes de performance

6. Plantage ou corruption de la base de données

7. Problèmes de sauvegarde et de restauration

8. Bug spécifique : Échec du démarrage InnoDB MariaDB 11.5.1 (`ib_logfile0 was not found` / `Missing FILE_CHECKPOINT`)