Il n'y a pas de commande ou d'outil de vérification de cohérence intégré dans PostgreSQL.
L'opinion générale est que cela ne devrait pas être nécessaire, car la corruption et l'incohérence ne devraient pas être possibles sur une pile matérielle / logicielle de qualité. Si des problèmes surviennent, il n'y a aucune garantie qu'une sorte de vérification de cohérence les trouverait, donc cela ne ferait que créer un faux sentiment de sécurité. Je ne suis pas d'accord avec ce sentiment, mais c'est ce qui semble ressortir lorsque cela est périodiquement discuté sur pgsql-hackers.
Comme d'habitude, le problème sous-jacent est que personne n'a particulièrement besoin d'un outil de vérification de cohérence pour répondre à ses besoins immédiats, donc personne ne passe le temps d'en écrire un pour gratter une démangeaison et personne ne finance le développement d'un sur un contrat commercial ou en interne. Faire du bénévolat? : p
PostgreSQL (jusqu'à 9.3) ne supportait pas les sommes de contrôle au niveau du bloc. Donc, l'une des principales choses que vous avez l'habitude de vérifier n'existait pas et ne pouvait donc pas être vérifiée. Un outil pour analyser toutes les relations et valider les sommes de contrôle n'existe pas dans PostgreSQL 9.3, mais il serait souhaitable de l'ajouter et pourrait apparaître dans une future version. En attendant, tout ce que vous pouvez faire est à SELECT *partir de chaque relation individuellement - mais étant donné que PostgreSQL utilise le cache de tampon du système d'exploitation pour les lectures, il n'y a aucune garantie qui forcera de toute façon la lecture du bloc de disque sous-jacent. Un nouvel outil serait nécessaire pour ce faire.
PostgreSQL a tendance à éviter de stocker des informations de manière redondante dans la mesure du possible, il n'y a donc souvent rien à vérifier, juste une seule source autorisée. Un vérificateur de cohérence ne peut pas faire grand-chose sauf si les mêmes informations apparaissent ou peuvent être dérivées de plusieurs endroits différents.
Il est également très difficile d'effectuer simultanément toutes sortes de vérifications utiles sur une base de données qui est toujours occupée et active. La plupart des installations ne seront pas disposées à verrouiller la base de données entière, ou au moins plusieurs relations majeures à la fois, pour exécuter une sorte de vérification de cohérence. Le vérificateur devrait donc pouvoir fonctionner sur une base de données sujette à des modifications simultanées, ce qui le rend encore plus difficile à écrire et capable de détecter moins de problèmes de manière fiable.
Il y a encore beaucoup de choses qu'un outil de validation pourrait faire si un était écrit, surtout s'il était autorisé à prendre plusieurs verrous exclusifs de relation:
Vérifiez que tous les espaces disque logiques existent sur le disque.
Vérifiez que chaque pg_classentrée possède un ou plusieurs fichiers correspondant à son relfilenodedans le bon espace de table.
Inspectez les cartes de visibilité, les cartes en espace libre, etc., en vous assurant qu'elles sont présentes lorsqu'elles devraient être, lisibles et semblent correspondre à la relation à laquelle elles sont associées.
Signaler les nœuds de fichiers orphelins sur disque. (Celles-ci sont normales en raison de la DDL transactionnelle et de la dissociation paresseuse, mais un vérificateur peut forcer la dissociation désirée et verrouiller toutes les relations avant d'exécuter la vérification).
Lisez chaque bloc de chaque relation et recherchez les problèmes évidents. Pour les relations de tas, ce serait des choses comme:
- un
xminplus grand que xmax(après avoir considéré le bouclage xid)
- Tuples créés par des transactions futures
- chaînes HOT cassées / chaînes ctid cassées
- structures de tuple qui ne correspondent pas aux attributs de la table
- toute donnée qui ne retourne pas
_inet _outfonctionne inchangée ou génère une erreur
NULLchamps bitmap définis sur NOT NULLles attributs de table- La réexécution des
CHECKcontraintes échoue
Revérifiez les contraintes de clé étrangère et d'exclusion après avoir verrouillé toutes les tables concernées
... et probablement beaucoup plus que je ne sais pas assez sur les tripes de Pg pour comprendre, comme les tentatives de détection de pages déchirées, la validation de la structure de l'arborescence b, la vérification de l'intégrité des index GIN et GiST, la vérification de l'intégrité pg_control, et plus je ne le ferais pas savoir par où commencer.
Si vous êtes désireux d'avoir un tel outil, la meilleure chose à faire est d'en apprendre suffisamment pour présenter une proposition concrète sur la façon dont il devrait fonctionner - et prendre le temps de travailler dessus ou de financer d'autres personnes pour passer du temps sur son développement.
Personnellement, je serais vraiment très heureux d'avoir quelque chose qui pourrait vérifier un cluster de base de données arrêté en utilisant un mode de démarrage spécial pour le postgresbackend, afin que je puisse (quelque peu) valider les copies de base de données physiques prises avec pg_basebackup, avec pg_start_backup(), rsync et pg_stop_backup, avec le niveau du système de fichiers instantanés atomiques, etc.
Alternativement, vous pouvez faire ce que font la plupart des autres: assurez-vous que votre pile matérielle et logicielle est robuste et correctement configurée, conservez de bonnes sauvegardes et surveillez vos journaux. Il n'y a pas de substitut pour tester correctement toute la pile avant de mettre en service un serveur - et pour de bonnes sauvegardes, à la fois physiques (streaming / PITR) et logiques (dumps). Effectuez des tests de plug-pull sur une base de données chargée - à plusieurs reprises - avant la mise en ligne pour vous assurer que votre sous-système d'E / S soi-disant fiable l'est vraiment. Utilisez plusieurs formes de sauvegarde.