No hay un comando o herramienta de comprobación de coherencia incorporada en PostgreSQL.
La opinión general es que uno no debería ser necesario, ya que la corrupción y la inconsistencia no deberían ser posibles en una pila de hardware / software de calidad. Si surgen problemas, no hay garantía de que algún tipo de verificación de coherencia los encuentre, por lo que solo crearía una falsa sensación de seguridad. No estoy de acuerdo con ese sentimiento, pero es lo que parece salir cuando esto se discute periódicamente en pgsql-hackers.
Como de costumbre, el problema subyacente es que nadie necesita particularmente una herramienta de verificación de consistencia para satisfacer sus necesidades inmediatas, por lo que nadie pasa el tiempo para escribir una para rascarse una picazón y nadie financia el desarrollo de una por contrato comercial o en la empresa. ¿Trabajar como voluntario? :pags
PostgreSQL (hasta 9.3) no admitía sumas de comprobación de nivel de bloque. Entonces, una de las cosas principales que está acostumbrado a verificar no existía y, por lo tanto, no se pudo verificar. No existe una herramienta para escanear todas las relaciones y validar sumas de verificación en PostgreSQL 9.3, pero sería deseable agregarla y puede aparecer en una versión futura. Mientras tanto, todo lo que puede hacer es SELECT *desde cada relación individualmente, pero debido al hecho de que PostgreSQL utiliza la memoria caché del búfer del sistema operativo para las lecturas, no hay garantía que obligue a una lectura del bloque de disco subyacente de todos modos. Se necesitaría una nueva herramienta para hacer esto.
PostgreSQL tiende a evitar el almacenamiento redundante de información cuando sea posible, por lo que a menudo no hay nada que verificar, solo una sola fuente autorizada. Un verificador de consistencia no puede hacer mucho a menos que aparezca la misma información, o se pueda derivar de múltiples lugares diferentes.
También es muy difícil hacer cualquier tipo de verificación útil al mismo tiempo, en una base de datos que todavía está ocupada y activa. La mayoría de las instalaciones no estarán dispuestas a bloquear toda la base de datos, o al menos varias relaciones importantes a la vez, para ejecutar algún tipo de verificación de consistencia. Por lo tanto, el verificador necesitaría poder operar en una base de datos que esté sujeta a modificaciones concurrentes, lo que hace que sea aún más difícil de escribir y capaz de detectar menos problemas de manera confiable.
Todavía hay mucho que una herramienta de validación podría hacer si se escribiera una, especialmente si se le permitiera tomar bloqueos exclusivos de múltiples relaciones:
Compruebe que todos los espacios de tablas existen en el disco.
Verifique que cada pg_classentrada tenga archivos correspondientes relfilenodeen el espacio de tabla correcto.
Inspeccione mapas de visibilidad, mapas de espacio libre, etc., asegurándose de que estén presentes cuando deberían ser, legibles y que parezcan coincidir con la relación con la que están asociados.
Informe sobre nodos de archivos huérfanos en el disco. (Esto es normal debido al DDL transaccional y a la desvinculación diferida, pero un verificador podría forzar la desvinculación ansiosa y bloquear todas las relaciones antes de ejecutar la comprobación).
Lea cada bloque de cada relación y busque problemas obvios. Para las relaciones de montón que serían cosas como:
- un
xminmayor que xmax(después de considerar la envoltura de xid)
- Tuplas creadas por transacciones en el futuro
- cadenas CALIENTES rotas / cadenas ctid rotas
- estructuras de tuplas que no coinciden con los atributos de la tabla
- cualquier dato que no se redondea
_iny _outfunciona sin cambios o arroja un error
NULLcampos de mapa de bits establecidos en NOT NULLatributos de tabla- La re-ejecución de
CHECKrestricciones falla
Vuelva a verificar la clave externa y las restricciones de exclusión después de bloquear todas las tablas involucradas
... y probablemente mucho más que no sé lo suficiente sobre las agallas de Pg para descubrir, como intentos de detectar páginas desgarradas, validación de la estructura de b-tree, comprobación de la cordura de los índices GIN y GiST, comprobación de la cordura pg_controly más, no lo haría saber por dónde empezar.
Si está interesado en tener una herramienta de este tipo, lo mejor que puede hacer es aprender lo suficiente como para llegar a una propuesta concreta sobre cómo debería funcionar, y hacer el tiempo para trabajar en ella, o para financiar a otros para que pasen tiempo en ella. desarrollo.
Personalmente, estaría muy contento de tener algo que pueda verificar un clúster de base de datos detenido utilizando un modo de inicio especial para el postgresbackend, por lo que podría (algo) validar (físico) copias de bases de datos tomadas con pg_basebackup, con pg_start_backup(), rsync y pg_stop_backup, con el nivel del sistema de archivos instantáneas atómicas, etc.
Alternativamente, puede hacer lo que hacen la mayoría de los demás: asegúrese de que su pila de hardware y software sea robusta y esté configurada correctamente, mantenga buenas copias de seguridad y monitoree sus registros. No hay sustituto para la prueba adecuada de toda la pila antes de la puesta en marcha de un servidor, y para las buenas copias de seguridad, tanto físicas (transmisión / PITR) como lógicas (volcados). Realice pruebas plug-pull en una base de datos cargada, repetidamente, antes de poner en funcionamiento para asegurarse de que su subsistema de E / S supuestamente confiable sea realmente. Use múltiples formas de respaldo.