В PostgreSQL нет встроенной команды или инструмента проверки согласованности.
Общее мнение состоит в том, что в этом не должно быть необходимости, так как повреждение и несогласованность не должны быть возможны для качественного аппаратного / программного стека. Если проблемы все же возникают, нет никакой гарантии, что какая-либо проверка целостности найдет их, так что это просто создаст ложное чувство безопасности. Я не согласен с этим мнением, но это то, что, кажется, выходит, когда это периодически обсуждается на pgsql-хакерах.
Как обычно, основная проблема заключается в том, что никому особенно не нужен инструмент проверки непротиворечивости, чтобы удовлетворить их насущные потребности, поэтому никто не тратит время на то, чтобы написать один, чтобы избавиться от зуда, и никто не финансирует его разработку по коммерческому или внутреннему договору. Работая на добровольных началах? :п
PostgreSQL (до 9.3) не поддерживал контрольные суммы на уровне блоков. Таким образом, одной из основных вещей, которую вы привыкли проверять, не существует и, следовательно, она не может быть проверена. Средство для сканирования всех отношений и проверки контрольных сумм не существует в PostgreSQL 9.3, но было бы желательно добавить и может появиться в будущей версии. В то же время все, что вы можете сделать, это SELECT *от каждого отношения в отдельности - но из-за того, что PostgreSQL использует буферный кеш операционной системы для операций чтения, нет гарантии, которая в любом случае фактически приведет к чтению базового блока диска. Для этого потребуется новый инструмент.
PostgreSQL старается избегать избыточного хранения информации, где это возможно, поэтому часто не с чем проверять, а только с одним авторским источником. Проверка согласованности не может многое сделать, если одна и та же информация не появляется или может быть получена из нескольких разных мест.
Также очень сложно одновременно выполнять полезные проверки в базе данных, которая все еще занята и активна. Большинство установок не собираются блокировать всю базу данных или, по крайней мере, несколько основных отношений одновременно, чтобы выполнить какую-либо проверку согласованности. Таким образом, контролер должен иметь возможность работать с базой данных, которая подвергается одновременным изменениям, что усложняет написание и позволяет надежно обнаруживать меньшее количество проблем.
Утилита-валидатор еще может многое сделать, если она будет написана, особенно если ей разрешено брать несколько монопольных блокировок:
Убедитесь, что все табличные пространства существуют на диске.
Убедитесь, что у каждой pg_classзаписи есть файлы, соответствующие ее relfilenodeв правильном табличном пространстве.
Проверяйте карты видимости, карты свободного пространства и т. Д., Чтобы убедиться, что они присутствуют, когда они должны быть доступны для чтения и выглядят так, чтобы соответствовать отношению, с которым они связаны.
Сообщить о бесхозных файловых узлах на диске. (Это нормально из-за транзакционного DDL и отложенного связывания, но средство проверки может принудительно разорвать соединение и заблокировать все отношения перед выполнением проверки).
Прочитайте каждый блок каждого отношения и найдите очевидные проблемы. Для кучи отношений, которые будут такими вещами, как:
xminбольше xmax(после рассмотрения Xid укручения)- Кортежи, созданные транзакциями в будущем
- сломанные цепочки HOT / сломанные цепочки Ctid
- структуры кортежей, которые не соответствуют атрибутам таблицы
- любой элемент данных, который не выполняет круговую передачу
_inи не _outизменяет свои функции или выдает ошибку
NULLрастровые поля, установленные в NOT NULLатрибутах таблицы- Повторное выполнение
CHECKограничений не удается
Перепроверьте ограничения внешнего ключа и исключения после блокировки всех задействованных таблиц.
... и, возможно, многое другое, что я не знаю достаточно о внутренностях Pg, чтобы понять, таких как попытки обнаружить порванные страницы, проверка структуры b-дерева, проверка работоспособности индексов GIN и GiST, проверка работоспособности pg_controlи многое другое, чего я бы не стал знать, с чего начать.
Если вы заинтересованы в таком инструменте, лучше всего научиться достаточно выдвигать конкретное предложение о том, как он должен работать, и уделять время работе над ним или финансировать других, чтобы тратить время на его использование. развитие.
Лично я был бы очень счастлив иметь что-то, что могло бы проверить остановленный кластер базы данных, используя специальный режим запуска для postgresбэкэнда, так что я мог (в некоторой степени) проверять физические копии базы данных, сделанные с pg_basebackup, с помощью pg_start_backup()rsync и pg_stop_backup, с уровнем файловой системы атомные снимки и т. д.
С другой стороны, вы можете делать то, что делает большинство других: убедитесь, что ваш аппаратный и программный стек надежен и правильно настроен, храните хорошие резервные копии и следите за своими журналами. Нельзя заменить надлежащее тестирование всего стека перед вводом в эксплуатацию сервера - и хорошим резервным копированием, как физическим (потоковое / PITR), так и логическим (дампы). Проводите тестирование по принципу plug-pull в загруженной базе данных - несколько раз - прежде чем начать работу, чтобы убедиться, что ваша предположительно надежная подсистема ввода / вывода действительно работает. Используйте несколько форм резервного копирования.