postgresql неуспешное завершение код выхода 1
Восстановление базы Postgre
Добрый день Уважаемые форумчане!
Столкнулась со следующей проблемой, через pgAdmin III делала архивы баз, сейчас для теста решила одну из них восстановить, но в процессе восстановления вылетает куча ошибок
pg_restore: setting owner and privileges for INDEX _task13_byprocpoint_rrr
pg_restore: setting owner and privileges for INDEX _task13_byprocpointexec_lrrr
pg_restore: setting owner and privileges for INDEX _task13_bytaskdate_tr
pg_restore: setting owner and privileges for INDEX _task13_bytasknum_sr
pg_restore: setting owner and privileges for INDEX _taskch4848_bydatakey_rr
pg_restore: setting owner and privileges for INDEX _taskch4848_bynodemsg_rnr
pg_restore: setting owner and privileges for INDEX _usersworkh_byid_b
pg_restore: setting owner and privileges for INDEX _usersworkh_byuserdate_bt
pg_restore: setting owner and privileges for INDEX _usersworkh_byuserurlhash_bn
pg_restore: setting owner and privileges for INDEX bydescr
pg_restore: setting owner and privileges for INDEX byeauth
pg_restore: setting owner and privileges for INDEX byname
pg_restore: setting owner and privileges for INDEX byosname
pg_restore: setting owner and privileges for INDEX byrolesid
pg_restore: setting owner and privileges for INDEX byshow
WARNING: errors ignored on restore: 5535
Процесс вернул код выхода 1.
Пробовала создавать чистые базы и в них импортировать, те же ошибки( Поделитесь опытом как правильно восстанавливать, у Гилева читал статьи, не помогло)
Postgresql неуспешное завершение код выхода 1
Опытный пользователь
Зарегистрирован: 08.11.2012 12:52:39
Сообщений: 2112
От: VR
Оффлайн
. pg_restore: восстановление большого объекта с OID 2309595
pg_restore: восстановление большого объекта с OID 2309596
pg_restore: восстановление большого объекта с OID 2309596
pg_restore: восстановление большого объекта с OID 2309597
pg_restore: восстановление большого объекта с OID 2309597
pg_restore: восстановление большого объекта с OID 2309598
pg_restore: восстановление большого объекта с OID 2309598
pg_restore: восстановление большого объекта с OID 2309599
pg_restore: восстановление большого объекта с OID 2309599
pg_restore: восстановление большого объекта с OID 2309600
pg_restore: восстановление большого объекта с OID 2309600
pg_restore: восстановление большого объекта с OID 2309601
pg_restore: восстановление большого объекта с OID 2309601
pg_restore: восстановление большого объекта с OID 2309602
pg_restore: восстановление большого объекта с OID 2309602
pg_restore: восстановление большого объекта с OID 2309603
pg_restore: восстановление большого объекта с OID 2309603
pg_restore: восстановление большого объекта с OID 2309604
pg_restore: восстановление большого объекта с OID 2309604
pg_restore: [архиватор] не удалось записать большой объект (результат: 4294967295, ожидалось: 16384)
Процесс вернул код выхода 1.
Опытный пользователь
Пользователь
Зарегистрирован: 01.02.2013 14:11:24
Сообщений: 781
Оффлайн
VROSU wrote: При восстановлении БД на постгри:
Процесс вернул код выхода 1.
Пользователь
Зарегистрирован: 01.02.2013 14:11:24
Сообщений: 781
Оффлайн
pg_restore: creating ACL «userdata.TFU_ParusBusinessInventoryObjectNfaInInventoryStatement()»
pg_restore: creating ACL «userdata.TFU_ParusBusinessObjectStateHistory()»
pg_restore: creating ACL «userdata.TFU_ParusBusinessSalaryCalculationHisGrParam()»
pg_restore: creating ACL «userdata.TFU_ParusBusinessSalaryCalculationHisParam()»
pg_restore: creating ACL «userdata.TFU_ParusBusinessSalaryCalculationOsnParam()»
pg_restore: creating ACL «userdata.TFU_ParusBusinessSalaryCalculationRowsDepositorsTransactions()»
pg_restore: creating ACL «userdata.TFU_ParusBusinessSalaryCalculationRowsPaymentTransactions()»
pg_restore: creating ACL «userdata.TFU_ParusBusinessSalaryCalculationRowsTransfersTransactions()»
pg_restore: creating ACL «userdata.TFU_ParusBusinessSalaryGenericBaseAnalytics()»
pg_restore: creating ACL «userdata.TFU_ParusBusinessSalaryGenericExpensesCategorySources()»
pg_restore: creating ACL «userdata.TFU_ParusBusinessSalaryGenericSnuParam()»
pg_restore: creating ACL «userdata.TFU_ParusBusinessStrictReportingFormsAccountingCardOperation()»
pg_restore: creating ACL «userdata.TFU_ParusNetServerAttachFilesDescription()»
pg_restore: creating ACL «userdata.TFU_ParusNetServerObjectLink()»
pg_restore: creating ACL «userdata.TFU_ParusYugBusinessDataAnalysisLookupParameter()»
pg_restore: creating ACL «userdata.TFU_ParusYugBusinessDataAnalysisMultiLookupValue()»
pg_restore: creating ACL «userdata.TFU_ParusYugBusinessGenericPersonnelLPFFuncParam()»
pg_restore: creating ACL «userdata.TFU_ParusYugBusinessLoggingLogObject()»
pg_restore: creating ACL «userdata.TFU_ParusYugBusinessMedicinePersonnelRecordsCorrespondent()»
pg_restore: creating ACL «userdata.TFU_ParusYugBusinessPersonnelSkillCategory()»
pg_restore: creating ACL «userdata.TFU_TBL_9c4749d3f444fab1be9322b2954ab94eCapitalInvestmentsCard()»
pg_restore: creating ACL «userdata.TFU_b28b80c4f96a9f6b6e2368925e661875()»
pg_restore: creating ACL «userdata.TFU_c0e57c99becc656cc71c5ad6a47a8e1e()»
pg_restore: creating ACL «userdata.TFU_e4ad64ad4e11b5ef8d0b450728c768c6()»
pg_restore: creating ACL «userdata.TFU_e637310eb39964cb58523da3d41df09e()»
pg_restore: creating ACL «userdata.objectUse_DELFUNC()»
WARNING: errors ignored on restore: 1
Пользователь
Зарегистрирован: 06.11.2012 10:30:16
Сообщений: 513
От: Алексей Шибанов
Оффлайн
ANDERS wrote: Восстанавливаю базу
.
WARNING: errors ignored on restore: 1
В чем причина, подскажите?
Опытный пользователь
Зарегистрирован: 30.08.2012 16:39:07
Сообщений: 1128
Оффлайн
ANDERS wrote: Восстанавливаю базу
WARNING: errors ignored on restore: 1
В чем причина, подскажите?
Это сообщение было изменено 1 раз. Последнее изменение было в 21.10.2019 11:20:42
Создание бэкапа базы PostgreSQL для Windows
В PostgreSQL есть утилита, которая создает дамп базы данных и называется она pg_dump. Для того чтобы автоматизировать процесс создания бэкапов баз PostgreSQL нужно будет создать bat-файл, который будет вызывать утилиту pg_dump и вызывать его с помощью планировщика заданий. Результатом выполнения такого сценария будет ежедневное копирование базы данных PostgreSQL, ведение журнала с информацией о датах и результатах выполнения, сохранение подробных сведений о ходе выполнения каждой резервной копии в отдельный текстовый файл и в случае неудачи отображение диалогового окна с сообщением. Содержимое bat-файла следующее:
Справочную информацию о командах, испульзуемых в этом файле можно получить из командной строки набрав следующую команду: «[Имя команды] /?»
Многие использованные здесь команды достаточно распространены и известны, поэтому хочется акцентировать внимание на нескольких менее известных.
Строки 15, 16 выполняют переход в папку в которой находится файл «backup.bat». «%0» возвращает имя bat-файла; «%
dp0″ возвращают соответственно диск и путь к bat-файлу. Подробные сведения о работе с параметрами файла можно посмотреть по этой ссылке.
В строке 19 формируется строковое представление даты и времени в нужном формате. При формировании происходит обращение к переменным окружения DATE и TIME, которые хранят текстовое представление даты и времени соответственно. После имени переменной указывается строка вида «:
В строке 27 вызывается утилита резервного копирования pg_dump.exe. Вызов выполняется с применением команды CALL, это позволяет дождаться завершения утилиты и проанализировать результат выполнения. Вызов утилиты завершается строкой «2>%LOGPATH%». Эта строка означает что поток ошибок STDERR, номер которого 2, приложения pg_dump.exe перенаправляется в файл, имя которого сохранено в переменной окружения LOGPATH. Так как приложение pg_dump.exe выводит все сообщения в стандартный поток ошибок, то в файле LOGPATH будет сохранен подробный отчет о выполнении резервного копирования.
Проверяем как работает bat-файл. Если дампы базы создаются, то можно приступать к созданию задачи для планировщика заданий Windows.
Создаем задание, которое будет запускать bat-файл каждый день в ночное время.
Ежедневные бэкапы со временям породят проблему свободного пространства на жестком диске. Можно чистить ручками, но лучше уж автоматизацию сделать полной. Решается этот вопрос также созданием bat-файла и задачи в планировщике заданий Windows.
Содержимое bat-файла такое:
Здесь указана команда при выполнении которой будут удаляться файлы старше 5 дней.
В планировщике заданий можно создать задачу на исполнения этого bat-файла раз в неделю.
Мой первый опыт восстановления базы данных Postgres после сбоя (invalid page in block 4123007 of relatton base/16490)
Хочу поделиться с вами моим первым успешным опытом восстановления полной работоспособности базы данных Postgres. С СУБД Postgres я познакомился пол года назад, до этого опыта администрирования баз данных у меня не было совсем.
Я работаю полу-DevOps инженером в крупной IT-компании. Наша компания занимается разработкой программного обеспечения для высоконагруженных сервисов, я же отвечаю за работоспособность, сопровождение и деплой. Передо мной поставили стандартную задачу: обновить приложение на одном сервере. Приложение написано на Django, во время обновления выполняются миграции (изменение структуры базы данных), и перед этим процессом мы снимаем полный дамп базы данных через стандартную программу pg_dump на всякий случай.
Во время снятия дампа возникла непредвиденная ошибка (версия Postgres – 9.5):
Ошибка «invalid page in block» говорит о проблемах на уровне файловой системы, что очень нехорошо. На различных форумах предлагали сделать FULL VACUUM с опцией zero_damaged_pages для решения данной проблемы. Что же, попрробеум…
Подготовка к восстановлению
ВНИМАНИЕ! Обязательно сделайте резервную копию Postgres перед любой попыткой восстановить базу данных. Если у вас виртуальная машина, остановите базу данных и сделайте снепшот. Если нет возможности сделать снепшот, остановите базу и скопируйте содержимое каталога Postgres (включая wal-файлы) в надёжное место. Главное в нашем деле – не сделать хуже. Прочтите это.
Сервер был физическим, снять снепшот было невозможно. Бекап снят, двигаемся дальше.
Проверка файловой системы
Перед попыткой восстановления базы данных необходимо убедиться, что у нас всё в порядке с самой файловой системой. И в случае ошибок исправить их, поскольку в противном случае можно сделать только хуже.
В моём случае файловая система с базой данных была примонтирована в «/srv» и тип был ext4.
Останавливаем базу данных: systemctl stop postgresql@9.5-main.service и проверяем, что файловая система никем не используется и её можно отмонтировать с помощью команды lsof:
lsof +D /srv
Мне пришлось ещё остановить базу данных redis, так как она тоже исползовала «/srv». Далее я отмонтировал /srv (umount).
Далее с помощью утилиты dumpe2fs (sudo dumpe2fs /dev/mapper/gu2—sys-srv | grep checked) можно убедиться, что проверка действительно была произведена:
e2fsck говорит, что проблем на уровне файловой системы ext4 не найдено, а это значит, что можно продолжать попытки восстановить базу данных, а точнее вернуться к vacuum full (само собой, необходимо примонтирвоать файловую систему обратно и запустить базу данных).
Попытка 1: zero_damaged_pages
Подключаемся к базе через psql аккаунтом, обладающим правами суперпользователя. Нам нужен именно суперпользователь, т.к. опцию zero_damaged_pages может менять только он. В моём случае это postgres:
Опция zero_damaged_pages нужна для того, чтобы проигнорировать ошибки чтения (с сайта postgrespro):
При выявлении повреждённого заголовка страницы Postgres Pro обычно сообщает об ошибке и прерывает текущую транзакцию. Если параметр zero_damaged_pages включён, вместо этого система выдаёт предупреждение, обнуляет повреждённую страницу в памяти и продолжает обработку. Это поведение разрушает данные, а именно все строки в повреждённой странице.
Включаем опцию и пробуем делать full vacuum таблицы:
К сожалению, неудача.
Мы столкнулись с аналогичной ошибкой:
pg_toast – механизм хранения «длинных данных» в Postgres, если они не помещаются в одну страницу (по умолчанию 8кб).
Попытка 2: reindex
Первый совет из гугла не помог. После нескольких минут поиска я нашёл второй совет – сделать reindex повреждённой таблицы. Этот совет я встречал во многих местах, но он не внушал доверия. Сделаем reindex:
reindex завершился без проблем.
Однако это не помогло, VACUUM FULL аварийно завершался с аналогичной ошибкой. Поскольку я привык к неудачам, я стал искать советов в интернете дальше и наткнулся на довольно интересную статью.
Попытка 3: SELECT, LIMIT, OFFSET
В статье выше предлагали посмотреть таблицу построчно и удалить проблемные данные. Для начала необходимо было просмотреть все строки:
В моём случае таблица содержала 1 628 991 строк! По-хорошему необходимо было позаботиться о партициирвоании данных, но это тема для отдельного обсуждения. Была суббота, я запустил вот эту команду в tmux и пошёл спать:
К утру я решил проверить, как обстоят дела. К моему удивлению, я обнаружил, что за 20 часов было просканировано только 2% данных! Ждать 50 дней я не хотел. Очередной полный провал.
Но я не стал сдаваться. Мне стало интересно, почему же сканирование шло так долго. Из документации (опять на postgrespro) я узнал:
OFFSET указывает пропустить указанное число строк, прежде чем начать выдавать строки.
Если указано и OFFSET, и LIMIT, сначала система пропускает OFFSET строк, а затем начинает подсчитывать строки для ограничения LIMIT.
Применяя LIMIT, важно использовать также предложение ORDER BY, чтобы строки результата выдавались в определённом порядке. Иначе будут возвращаться непредсказуемые подмножества строк.
Очевидно, что вышенаписанная команда была ошибочной: во-первых, не было order by, результат мог получиться ошибочным. Во-вторых, Postgres сначала должен был просканировать и пропустить OFFSET-строк, и с возрастанием OFFSET производительность снижалась бы ещё сильнее.
Попытка 4: снять дамп в текстовом виде
Далее мне в голову пришла, казалось бы, гениальная идея: снять дамп в текстовом виде и проанализировать последнюю записанную строку.
Но для начала, ознакомимся со структурой таблицы ws_log_smevlog:
В нашем случае у нас есть столбец «id», который содержал уникальный идентификатор (счётчик) строки. План был такой:
Снятия дампа, как и ожидалось, прервался с той же самой ошибкой:
Попытка 5: SELECT, FROM, WHERE > Неудачи делают нас сильнее. Не стоит никогда сдаваться, нужно идти до конца и верить в себя и свои возможности. Поэтому я решил попробовать ешё один вариант: просто просмотреть все записи в базе данных по одному. Зная структуру моей таблицы (см. выше), у нас есть поле id, которое является уникальным (первичным ключом). В таблице у нас 1 628 991 строк и id идут по порядку, а это значит, что мы можем просто перербрать их по одному:
Если кто не понимает, команда работает следующим образом: просматривает построчно таблицу и отправляет stdout в /dev/null, но если команда SELECT проваливается, то выводится текст ошибки (stderr отправляется в консоль) и выводится строка, содержащая ошибку (благодаря ||, которая означает, что у select возникли проблемы (код возврата команды не 0)).
Мне повезло, у меня были созданы индексы по полю id:
А это значит, что нахождение строки с нужным id не должен занимать много времени. В теории должно сработать. Что же, запускаем команду в tmux и идём спать.
К утру я обнаружил, что просмотрено около 90 000 записей, что составляет чуть более 5%. Отличный результат, если сравнивать с предыдущим способом (2%)! Но ждать 20 дней не хотелось…
Postgresql неуспешное завершение код выхода 1
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 2556; 0 0 SHELL TYPE mchar sysdba
pg_restore: [archiver (db)] could not execute query: ERROR : type «mchar» already exists
Command was: CREATE TYPE mchar;
pg_restore: creating FUNCTION mchar_in(cstring)
pg_restore: [archiver (db)] Error from TOC entry 2061; 1255 16414 FUNCTION mchar_in(cstring) sysdba
pg_restore: [archiver (db)] could not execute query: ERROR : function «mchar_in» already exists with same argument types
Command was: CREATE FUNCTION mchar_in(cstring) RETURNS mchar
LANGUAGE c IMMUTABLE STRICT
AS ‘$libdir/mchar’, ‘mchar_in’;
������: Melbourne, ���������
���������: 4941