Quels sont les signes avant-coureurs indiquant qu’un conteneur de base de données a été corrompu par une coupure de courant ?
Soupçonnez une corruption lorsque la base de données ne peut pas terminer la récupération normale après incident ou signale ensuite des incohérences de sommes de contrôle, de pages, de séquences de journaux, de tables ou d’index.
Un arrêt incorrect ne signifie pas automatiquement que la base de données est corrompue ; PostgreSQL, MySQL, MariaDB et les moteurs similaires utilisent précisément des journaux ou des journaux d’écriture anticipée pour récupérer l’état validé. Le seuil d’alerte est franchi lorsque la récupération se répète, que le moteur s’arrête, que la même requête rencontre des pages invalides, que les sommes de contrôle échouent, que des tables disparaissent, que les index contredisent les données des tables, ou que les sauvegardes et les contrôles d’intégrité ne peuvent pas lire le cluster de manière cohérente.
Distinguez la récupération normale après incident d’une boucle de récupération
Conservez le premier journal de démarrage après le retour du courant. Notez si le moteur rejoue les journaux une seule fois et devient opérationnel, ou s’il redémarre sans cesse, passe en récupération forcée ou s’arrête toujours au même enregistrement ou sur la même page.
InnoDB peut signaler la restauration de pages potentiellement partiellement écrites après une écriture interrompue ; ce message indique que le moteur tente une récupération sûre après incident, mais des échecs répétés peuvent pointer vers des erreurs InnoDB postérieures à une panne.
Une récupération réussie suivie de contrôles normaux ne prouve pas à elle seule l’absence de corruption. Une boucle, une assertion fatale, un signal répété ou l’impossibilité d’atteindre l’état opérationnel doivent inciter à arrêter la copie des fichiers bruts et à tester les sauvegardes avant toute nouvelle écriture.
Recherchez les erreurs de somme de contrôle et de page invalide
Recherchez dans les journaux les mentions de somme de contrôle incohérente, d’échec de vérification de page, de page invalide dans un bloc, de page corrompue, de lecture courte, de nombre magique incorrect ou de fin de fichier inattendue. Notez la relation, la table, le bloc ou l’espace de tables indiqué.
pganalyze montre que la corruption de PostgreSQL peut se manifester par des échecs de somme de contrôle de page, suivis d’une erreur de page invalide lorsque le bloc endommagé est lu.
Ne masquez pas l’erreur et ne mettez pas à zéro les pages endommagées avant d’avoir préservé les éléments de preuve et confirmé la couverture des sauvegardes. Le fait que le même bloc échoue après plusieurs redémarrages constitue une preuve plus solide qu’une expiration de délai applicative ponctuelle.
Surveillez les requêtes qui échouent uniquement sur certaines lignes ou tables
Exécutez des contrôles en lecture seule sur les tables et les requêtes normalement utilisées par l’application. La corruption peut rester cachée jusqu’à ce qu’une analyse, un vacuum, une sauvegarde ou une requête touche une page endommagée.
Une analyse de PostgreSQL explique qu’une somme de contrôle incohérente pointe vers un problème situé en dessous de la base de données, tandis qu’une page invalide sans avertissement de somme de contrôle peut tout de même refléter un problème de stockage, de mémoire, de système de fichiers ou une détérioration accidentelle d’un fichier. Le symptôme concret est une lecture de page invalide reproductible lors de requêtes ordinaires.
Notez précisément la requête et l’objet qui échouent. Ne laissez pas l’application poursuivre des écritures massives alors que seule une partie de la base de données reste lisible, car les nouveaux états peuvent compliquer la récupération et les sauvegardes.
Vérifiez les incohérences d’index, de transactions et de métadonnées
Les signes avant-coureurs comprennent des clés en double qui violent un index unique, des lignes manquantes accessibles par un chemin d’accès mais pas par un autre, des identifiants de transaction invalides, des blocs TOAST ou de grandes valeurs endommagés, ainsi que des index qui échouent à la validation.
L’analyse de Credativ sur la corruption indique que les clusters sans sommes de contrôle des données peuvent révéler des dommages par des erreurs de bas niveau telles que des pages invalides, des problèmes d’identifiants de transaction, des incohérences TOAST ou des plantages du processus serveur. Certaines sauvegardes par copie de fichiers peuvent conserver des pages corrompues sans les détecter.
Exécutez les contrôles d’intégrité et d’index pris en charge sur une copie ou pendant une fenêtre de maintenance contrôlée. La reconstruction d’un index peut réparer un index dérivé endommagé, mais elle ne répare ni les données corrompues des tables ni le stockage sous-jacent.
Mettez en corrélation les erreurs de la base de données avec les avertissements du système de fichiers et du stockage
Inspectez les journaux du noyau de l’hôte, du système de fichiers, du pool, du disque, du contrôleur, de l’onduleur et du moteur d’exécution des conteneurs autour de l’incident. Recherchez les erreurs d’E/S, les réinitialisations, les erreurs de somme de contrôle, les remontages en lecture seule, les pools dégradés ainsi que les fichiers perdus ou tronqués.
Un guide de récupération de base de données indique que les pannes de courant et les mémoires défectueuses peuvent produire des écritures de pages corrompues, en particulier lorsque le comportement du stockage ne correspond pas aux hypothèses de durabilité de la base de données. Ces événements au niveau de l’hôte aident à distinguer la corruption de pages InnoDB d’un redémarrage normal de l’application.
Réparez le chemin de stockage avant d’y restaurer une base de données saine. Une restauration logique réussie sur un support défaillant peut reproduire l’incident ou endommager silencieusement le système de remplacement.
Arrêtez les écritures et prouvez la récupération à partir d’une sauvegarde saine
Lorsque les signes de corruption sont reproductibles, arrêtez les applications dépendantes, créez un instantané ou un clone du volume affecté si cela ne présente pas de risque, et préservez les journaux et la configuration. Testez la sauvegarde la plus récente sur un stockage distinct avant de modifier le cluster d’origine.
La liste de contrôle ZimaSpace pour la sauvegarde de l’état des applications Docker définit ce qui doit être disponible avant de tenter une récupération destructive de la base de données.
Le système n’est digne de confiance que lorsque la base de données restaurée démarre correctement, que les contrôles d’intégrité réussissent, que des requêtes et des écritures représentatives aboutissent, que les sauvegardes se terminent et que le stockage de l’hôte ne signale aucune nouvelle erreur. Les modes de récupération forcée doivent servir à récupérer les données dans le cadre d’un plan documenté, et non constituer un mode de fonctionnement normal.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
