Как восстановить удаленные файлы индексов?

Question

[illusionD]

Есть база данных postgres (файловой структурой), расшифрованная после шифровальщика. Дешифратор удаляет тысячи индексных файлов, т.к. они маленького объёма, а сами базы целые. Интересна именно эта рабочая база, именно файловой структурой, не бэкапы.

Если я запускаю REINDEX, то он говорит мне

ERROR:  could not open file "base/26458/4745576": No such file or directory

Я подсовываю ему пустой 8кб файлик, снова запускаю REINDEX, он хочет следующий. Я автоматизирую это дело, но каждый проход по 20 секунд на 16-ядерном процессоре с 32 процессами и быстром SSD nvme, ещё и пара сотен гигабайт записей на диск за каждый проход. Размер базы 30 ГБ. Если индексов, например 15 тысяч, ему ведь месяц пустые файлики подсовывать. И ещё непонятно, что будет после этого, сработают ли пустые файлики, чтобы он в них записал индексы. Пока что он просто проверяет их наличие, они так и остаются пустыми, просто ругается на следующий несуществующий файлик.

Может есть какой-то более простой способ? Например, как-то получить список имён всех индексных файлов, которые ему требуются, и накопировать их пустышки за минуту вместо запуска REINDEX и выдёргивания очередного имени.
Может вообще другой подход требуется.

Comments

[alexalexes]

Грохнуть объекты-индексы в СУБД и создать заново?

[illusionD]

alexalexes, а как их грохнуть, если кратко? По каким ключевым словам загуглить?) Просто я postgres первый раз копаю, но, в целом, о некоторых вещах догадался. Это база 1С.

[alexalexes]

Надо сделать дамп базы.
В дампе оставить только предложения create index.
Из них сделать список drop index - прогнать его на выполнение.
Потом прогнать список с create index.
Так вы прибьете все индексы и создадите заново.
Это не правка ресурсов индексов, это их полное уничтожение и создание заново.
PS: Для объемных по строкам таблиц лучше создание индекса прогонять по одному - это ресурсоемкая операция.

[illusionD]

alexalexes, а он при pg_dump тоже требует файлики и прекращает работу Но pg_dump до ошибки проходит быстрей, чем reindexdb, и намного менее стрессово для SSD диска, так быстрей дёргать названия файлов при каждой ошибке и подменять пустышками. Но не то чтобы в десятки раз, раза в 3-4.

[mayton2019]

Мда. Случай вообще нетипичный. Не каждый день базу дешифруют да и еще таким жестоким образом
чтоб индексные (просто маленькие файлы) убить.

Если-бы это был Oracle можно было-бы стартовать базу в режиме mount. Подключить контрольный
файл и из него просто достать список всех файлов. Не знаю как Postgres хранит этот список. Скорее
всего где-то есть формула как получить список таких путей.

base/26458/4745576

Он-же где-то хранится. Вот.
Я-бы пошел от описания форматов файлов. Если автор говорит что их 15 тысяч то вручную
создавать их довольно утомительно.

[illusionD]

mayton2019, да, достать список файлов типа base/26458/4745576 было бы идеально, пустышки можно было бы создать за минуту. Но всё равно спасибо за предложение делать дамп, запрос очередного файла для подмены пустышкой так получается гораздо быстрей, чем реиндексацией. Затем операция прекращается и дамп начинается заново, чтобы получить имя следующего файла. Это долго, хоть и автоматизировано, но пока других путей не вижу.

Я испробовал этот способ на старой 2гб базе 10-летней давности, которая тоже имеется здесь, у меня получилось открыть 1С после таких манипуляций. Теперь продолжаю подсовывать пустышки рабочей 30гб базе, это надолго. И это очень сильно насилует SSD, прям терабайтами в сутки, поэтому пока развернул RAM диск для дампа.

Кстати, создание дампа ругается на гораздо меньшее количество файлов, чем реиндексация, это я проверил на старой маленькой базе. Но подмены файлов, на которые ругается дамп, достаточно для запуска 1С. А реиндексацию может и средствами 1С получится сделать потом.

Я думаю, список нумерованных файлов для базы так просто из postgres не выдернуть в данном случае. Хотя, если они в какой-то таблице, я мог бы вывести записи из этой таблицы, консольный psql работает нормально.