Base de données inaccessible ou en erreur : diagnostic et remise en service
Quand la base de données ne répond plus, toute l'application tombe avec elle : site en erreur, API qui renvoie des 500, back-office inutilisable. Les messages varient (« Connection refused », « Too many connections », « Access denied », « Table is marked as crashed », « could not connect to server ») et chacun pointe vers une cause différente.
Les causes les plus fréquentes sont un service MySQL, MariaDB ou PostgreSQL arrêté ou tué par manque de mémoire, un disque plein, un nombre de connexions saturé par une application qui ne les libère pas, des identifiants modifiés, une table corrompue après un arrêt brutal, ou une configuration réseau ou pare-feu qui bloque l'accès.
Cette page vous donne, pour MySQL/MariaDB et PostgreSQL, les vérifications à mener dans l'ordre, les corrections adaptées à chaque message d'erreur et les précautions à prendre pour ne pas transformer une panne en perte de données.
Symptômes typiques
- « Error establishing a database connection », « SQLSTATE[HY000] [2002] Connection refused » ou « could not connect to server: Connection refused ».
- « Too many connections » (MySQL) ou « FATAL: sorry, too many clients already » (PostgreSQL) aux heures de forte activité.
- « Access denied for user » ou « password authentication failed » après une migration, un changement de mot de passe ou une mise à jour.
- « Table './base/table' is marked as crashed and should be repaired » ou erreurs InnoDB dans le journal après un arrêt brutal.
- Requêtes extrêmement lentes, verrous (lock wait timeout, deadlock) et application qui se fige par intermittence.
- Le journal système montre que mysqld ou postgres a été tué par l'OOM killer, ou que le disque de données est plein.
Causes possibles
Service arrêté ou tué
Le processus de base de données s'est arrêté après un plantage, une mise à jour, un redémarrage du serveur sans activation au démarrage, ou a été tué par le noyau faute de mémoire (OOM killer).
Disque plein
Plus d'espace sur la partition de données ou de journaux : MySQL et PostgreSQL refusent d'écrire, puis de répondre. Les journaux binaires, les fichiers temporaires de requêtes ou les sauvegardes locales sont souvent en cause.
Connexions saturées
L'application ouvre plus de connexions que max_connections (MySQL) ou max_connections (PostgreSQL) n'en autorise : absence de pool, fuites de connexions, trop de workers PHP-FPM ou de pods, requêtes lentes qui monopolisent les connexions.
Identifiants ou droits incorrects
Mot de passe changé sans mise à jour de la configuration applicative, utilisateur créé pour localhost mais l'application se connecte via une IP, règles pg_hba.conf non mises à jour, base ou utilisateur supprimés.
Tables corrompues
Arrêt électrique, kill -9, disque défaillant ou plein en cours d'écriture : tables MyISAM marquées crashed, pages InnoDB invalides, index PostgreSQL incohérents.
Réseau ou pare-feu
Port 3306 ou 5432 bloqué par un groupe de sécurité, bind-address limité à 127.0.0.1 alors que l'application est sur une autre machine, changement d'adresse IP de la base managée.
Verrous et requêtes bloquantes
Une migration de schéma, une sauvegarde ou une requête longue verrouille des tables et fait attendre toutes les autres jusqu'au délai d'expiration.
Contrôles à effectuer
- 1
Lire le message d'erreur exact
Dans les journaux de l'application (Laravel, Symfony, WordPress debug.log, journaux Node ou Java) : « Connection refused » signifie service arrêté ou port bloqué ; « Access denied » identifiants ; « Too many connections » saturation ; « Unknown database » base absente.
- 2
Vérifier l'état du service
systemctl status mysql (ou mariadb, postgresql) indique si le service tourne et depuis quand. journalctl -u mysql -n 100 ou journalctl -u postgresql affiche les dernières erreurs au démarrage ou à l'arrêt.
- 3
Contrôler le disque et la mémoire
df -h et df -i sur la partition de données (/var/lib/mysql, /var/lib/postgresql), free -m, puis dmesg -T | grep -i 'killed process' pour savoir si le processus a été tué par l'OOM killer.
- 4
Tester la connexion manuellement
mysql -u utilisateur -p -h hôte base ou psql -U utilisateur -h hôte -d base depuis le serveur applicatif. Si la connexion locale fonctionne mais pas la distante, le problème est réseau, bind-address ou pg_hba.conf.
- 5
Mesurer les connexions
MySQL : SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections'; SHOW PROCESSLIST;. PostgreSQL : SELECT count(*) FROM pg_stat_activity; et SHOW max_connections;. Les requêtes en état Sleep ou idle en grand nombre révèlent une fuite de connexions.
- 6
Vérifier l'intégrité des tables
MySQL : CHECK TABLE nom_table; ou mysqlcheck --all-databases. PostgreSQL : consultez le journal pour les messages « invalid page » ou « could not read block » et lancez VACUUM et REINDEX sur les tables suspectes.
- 7
Identifier les verrous
MySQL : SHOW ENGINE INNODB STATUS; et la table information_schema.innodb_trx. PostgreSQL : SELECT * FROM pg_stat_activity WHERE wait_event_type = 'Lock'; et pg_locks pour trouver la transaction bloquante.
Solutions
Relancer et stabiliser le service
systemctl start mysql ou postgresql, puis systemctl enable pour le démarrage automatique. Si le service a été tué par manque de mémoire, réduire innodb_buffer_pool_size ou shared_buffers, ou augmenter la mémoire du serveur.
Libérer de l'espace disque
Purger les journaux binaires (PURGE BINARY LOGS), les journaux applicatifs, les anciennes sauvegardes locales et les fichiers temporaires, puis déplacer les données sur un volume plus grand si nécessaire.
Traiter la saturation des connexions
Corriger les fuites côté application, mettre en place un pool de connexions (PgBouncer pour PostgreSQL, pool applicatif côté Java ou Node), ajuster max_connections et wait_timeout de façon cohérente avec le nombre de workers.
Rétablir les accès
Recréer ou mettre à jour l'utilisateur et ses droits (GRANT, ALTER USER), aligner les identifiants dans la configuration applicative, corriger bind-address ou pg_hba.conf, ouvrir le port dans le pare-feu ou le groupe de sécurité.
Réparer les tables corrompues
MySQL : REPAIR TABLE pour MyISAM, innodb_force_recovery par paliers puis export et réimport pour InnoDB. PostgreSQL : REINDEX, restauration depuis la sauvegarde pour les blocs illisibles. Toujours sauvegarder les fichiers de données avant.
Restaurer une sauvegarde
Si les données sont irrécupérables, restaurer la dernière sauvegarde cohérente (mysqldump, xtrabackup, pg_dump, pg_basebackup) et rejouer les journaux si l'archivage était en place (binlog, WAL).
Quand contacter un professionnel ?
- La base contient des données de production et vous ne voulez pas tenter une réparation sans être sûr de la procédure.
- Les journaux signalent une corruption InnoDB ou des blocs illisibles PostgreSQL.
- La panne revient régulièrement (connexions saturées, OOM) et la cause est dans l'application ou le dimensionnement.
- Vous n'avez pas de sauvegarde récente ou vous ne savez pas si elle est restaurable.
- La base est managée (RDS, Cloud SQL, Azure Database) et vous devez comprendre les métriques ou ouvrir un ticket argumenté.
L'intervention proposée par Agencei
- 1
Sauvegarde de sécurité
Copie des fichiers de données et des journaux dans leur état actuel avant toute manipulation, pour garantir un point de retour.
- 2
Diagnostic
Analyse des journaux de la base et du système, de l'utilisation du disque et de la mémoire, des connexions et des verrous, identification de la cause précise.
- 3
Remise en service
Relance du service, libération des ressources, correction des accès, réparation des tables ou restauration ciblée, avec vérification de l'intégrité des données.
- 4
Correction structurelle
Réglage de MySQL, MariaDB ou PostgreSQL, mise en place d'un pool de connexions, correction des fuites applicatives, optimisation des requêtes bloquantes.
- 5
Sauvegardes et supervision
Sauvegardes automatiques testées, archivage des journaux pour la restauration à un instant donné, alertes sur le disque, la mémoire, les connexions et la réplication.
Questions fréquentes
Que signifie « Too many connections » et comment l'éviter ?
L'application a ouvert plus de connexions que la base n'en accepte. Augmenter max_connections soulage temporairement mais la solution durable est un pool de connexions correctement dimensionné et la correction des fuites ou des requêtes trop longues.
Puis-je réparer une table corrompue moi-même ?
Pour une table MyISAM, REPAIR TABLE est généralement sûr. Pour InnoDB ou PostgreSQL, les procédures de récupération forcée peuvent aggraver les dégâts si elles sont mal appliquées. Sauvegardez les fichiers bruts avant toute tentative.
La base était disponible hier, pourquoi plus aujourd'hui ?
Les causes soudaines les plus fréquentes sont un disque plein, un processus tué par manque de mémoire, un redémarrage du serveur sans démarrage automatique du service, un changement de mot de passe ou un pic de connexions.
Mes données sont-elles perdues ?
Rarement. Un service arrêté, un disque plein ou des identifiants invalides ne détruisent rien. La corruption réelle est plus rare et se traite par réparation ou restauration de sauvegarde.
Comment savoir si ma sauvegarde est exploitable ?
En la restaurant régulièrement sur un serveur de test. Une sauvegarde jamais restaurée n'est pas une garantie. Nous automatisons ce test dans le cadre d'une maintenance.
Services associés
Bases de données
Conception, optimisation, administration et sauvegardes de vos bases PostgreSQL, MySQL, MongoDB et Redis.
Voir ce serviceExpertise PostgreSQL
Conception de schéma, optimisation, réplication, montées de version et migration vers PostgreSQL.
Voir ce serviceSupport informatique
Assistance applicative et serveurs, gestion des incidents et engagements de service clairs.
Voir ce serviceMigration de données
Migration entre bases, moteurs, versions ou systèmes, avec ETL, validation et bascule sans interruption.
Voir ce serviceMaintenance informatique
Supervision, mises à jour, sauvegardes et amélioration continue de vos applications en production.
Voir ce serviceParlez-nous de votre projet
Décrivez votre besoin en quelques lignes : nous revenons vers vous avec une première analyse et les prochaines étapes.