F.1. amcheck — модуль с инструментами, проверяющими целостность таблиц и индексов #
Модуль amcheck
предоставляет функции, позволяющие проверять логическую целостность структуры отношений.
Функции проверки B-дерева контролируют различные инварианты в структуре представления определённых отношений. Правильность работы функций методов доступа, стоящих за сканированием индекса и другими важными операциями, зависит от всегда соблюдаемых инвариантов. Например, определённые функции проверяют, помимо остальных вещей, что все страницы B-дерева содержат элементы в «логическом» порядке (например, индекс-B-дерево, построенный по столбцу text
, должен содержать кортежи, упорядоченные в лексическом порядке с учётом правила сортировки). Если этот конкретный инвариант каким-то образом нарушается, следует ожидать, что бинарный поиск на затронутой странице введёт в заблуждение процедуру сканирования индекса, что приведёт к неверным результатам запросов SQL. Если нарушения структуры не обнаруживаются, эти функции отрабатывают без ошибок. На время выполнения этих функций search_path временно меняется на pg_catalog, pg_temp
.
Проверка выполняется теми же процедурами, что используются при сканировании индекса, и это может быть код пользовательского класса операторов. Например, проверка индекса-B-дерева задействует сравнения, выполняемые одной или несколькими опорными функциями B-дерева под номером 1. Подробнее опорные функции класса операторов описываются в Подразделе 38.16.3.
В отличие от функций проверки B-дерева, которые сообщают о повреждениях, выдавая ошибки, функция проверки кучи verify_heapam
проверяет таблицу и пытается вернуть набор строк: по одной строке на каждое обнаруженное повреждение. Тем не менее, если будут повреждены средства, которые использует функция verify_heapam
, она не сможет продолжить работу и выдаст ошибку.
Права на выполнение функций amcheck
можно выдать и не суперпользователю, но перед этим следует тщательно учесть аспекты безопасности и конфиденциальности данных. Хотя эти функции прежде всего выдают информацию о структуре данных и характере найденных повреждений, а не выводят собственно повреждённые данные, если злоумышленник сможет выполнять эти функции, а особенно если ему также удастся вызвать повреждение данных, он сможет узнать что-то о самих данных из полученной информации.
Примечание
Использовать amcheck
версии 1.1.1 не рекомендуется, поскольку в этой версии функция bt_index_parent_check
работает некорректно.
F.1.1. Функции #
-
bt_index_check(index regclass, heapallindexed boolean, checkunique boolean) returns void
bt_index_check
проверяет, соблюдаются ли в целевом индексе-B-дереве различные инварианты. Пример использования:test=# SELECT bt_index_check(index => c.oid, heapallindexed => i.indisunique), c.relname, c.relpages FROM pg_index i JOIN pg_opclass op ON i.indclass[0] = op.oid JOIN pg_am am ON op.opcmethod = am.oid JOIN pg_class c ON i.indexrelid = c.oid JOIN pg_namespace n ON c.relnamespace = n.oid WHERE am.amname = 'btree' AND n.nspname = 'pg_catalog' -- Не проверять временные таблицы (они могут относиться к другим сеансам): AND c.relpersistence != 't' -- Функция может выдать ошибку без этих условий: AND c.relkind = 'i' AND i.indisready AND i.indisvalid ORDER BY c.relpages DESC LIMIT 10; bt_index_check | relname | relpages ----------------+---------------------------------+---------- | pg_depend_reference_index | 43 | pg_depend_depender_index | 40 | pg_proc_proname_args_nsp_index | 31 | pg_description_o_c_o_index | 21 | pg_attribute_relid_attnam_index | 14 | pg_proc_oid_index | 10 | pg_attribute_relid_attnum_index | 9 | pg_amproc_fam_proc_index | 5 | pg_amop_opr_fam_index | 5 | pg_amop_fam_strat_index | 5 (10 rows)
Этот пример демонстрирует сеанс проверки 10 самых больших индексов системных каталогов в базе данных «test». Проверка всех кортежей кучи на предмет наличия соответствующих кортежей индекса запрашивается только для тех из этих индексов, которые являются уникальными. Так как ошибки не было, все проверенные индексы представляются логически целостными. Естественно, этот запрос можно легко изменить, чтобы функция
bt_index_check
вызывалась для всех индексов в базе, которые поддерживают эту проверку.Функция
bt_index_check
запрашивает блокировкуAccessShareLock
для целевого индекса и отношения, которому он принадлежит. Это тот же режим блокировки, что запрашивается для отношений обычными операторамиSELECT
.bt_index_check
не проверяет инварианты, существующие в иерархии потомок/родитель, но проверяет представление всех кортежей кучи в индексе в виде индексных кортежей, когда параметрheapallindexed
равенtrue
. Еслиcheckunique
имеет значениеtrue
,bt_index_check
проверяет, что в каждом индексе с ограничением уникальности нет одновременно видимых дубликатов. Когда в работающей производственной среде требуется регулярная лёгкая проверка на наличие нарушений, использованиеbt_index_check
часто будет подходящим компромиссом между полнотой проверки и минимизацией влияния на производительность и доступность приложения.-
bt_index_parent_check(index regclass, heapallindexed boolean, rootdescend boolean, checkunique boolean) returns void
Функция
bt_index_parent_check
проверяет, соблюдаются ли в целевом объекте, индексе B-дереве, различные инварианты. Кроме того, если аргументheapallindexed
равенtrue
, эта функция проверяет наличие в индексе всех кортежей из кучи, которые должны в него попасть. Если аргументcheckunique
равенtrue
,bt_index_check
проверяет, что в каждом индексе с ограничением уникальности нет одновременно видимых дубликатов. Когда необязательный параметрrootdescend
равенtrue
, при проверке для каждого кортежа на уровне листьев производится ещё один поиск, начиная с корневой страницы. Проверки, которые может производитьbt_index_parent_check
, включают в себя все проверки, выполняемые функциейbt_index_check
. Функциюbt_index_parent_check
можно считать более полноценным вариантомbt_index_check
: в отличие отbt_index_check
,bt_index_parent_check
проверяет ещё и инварианты, существующие в иерархии родитель/потомок, в том числе отсутствие потерянных связей в структуре индекса.bt_index_parent_check
следует общему соглашению и выдаёт ошибку в случае обнаружения логической несогласованности или другой проблемы.Функция
bt_index_parent_check
запрашивает в целевом индексе блокировкуShareLock
(такжеShareLock
запрашивается и в основном отношении). Эти блокировки предотвращают одновременное изменение данных командамиINSERT
,UPDATE
иDELETE
. Эти блокировки также препятствуют одновременной обработке нижележащего отношения командойVACUUM
и другими вспомогательными командами. Заметьте, что эта функция удерживает блокировки только во время выполнения, а не на протяжении всей транзакции.Дополнительные проверки, проводимые функцией
bt_index_parent_check
, более ориентированы на выявление различных патологических случаев. В том числе это может быть неправильно реализованный класс операторов B-дерева, используемый проверяемым индексом, или, гипотетически, неизвестные ошибки в нижележащем коде метода доступа индекса-B-дерева. Заметьте, что функциюbt_index_parent_check
нельзя применять, когда включён режим горячего резерва (то есть на физических репликах в режиме «только чтение»), в отличие отbt_index_check
.
Подсказка
Функции bt_index_check
и bt_index_parent_check
выводят отладочные сообщения о процессе проверки на уровнях важности DEBUG1
и DEBUG2
. Эти сообщения содержат подробные сведения о проверке, которые могут представлять интерес для разработчиков PostgreSQL. Они могут быть полезны и для опытных пользователей в качестве дополнительного контекста в случае обнаружения несогласованности. Чтобы получать сообщения о процессе проверки с подходящим уровнем детализации, выполните до запуска проверяющего запроса в интерактивном psql:
SET client_min_messages = DEBUG1;
-
verify_heapam(relation regclass, on_error_stop boolean, check_toast boolean, skip text, startblock bigint, endblock bigint, blkno OUT bigint, offnum OUT integer, attnum OUT integer, msg OUT text) returns setof record
Проверяет таблицу, последовательность или материализованное представление на наличие структурных повреждений (когда страницы отношения содержат данные в неправильном формате) и логических повреждений (когда структура страниц не повреждена, но и не соответствует остальной части кластера).
В качестве необязательных аргументов принимаются:
on_error_stop
Если true, проверка на наличие повреждений останавливается в конце первого блока, в котором обнаружены какие-либо повреждения.
По умолчанию false.
check_toast
Если true, поля TOAST проверяются по TOAST-таблице целевого отношения.
Эта проверка может быть длительной. Кроме того, если TOAST-таблица или её индекс повреждены, проверка TOAST-полей потенциально может привести к сбою в работе сервера, хотя во многих случаях это просто вызовет ошибку.
По умолчанию false.
skip
Если указано значение, отличное от
none
, проверка на наличие повреждений пропускает блоки, которые помечены как полностью видимые или полностью замороженные, в зависимости от указанного значения. Допустимые варианты:all-visible
,all-frozen
иnone
.По умолчанию
none
.startblock
Если этот параметр задан, проверка на наличие повреждений начинается с указанного блока и пропускает все предыдущие блоки. Если в
startblock
указано значение вне диапазона блоков целевой таблицы, выдаётся ошибка.По умолчанию проверка начинается с первого блока.
endblock
Если этот параметр задан, проверка на наличие повреждений заканчивается на указанном блоке и пропускает все оставшиеся блоки. Если в
endblock
указано значение вне диапазона блоков целевой таблицы, выдаётся ошибка.По умолчанию проверяются все блоки.
Для каждого обнаруженного повреждения
verify_heapam
возвращает строку со следующими столбцами:blkno
Номер блока, содержащего повреждённую страницу.
offnum
Номер смещения повреждённого кортежа.
attnum
Номер атрибута повреждённого столбца в кортеже, если повреждён именно столбец, а не весь кортеж.
msg
Сообщение с описанием выявленной ошибки.
F.1.2. Дополнительная проверка heapallindexed
#
Когда аргумент heapallindexed
функций проверки B-дерева равен true
, для таблицы, связанной с отношением целевого индекса, добавляется дополнительная фаза проверки. Она включает «фиктивную» операцию CREATE INDEX
, которая проверяет присутствие всех гипотетических новых индексных кортежей по временной сводной структуре в памяти (она создаётся при необходимости на первом этапе проверки). Сводная структура «помечает» каждый кортеж, который находится в целевом индексе. На высоком уровне идея проверки heapallindexed
состоит в том, чтобы убедиться, что новый индекс, равнозначный целевому, содержит только те записи, которые можно найти в существующей структуре.
С дополнительным этапом heapallindexed
связаны значительные издержки: проверка обычно будет выполняться в несколько раз дольше. Однако никакие новые блокировки уровня отношения при проверке heapallindexed
не запрашиваются.
Сводная структура ограничивается по объёму значением maintenance_work_mem
. Для выявления несогласованности в представленных в индексе кортежах с вероятностью упущений в пределах 2% требуется приблизительно 2 байта памяти на кортеж. По мере уменьшения объёма памяти в пересчёте на кортеж этот процент медленно растёт. Этот подход значительно ограничивает издержки такой проверки, и при этом лишь немного уменьшается вероятность выявления проблемы, особенно в инсталляциях, где эта проверка включена в процедуру регулярного обслуживания. Даже если единичное отсутствие или повреждение кортежа упущено, есть все шансы выявить его при очередной проверке.
F.1.3. Эффективное использование amcheck
#
Модуль amcheck
может быть полезен для выявления различных типов проблем, которые могут остаться незамеченными при включении контрольных сумм страниц данных. В частности это:
Структурные несоответствия, возникающие при некорректной реализации класса операторов.
В том числе это проблемы, возникающие при изменении правил сравнения в операционной системе. Сравнения данных сортируемого типа, например
text
, должны быть постоянными (как и все сравнения, применяемые при сканировании индекса-B-дерева), что подразумевает неизменность правил сортировки в операционной системе. Проблемы могут возникать при обновлениях правил в операционной системе, хотя такие случаи редки. Чаще проявляются несоответствия порядка сортировки между ведущим и ведомым сервером, например, из-за различий основных версий используемых операционных систем. Возникающие расхождения обычно наблюдаются только на ведомых серверах, так что и выявить их обычно можно только на них.Когда возникает подобная проблема, она может затрагивать не абсолютно все индексы, построенные с порочным правилом сортировки, просто потому что индексированные значения могут иметь тот же абсолютный порядок, независящий от различий поведения. За дополнительными сведениями об использовании в Postgres Pro правил сортировки и локалей операционной системы обратитесь к Разделу 23.1 и Разделу 23.2.
Несоответствия структуры между индексами и проиндексированными отношениями в куче (когда выполняется проверка
heapallindexed
).Во время обычных операций перекрёстная проверка индексов по отношениям в куче не производится. Симптомы повреждения данных в куче могут быть неочевидными.
Повреждения, вызванные гипотетическими неизвестными ошибками в нижележащем коде методов доступа, коде сортировки и управления транзакциями Postgres Pro.
Автоматическая проверка структурной целостности индексов играет важную роль в общем тестировании новых или предлагаемых возможностей Postgres Pro, с которыми может возникнуть логическая несогласованность. Такую же роль играет проверка структуры таблицы и связанной информации о видимости и состоянии транзакций. И поэтому одна из очевидных стратегий тестирования — регулярно вызывать функции
amcheck
при проведении стандартных регрессионных тестов.Ошибки в файловой системе или подсистеме хранения, когда просто не включены контрольные суммы.
Заметьте, что
amcheck
рассматривает страницу в том виде, как она представлена в некотором буфере разделяемой памяти к моменту проверки, если при обращению к нужному блоку он уже находится в разделяемом буфере. Вследствие этого,amcheck
не обязательно видит данные, находящиеся в файловой системе в момент проверки. Заметьте, что когда контрольные суммы включены,amcheck
может выдать ошибку из-за несоответствия контрольных сумм, если в буфер будет считываться испорченный блок.Повреждения, вызванные дефектными чипами ОЗУ или вообще подсистемой памяти.
Postgres Pro не защищает от ошибок памяти; предполагается, что в эксплуатируемом вами сервере установлена память с ECC (Error Correcting Codes, Коды исправления ошибок) или лучшая защита. Однако память ECC обычно защищает только от ошибок в одном бите и не следует считать её абсолютной защитой от сбоев, приводящих к повреждению памяти.
Когда выполняется проверка
heapallindexed
, в целом значительно увеличивается шанс выявления ошибок в отдельных битах, так как она тестирует точное двоичное равенство и сверяет проиндексированные атрибуты с кучей.
Причиной повреждения структуры данных может стать неисправность оборудования или же перезапись или изменение файлов отношения сторонним ПО. Этот вид повреждения также можно обнаружить с помощью контрольных сумм страниц данных.
Даже если страницы отношений имеют правильный формат, их внутренняя структура не повреждена и данные соответствуют контрольной сумме, это не гарантирует отсутствие логических повреждений. Повреждения такого типа невозможно обнаружить с помощью контрольных сумм. Примеры: значения TOAST в основной таблице, для которых нет соответствующей записи в таблице TOAST; кортежи в основной таблице с идентификатором транзакции, который старше, чем самый старый действительный идентификатор транзакции в базе данных или кластере.
В производственных системах выявляются разнообразные причины логических повреждений: ошибки в серверном ПО PostgreSQL, неисправные и непродуманные инструменты резервного копирования и восстановления, ошибки пользователей.
Повреждение отношений особенно опасно в работающей производственной среде, то есть в той среде, где высокий риск совсем нежелателен. Поэтому для диагностики повреждения данных без излишнего риска была разработана функция verify_heapam
. Она не может обеспечить защиту от всех сбоев сервера, так как даже выполнение вызывающего запроса может быть небезопасным на сильно повреждённой системе. Если сами каталоги повреждены, то вероятны проблемы с доступом к таблицам.
Вообще говоря, amcheck
может доказать только наличие повреждений, но не доказать их отсутствие.
F.1.4. Исправление повреждений #
Когда amcheck
сигнализирует о повреждении данных, ложные срабатывания практически исключены. amcheck
считает ошибочными ситуации, которые никогда не должны наблюдаться по определению, поэтому ошибки amcheck
, как правило, требуют тщательного анализа.
Общего метода устранения проблем, которые может выявить amcheck
, не существует. Начать нужно с поиска корня проблемы, приводящей к нарушению инварианта. Полезную роль в диагностике повреждений, которые выявляет amcheck
, может сыграть pageinspect. Одна лишь команда REINDEX
может быть неэффективна, когда потребуется исправить повреждения.