Добрый день, на сервере появилась проблема с bad block ами.

Скопировал pg_data на другой сервер 1.2 тб. Были ошибки с чтением данных на некоторых файлах. Там все поднял, но теперь появилась проблема на новом сервере. ERROR: xlog flush request 133/D8621A58 is not satisfied --- flushed only to 132/E1F09078 CONTEXT: writing block 3009 of relation base/16394/2345011 такого рода. Как можно это решить?

> Там все поднял, но теперь появилась проблема на новом сервере. Очевидно, не подняли (наоборот, испортили). Из backup надо было восстанавливаться на новое "железо". В сторону: вот как людям в голову вообще приходит мысль, что поступить подобным образом (частично что-то вытащить, и сделать вид, что ничего не было) — это нормально? :( > Как можно это решить? Восстановить из backup. И этот кластер "под снос" в любом случае, учтите. Если backup-а нет — Вас ждут попытки вытащить, что получится, с помощью pg_dump, а потом развернуть в новый кластер. И больше никогда так не делать.

backup a нет. Почему копировал pg_data, так советовали и тут. Старый и новый сервер оба работают. Вот и по гуглу. https://www.postgresql-archive.org/recover-as-much-as-possible-xlog-flush-request-not-satisfied-td5715853.html

> backup a нет. Надеюсь, Вы там не DBA. ;) > так советовали и тут. Хмм... кто это Вам тут такое посоветовал? Вы понимаете, что таким образом могло быть потеряно или искажено произвольное количество любых данных? > Вот и по гуглу. Не "вот и", а там Tom Lane советует ровно то, что написал и я. > Что испортил если бекапа то нет ? Данные Вы испортили! Работа на "битой" БД зачастую усугубляет corruption, даже после того, как Вы её перенесли на нормальное "железо".

ДБА не я. Его вообще нет. Я разработчик. Система работала 8 лет. Насколько я понял сделать копию data нужно на всякий случай. Но перевод делать pg_dumpall правильно?

Да, копия нужна (чтобы к ней вернуться опять, если что). После чего работу с production нужно останавливать (для пользователей, в смысле), и пытаться снять pg_dumpall. Дальнейшее зависит от того, получится это или нет.

8 лет без бэкапа... Это диагноз. Вопрос почему столько продержалось

Eсть проблема у них нет места для бекапа на 1,2 тб. Поэтому рсинком все перебрасывал. Связь обрывается каждые пару часов поэтому пгдамп не сработает через ssh. A rsync получилось настроить

Ну теперь есть чем заняться. В Америке два президента сменилось, а они только начнут (может быть) пользоваться бэкапом при стоимости железа до 10к.

Пгпробэкап позволяет бэкапить с обрывами. И вишенка на торте наверное checksum выключен?

Ещё одно "серьёзная фирма возьмёт в долгосрочную аренду дырокол"? Бывает, что тут скажешь... :( Если хотите решить проблему — место придётся найти, и что-то решить со связью.

Alfred
9.2 нет

Неудивительно, потому что 9.2 уже несколько лет как "мёртв". Это примерно как сейчас на Windows 95 работать. ;)

решение есть какое нибудь?

Alfred
9.2 нет

Ой Вэй... 9 лет назад вышла... Здесь нечего спасать...

Остановить postgres на этом "сервере". Скопировать data directory туда (на такую же OS и архитектуру!), где: 1) Есть место и для backup-а, и для dump-ов (т.е. лучше терабайт 5 там иметь, на всякий случай). 2) Установлен PostgreSQL 9.2.x Запустить там скопированный instance. Попробовать снять дамп. Дальше уже зависит от, опять-таки.

pg_dump: Dumping the contents of table "pf_pens_type" failed: PQgetResult() failed. pg_dump: Error message from server: ERROR: could not read block 0 in file "base/16394/40299": Input/output error Это все габелла?

Можно пытаться вытягивать по кусочкам. Но это долгая история, и что-то Вы почти наверняка потеряете (какие-то записи этой таблицы, как минимум).

Есть ли метод вытащить то что есть, чего нет отсечь

Есть. Вы можете попробовать поискать в истории этого чата (тут когда-то разбирали подобное, насколько я помню)? Искать можно по pg_dumpall... Может, это вот тут (а может, было и ещё), но я не смотрел подробно: https://t.me/pgsql/256083 Напишите, если не найдёте или будут вопросы по найденному.