Erreurs base de données OVHcloud : diagnostic et solutions d’hébergement Web

Table des matières :

1. Cartographier une erreur base de données OVHcloud (sans perdre 2 heures dans le mauvais log)
2. Diagnostic rapide selon l’hébergement OVHcloud : mutualisé, Web Cloud Databases, VPS, Managed Databases
3. Erreurs de connexion MySQL/MariaDB sur OVHcloud : réseau, DNS, TLS, droits et paramètres PrestaShop
4. Saturation et erreurs transitoires : Too many connections, server has gone away, timeouts
5. Contention InnoDB : lock wait timeout, deadlocks, transactions trop longues (souvent du code)
6. Corruption, disque et maintenance : “table is marked as crashed”, erreur 28, et restaurations propres
7. Observabilité exploitable : métriques, logs, alerting (sinon vous “diagnostiquez” aprsl incident)
8. Actions correctives et arbitrages : quand l’incident prouve que l’offre OVHcloud est trop limitée

Cartographier une erreur base de données OVHcloud (sans perdre 2 heures dans le mauvais log)

Sur PrestaShop, une « erreur base de données OVHcloud » n’est presque jamais « une erreur MySQL » au sens strict. C’est un symptôme observable à un étage (PHP, Symfony, front controller, module, cron, pool PHP-FPM) dont la cause réelle est souvent ailleurs (saturation CPU, disque plein, limites mutualisées, DNS, TLS, contention InnoDB). Avant d’optimiser quoi que ce soit, il faut déterminer l’endroit exact où l’erreur est produite : connexion initiale, requête SQL lente, transaction bloquée, ou backend MySQL indisponible.

Commencez par classifier le message côté application. En production, les signatures les plus fréquentes sont :

• SQLSTATE[HY000] [2002] Connection refused (port fermé / service down / firewall)
• SQLSTATE[HY000] [2002] No such file or directory (socket local inexistant quand on croit être en TCP)
• SQLSTATE[HY000] [1045] Access denied for user (mauvais couple user/pass, host interdit, droits)
• SQLSTATE[HY000] [2006] MySQL server has gone away (timeout, paquet trop gros, restart, kill)
• SQLSTATE[HY000] [1205] Lock wait timeout exceeded (contention / transactions longues)
• SQLSTATE[40001] Deadlock found when trying to get lock (deadlock InnoDB)

Pour gagner du temps, utilisez une logique “3 timestamps” : heure de l’erreur en front, heure de l’entrée log PHP/Symfony, heure des logs web (access/error). Les décalages de timezone (serveur en UTC, navigateur en heure locale) font perdre beaucoup de temps lors des corrélations : vérifiez au passage la timezone système et celle de PHP.

Un mémo utile (à appliquer sans dogmatisme) :

Symptôme côté PrestaShop	Couche la plus probable	Prochaine preuve à collecter
Erreur immédiate dès le chargement BO/FO	Connexion DB / réseau / droits	test mysql en CLI + résolution DNS + port 3306
Lenteur puis erreur aléatoire	Saturation / requêtes lentes	p95 latence DB + slow queries (si possible) + Threads_connected
Erreur pendant import/cron	Transactions longues / locks	horaire cron + SHOW ENGINE INNODB STATUS\G + requêtes du module
Erreur uniquement sur certaines pages	Module / requête non indexée	profiler / EXPLAIN sur la requête incriminée

Pour PrestaShop 8.1–9.1 (PHP 8.1–8.3 en pratique, voir la matrice de compatibilité de votre boutique), activez temporairement un niveau de logs exploitable : logs Symfony (var/log/), logs PrestaShop (Back Office > Paramètres avancés > Logs) et surtout logs PHP (error_log). La gestion d’erreur PHP est un prérequis pour éviter les faux positifs applicatifs : voir « Gestion d’erreur PHP : bonnes pratiques et configuration développement/production ».

Côté OVHcloud, la règle est simple : si vous êtes sur mutualisé, vous n’avez pas la main sur les logs MySQL serveur ni sur la configuration globale. Vous devrez alors corréler : (1) logs applicatifs, (2) journaux web (Apache/Nginx), (3) tableau de bord OVHcloud (état du service, limites atteintes). Si vous êtes sur VPS/Public Cloud, l’erreur DB doit être confirmée dans journalctl, les logs MariaDB/MySQL (/var/log/mysql/ ou journald selon distro), et via des commandes de santé (mysqladmin ping, SHOW GLOBAL STATUS).

Astuce “terrain” : avant d’aller trop loin, vérifiez s’il n’y a pas un incident fournisseur côté OVHcloud (rare, mais ça arrive) via la page officielle d’état de service.

Diagnostic rapide selon l’hébergement OVHcloud : mutualisé, Web Cloud Databases, VPS, Managed Databases

Le diagnostic change radicalement selon l’offre OVHcloud. Sur mutualisé, la base est souvent un service partagé (ressources limitées, quotas connexions, pas de tuning InnoDB). Vous pouvez généralement agir sur : (a) la fréquence des requêtes (cache, index), (b) la qualité des requêtes (EXPLAIN, pagination), (c) le nombre de connexions simultanées (réglages PHP-FPM si vous avez la main, sinon trafic). Toute stratégie « je monte max_connections » est hors-sujet : vous ne contrôlez pas le paramètre.

Sur Web Cloud Databases (offre dédiée DB historiquement proposée pour accompagner l’hébergement web), vous avez plus de stabilité et parfois des métriques, mais les droits restent limités : certaines variables sont verrouillées, et l’accès système est inexistant. Sur Managed Databases for MySQL (DBaaS), vous gagnez en supervision et en options (sauvegardes gérées, réplication selon plans), mais vous payez la simplicité par des contraintes : certaines opérations (plugins, paramètres) ne sont pas modifiables librement.

Sur VPS OVHcloud (Ubuntu/Debian), vous êtes responsable de tout : sécurité, backups, tuning MySQL/MariaDB, monitoring, patchs. Le runbook doit inclure firewall, anti-DDoS, gestion SMTP, et surtout sécurisation (accounts, réseau, SSH) : voir « VPS OVHcloud : sécurité, anti-DDoS, SMTP 25 et bonnes pratiques admin ».

Un tableau “réflexe” pour choisir le bon angle d’attaque :

Offre OVHcloud	Accès aux logs DB	Tuning MySQL/MariaDB	Levier principal en incident
Mutualisé	Non	Non	cache + optimisation requêtes + réduire concurrence
Web Cloud Databases	Partiel	Très limité	optimiser applicatif + métriques/quotas + latence réseau
Managed Databases (DBaaS)	Métriques + journaux selon offre	Limité	dimensionnement + connexions + index + règles réseau/TLS
VPS	Oui	Oui	diagnostics complets (IO/CPU/locks) + tuning + observabilité

Ajoutez une dimension souvent négligée : la géolocalisation des composants. OVHcloud opère des régions/datacenters (ex. France, Canada, etc.). Si votre serveur web et votre base sont dans des zones éloignées (par exemple web en Europe et DB en Amérique du Nord), la latence réseau peut suffire à transformer une boutique “OK” en boutique instable (timeouts, connexions qui s’empilent). Sans supposer de chiffres, mesurez :

• la latence brute (ping, mtr)
• la latence applicative (temps de connexion MySQL + requête simple)

Dans tous les cas, commencez par répondre à 3 questions factuelles (pas d’intuition) : 1) L’erreur est-elle corrélée à une fenêtre horaire (cron, import, pics de trafic, campagnes) ? 2) Le service DB est-il joignable depuis le serveur web (TCP 3306/SSL) ? 3) Quel est le goulet au moment T (connexions, CPU, IO disque, locks InnoDB, mémoire) ?

Erreurs de connexion MySQL/MariaDB sur OVHcloud : réseau, DNS, TLS, droits et paramètres PrestaShop

La première famille d’« erreurs base de données OVHcloud » est triviale : la connexion ne s’établit pas. Sur PrestaShop 8.1–9.1, vérifiez la configuration DB dans app/config/parameters.php (et selon votre historique, parfois config/settings.inc.php existe encore en lecture/compat). Une mauvaise migration, un changement d’hôte OVHcloud, ou une restauration de backup avec des identifiants obsolètes suffit à produire un Access denied ou Unknown database.

Checklist rapide (2 minutes) :

• l’hôte DB (database_host) est-il bien celui fourni par OVHcloud (et pas localhost “par habitude”) ?
• le port est-il explicitement requis (3306 le plus souvent) ?
• le nom de base (database_name) correspond-il exactement (attention aux environnements staging/prod) ?
• l’utilisateur a-t-il les droits sur ce schéma (et pas seulement un login valide) ?
• si vous utilisez un préfixe de tables, vérifiez que PrestaShop pointe bien sur le bon préfixe lors d’une restauration/migration.

Depuis le serveur web (VPS / cloud), testez la connexion hors PrestaShop pour éliminer la couche applicative :

# TCP
mysql -h DB_HOST -P 3306 -u DB_USER -pDB_PASS DB_NAME -e 'SELECT 1;'

# Vérifier DNS + latence
getent hosts DB_HOST
nc -vz DB_HOST 3306

Si vous suspectez le cas “socket vs TCP” (typiquement No such file or directory lorsque le client tente un socket local), forcez le protocole TCP :

mysql --protocol=TCP -h DB_HOST -P 3306 -u DB_USER -p DB_NAME -e 'SELECT 1;'

Si le service impose TLS (fréquent sur DB managées), testez explicitement :

mysql -h DB_HOST -u DB_USER -p --ssl-mode=REQUIRED DB_NAME -e 'SHOW STATUS LIKE "Ssl_cipher";'

Et pour distinguer un problème TLS d’un problème réseau pur, un test bas niveau peut aider :

# Déclenche une négociation TLS au niveau MySQL (si supporté côté client OpenSSL)
openssl s_client -starttls mysql -connect DB_HOST:3306 -servername DB_HOST

Deux points piégeux sur OVHcloud :

• Firewall / security group (Public Cloud) : un port 3306 fermé donne un Connection refused ou timeout. Ce n’est pas un bug PrestaShop.
• DNS/IPv6 : si votre serveur résout un AAAA non routable, vous verrez des timeouts intermittents. Forcer IPv4 côté client MySQL (ou corriger la résolution) stabilise souvent.

Enfin, ne mélangez pas « droits MySQL » et « droits OVHcloud ». Même si OVHcloud vous donne un login, MySQL peut restreindre par host (user@'%' vs user@'ip'). Sur un VPS, contrôlez :

SELECT user, host FROM mysql.user WHERE user = 'DB_USER';
SHOW GRANTS FOR 'DB_USER'@'%';

Mini-scénario fréquent : vous migrez une boutique vers un nouveau serveur OVHcloud (nouvelle IP). Le login DB autorise user@'ancienne_ip' mais pas user@'%'. Résultat : Access denied uniquement depuis le nouveau serveur, alors que phpMyAdmin/Manager “fonctionne”. La correction est un ajustement de l’hôte autorisé (ou une règle réseau), pas un changement de mot de passe.

Saturation et erreurs transitoires : Too many connections, server has gone away, timeouts

Quand la connexion fonctionne mais s’effondre sous charge, vous êtes typiquement sur une saturation de ressources ou une mauvaise orchestration entre PHP-FPM et MySQL/MariaDB. Une boutique PrestaShop qui ouvre trop de connexions simultanées peut déclencher Too many connections (MySQL error 1040) sur une DB limitée (mutualisé/DBaaS) ou sur un MySQL mal tuné.

Sur VPS (MariaDB 10.11 LTS ou MySQL 8.0), commencez par mesurer au lieu de « deviner » :

SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';
SHOW VARIABLES LIKE 'max_connections';
SHOW PROCESSLIST;

Interprétation rapide :

• Threads_connected élevé et stable : trop de concurrence ou connexions qui “traînent” (requêtes lentes, transactions, application qui attend).
• Max_used_connections proche de max_connections : vous avez déjà touché le plafond.
• SHOW PROCESSLIST : permet de voir si vous êtes bloqué sur des requêtes “Sending data”, “Locked”, “Copying to tmp table”, etc.

Puis corrélez avec la config PHP-FPM : si pm.max_children=80 et que chaque worker déclenche plusieurs requêtes lentes, vous construisez vous-même votre incident. Dans un cas réel anonymisé (PrestaShop 8.1, PHP 8.2, MariaDB 10.11 sur VPS 4 vCPU / 8 Go), baisser pm.max_children de 80 à 40, ajouter un cache applicatif Redis, et corriger deux requêtes non indexées a réduit Threads_connected (p95) de ~120 à ~35 et supprimé les 1040 pendant les pics.

Un repère utile : si votre DB est sur une offre où vous ne contrôlez pas max_connections, le levier le plus propre est presque toujours côté web (limiter les workers, accélérer les pages les plus demandées avec cache, réduire le travail DB par requête).

MySQL server has gone away (error 2006) est plus ambigu : il peut venir d’un timeout (wait_timeout), d’un redémarrage, d’un kill OOM, ou d’un paquet trop gros (max_allowed_packet). Le diagnostic passe par les logs serveur (si vous y avez accès) et les stats :

SHOW GLOBAL STATUS LIKE 'Aborted_connects';
SHOW GLOBAL STATUS LIKE 'Aborted_clients';
SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'max_allowed_packet';

À vérifier aussi côté application : import CSV/flux qui insère des descriptions très longues, images encodées, ou payloads anormalement gros (certains modules font des inserts “massifs”). Si vous êtes sur mutualisé/DBaaS sans logs, la stratégie « robuste » consiste à réduire la variabilité : limiter la concurrence (workers), réduire les requêtes lourdes (index, pagination), et déplacer hors front les jobs volumineux (imports, exports) via CLI/cron avec quotas et fenêtres dédiées.

Cette recommandation motive l’activation du slow query log sur les environnements où vous avez la main (VPS) : attaquez d’abord les requêtes lentes, pas les paramètres.

Contention InnoDB : lock wait timeout, deadlocks, transactions trop longues (souvent du code)

Lock wait timeout exceeded (1205) et les deadlocks (1213) ne se « règlent » pas en montant un timeout. Sur PrestaShop, ils arrivent souvent pendant des opérations concurrentes : mise à jour de stock, création de panier/commande, import catalogue, génération de facettes, ou modules qui écrivent de façon agressive. Le cœur PrestaShop n’est pas exempt : certaines séquences peuvent générer des transactions longues si la boutique fait beaucoup d’écritures et que la DB est sous-dimensionnée.

Sur MySQL/MariaDB, le diagnostic sérieux impose SHOW ENGINE INNODB STATUS\G au moment du problème. Vous y verrez : dernière deadlock, transactions actives, verrous détenus/attendus. Exemple de démarche :

SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';
SHOW ENGINE INNODB STATUS\G

Sur un VPS, si vous devez investiguer des deadlocks intermittents en production, un réglage utile (quand vous avez la main) est d’augmenter la “traçabilité” dans les logs MySQL/MariaDB pour retrouver la requête fautive. L’objectif n’est pas de laisser des logs verbeux indéfiniment, mais de capturer une fenêtre représentative (période de soldes, campagne e-mailing, import).

Puis vous remontez au code : quelle requête bloque, quel index manque, quel module fait un UPDATE sans condition sélective. L’article « Index MySQL : optimiser WHERE, JOIN et ORDER BY avec EXPLAIN » donne une méthode reproductible pour arrêter de « tuner à l’aveugle ».

Le point important, côté PrestaShop : un deadlock est un mécanisme normal en charge, pas une corruption. Votre job est de réduire sa fréquence (index, ordre des mises à jour, transactions plus courtes) et de rendre l’application tolérante (retry contrôlé sur opérations idempotentes côté module/cron, pas sur paiement).

Un anti-pattern fréquent en e-commerce : un module d’import qui fait de gros UPDATE sur des tables très sollicitées (stock/prix) pendant que le trafic client est au plus haut. Le bon arbitrage est souvent organisationnel : fenêtrer les imports (nuit / heures creuses), ou les exécuter sur un worker séparé pour éviter que le front ne se retrouve en compétition directe sur les mêmes lignes.

Corruption, disque et maintenance : “table is marked as crashed”, erreur 28, et restaurations propres

Une « erreur base de données OVHcloud » peut être beaucoup plus bas niveau : table MyISAM corrompue (rare sur PrestaShop moderne mais encore présent via modules), crash disque, espace saturé (Got error 28 from storage engine), ou filesystem en lecture seule après incident. Sur mutualisé, vous n’aurez pas la main pour réparer au niveau OS : il faut passer par l’interface OVHcloud (quota, état) et par des opérations SQL autorisées.

Sur VPS, adoptez une approche conservatrice : backup avant réparation. Pour les tables non InnoDB ou les incohérences, mysqlcheck peut aider, mais ne remplace pas une restauration cohérente :

# Vérification et tentative de réparation (attention en production)
mysqlcheck -u root -p --check --databases DB_NAME
mysqlcheck -u root -p --auto-repair --databases DB_NAME

Avant même de “réparer”, vérifiez l’évidence (surtout pour l’erreur 28) :

• df -h : espace disque
• df -i : inodes (plus rare, mais possible)
• taille de /var/lib/mysql, des backups locaux, des logs (binlogs, journaux applicatifs), et des fichiers temporaires

Pour InnoDB, « réparer une table » est rarement la bonne action. Si vous êtes dans un scénario de crash/redo log, l’option innodb_force_recovery peut permettre un dump de secours, mais c’est une opération à risques (perte de données, instance en mode dégradé). Dans un contexte e-commerce, la procédure standard est : figer l’écriture (maintenance), dumper ce qui peut l’être, puis restaurer sur une instance saine.

La maintenance applicative compte autant que la maintenance DB. PrestaShop accumule des données (paniers, logs, stats, tables de modules) qui dégradent les index et les temps de réponse. Si vous cherchez une routine pragmatique (nettoyage, purge, vérifications, automatisation), appliquez « Base de données PrestaShop : routine de maintenance et nettoyage automatisé ».

Point d’attention : une “base pleine” ne vient pas uniquement du catalogue. Les tables de logs (certaines extensions), les tables de recherche/facettes, ou des historiques de paniers/connexions peuvent grossir plus vite que prévu. Le bon réflexe est de mesurer le top 10 des tables (taille data + index) et de traiter en priorité celles qui explosent sans valeur métier directe.

Observabilité exploitable : métriques, logs, alerting (sinon vous “diagnostiquez” aprsl incident)

Sans métriques, vous confondez cause et conséquence. Une base qui “tombe” peut être en réalité un serveur web qui sature et ouvre trop de connexions, un import qui monopolise l’IO, ou un manque de buffer pool. L’objectif n’est pas de « monitorer pour monitorer », mais de construire une chaîne de preuves : DB latency (p95), nombre de connexions, IO, locks, CPU steal, et corrélation avec le trafic.

Netdata est un bon point de départ pour un VPS/Public Cloud, parce qu’il donne rapidement : latence MySQL, hits InnoDB buffer pool, saturation disque, swap, et alertes. Référence interne : « Netdata monitoring : surveiller AWS, Kubernetes, bases de données et serveurs web ».

Pour l’industrialisation (historique, dashboards, SLO), Grafana + Prometheus (ou Grafana Agent) reste la base. Référence interne : « Grafana sur Ubuntu : installation APT et configuration initiale ».

« Monitoring is one of the primary means by which service owners keep track of a system’s health and availability. » — Google, “Site Reliability Engineering”, O’Reilly (2016) https://sre.google/sre-book/monitoring-distributed-systems/

Concrètement, définissez 5 alertes qui évitent 80% des surprises :

• Threads_connected proche de max_connections (seuil 70–80% en warning)
• latence requêtes (p95) > X ms pendant Y minutes
• Innodb_row_lock_time qui explose (contention)
• disque > 85% (risque erreur 28)
• redémarrages mysqld (uptime qui reset)

Pour rendre ces alertes actionnables, associez-leur une action immédiate (runbook). Exemple :

• alerte connexions : baisser temporairement la concurrence web (workers), activer une page de maintenance légère, et identifier la page/end-point qui déclenche le pic (access logs).
• alerte latence : lister les requêtes les plus longues (slow log si VPS) ou au minimum identifier la fenêtre (cron/import).
• alerte disque : purger backups/logs locaux, puis corriger la cause (rotation, rétention).

Même sur des offres gérées (DBaaS), vous disposez souvent d’indicateurs (connexions, CPU, stockage). Exploitez-les au même titre que vos logs applicatifs : une “erreur base de données OVHcloud” devient beaucoup plus simple à trancher quand on voit un plafond atteint au même moment.

Actions correctives et arbitrages : quand l’incident prouve que l’offre OVHcloud est trop limitée

Sur mutualisé, les solutions sont principalement applicatives : réduire la charge DB via cache et optimisation. Sur PrestaShop, le cache côté serveur (Redis/Memcached), le cache HTTP (Varnish) et l’optimisation PHP-FPM/OPcache réduisent directement les lectures/écritures et donc les “erreurs base de données OVHcloud” induites par saturation. Pour une stratégie complète, référez-vous à « Cache PrestaShop : Varnish, Redis, Memcached et OPcache côté serveur ».

Sur VPS, la correction est souvent une combinaison : (1) tuning MySQL (buffer pool, redo logs, slow log), (2) correction des requêtes (index, éviter SELECT *, limiter les ORDER BY sans index), (3) limitation de la concurrence côté PHP-FPM, et (4) séparation des workloads (front vs workers/cron). Une boutique qui fait des imports massifs et du trafic en même temps devrait isoler un worker (container, VM) et exécuter les traitements lourds hors des heures de pointe.

• innodb_buffer_pool_size est généralement dimensionné pour contenir une grande partie des données “chaudes” (souvent une fraction importante de la RAM disponible), sinon vous payez en IO disque et en latence.
• une latence DB stable vaut souvent mieux qu’un pic de débit : évitez de sur-paralléliser (web + crons + imports) si la DB est le goulot.

Enfin, il y a un point transactionnel mais non “marketing” : parfois, la seule solution durable est de sortir de l’hébergement qui impose les limites. Indicateurs concrets :

• vous touchez régulièrement des plafonds connexions/CPU sans pouvoir scaler,
• vous ne pouvez pas activer ni exploiter le slow log,
• vous n’avez pas de backups point-in-time ou de réplication,
• vous faites des opérations critiques (soldes, drops, B2B) et l’indisponibilité DB n’est plus acceptable.

Dans ce cas, documentez le plan (export DB, fenêtres de maintenance, DNS, rollback) et traitez l’hébergement comme un composant de prod à part entière. Deux articles internes utiles pour cadrer une décision : « Hébergement cloud managé : performance NVMe, CDN mondial et TTFB <50 ms » et « Résiliation hébergement PrestaShop : sauvegarde complète et plan de migration ».

Checklist de migration “propre” (résumé) :

• baisser le TTL DNS 24–48h avant (si possible)
• figer les écritures (maintenance) le temps du dump
• exporter la DB avec un outil fiable et vérifier la restauration sur un environnement de test
• basculer, puis surveiller erreurs 5xx, latence DB et commandes pendant la première heure
• prévoir un rollback réaliste (pas théorique)

Enfin, ne laissez pas la DB devenir votre angle mort sécurité : comptes MySQL trop permissifs, backups non chiffrés, accès réseau trop large. Une base qui “tombe” est souvent une base qui fuit (scan, brute force, injection via module vulnérable). Pour durcir, voir « Sécurité PrestaShop : mises à jour, SSL et durcissement .htaccess ».