Résolution de l'erreur Zimbra « DB error: DB failure / corruption » dans les journaux de messagerie : diagnostic et récupération sécurisés

L' erreur « DB Error: DB Failure » ​​dans le journal de messagerie Zimbra est un symptôme, et non un diagnostic. Elle peut indiquer une base de données arrêtée, une connexion défaillante, un espace disque insuffisant, un nombre excessif de connexions ou une corruption réelle des tables ou de la base de données InnoDB. La solution la plus appropriée dépend des lignes de journal environnantes et du serveur concerné. Commencez par des vérifications en lecture seule, protégez les données et n'exécutez pas de commande de réparation générique simplement parce que le mot « corruption » apparaît.

Ce guide utilise les chemins d'accès et les commandes Zimbra courants documentés dans le Centre technique de Zimbra. Certaines pages wiki associées sont archivées ou incomplètes ; veuillez donc vérifier chaque commande et procédure de récupération auprès de votre version et édition exactes de Zimbra en consultant l' index de la documentation officielle de Zimbra . Les exemples ci-dessous ne supposent pas une version spécifique.

Que signifie concrètement une erreur de base de données dans le fichier mailbox.log ?

La base de données de messagerie de Zimbra stocke les métadonnées des boîtes aux lettres, telles que les dossiers, les étiquettes, l'état des messages et les pointeurs vers les fichiers de messages. Les index de recherche sont stockés séparément, et le contenu des messages est stocké dans la base de données de messagerie. Une erreur de base de données n'implique donc pas automatiquement que tous les fichiers de messagerie sont corrompus. De même, une erreur d'index ne constitue pas, à elle seule, une preuve de dommage à la base de données. Zimbra décrit ces différents espaces de stockage dans sa documentation de référence sur l'architecture serveur .

L'indice décisif est généralement l'erreur de base de données sous-jacente qui apparaît à proximité de l'exception de boîte aux lettres, notamment dans les notes de dépannage /opt/zimbra/log/mysql_error.logde Zimbra. Ces notes indiquent que les erreurs de base de données mailbox.loget les erreurs de base mysql_error.logde données sont des points de départ utiles, la première zmmailboxd.outfournissant des informations sur le démarrage du service de boîte aux lettres. Consultez la documentation de dépannage des journaux de Zimbra .

Que devez-vous faire avant d'essayer une réparation ?

• Consignez l'heure de la première occurrence, le fuseau horaire, le nom d'hôte du serveur, le ou les comptes concernés, ainsi que l'exception complète et les lignes adjacentes. Masquez les mots de passe, le contenu des messages et les données personnelles avant de partager les journaux.
• Déterminez le périmètre : une seule boîte aux lettres, plusieurs boîtes aux lettres sur un même serveur ou des utilisateurs répartis sur plusieurs serveurs. Un problème affectant un seul compte ne justifie pas un redémarrage de la base de données à l’échelle du cluster.
• Vérifiez l'existence d'une sauvegarde récente et exploitable et identifiez la procédure de restauration spécifique à votre version. Si des erreurs se répètent ou si des utilisateurs sont affectés, évitez les redémarrages et les écritures répétées jusqu'à ce que l'état de la base de données soit connu.
• Utilisez une fenêtre de maintenance pour les vérifications qui analysent les tables de la base de données. Même une vérification d'intégrité peut augmenter les E/S et ralentir le service de messagerie.

Comment diagnostiquer cette maladie en toute sécurité ?

1. Vérifier l'état du service

Sur le serveur de messagerie, connectez-vous au compte Zimbra et vérifiez l'état du service. Exécutez les commandes avec le compte indiqué dans chaque invite ; ne collez pas de symbole d'invite (par exemple, \) $dans la commande.

su - zimbra
zmcontrol status

Vérifiez si le service de messagerie est en cours d'exécution et si le problème signalé est localisé sur un seul serveur de messagerie. L'arrêt du processus de messagerie ne suffit pas à conclure à une corruption de la base de données. La page de dépannage de Zimbra relative à la messagerie propose également des vérifications distinctes de l'état du service et de la connexion/configuration de la base de données ; cette page étant archivée, consultez-la et reportez-vous à la documentation de votre version.

2. Comparez simultanément les journaux de messagerie et de base de données.

Consultez la même période dans les deux journaux. La première erreur de la séquence est souvent plus utile que la dernière ligne « défaillance système ».

tail -n 100 /opt/zimbra/log/mailbox.log
tail -n 100 /opt/zimbra/log/mysql_error.log
tail -n 100 /opt/zimbra/log/zmmailboxd.out

Recherchez le message de base de données sous-jacent, le nom de la base de données ou du groupe de boîtes aux lettres, les horodatages répétés, les échecs de démarrage ou une erreur système correspondante. Considérez ces éléments comme des indices, et non comme des solutions automatiques.

3. Vérifiez la capacité du disque et les erreurs du système d'exploitation

Des volumes de données ou de journaux saturés, des inodes épuisés ou un stockage défaillant peuvent être confondus avec une panne de base de données. Effectuez des vérifications non destructives sur l'hôte de stockage :

df -h /opt/zimbra
df -i /opt/zimbra

Consultez le journal système ou le journal système pour détecter les erreurs d'E/S disque, de système de fichiers ou de mémoire insuffisante survenues durant la même période. Si un volume est plein, libérez de l'espace ou ajoutez-en en suivant votre procédure de stockage habituelle. Ne supprimez pas les fichiers de base de données, les journaux InnoDB ni les journaux Zimbra actifs pour libérer de l'espace ; cela pourrait compliquer la récupération ou détruire des preuves.

4. Effectuez un contrôle d'intégrité uniquement après avoir examiné l'impact.

Si le service de base de données de Zimbra est accessible et que les journaux ne font pas déjà apparaître de problème de connexion ou de stockage évident, un administrateur peut envisager de consulter le rapport d'intégrité standard pendant une fenêtre de maintenance en période de faible trafic :

su - zimbra
/opt/zimbra/libexec/zmdbintegrityreport

La documentation relative aux rapports d'intégrité de Zimbra décrit cette opération comme une vérification de la base de données et prévient qu'elle peut engendrer une augmentation des E/S et de la latence des boîtes aux lettres. Elle mentionne également une -roption de tentative de réparation automatique des tables. Il est déconseillé -rd'effectuer cette opération systématiquement : la page est en cours de rédaction et la procédure à suivre dépend du moteur de base de données, du type de table, de la version du produit et de l'état des sauvegardes. Un rapport mentionnant uniquement un message de verrouillage de table de journalisation sans conséquence doit être interprété conformément à la note figurant sur la page ; tous les messages d'erreur de base de données ne doivent pas être considérés comme équivalents.

Quelle solution correspond aux preuves ?

• Le service de base de données est arrêté, mais aucune corruption n'est constatée : commencez par résoudre l'erreur spécifique de démarrage, de configuration, d'authentification ou de ressource. Une fois le problème résolu, suivez la procédure de récupération du service correspondant à votre version et à votre topologie de déploiement. Évitez les redémarrages à l'aveugle répétés.
• Trop de connexions : examinez la charge, les clients bloqués et la capacité du service. N’attribuez pas le problème à une corruption de la base de données et n’appliquez pas une ancienne recommandation pour augmenter les limites sans consulter les recommandations actuelles de dimensionnement et de mise en production.
• Problème de disque ou de système de fichiers : stabilisez le stockage et vérifiez l’intégrité du système de fichiers. Si la base de données a enregistré des échecs d’écriture ou des erreurs InnoDB, considérez cela comme un incident d’intégrité potentiel, même après la restauration de l’espace disque.
• Le rapport d'intégrité signale les tables suivantes : enregistrez la sortie exacte, les noms des tables/bases de données, les horodatages et les journaux pertinents. Sauvegardez ou créez un instantané du volume de la base de données à l'aide d'une méthode prise en charge avant toute opération d'écriture. Demandez à un administrateur de suivre la procédure de réparation ou de restauration fournie par le fournisseur pour la version de Zimbra installée.
• Un compte reste affecté alors que le moteur de base de données est opérationnel : examinez séparément les métadonnées de sa boîte aux lettres, sa messagerie ou son index. Évitez de modifier manuellement les lignes SQL ou de supprimer des fichiers pour « reconstruire » le compte.

En cas de suspicion de corruption d'InnoDB, la solution la plus sûre consiste généralement en une restauration spécifique à la version à partir d'une sauvegarde vérifiée ou en une restauration guidée par le support, et non en une REPAIR TABLEréinitialisation générique de la base de données ou en une simple copie de la séquence de commandes. Certains anciens articles du wiki Zimbra relatifs à la restauration contiennent des étapes destructives et sont explicitement archivés ; ne les appliquez pas à un système actuel sans confirmation directe du support Zimbra et sans avoir vérifié votre sauvegarde.

Comment pouvez-vous confirmer que le problème est résolu ?

Après l'application de la mesure corrective approuvée, vérifiez que les services de base de données et de messagerie restent opérationnels, que les nouvelles entrées ne présentent plus la même erreur de base de données sous-jacente et que le compte concerné peut effectuer des opérations de messagerie normales. Relancez le rapport d'intégrité standard uniquement si cela est pertinent pour votre fenêtre de chargement et votre version. Assurez-vous que la tâche de sauvegarde est terminée et conservez les journaux et l'enregistrement de réparation. Si le problème persiste, veuillez communiquer à votre administrateur ou au support Zimbra la version/build exacte de Zimbra, la configuration (mono-serveur ou multi-serveurs), le périmètre de la messagerie, l'heure de la première défaillance, les extraits de journaux pertinents, l'état du disque, le résultat du rapport d'intégrité et l'horodatage de la sauvegarde.

Point essentiel : diagnostiquez l’erreur de base de données à l’origine de l’exception de boîte aux lettres avant de modifier les données. Le seul message « Défaillance de la base de données » ne permet pas de déterminer si la solution consiste à corriger les informations d’identification, à modifier la capacité, à réparer le stockage ou à restaurer la base de données.

Références principales : Index de la documentation Zimbra ; Architecture du serveur Zimbra ; Dépannage des journaux Zimbra ; Référence du rapport d’intégrité de la base de données Zimbra ; Référence de l’erreur 1040 de MySQL Zimbra ; et Référence de dépannage de la messagerie Zimbra . Certaines pages du Centre technique sont archivées ou en cours de rédaction, comme indiqué dans l’article.