Подозреваемый Postgres повреждение данных

Question

Наше приложение работает на Postgres 7.4.X.Я согласен, что это очень старая версия Postgres, и мы должны были обновить ее.Проблема, с которой мы столкнулись, заключается в том, что

1.Произошел сбой системы из-за аппаратного сбоя.

2.Когда система появилась, мы попытались вставить несколько записей в базу данных.Однако в этот момент мы увидели, что Postgres потребляет много ресурсов ЦП и памяти.

Примерно 42% потребления ЦП.Это было причиной беспокойства.

3.Мы реиндексировали базу данных, и это помогло снизить потребление ресурсов процессора и памяти.

Мой вопрос:

A) Разве база данных Postgres не достаточно устойчива для обработки аппаратных сбоев системы?или это иногда приводит к поврежденному индексу для его таблиц?Я прочитал на сайте Postgres, что сбой оборудования может привести к повреждению индексов.Помимо этого, существует ли какой-либо другой сценарий, который может привести к такому повреждению.

B) Если Postgres сделал улучшения / усовершенствования в отношении того, как он обрабатывает поврежденные индексы, пожалуйста, передайте мне больше информации об идентификаторе ошибкиили какая-то документация по этому поводу?Наше приложение не делает никаких указаний.Я сталкиваюсь с дилеммой, если мы должны серьезно включить это в нашу заявку.

Answer 1

Разве база данных Postgres не достаточно эластична для обработки аппаратного сбоя системы?или это иногда приводит к поврежденному индексу для его таблиц?Я прочитал на сайте Postgres, что сбой оборудования может привести к повреждению индексов.

Какую часть "сбоя оборудования может привести к повреждению индексов" вы не поняли?(улыбается) Я думаю, что люди, которые поддерживают веб-сайт PostgreSQL, примерно знают, о чем говорят.

Аппаратный сбой - и особенно отказ в дисковой подсистеме - может записать мусор на диск.Серьезный сбой может физически повредить поверхность диска.Особенно впечатляющий аппаратный сбой может перераспределить части вашего диска по нескольким городским кварталам.(Взрыв на клиентском сайте; они сказали, что некоторые обломки приземлились в 20 милях. Я научился не слишком полагаться на устойчивость dbms в таком случае.)

Существует множество способов снизить рискаппаратный сбой.Однако большинство из них не имеют ничего общего с PostgreSQL.Резервное оборудование - источники питания, сетевые платы, дисковые системы RAID - кэш с резервным питанием от батареи (или отключение кэша записи), репликация сервера, холодное и горячее восстановление после отказа.Ничто из этого не имеет ничего общего с собственной отказоустойчивостью PostgreSQL.

Я не знаю, в какой степени PostgreSQL диагностирует состояние своих собственных индексов.Если у меня будет время, я посмотрю исходный код PostgreSQL .