Récupération PostgreSQL sans sauvegarde de 2,5 To

Récupération PostgreSQL sans sauvegardes : Étude de cas d'un cluster de 2,5 To

Un cluster PostgreSQL de 2,5 To de Postgres Professional a fonctionné pendant trois ans sur une machine virtuelle sans sauvegardes. Le disque, configuré sans réservation d'espace, a dépassé la taille physique de l'hôte, s'étendant via copy-on-write. Dix bases de données actives, dont 1C, ont planté après le chargement d'une nouvelle infobase : les journaux WAL ont rempli le disque de l'hyperviseur et les checkpoints n'ont pas pu se terminer.

Les administrateurs ont supprimé manuellement les fichiers WAL et tenté d'arrêter le postmaster en mode fast, sans succès. Un arrêt forcé SIGKILL a entraîné une corruption des données en raison de shared_buffers massifs. Le démarrage via pg_resetwal a désactivé la récupération WAL ; les requêtes simples fonctionnaient, mais pas les complexes.

Diagnostics et correctifs initiaux

En utilisant l'utilitaire crash_info (disponible dans la version gratuite de Postgres Professional) via le signal SIGRTMIN+6, nous avons identifié un blocage sur _bt_moveright dans un index btree du catalogue système. Nous avons activé le paramètre ignore_system_indexes ou appliqué un patch pour contourner les index système. REINDEX SYSTEM ne s'est pas terminé pendant la nuit.

pg_dump s'est bloqué lors de la récupération de la liste des tables en raison d'index manquants. Le paramètre --data-only n'a pas aidé : l'utilitaire demandait des statistiques étendues. Un patch pour pg_dump a exclu les requêtes inutiles vers le catalogue système.

Export des données et conséquences

Après 24 heures, les données de la base clé ont été exportées vers un nouveau cluster. Un rapport de bug soumis à la communauté PostgreSQL avec un patch (pour les versions 13–17) a mis en évidence les problèmes de pg_dump avec les index corrompus. La communauté a refusé de classer cela comme un bug : la récupération sans sauvegardes n'est pas une priorité.

Le client a acheté un support entreprise chez Postgres Professional. Une alternative à pg_dump était COPY via une liste de tables depuis 1C (50 000 tables dans la base), générée par un script sans accéder au catalogue système.

Erreurs clés des administrateurs

• Absence de sauvegardes et de réplicas.
• Suppression manuelle des journaux WAL.
• Arrêt du postmaster avec SIGKILL au lieu de SIGQUIT.
• Ignorer les recommandations de réservation d'espace disque.
• Confiance dans des 'guides' sans vérifier les sauvegardes.
• Mauvais choix de pg_dump sans tenir compte des dommages au catalogue.

Ce qu'il faut retenir

• Sans sauvegardes (dumps, réplicas), la récupération complète d'un cluster de 2,5 To est impossible.
• ignore_system_indexes permet de contourner les index système corrompus.
• crash_info est utile pour les dumps d'état sans accès console.
• pg_dump est vulnérable aux dommages du catalogue : utilisez --data-only avec des patches ou COPY.
• Tuer le postmaster avec SIGKILL détruit les données lorsque shared_buffers est important.

Leçons pour les DBA

Un cluster 1C nécessite un nettoyage WAL, une surveillance de l'espace disque et une réplication. Des shared_buffers énormes masquent les problèmes jusqu'à ce que la catastrophe frappe. Pour 50 000 tables, générez des scripts COPY depuis les métadonnées 1C.

— Editorial Team