> А как Вы это поняли? Наверное, потому, что при удалении

Question

> А как Вы это поняли? Наверное, потому, что при удалении

индекса и копировании всех данных в новую таблицу (vacuum full) подобных ошибок не возникало.

> И это абсолютно ничего не значит! Вообще, это неплохой способ спрятать corruption.
Верно. Если бы ошибка сегмента была в сегменте самой таблицы, то при чтении сбойной страницы в отсутствии индекса она бы имела место быть.

> Пока битый диск (или, в крайнем случае, другое "железо") спокойно доедает данные? ;(
В данном частном случае - это виртуальный сервер. Было подозрение на ошибки файловой системы, но думаю, что проверка чекдиском закрыла этот вопрос.

В плане восстановления виртуализация офигенная вещь - можно отработать способы восстановления на клоне, не трогая худо-бедно работающий прод.

Спасибо за советы. Ситуации, конечно, разные бывают.

#backend #devops #pgsql #programming #russian

0

18.01.2020

1 ответов

20 просмотров

Yaroslav Schekin · Accepted Answer

> подобных ошибок не возникало. И это тоже ничего не значит (в общем случае). ;) К примеру — был "сбойный" кластер на диске, который либо более не использовался, либо реаллоцировался (или подобная ошибка в виртуалке). Тогда не факт, что в других местах того же нет, а в случае "железа" — что это не "вернётся", но уже в большем масштабе. > при чтении сбойной страницы в отсутствии индекса она бы имела место быть. Да, это скорее всего, так. А у Вас data_checksums включены? > но думаю, что проверка чекдиском закрыла этот вопрос. Тогда да, почти наверняка. Но, в таком случае (если это клон) — не факт, что на PROD нет чего-то "нехорошего". А какая это версия PostgreSQL (полная)? И сама виртуалка настроена на "пробрасывание" fsync "от и до", точно?

172 похожих чатов

> А как Вы это поняли? Наверное, потому, что при удалении

1 ответов

Похожие вопросы