|
Восстановление TOAST файла (v12.8)
|
|||
---|---|---|---|
#18+
Здравствуйте ! Помогите, пжл, разобраться с проблемой (Postgresql v12.8). Ситуация : в какой-то момент стала появляться ошибка (ERROR: could not open file "base/18327/2840": No such file or directory), если посмотреть, что за файл не находится - toast к одной из системных таблиц Код: plaintext 1. 2. 3. 4. 5. 6.
Можно ли что-то предпринять для исправления ситуации ? Заранее Огромное Спасибо за любого вида информацию ! ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2022, 10:27 |
|
Восстановление TOAST файла (v12.8)
|
|||
---|---|---|---|
#18+
prokhorov Здравствуйте ! Помогите, пжл, разобраться с проблемой (Postgresql v12.8). Ситуация : в какой-то момент стала появляться ошибка (ERROR: could not open file "base/18327/2840": No such file or directory), если посмотреть, что за файл не находится - toast к одной из системных таблиц Код: plaintext 1. 2. 3. 4. 5. 6.
Можно ли что-то предпринять для исправления ситуации ? Заранее Огромное Спасибо за любого вида информацию ! Ну pg_statistic не смертельно действительно. Я бы попробовал бы сначала перезапусть базу с allow_system_table_mods потом сделать truncate pg_statistic; потом analyze; по проблемной базы и перезапуск базы с отключенным allow_system_table_mods ВАЖНО: в нормальной ситуации и обычно - надо просто переключиться на реплику и переналить мастер (мало ли что там ещё там побилось). Или начисто в новом кластере восстановиться из backup. То что я написал выше - пробовать если у вас ни то ни другое недоступно а очень хочется поковыряться. Обязательно полную копию кластера перед этим сделать (файловую на остановленной базе). PS: предполагается что всеми основными инструментами recovery вы владеете. PPS: а как вы вообще этого добились? были какие то сбои перед этим? -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2022, 10:51 |
|
Восстановление TOAST файла (v12.8)
|
|||
---|---|---|---|
#18+
Maxim Boguk, Добились - при падении оборудования ... :( При чём - "пропал" только сам toast файл, vm и fsm для него существуют. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2022, 11:04 |
|
Восстановление TOAST файла (v12.8)
|
|||
---|---|---|---|
#18+
Maxim Boguk Я бы попробовал бы сначала перезапусть базу с allow_system_table_mods потом сделать truncate pg_statistic; хмхм, не думаю что это хорошая идея, enable-cassert сборка некрасиво ругается на сломанные assert'ы select relpages from pg_class where relfilenode = 2840; dd if=/dev/zero bs=8K count=$(relpages) of=$(pgdata/base/...) delete from pg_statistic; analyze; так выглядит поаккуратнее. Но всё равно не надо так ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2022, 11:33 |
|
Восстановление TOAST файла (v12.8)
|
|||
---|---|---|---|
#18+
Не туда написал. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2022, 11:35 |
|
Восстановление TOAST файла (v12.8)
|
|||
---|---|---|---|
#18+
Maxim Boguk, Melkij, Спасибо Огромное за Ответы ! Maxim Boguk, Повторил предложенное решение : 1) Перезапуск кластера с allow_system_table_mods='ON' (исправление postgresql.auto.conf) 2) Очистка таблицы pg_statistic (truncate pg_statistic) 3) Обновление статистики БД (analyze) 4) Перезапуск кластера с allow_system_table_mods='OFF' (исправление postgresql.auto.conf) Код: plaintext 1. 2. 3. 4. 5. 6. 7.
Ошибка вроде пропала, поменялось название TOAST файла и удалены слои (vm,fsm) от "старой" версии. Как ещё убедиться в корректности решения ? Не совсем понял про enable-assert - где это может проявиться в дальнейшем ? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2022, 12:13 |
|
Восстановление TOAST файла (v12.8)
|
|||
---|---|---|---|
#18+
prokhorov Не совсем понял про enable-assert - где это может проявиться в дальнейшем ? А никто не знает. Как и в целом при любых манипуляциях после allow_system_table_mods. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2022, 12:19 |
|
Восстановление TOAST файла (v12.8)
|
|||
---|---|---|---|
#18+
Melkij, Допустим, кластер с дефектной БД - тестовый, включить на нём опцию allow_system_table_mods, исправить проблему и выгрузить БД с помощью pg_dump - полученный дамп загрузить на боевой кластер ? Может быть тут какая-то "побочка" для боевого кластера ? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2022, 15:17 |
|
Восстановление TOAST файла (v12.8)
|
|||
---|---|---|---|
#18+
prokhorov, pg_dump делает логический снимок данных и разворачивается обычным SQL (даже custom и dir форматы). Поэтому повреждения исходного кластера не переносит. Это рекомендуемый путь после повреждений внутренностей базы, снять дамп, переинициализировать кластер с initdb и влить данные. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2022, 15:24 |
|
Восстановление TOAST файла (v12.8)
|
|||
---|---|---|---|
#18+
Огромное Спасибо за Ответы !!! Подитожу, действия проводились на 2х кластерах (условно - TEST и PROD, файл пропал на TEST) : Код: plaintext 1. 2. 3. 4. 5.
++++++++++++++++++ Действия на TEST при включённой опции allow_system_table_mods лучше ограничить только очисткой таблицы. Предполагаемая причина "пропажи" toast файла к таблице pg_statistic - проблемы с СХД, аварийный останов ОС с СУБД. Несколько дней эксплуатации "исправленной" БД на PROD - ошибок вроде не обнаружено. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2022, 10:24 |
|
|
start [/forum/topic.php?fid=53&fpage=3&tid=1993699]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
others: | 10ms |
total: | 147ms |
0 / 0 |