Postgresql ошибка восстановления базы

Хочу поделиться с вами моим первым успешным опытом восстановления полной работоспособности базы данных Postgres. С СУБД Postgres я познакомился пол года назад, до этого опыта администрирования баз данных у меня не было совсем.

Я работаю полу-DevOps инженером в крупной IT-компании. Наша компания занимается разработкой программного обеспечения для высоконагруженных сервисов, я же отвечаю за работоспособность, сопровождение и деплой. Передо мной поставили стандартную задачу: обновить приложение на одном сервере. Приложение написано на Django, во время обновления выполняются миграции (изменение структуры базы данных), и перед этим процессом мы снимаем полный дамп базы данных через стандартную программу pg_dump на всякий случай.

Во время снятия дампа возникла непредвиденная ошибка (версия Postgres – 9.5):

pg_dump: Oumping the contents of table “ws_log_smevlog” failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989
pg_dump: The command was: COPY public.ws_log_smevlog [...]
pg_dunp: [parallel archtver] a worker process dled unexpectedly

Ошибка «invalid page in block» говорит о проблемах на уровне файловой системы, что очень нехорошо. На различных форумах предлагали сделать FULL VACUUM с опцией zero_damaged_pages для решения данной проблемы. Что же, попрробеум…

Подготовка к восстановлению

ВНИМАНИЕ! Обязательно сделайте резервную копию Postgres перед любой попыткой восстановить базу данных. Если у вас виртуальная машина, остановите базу данных и сделайте снепшот. Если нет возможности сделать снепшот, остановите базу и скопируйте содержимое каталога Postgres (включая wal-файлы) в надёжное место. Главное в нашем деле – не сделать хуже. Прочтите это.

Поскольку в целом база у меня работала, я ограничился обычным дампом базы данных, но исключил таблицу с повреждёнными данными (опция -T, —exclude-table=TABLE в pg_dump).

Сервер был физическим, снять снепшот было невозможно. Бекап снят, двигаемся дальше.

Проверка файловой системы

Перед попыткой восстановления базы данных необходимо убедиться, что у нас всё в порядке с самой файловой системой. И в случае ошибок исправить их, поскольку в противном случае можно сделать только хуже.

В моём случае файловая система с базой данных была примонтирована в «/srv» и тип был ext4.

Останавливаем базу данных: systemctl stop postgresql@9.5-main.service и проверяем, что файловая система никем не используется и её можно отмонтировать с помощью команды lsof:
lsof +D /srv

Мне пришлось ещё остановить базу данных redis, так как она тоже исползовала «/srv». Далее я отмонтировал /srv (umount).

Проверка файловой системы была выполнена с помощью утилиты e2fsck с ключиком -f (Force checking even if filesystem is marked clean):

Далее с помощью утилиты dumpe2fs (sudo dumpe2fs /dev/mapper/gu2—sys-srv | grep checked) можно убедиться, что проверка действительно была произведена:

e2fsck говорит, что проблем на уровне файловой системы ext4 не найдено, а это значит, что можно продолжать попытки восстановить базу данных, а точнее вернуться к vacuum full (само собой, необходимо примонтирвоать файловую систему обратно и запустить базу данных).

Если у вас сервер физический, то обязательно проверьте состояние дисков (через smartctl -a /dev/XXX) либо RAID-контроллера, чтобы убедиться, что проблема не на аппаратном уровне. В моём случае RAID оказался «железный», поэтому я попросил местного админа проверить состояние RAID (сервер был в нескольких сотнях километров от меня). Он сказал, что ошибок нет, а это значит, что мы точно можем начать восстановление.

Попытка 1: zero_damaged_pages

Подключаемся к базе через psql аккаунтом, обладающим правами суперпользователя. Нам нужен именно суперпользователь, т.к. опцию zero_damaged_pages может менять только он. В моём случае это postgres:

psql -h 127.0.0.1 -U postgres -s [database_name]

Опция zero_damaged_pages нужна для того, чтобы проигнорировать ошибки чтения (с сайта postgrespro):

При выявлении повреждённого заголовка страницы Postgres Pro обычно сообщает об ошибке и прерывает текущую транзакцию. Если параметр zero_damaged_pages включён, вместо этого система выдаёт предупреждение, обнуляет повреждённую страницу в памяти и продолжает обработку. Это поведение разрушает данные, а именно все строки в повреждённой странице.

Включаем опцию и пробуем делать full vacuum таблицы:

VACUUM FULL VERBOSE

К сожалению, неудача.

Мы столкнулись с аналогичной ошибкой:

INFO: vacuuming "“public.ws_log_smevlog”
WARNING: invalid page in block 4123007 of relation base/16400/21396989; zeroing out page
ERROR: unexpected chunk number 573 (expected 565) for toast value 21648541 in pg_toast_106070

pg_toast – механизм хранения «длинных данных» в Postgres, если они не помещаются в одну страницу (по умолчанию 8кб).

Попытка 2: reindex

Первый совет из гугла не помог. После нескольких минут поиска я нашёл второй совет – сделать reindex повреждённой таблицы. Этот совет я встречал во многих местах, но он не внушал доверия. Сделаем reindex:

reindex table ws_log_smevlog

reindex завершился без проблем.

Однако это не помогло, VACUUM FULL аварийно завершался с аналогичной ошибкой. Поскольку я привык к неудачам, я стал искать советов в интернете дальше и наткнулся на довольно интересную статью.

Попытка 3: SELECT, LIMIT, OFFSET

В статье выше предлагали посмотреть таблицу построчно и удалить проблемные данные. Для начала необходимо было просмотреть все строки:

for ((i=0; i<"Number_of_rows_in_nodes"; i++ )); do psql -U "Username" "Database Name" -c "SELECT * FROM nodes LIMIT 1 offset $i" >/dev/null || echo $i; done

В моём случае таблица содержала 1 628 991 строк! По-хорошему необходимо было позаботиться о партициирвоании данных, но это тема для отдельного обсуждения. Была суббота, я запустил вот эту команду в tmux и пошёл спать:

for ((i=0; i<1628991; i++ )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog LIMIT 1 offset $i" >/dev/null || echo $i; done

К утру я решил проверить, как обстоят дела. К моему удивлению, я обнаружил, что за 20 часов было просканировано только 2% данных! Ждать 50 дней я не хотел. Очередной полный провал.

Но я не стал сдаваться. Мне стало интересно, почему же сканирование шло так долго. Из документации (опять на postgrespro) я узнал:

OFFSET указывает пропустить указанное число строк, прежде чем начать выдавать строки.
Если указано и OFFSET, и LIMIT, сначала система пропускает OFFSET строк, а затем начинает подсчитывать строки для ограничения LIMIT.

Применяя LIMIT, важно использовать также предложение ORDER BY, чтобы строки результата выдавались в определённом порядке. Иначе будут возвращаться непредсказуемые подмножества строк.

Очевидно, что вышенаписанная команда была ошибочной: во-первых, не было order by, результат мог получиться ошибочным. Во-вторых, Postgres сначала должен был просканировать и пропустить OFFSET-строк, и с возрастанием OFFSET производительность снижалась бы ещё сильнее.

Попытка 4: снять дамп в текстовом виде

Далее мне в голову пришла, казалось бы, гениальная идея: снять дамп в текстовом виде и проанализировать последнюю записанную строку.

Но для начала, ознакомимся со структурой таблицы ws_log_smevlog:

В нашем случае у нас есть столбец «id», который содержал уникальный идентификатор (счётчик) строки. План был такой:

1. Начинаем снимать дамп в текстовом виде (в виде sql-команд)
2. В определённый момент времени снятия дампа бы прервалось из-за ошибки, но тектовый файл всё равно сохранился бы на диске
3. Смотрим конец текстового файла, тем самым мы находим идентификатор (id) последней строки, которая снялась успешно

Я начал снимать дамп в текстовом виде:

pg_dump -U my_user -d my_database -F p -t ws_log_smevlog -f ./my_dump.dump

Снятия дампа, как и ожидалось, прервался с той же самой ошибкой:

pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989

Далее через tail я просмотрел конец дампа (tail -5 ./my_dump.dump) обнаружил, что дамп прервался на строке с id 186 525. «Значит, проблема в строке с id 186 526, она битая, её и надо удалить!» – подумал я. Но, сделав запрос в базу данных:
«select * from ws_log_smevlog where id=186529» обнаружилось, что с этой строкой всё нормально… Строки с индексами 186 530 — 186 540 тоже работали без проблем. Очередная «гениальная идея» провалилась. Позже я понял, почему так произошло: при удаленииизменении данных из таблицы они не удаляются физически, а помечаются как «мёртвые кортежи», далее приходит autovacuum и помечает эти строки удалёнными и разрешает использовать эти строки повторно. Для понимания, если данные в таблице меняются и включён autovacuum, то они не хранятся последовательно.

Попытка 5: SELECT, FROM, WHERE id=

Неудачи делают нас сильнее. Не стоит никогда сдаваться, нужно идти до конца и верить в себя и свои возможности. Поэтому я решил попробовать ешё один вариант: просто просмотреть все записи в базе данных по одному. Зная структуру моей таблицы (см. выше), у нас есть поле id, которое является уникальным (первичным ключом). В таблице у нас 1 628 991 строк и id идут по порядку, а это значит, что мы можем просто перербрать их по одному:

for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

Если кто не понимает, команда работает следующим образом: просматривает построчно таблицу и отправляет stdout в /dev/null, но если команда SELECT проваливается, то выводится текст ошибки (stderr отправляется в консоль) и выводится строка, содержащая ошибку (благодаря ||, которая означает, что у select возникли проблемы (код возврата команды не 0)).

Мне повезло, у меня были созданы индексы по полю id:

А это значит, что нахождение строки с нужным id не должен занимать много времени. В теории должно сработать. Что же, запускаем команду в tmux и идём спать.

К утру я обнаружил, что просмотрено около 90 000 записей, что составляет чуть более 5%. Отличный результат, если сравнивать с предыдущим способом (2%)! Но ждать 20 дней не хотелось…

Попытка 6: SELECT, FROM, WHERE id >= and id <

У заказчика под БД был выделен отличный сервер: двухпроцессорный Intel Xeon E5-2697 v2, в нашем расположении было целых 48 потоков! Нагрузка на сервере была средняя, мы без особых проблем могли забрать около 20-ти потоков. Оперативной памяти тоже было достаточно: аж 384 гигабайт!

Поэтому команду нужно было распараллелить:

for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

Тут можно было написать красивый и элегантный скрипт, но я выбрал наиболее быстрый способ распараллеливания: разбить диапазон 0-1628991 вручную на интервалы по 100 000 записей и запустить отдельно 16 команд вида:

for ((i=N; i<M; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

Но это не всё. По идее, подключение к базе данных тоже отнимает какое-то время и системные ресурсы. Подключать 1 628 991 было не очень разумно, согласитесь. Поэтому давайте при одном подключении извлекать 1000 строк вместо одной. В итоге команда преобразилоась в это:

for ((i=N; i<M; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

Открываем 16 окон в сессии tmux и запускаем команды:

1) for ((i=0; i<100000; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
2) for ((i=100000; i<200000; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
…
15) for ((i=1400000; i<1500000; i=$((i+1000)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
16) for ((i=1500000; i<1628991; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

Через день я получил первые результаты! А именно (значения XXX и ZZZ уже не сохранились):

ERROR:  missing chunk number 0 for toast value 37837571 in pg_toast_106070
829000
ERROR:  missing chunk number 0 for toast value XXX in pg_toast_106070
829000
ERROR:  missing chunk number 0 for toast value ZZZ in pg_toast_106070
146000

Это значит, что у нас три строки содержат ошибку. id первой и второй проблемной записи находились между 829 000 и 830 000, id третьей – между 146 000 и 147 000. Далее нам предстояло просто найти точное значение id проблемных записей. Для этого просматриваем наш диапазон с проблемными записями с шагом 1 и идентифицируем id:

for ((i=829000; i<830000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done
829417
ERROR:  unexpected chunk number 2 (expected 0) for toast value 37837843 in pg_toast_106070
829449
for ((i=146000; i<147000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done
829417
ERROR:  unexpected chunk number ZZZ (expected 0) for toast value XXX in pg_toast_106070
146911

Счастливый финал

Мы нашли проблемные строки. Заходим в базу через psql и пробуем их удалить:

my_database=# delete from ws_log_smevlog where id=829417;
DELETE 1
my_database=# delete from ws_log_smevlog where id=829449;
DELETE 1
my_database=# delete from ws_log_smevlog where id=146911;
DELETE 1

К моему удивлению, записи удалились без каких-либо проблем даже без опции zero_damaged_pages.

Затем я подключился к базе, сделал VACUUM FULL (думаю делать было необязательно), и, наконец, успешно снял бекап с помощью pg_dump. Дамп снялся без каких либо ошибок! Проблему удалось решить таким вот тупейшим способом. Радости не было предела, после стольких неудач удалось найти решение!

Благодарности и заключение

Вот такой получился мой первый опыт восстановления реальной базы данных Postgres. Этот опыт я запомню надолго.

Ну и напоследок, хотел бы сказать спасибо компании PostgresPro за переведённую документацию на русский язык и за полностью бесплатные online-курсы, которые очень сильно помогли во время анализа проблемы.

I’m taking an intro to SQL course and I can’t get my very first database loaded. I have a file dvdrental.tar, I create a new database dvdrental > right click > Restore > Select File > Pick «Data» under Restore options, and I get the error below.

I’m on Mac OSX and the pgAmin instance is being loaded in Chrome if that helps. I’ve tried deleting and re-adding the database twice and I still get the same error. I also tried reinstalling pgAdmin and fully reinstalling postgresql including removing the user account. I just tried doing it on a fresh install in a Windows environment and I get the exact same error.

I’ve also completely rebooted the computer several times since then. I also just verified that other tar files and a sql file aren’t working.

Here’s the full error, I have no idea what any of it means, as I’m brand new to SQL and just setting it up:

/Library/PostgreSQL/10/bin/pg_restore --host "localhost" --port "5432" --username "postgres" --no-password --dbname "dvdrental" --section=data --verbose "/Users/chasehippen/Downloads/Postgresql/dvdrental.tar"
pg_restore: connecting to database for restore
pg_restore: implied data-only restore
pg_restore: processing data for table "public.actor"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 2610; 0 16430 TABLE DATA actor postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "actor" does not exist
Command was: COPY actor (actor_id, first_name, last_name, last_update) FROM stdin;
pg_restore: executing SEQUENCE SET actor_actor_id_seq
pg_restore: [archiver (db)] Error from TOC entry 2643; 0 0 SEQUENCE SET actor_actor_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "actor_actor_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('actor_actor_id_seq', 200, true);
^
Command was: SELECT pg_catalog.setval('actor_actor_id_seq', 200, true);
pg_restore: processing data for table "public.address"
pg_restore: [archiver (db)] Error from TOC entry 2618; 0 16471 TABLE DATA address postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "address" does not exist
Command was: COPY address (address_id, address, address2, district, city_id, postal_code, phone, last_update) FROM stdin;
pg_restore: executing SEQUENCE SET address_address_id_seq
pg_restore: [archiver (db)] Error from TOC entry 2644; 0 0 SEQUENCE SET address_address_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "address_address_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('address_address_id_seq', 605, true...
^
Command was: SELECT pg_catalog.setval('address_address_id_seq', 605, true);
pg_restore: processing data for table "public.category"
pg_restore: [archiver (db)] Error from TOC entry 2612; 0 16437 TABLE DATA category postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "category" does not exist
Command was: COPY category (category_id, name, last_update) FROM stdin;
pg_restore: executing SEQUENCE SET category_category_id_seq
pg_restore: [archiver (db)] Error from TOC entry 2645; 0 0 SEQUENCE SET category_category_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "category_category_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('category_category_id_seq', 16, tru...
^
Command was: SELECT pg_catalog.setval('category_category_id_seq', 16, true);
pg_restore: processing data for table "public.city"
pg_restore: [archiver (db)] Error from TOC entry 2620; 0 16478 TABLE DATA city postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "city" does not exist
Command was: COPY city (city_id, city, country_id, last_update) FROM stdin;
pg_restore: executing SEQUENCE SET city_city_id_seq
pg_restore: [archiver (db)] Error from TOC entry 2646; 0 0 SEQUENCE SET city_city_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "city_city_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('city_city_id_seq', 600, true);
^
Command was: SELECT pg_catalog.setval('city_city_id_seq', 600, true);
pg_restore: processing data for table "public.country"
pg_restore: [archiver (db)] Error from TOC entry 2622; 0 16485 TABLE DATA country postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "country" does not exist
Command was: COPY country (country_id, country, last_update) FROM stdin;
pg_restore: executing SEQUENCE SET country_country_id_seq
pg_restore: [archiver (db)] Error from TOC entry 2647; 0 0 SEQUENCE SET country_country_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "country_country_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('country_country_id_seq', 109, true...
^
Command was: SELECT pg_catalog.setval('country_country_id_seq', 109, true);
pg_restore: processing data for table "public.customer"
pg_restore: [archiver (db)] Error from TOC entry 2608; 0 16419 TABLE DATA customer postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "customer" does not exist
Command was: COPY customer (customer_id, store_id, first_name, last_name, email, address_id, activebool, create_date, last_update, active) FROM stdin;
pg_restore: executing SEQUENCE SET customer_customer_id_seq
pg_restore: [archiver (db)] Error from TOC entry 2648; 0 0 SEQUENCE SET customer_customer_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "customer_customer_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('customer_customer_id_seq', 599, tr...
^
Command was: SELECT pg_catalog.setval('customer_customer_id_seq', 599, true);
pg_restore: processing data for table "public.film"
pg_restore: [archiver (db)] Error from TOC entry 2614; 0 16444 TABLE DATA film postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "film" does not exist
Command was: COPY film (film_id, title, description, release_year, language_id, rental_duration, rental_rate, length, replacement_cost, rating, last_update, special_features, fulltext) FROM stdin;
pg_restore: processing data for table "public.film_actor"
pg_restore: [archiver (db)] Error from TOC entry 2615; 0 16456 TABLE DATA film_actor postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "film_actor" does not exist
Command was: COPY film_actor (actor_id, film_id, last_update) FROM stdin;
pg_restore: processing data for table "public.film_category"
pg_restore: [archiver (db)] Error from TOC entry 2616; 0 16460 TABLE DATA film_category postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "film_category" does not exist
Command was: COPY film_category (film_id, category_id, last_update) FROM stdin;
pg_restore: executing SEQUENCE SET film_film_id_seq
pg_restore: [archiver (db)] Error from TOC entry 2649; 0 0 SEQUENCE SET film_film_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "film_film_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('film_film_id_seq', 1000, true);
^
Command was: SELECT pg_catalog.setval('film_film_id_seq', 1000, true);
pg_restore: processing data for table "public.inventory"
pg_restore: [archiver (db)] Error from TOC entry 2624; 0 16502 TABLE DATA inventory postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "inventory" does not exist
Command was: COPY inventory (inventory_id, film_id, store_id, last_update) FROM stdin;
pg_restore: executing SEQUENCE SET inventory_inventory_id_seq
pg_restore: [archiver (db)] Error from TOC entry 2650; 0 0 SEQUENCE SET inventory_inventory_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "inventory_inventory_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('inventory_inventory_id_seq', 4581,...
^
Command was: SELECT pg_catalog.setval('inventory_inventory_id_seq', 4581, true);
pg_restore: processing data for table "public.language"
pg_restore: [archiver (db)] Error from TOC entry 2626; 0 16509 TABLE DATA language postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "language" does not exist
Command was: COPY language (language_id, name, last_update) FROM stdin;
pg_restore: executing SEQUENCE SET language_language_id_seq
pg_restore: [archiver (db)] Error from TOC entry 2651; 0 0 SEQUENCE SET language_language_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "language_language_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('language_language_id_seq', 6, true...
^
Command was: SELECT pg_catalog.setval('language_language_id_seq', 6, true);
pg_restore: processing data for table "public.payment"
pg_restore: [archiver (db)] Error from TOC entry 2628; 0 16521 TABLE DATA payment postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "payment" does not exist
Command was: COPY payment (payment_id, customer_id, staff_id, rental_id, amount, payment_date) FROM stdin;
pg_restore: executing SEQUENCE SET payment_payment_id_seq
pg_restore: [archiver (db)] Error from TOC entry 2652; 0 0 SEQUENCE SET payment_payment_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "payment_payment_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('payment_payment_id_seq', 32098, tr...
^
Command was: SELECT pg_catalog.setval('payment_payment_id_seq', 32098, true);
pg_restore: processing data for table "public.rental"
pg_restore: [archiver (db)] Error from TOC entry 2630; 0 16527 TABLE DATA rental postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "rental" does not exist
Command was: COPY rental (rental_id, rental_date, inventory_id, customer_id, return_date, staff_id, last_update) FROM stdin;
pg_restore: executing SEQUENCE SET rental_rental_id_seq
pg_restore: [archiver (db)] Error from TOC entry 2653; 0 0 SEQUENCE SET rental_rental_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "rental_rental_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('rental_rental_id_seq', 16049, true...
^
Command was: SELECT pg_catalog.setval('rental_rental_id_seq', 16049, true);
pg_restore: processing data for table "public.staff"
pg_restore: [archiver (db)] Error from TOC entry 2632; 0 16539 TABLE DATA staff postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "staff" does not exist
Command was: COPY staff (staff_id, first_name, last_name, address_id, email, store_id, active, username, password, last_update, picture) FROM stdin;
pg_restore: executing SEQUENCE SET staff_staff_id_seq
pg_restore: [archiver (db)] Error from TOC entry 2654; 0 0 SEQUENCE SET staff_staff_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "staff_staff_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('staff_staff_id_seq', 2, true);
^
Command was: SELECT pg_catalog.setval('staff_staff_id_seq', 2, true);
pg_restore: processing data for table "public.store"
pg_restore: [archiver (db)] Error from TOC entry 2634; 0 16550 TABLE DATA store postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "store" does not exist
Command was: COPY store (store_id, manager_staff_id, address_id, last_update) FROM stdin;
pg_restore: executing SEQUENCE SET store_store_id_seq
pg_restore: [archiver (db)] Error from TOC entry 2655; 0 0 SEQUENCE SET store_store_id_seq postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "store_store_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('store_store_id_seq', 2, true);
^
Command was: SELECT pg_catalog.setval('store_store_id_seq', 2, true);
WARNING: errors ignored on restore: 28

I have a Postgres 8.4 database on a linux server that I have dumped using the following command:

pg_dump --format=c --exclude-table=log --file=/path/to/output my_db

I then ftp the created file to my local Windows 7 machine and attempt to restore the file to my local Postgres 8.4 instance using the following command:

pg_restore --create --exit-on-error --verbose c:pathtofile

The restore command generates plenty of output claiming it created my database, connected to it, and then created all the other tables as expected. However, when I view the databases on my local machine through pgAdmin the restored database doesn’t exist at all.

In an attempt to troubleshoot I tried the following command:

pg_restore --create --exit-on-error --verbose --host=blahblah --username=no_one c:pathtofile

When I run this command even though the host and username given are complete nonsense I still get the exact same output from the command without any errors.

Has anyone run into this before or know what could by causing this?

Модератор: Дмитрий Юхтимовский

---

---

---

---

---

---

---

---

---

---

---

Вернуться в Прочее

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

Ошибка формата потока — одна из самых неприятных ошибок в работе 1С и вызывает панический ужас у многих администраторов и пользователей данной учетной системы. Ее появление обычно говорит о серьезных повреждениях базы данных и, чаще всего, наиболее верным решением будет восстановить базу из резервной копии. В случаях, когда это нежелательно или невозможно придется заняться восстановлением базы, но большинство инструкций в сети рассматривают данный вопрос только на примере MS SQL Server, а PostgreSQL если и касаются, то очень вскользь. Поэтому в данной статье мы постараемся исправить данный пробел.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Начнем с того, что именно обозначает эта ошибка. Разработчики немногословны, никаких подробностей сообщение об ошибке не содержит:

Столь же скупа и информация для технической поддержки:

Обычно это вызывает у пользователей и неподготовленных администраторов тихую панику, особенно если под рукой нет актуальной резервной копии. А судорожные попытки восстановления базы, обычно без понимания смысла выполняемых действий приводят как правило к ее полному разрушению.

К возникновению данной ошибки приводит повреждение основной конфигурации информационной базы. Реже — кеша конфигурации информационной базы, в последнем случае устранить ошибку можно путем очистки кеша, для этого можете воспользоваться нашей утилитой 1:Tools (кто хочет поддержать нас — может скачать ее по ссылке с Инфостарта)

1:Tools (Зеркало на Инфостарте)
MD5: 448277422B59EFA426CC51E4F3A52F53

В остальных случаях придется заниматься восстановлением непосредственно базы. В этом месте мы сразу внесем ясность и разделим сущности: информационная база 1С — это хранилище данных на уровне логики 1С:Предприятия которое описывается конфигурацией информационной базы. Т.е. именно здесь содержатся документы, справочники, регистры и т.д. и т.п., а повреждение конфигурации информационной базы делает невозможной работу с ними на этом уровне абстракции. База данных СУБД — это набор таблиц в которых хранятся как данные, так и конфигурация информационной базы 1С.

Повреждение основной конфигурации информационной базы происходит именно на уровне логики 1С:Предприятия, база данных СУБД остается работоспособной и не содержит ошибок с точки зрения СУБД. Если это не так, то мы будем иметь дело с повреждением самой базы данных СУБД, а это уже совсем иная ситуация.

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

Все это достаточно сложно и не всегда приносит требуемый результат, поэтому проще и надежнее заменить конфигурацию информационной базы на заведомо исправную используя инструменты СУБД, в нашем случае PostgreSQL. В зависимости от используемой ОС (Windows или Linux) некоторые аспекты работы с PostgreSQL могут отличаться и это будет оговорено отдельно, в остальных случаях указанные команды применяются вне зависимости от платформы.

Перед тем как начинать работу с PostgreSQL в Linuх последовательно повысим свои права для суперпользователя и затем войдем в систему от имени пользователя postgres:

sudo -s
su postgres

Если утилита sudo не установлена (такой вариант может быть в Debian), то:

su -
su postgres

В первом случае вам потребуется ввести пароль от текущей учетной записи, во втором — от учетной записи суперпользователя (root).

Затем обязательно сделаем копию информационной базы средствами СУБД. Получить список баз данных в кластере СУБД можно командой:

psql -l

В Windows вам потребуется ввести пароль пользователя postgres.

Выяснив имя необходимой базы данных выгрузим ее дамп командой:

#Linux
pg_dump basename > ~/basename.psql
#Windows
pg_dump basename > D:backupbasename.psql

Где basename — имя нужной базы данных. Обратите внимание, что в Windows мы можем явно задать путь выгрузки дампа, а в Linux выгружаем его в домашнюю директорию пользователя postgres, т.е. /var/lib/postgresql.

Для дальнейших действий нам потребуется развернуть на этом же сервере СУБД еще одну базу с точно такой же конфигурацией информационной базы, это может быть как старый бекап поврежденной базы, так и другая база такой же конфигурации, чистая установка или демо база. Главное, чтобы конфигурация новой базы с точностью до релиза совпадала с конфигурацией поврежденной.

После чего откроем интерактивный терминал PostgreSQL в котором будем производить все последующие действия:

psql

В Windows вы можете получить сообщение:

ПРЕДУПРЕЖДЕНИЕ: Кодовая страница консоли (866) отличается от основной
          страницы Windows (1251).
          8-битовые (русские) символы могут отображаться некорректно.

В этом случае выполните:

 ! chcp 1251

Теперь подключимся к исправной базе:

с newbasename

где newbasename — имя исправной базы данных. При этом в строке приглашения появится имя подключенной базы.

Из нее мы выгрузим таблицу config в которой находится основная конфигурация информационной базы.

#Linux
COPY config TO '/var/lib/postgresql/config_OK.txt';#Windows
COPY config TO 'D:/backup/config_OK.txt';

Обратите внимание, при указании пути для операционной системы Windows вы также должны использовать прямой, а не обратный слеш. Также служба СУБД должна иметь права на запись в целевую аудиторию, проще всего это сделать выдав полные разрешения для пользователя Все.

Переподключимся к поврежденной базе:

с basename

На всякий случай, также сохраним содержимое таблицы config:

#Linux
COPY config TO '/var/lib/postgresql/config_ERR.txt';#Windows
COPY config TO 'D:/backup/config_ERR.txt';

После чего очистим сбойную таблицу:

DELETE FROM config;

И загрузим в нее данные из исправной информационной базы:

#Linux
COPY config FROM '/var/lib/postgresql/config_OK.txt';#Windows
COPY config FROM 'D:/backup/config_OK.txt';

Для выхода из терминала PostgreSQL введите:

q

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

В некоторых случаях оказывается повреждена не основная конфигурация информационной базы, а конфигурация, открытая на редактирование в Конфигураторе. Внешне это проявляется как невозможность загрузить информационную базу в этом режиме. Для исправления этой ошибки достаточно очистить таблицу configsave:

DELETE FROM configsave;

Как видим, устранение ошибки формата потока средствами СУБД PostgreSQL достаточно несложно, однако требует некоторых навыков работы с данной СУБД. Но если вы будете внимательно и вдумчиво следовать нашей инструкции, то проблем у вас возникнуть не должно.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

  

Sergio-ps

17.09.12 — 19:09

  

Sergio-ps

1 — 17.09.12 — 19:12

  

глазковыколупыватель

2 — 17.09.12 — 19:37

Base сначала очистить надо. Или удалить, а потом — опять создать.

  

Ben_art

3 — 17.09.12 — 19:39

схему дропни или только таблицы

  

Sergio-ps

4 — 17.09.12 — 20:32

Я пустую базу создаю и в нее пытаюсь восстанавливать, наверно не имеет значения что у нее имя другое?

  

ansh15

5 — 17.09.12 — 21:51

  

Sergio-ps

6 — 17.09.12 — 22:09

  

ansh15

7 — 17.09.12 — 22:54

А базу чем создаете? Из консоли администрирования 1С? Или в PgAdmin?

  

Sergio-ps

8 — 17.09.12 — 23:26

уже и тем и другим способом пробовал. Все равно не восстанавливает. причем пробовал уже и другой архив брать, тоже самое. может не правильная команда создания копии?

  

ansh15

9 — 18.09.12 — 10:17

  

Sergio-ps

10 — 18.09.12 — 11:54

  

Sergio-ps

11 — 18.09.12 — 12:29

  

Sergio-ps

12 — 18.09.12 — 12:36

  

ansh15

13 — 18.09.12 — 12:36

  

Sergio-ps

14 — 18.09.12 — 13:55

  

Sergio-ps

15 — 18.09.12 — 14:06

если только попробовать загрузить сначала в базу дтшник старый, а потом попробовать через постгрес восстановить только данные?

  

BigHarry

16 — 18.09.12 — 15:20

«COPY failed: ERROR:  out of memory» — проходили, вылечили только загрузкой дампа в постгри, установленный на линуксе, на виндовый постгря дамп упорно не хотел заливаться, вылезала «out of memory»,  никакие манипуляции с конфигом не помогали.

  

BigHarry

17 — 18.09.12 — 15:22

А корень зла — бинарники, хранимые в БД, большие фотографии или pdf-ки…

  

Sergio-ps

18 — 18.09.12 — 15:56

Бухгалтерия предприятия. вроде нет файлов. если только документы.

  

Sergio-ps

19 — 18.09.12 — 15:58

а на виртуалке если поднять постгри, думаете поможет?

  

Sergio-ps

20 — 18.09.12 — 16:21

  

Sergio-ps

21 — 18.09.12 — 16:21

и соответственно новых данных не появляется

  

BigHarry

22 — 18.09.12 — 16:30

  

alxbzm

23 — 18.09.12 — 16:46

Я бы посоветовал взять 9-й постгри и попробовать на нем (в том числе и утилиты pg_dump / pg_restore соответствующих версий)… Я тут неоднократно писал про чудеса 8.4.x. У меня сейчас крутится 9.1.2 от 1С — вроде полет нормальный — и с бэкапом, и с восстановлением.

  

Sergio-ps

24 — 18.09.12 — 17:41

поставил 9,1,2 постгри, пытаюсь туда восстановить. посмотрим

  

Sergio-ps

25 — 18.09.12 — 18:41

  

BigHarry

26 — 18.09.12 — 19:33

Сильно большой у вас дамп?

  

глазковыколупыватель

27 — 18.09.12 — 20:15

+ (26) Давай дамп, выкладывай куда-нить.

  

alxbzm

28 — 18.09.12 — 22:27

  

ansh15

29 — 18.09.12 — 23:05

  

Sergio-ps

30 — 19.09.12 — 01:16

  

Sergio-ps

31 — 19.09.12 — 01:18

дамп размером 600 метров, размер азы в папке постгри 7 гигов.

  

zzhiraf

32 — 19.09.12 — 09:55

(29) А можно ссылочку? И еще вопрос как перенести данные с MS SQL?

  

ansh15

33 — 19.09.12 — 10:38

  

ansh15

34 — 19.09.12 — 10:49

  

ansh15

35 — 19.09.12 — 10:51

  

ansh15

36 — 19.09.12 — 11:03

  

zzhiraf

37 — 19.09.12 — 11:55

(33) Спасибо. Нет доступа(

  

Sergio-ps

38 — 19.09.12 — 12:47

  

Sergio-ps

39 — 19.09.12 — 13:03

  

Sergio-ps

40 — 19.09.12 — 13:06

  

zzhiraf

41 — 19.09.12 — 13:14

(40) Спасибо!

  

ansh15

42 — 19.09.12 — 13:45

  

zzhiraf

43 — 19.09.12 — 14:09

(42) а постгрес еще надо настраивать? есть ли готовые файлы с оптимальными настройками?)

  

ansh15

44 — 19.09.12 — 14:29

  

zzhiraf

45 — 19.09.12 — 14:37

(44) Нашел сайт Гилева, почитаю, спасибо.

  

ansh15

46 — 19.09.12 — 14:51

  

zzhiraf

47 — 19.09.12 — 15:43

(46) ага, спасибо!

  

Sergio-ps

48 — 19.09.12 — 16:25

(48) Виртуалку поставь