Почему не восстанавливаются резервные копии?

Question

[partisan42]

Доброго дня.
Появилась проблема, и я очень прошу помощи.

Суть.
Есть сервер с CentOS 6, на базе которого крутится postgres.

[root@DataB ~]# psql -V
psql (PostgreSQL) 9.4.2

Там имеются базы данных, которые используются как базы 1С.
На этом сервере есть sh скрипт который выполняется по cron. Суть этого скрипта, это бэкапить базы на NAS. Пример скрипта, приведу ниже.

/usr/pgsql-9.4/bin/pg_dump --host localhost --port 5432 --username "postgres" --role "postgres" --no-password  --format custom --blobs --compress 9 --encoding UTF8 --verbose --file /mnt/NASbackup/Buh_UKEKNew/Buh_UKEKNew-$(date +%Y-%m-%d).backup "Buh_UKEKNew"  2> $LOG_FILE

И вроде всё делается нормально, бэкапы делаются, я спокоен, и пару мепсяцев один из них разворачивал, и тут попытался сделать это снова с помощью...

pg_restore --host localhost --port 5432 --username "postgres" --dbname "Buh_sheregesh_31032021" --role "postgres" --no-password --clean  --section pre-data --section data --section post-data --verbose "/root/Buh_sheregesh3-2021-03-31.backup"

База изначально была создана с помощью консоли 1С.

И вот, после восстановления бэкапа я получаю следующее.

WARNING: errors ignored on restore: 23685
You have mail in /var/spool/mail/root

Другие бэкапы так же пытался восстановить. Количество ерроров меняется, но суть остаётся неизменной.
Я получаю следующее.

И вот полный текст.
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/login:
по причине:
Ошибка при выполнении операции с информационной базой
Ошибка СУБД:
XX000: ERROR: There are 2 candidates for 'mchar_pattern_fixed_prefix' function'

по причине:
Ошибка СУБД:
XX000: ERROR: There are 2 candidates for 'mchar_pattern_fixed_prefix' function'

Что то мне подсказывает что это может быть типичная ошибка новичка, но я пока ума не приложу, в какую сторону копать?

PS. Я понимаю что и CentOS старый, и PGSQL. Но пока не было возможности остановить предприятие более чем на 8 часов, что бы всё перенести, а текучку никто не отменял:(

Comments

[effko32]

Попробуйте создать БД в postgres, залить бэкап, потом уже присоединить в 1с.

[partisan42]

effko32, Пробовал, но там была какая то ошибка с типо данных, и типовой форум посоветовал сделать базу именно через 1с. Но.... Попробую ещё раз:) Спасибо:)

[partisan42]

effko32, попробовал, но при восстановлении бэкапа получил вот это.

[Melkij]

а вы pg_restore вызываете как заклинание, что ли? На мой взгляд DBA осмысленно вы могли написать только две опции из всех перечисленных.

В частности, --clean и должен генерировать ошибки, показанные на наскальной живописи выше.

PS: зачем останавливать предприятие на 8 часов для обновления ОС или базы - оставлю за скобками.

[partisan42]

Melkij, Вот потому то я и обратился за помощью к сообществу, что бы получить подсказку, что я делаю не так, особенно с учётом того, что этот скрипт достался мне от аутсорсеров, и с тех пор не менялся, только лишь был мной немного изучен, в свободные минуты. Если бы я хотел получить порцию упрёков, я бы сходил к психологу, а IT сообщество я думал чуточку добрее.
а теперь по существу.
Меня смущает тот факт, что до этого тот же самый кусочек команды, при восстановлении иного бэкапа, работало прекрасно ещё 2 месяца назад. Следовательно, за последние два месяца, что то случилось без моего вмешательства.
Вот я и хотел спросить, в том числе у знающих DBA, что это могло быть? Ведь не могло что то сломаться само собой?
Хотя, если вы родились со знаниями, и не были в ситуации когда новые навыки нужно вырабатывать быстро и с помощью других людей, я могу вам только позавидовать.

[galaxy]

partisan42,

но при восстановлении бэкапа получил вот это

убирайте --clean, если восстанавливаете в чистую базу

[Melkij]

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

create database test_restore template template0;
затем покажите начало от pg_restore --shema-only -d "test_restore" "файл бекапа"

[partisan42]

Melkij, Уверяю вас, вызывать эксперта только для того что бы он решал бы за меня мою проблему, я бы точно не стал. Это как минимум не уважительно по отношению к эксперту, и точно никак не поможет мне понять причину моей проблемы. Ну если только это не будет вопрос жизни и смерти.
Так или иначе спасибо что откликнулись. Привожу вывод того что у меня получилось.

[root@DataB ~]# su postgres
bash-4.1$ psql
could not change directory to "/root": Permission denied
psql (9.4.2)
Type "help" for help.

postgres=# create database test_restore template template0;
CREATE DATABASE
postgres=# \q
bash-4.1$ pg_restore --schema-only -d "test_restore" /tmp/Buh_sheregesh3-2021-03-31.backup

pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 8096; 0 0 SHELL TYPE mchar postgres
pg_restore: [archiver (db)] could not execute query: ОШИБКА:  тип "mchar" уже существует
    Command was: CREATE TYPE mchar;



pg_restore: [archiver (db)] Error from TOC entry 7597; 1255 16396 FUNCTION mchar_in(cstring) postgres
pg_restore: [archiver (db)] could not execute query: ОШИБКА:  функция "mchar_in" с аргументами таких типов уже существует
    Command was: CREATE FUNCTION mchar_in(cstring) RETURNS mchar
    LANGUAGE c IMMUTABLE STRICT
    AS '$libdir/mchar', 'mchar_in';



pg_restore: [archiver (db)] Error from TOC entry 7598; 1255 16397 FUNCTION mchar_out(mchar) postgres
pg_restore: [archiver (db)] could not execute query: ОШИБКА:  функция "mchar_out" с аргументами таких типов уже существует
    Command was: CREATE FUNCTION mchar_out(mchar) RETURNS cstring
    LANGUAGE c IMMUTABLE STRICT
    AS '$libdir/mchar', 'mchar_out';



pg_restore: [archiver (db)] Error from TOC entry 7600; 1255 16399 FUNCTION mchar_recv(internal) postgres
pg_restore: [archiver (db)] could not execute query: ОШИБКА:  функция "mchar_recv" с аргументами таких типов уже существует
    Command was: CREATE FUNCTION mchar_recv(internal) RETURNS mchar
    LANGUAGE c IMMUTABLE STRICT
    AS '$libdir/mchar', 'mchar_recv';



pg_restore: [archiver (db)] Error from TOC entry 7599; 1255 16398 FUNCTION mchar_send(mchar) postgres
pg_restore: [archiver (db)] could not execute query: ОШИБКА:  функция "mchar_send" с аргументами таких типов уже существует
    Command was: CREATE FUNCTION mchar_send(mchar) RETURNS bytea
    LANGUAGE c IMMUTABLE STRICT
    AS '$libdir/mchar', 'mchar_send';

И дальше всё примерно в том же духе.

[Melkij]

хмхм. А у вас pg_dump точно от этого форка postgresql вызывается?
На вид похоже, что сама база у вас отдельный форк для 1с, на самом деле не умеющего работать с postgresql. Но pg_dump записал создание этих нестандартных типов данных. При том, судя по "there are 2 candidates for ... function" - они ещё и различаются между тем что в дампе и тем что нагородили в этом форке.

Если у вас на самом деле установлено несколько разных pg_dump и теперь вызывается не тот модифицированный для форка, а, например, от оригинального немодифицированного postgresql - то это может объяснить происходящее.

[partisan42]

Melkij, Доброго утра. Прошу прощения, просто вырубился прямо за ноутбуком.
По факту, pg_dump в системе один.

[root@DataB ~]# updatedb
You have mail in /var/spool/mail/root
[root@DataB ~]# locate pg_dump
/etc/alternatives/pgsql-pg_dump
/etc/alternatives/pgsql-pg_dumpall
/etc/alternatives/pgsql-pg_dumpallman
/etc/alternatives/pgsql-pg_dumpman
/root/old/komanda pg_dump pgsql.txt
/root/old/logpg_dump.log
/usr/bin/pg_dump
/usr/bin/pg_dumpall
/usr/pgsql-9.4/bin/pg_dump
/usr/pgsql-9.4/bin/pg_dumpall
/usr/pgsql-9.4/share/locale/cs/LC_MESSAGES/pg_dump-9.4.mo
/usr/pgsql-9.4/share/locale/de/LC_MESSAGES/pg_dump-9.4.mo
/usr/pgsql-9.4/share/locale/es/LC_MESSAGES/pg_dump-9.4.mo
/usr/pgsql-9.4/share/locale/fr/LC_MESSAGES/pg_dump-9.4.mo
/usr/pgsql-9.4/share/locale/it/LC_MESSAGES/pg_dump-9.4.mo
/usr/pgsql-9.4/share/locale/ja/LC_MESSAGES/pg_dump-9.4.mo
/usr/pgsql-9.4/share/locale/pl/LC_MESSAGES/pg_dump-9.4.mo
/usr/pgsql-9.4/share/locale/pt_BR/LC_MESSAGES/pg_dump-9.4.mo
/usr/pgsql-9.4/share/locale/ru/LC_MESSAGES/pg_dump-9.4.mo
/usr/pgsql-9.4/share/locale/zh_CN/LC_MESSAGES/pg_dump-9.4.mo
/usr/pgsql-9.4/share/man/man1/pg_dump.1
/usr/pgsql-9.4/share/man/man1/pg_dumpall.1
/usr/share/man/man1/pg_dump.1
/usr/share/man/man1/pg_dumpall.1
/var/lib/alternatives/pgsql-pg_dump
/var/lib/alternatives/pgsql-pg_dumpall
/var/lib/alternatives/pgsql-pg_dumpallman
/var/lib/alternatives/pgsql-pg_dumpman

На свежую голову попробовал выполнить

pg_restore --host localhost --port 5432 --username "postgres" --dbname "buhsh3_test" --role "postgres" --no-password --section pre-data --section data --section post-data --verbose "/tmp/Buh_sheregesh3-2021-03-31.backup"

то есть тоже самое, но без ключа --clean
И всё восстановилось без проблем.
Осталось разобраться в двух вопросах.
1) Почему чуть ранее этот ключ не мешал восстановлению резервных копий.
2) Что это за ключ такой.
ОГРОМНОЕ вам спасибо что откликнулись и навели меня на правильную мысль. Обещаю что на выходных изучу вопрос самостоятельно, что бы больше глупых вопросов не задавать:)

Answer 1

[kav1984]

У меня, тоже перестали восстанавливаться бэкапы.
1с 8.3 + Win serv 2008 + Postgres 9.6.7-1.1С
Делались бэкапы скриптом из командной строки.

Раньше работала такая последовательность действий. Создавал с помощью 1с пустую базу Postgres и восстанавливал из командной строки используя pg_restore
Но сейчас при восстановлении стали сыпаться ошибки и в итоге как у вас при входе в 1с
XX000: ERROR: There are 2 candidates for 'mchar_pattern_fixed_prefix' function'

Все заработало при такой последовательности:
Создал пустую базу в PgAdmin3 1.22.2 с шаблоном template0
И восстановил базу в самом же PgAdmin. Ошибок не было.
Затем создал базу с таким же именем в 1с и все заработало.

Comments

[partisan42]

Именно так я этот вопрос 3 недели назад и решил:) Спасибо:)

[artemptichkin]

Спасибо, именно так решилось.

[Z7D]

Было тоже самое при переходе на новый 1С и новую PG.
Нашёл эту функцию в базе в Schemas / Public / Functions и увидел, что там действительно 2 одинаковые функции mchar_pattern_fixed_prefix() , одна с аргументом 3 вторая с 4. Удалил последнюю. И база запустилась.

Answer 2

[mkone112]

У меня к счастью мало опыта с 1с, но могу точно сказать что ты облажался. Бекап делается следующим образом - снимаем образ(желательно всего и вся), а потом делаем вид будто серверная взорвалась, вместе со зданием. После этого - пытаемся восстановить, если не удалось - значит бекапа никогда не было.

Comments

[partisan42]

То есть вы предлагаете, в случае необходимости развернуть останавливать предприятие на сутки, и восстанавливать вообще все базы? Или даже образ диска? А вы знатный любитель извращений:)

[mkone112]

partisan42,

То есть вы предлагаете, в случае необходимости развернуть останавливать предприятие на сутки, и восстанавливать вообще все базы? Или даже образ диска?

Я предлагаю то что написал. Какая связь с тем что написал ты - я не представляю.

Answer 3

[GrandGCH]

Некропостинг, но может кому поможет.
Проблему заметил еще когда CMD вывод писал, но внимания не обратил, получил эту ошибку.
Чтобы не восстанавливать базу еще раз, в моем случае 1.5 часа, можно отправить следующий SQL запрос на эту базу, я делал через PGAdmin, где в схему базы не давало провалиться из-за этой ошибки.
"DROP FUNCTION IF EXISTS mchar_pattern_fixed_prefix (internal, internal, internal)".
По идее, остается только эта функция с 4-мя аргументами (на моих остальных 1С базах, эта функция имеет только 4 аргумента) и все работает.

Answer 4

[ky0]

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

Возможно, стоит загуглить какие-то стандартные, общерекомендованные решения по бэкапу.