Вход | Регистрация

  1  2
1С:Предприятие :: 1С:Предприятие 8 общая

КА 1.1.107.4 - проблемы с архивацией на СУБД Postgres

КА 1.1.107.4 - проблемы с архивацией на СУБД Postgres
Я
   mgk2
 
16.10.18 - 08:52
Исходные данные :
КА 1.1.107.4 с мелкими доработками
Платформа 8.3.9.2170
СУБД Postgres Pro 9.4

Все работало стабильно почти 2 года, пока не обновил конфу на релиз 1.1.107.4 .
Заметил, что перестали восстанавливаться архивы созданные с помощью pg_dump.

Начал разбираться и выяснил, что pg_dump в процессе архивации выдает ошибки :

pg_dump: Ошибка выгрузки таблицы "config": сбой в PQgetResult().
pg_dump: Сообщение об ошибке с сервера: Р?РЁР?Р'Р?Р?:  invalid memory alloc request size 1174829507
pg_dump: Выполнялась команда: COPY public.config (filename, creation, modified,attributes, datasize, binarydata) TO stdout;

Переносил базу на другие сервера , менял версии Postgres (9.6 и 10.5), менял платформу (8.3.9.2309 и 8.3.10.2772) - результат тот же, pg_dump не может нормально создать архив.

При постановке конфы обратно на поддержку архивация начинает работать нормально.

Как можно решить проблему?
 
 
   ansh15
 
101 - 08.11.18 - 10:36
Извиняюсь за многословие.
Простой эксперимент.
createdb test; psql test
В базе создаем таблицу
create table config(id int, bindata bytea);
и грузим в нее что-нибудь(неважно что, какой-нибудь файл)
insert into config values (1, pg_read_binary_file('_input/tstf.tgz'));
Все хорошо загрузилось, без ошибок.
Смотрим размер бинарной строки select octet_length(bindata) FROM config;
octet_length
--------------
    668411047                 размер загруженного файла в байтах
(1 row)

После этого пытаемся использовать pg_dump для создания выгрузки
pg_dump -F c -b  -f test.backup test
Результат — такая же ошибка, как и у автора темы
invalid memory alloc request size 1336822097   -  число, равное длина_бинарной_строки * 2 + 3

Далее, опять psql test
Смотрим, можно ли командой copy выгрузить таблицу config в файл
copy config to '/home/postgres/config.tbl';
Нет, нельзя, возникает та же ошибка.
В документации видим, что у команды copy есть параметр формата чтения/записи
данных binary, пробуем - copy config to '/home/postgres/temp2/config.tbl' with binary;
Ошибки не возникает, файл создается того же размера, что и бинарная строка.
Если размер бинарной строки, скажем, 350 МБ, то ошибки не возникает.
   Фрэнки
 
102 - 08.11.18 - 10:42
(101) круто!

А вот интересно (раз пошла такая пьянка - режь последний огурец), почему такого вида траблы нет, когда конфигурации не равны КА 1.1 или УПП 1.3 , например, КА 2 какая-то ?
   Garykom
 
103 - 08.11.18 - 11:16
(99) Но он же хочет больше "invalid memory alloc request size 1 174 829 507"
Может в этом дело?
   Garykom
 
104 - 08.11.18 - 11:19
(101) Урра ошибка не в 1С а в PostgreSQL так?
   Фрэнки
 
105 - 08.11.18 - 11:25
(104) нет. Пост собственно о том, что платформа 1С как-то криво и неоднозначно прописывает в базу конфигу Поставщика
   ansh15
 
106 - 08.11.18 - 11:29
Сервер для выполнения команды copy пытается выделить память, натыкается на ограничение в 1 GB и выдает ошибку.
< 2018-11-08 10:53:02.140 MSK >LOG:  00000: statement: copy config to '/home/postgres/config.tbl';
< 2018-11-08 10:53:02.140 MSK >LOCATION:  exec_simple_query, postgres.c:940
< 2018-11-08 10:53:02.513 MSK >ERROR:  XX000: invalid memory alloc request size 1336822097
< 2018-11-08 10:53:02.513 MSK >LOCATION:  palloc, mcxt.c:858
< 2018-11-08 10:53:02.513 MSK >STATEMENT:  copy config to '/home/postgres/config.tbl';
   Garykom
 
107 - 08.11.18 - 11:36
(105) Тоже верно, не учли особенностей постгрес и лимитов на одну запись.
Точнее учли но не догадались что при выгрузке бинарного поля оно каким то хитрым образом конвертится и занимает чуть более чем в 2 раза памяти.
   Фрэнки
 
108 - 08.11.18 - 11:57
(107) все бы ничего, но почему-то в других конфигах с этими примерно размерами траблы не возникает

з.ы. я уже одно и тоже повторяю :-)
   stopa85
 
109 - 08.11.18 - 12:10
(101) Снимаю шляпу. Я был уверен что эта фича-бага как-то так воспроизведется. Но вы меня опередили)
   ansh15
 
110 - 08.11.18 - 12:38
(109)Просто интересно стало.
(108)Может в более новых конфигурациях и стали учитывать. Не превышать размер конфы поставщика выше определенного значения.
 
 Рекламное место пустует
   Rema Dan
 
111 - 08.11.18 - 12:38
(0) Хорошо бы проверить повторится ли эта ошибка на демобазе с разрешёнными изменениями и отключённым режимом совместимости. Возможно, что из-за активного режима совместимости платформа не использует какой-нибудь трюк для обхода этой проблемы.
   mgk2
 
112 - 08.11.18 - 12:57
(111) на демобазе все воспроизводится.
   stopa85
 
113 - 08.11.18 - 15:43
ansh15, а тебе удается восстановить табличку config из файла после COPY ... binary?


COPY public.config (id, bindata) FROM '/var/lib/postgresql/copy.test' with binary;

У меня вызывает крах сервера ИЛИ "Ошибка при запросе памяти (850672995 Б)"
   NorthWind
 
114 - 08.11.18 - 21:42
(102) возможно, там либо этот объем меньше, либо как-то изменен формат хранения, чтобы в одном поле одной строки столько не хранилось. Собственно, в (105) вы пишете как раз об этом
   NorthWind
 
115 - 08.11.18 - 21:47
(108) "примерно" здесь не сработает, нужно сделать запрос и посмотреть размер. Скорее всего, в новых конфигурациях каким-то образом обошли критический размер поля, а в старых это либо оказалось трудоемко, либо просто поленились связываться с этим. Либо третий вариант - обошли, но в сочетании новая платформа/новая конфигурация.
   kook
 
116 - 08.11.18 - 21:49
(115)Вероятнее всего дело в объеме данных.
Формат хранения конфигурации поставщика поменять - это ж нужно платформу допиливать, так?
   ansh15
 
117 - 08.11.18 - 21:49
(113) Да, в пустую таблицу.
   NorthWind
 
118 - 08.11.18 - 21:57
(116) здесь может быть сочетание особенностей платформы и особенностей файла конфигурации. Т.е. что постарше хранят так, а что поновее - по-другому.
   Фрэнки
 
119 - 09.11.18 - 09:05
(118) +100500 :-)
вот у меня абсолютно такое же впечатление - сочетание особенностей
   ewgenik
 
120 - 17.11.18 - 08:43
Возьму на себя смелость описать техническую причину проблемы.
1. У PG давным-давно сложилось, что размер буфера памяти для работы со строками не может превышать 1Гб.
2. pg_dump развёртывает бинарные строки в текст (под 1 байт бинарных данных отводится 16 бит (2 байта) текстовых данных). Таким образом размер данных удваивается.
3. Конфигурация в базе хранится одной бинарной строкой. Как только ее размер перевалит за ~0.5Гб.  pg_dump не сможет ее сохранить, это и приводит к ошибке описанной в первом посте.

Что можно сделать.
1. Использовать pg_basebackup https://its.1c.ru/db/metod8dev#content:5947:hdoc
2. Перекомпилировать pg_dump заменив оператор выгрузки COPY на бинарный. В инете есть инфа, что люди так делали, и что характерно, выгруженные данные с исправленного pg_dump`а нормально восстанавливаются стандартным pg_restore.
3. Сами разработчики PG ограничение в 1Гб снимать не торопятся, так как не уверены, что снятие ограничения не вызовет других конфликтов. Вопрос находится в категории «пожелания».

PS: В техподдержку 1С заява отправлеа. ИМХО 1С должна была учитывать эту особенность и хранить конфигурацию как-то иначе.
   palsergeich
 
121 - 17.11.18 - 09:42
(120) Снимаю шляпу
   Фрэнки
 
122 - 17.11.18 - 10:38
(120) фишка заключается в одной маленькой подробности и я об этой подробности выше упоминал уже неоднократно.

А подробность эта свидетельствует о том, что ничего особенного 1С делать не будет. И проблема эта им в 1С известна уже не первый и не второй год.

Вот эта подробность: Особенность в работе с СУБД Postgres наблюдается только с двумя конфигурациями, хотя и в остальных конфигурациях размер превышает в сумме 1Гб - это только КА 1.1 и УПП 1.3

Так что на Ваше ИМХО отвечу своим ИМХО - 1С предлагает просто переходить с КА 1.1 на КА 2.4 без доплаты за апдейт, так же как на любых других ЗУП или БП или УТ
Ну нет официального заявления о прекращении поддержки и какие-то обновления по КА 1.1 выходят, но на системном уровне обеспечить в конфигурации (в ее системно закрытой части) решение такого рода проблемы 1С не станет.
   Фрэнки
 
123 - 17.11.18 - 10:46
Да и вообще, если смотреть серьезно, то и сама описываемая проблема не является какой-то мега-супер-пупер критичной траблой, а вполне себе обходится на практике ловкостью рук безо всякого мошенничества (и выше об этом в постах тоже было написано) - базу на СУБД можно хранить в виде "снята с поддержки", чтоб конфигурации поставщика в ней просто не было. Ну не нужна там на сервере никому в процессе ежедневной пользовательской работы.
   avm7
 
124 - 20.11.18 - 09:59
(120) На данный момент проблему резервных копий решили так (в том числе благодаря информации с данного обсуждения) (linux).
Резервная копия создается тремя командами вместо одной:
pg_dump -Z 9 -T config -f путь_к_файлу имя_базы
pg_dump -t config -s -f путь_к_файлу_схемы имя_базы
psql -d имя_базы -c "COPY public.config TO 'путь_к_файлу_конф' WITH BINARY;"

Первой командой выгружаем дамп базы за исключением проблемной таблицы config.
Второй командой выгружаем схему для таблицы config.
Третьей - выгружаем таблицу config в бинарном виде.
В результате у нас на выходе три файла.

Восстановление.
Распаковыввем основной архив:
gunzip --keep путь_к_файлу
Восстанавливаем БД, при этом восстанавливается БД без таблицы config
>psql имя_базы < путь_к_распакованному_файлу
Теперь восстанавливаем таблицу config.
Создаем в БД таблицу config:
>psql имя_базы < путь_к_файлу_схемы
Заливаем в таблицу config данные из файла
psql -d имя_базы -c "COPY public.config FROM 'путь_к_файлу_конф' WITH BINARY;"
   MaximRodnik
 
125 - 20.11.18 - 10:07
(120) Исправлена ли эта проблема в PG 11, которая вышла недавно?
   Serg_1960
 
126 - 20.11.18 - 10:14
Зачем вам в рабочей базе нужна конфигурация поставщика?

PS: особо всё внимательно не читал, поэтому sorry если уже спрашивали.
   Serg_1960
 
127 - 20.11.18 - 10:20
PSS: проблемы, возникающие с конфигурацией УПП,  не только связаны с самой конфигурацией, но с "низким" режимом совместимости на "высоких" платформах.
   Фрэнки
 
128 - 20.11.18 - 10:25
(127) конечно. Поэтому я даже не знаю, как можно рассчитывать на решение подобного рода проблем в конфиге КА 1.1 и УПП 1.3

Если повышение релиза СУБД даст какой-то заметный эффект только при повышении релиза платформы, а релиз платформы упирается в грабли под названием "режим совместимости"
   rsv
 
129 - 20.11.18 - 10:59
(0) похоже скоро слон будет без альтернатив http://www.cnews.ru/news/top/2018-11-20_microsoft_sokrashchaet_shtat_v_rossii_sotrudnikov
   ansh15
 
130 - 20.11.18 - 11:09
(128) Когда снимут с поддержки и КА 1.1 и УПП 1.3, и у людей не останется выбора, кроме как переползти на КА 2 и ERP, проблема решится сама собой. Наверное, перейти на новые конфы с "переписанных вдоль и поперек" старых будет весьма непросто...
   ewgenik
 
131 - 21.11.18 - 11:09
(124) Проверено, работает! Спасибо, жму руку!

Вопрос, а имеет ли смысл каждый раз сохранять таблицу 'config', или ее копию можно делать только после внесений изменений в конфигурацию?
   stopa85
 
132 - 21.11.18 - 11:35
(124)(131) Вот она сила Мисты! Первые подобные проблемы в интернете встечаются очень давно. Но разобрались только в Мисте.
   stopa85
 
133 - 21.11.18 - 12:03
(124) Нужно только не забывать что команда
psql -d имя_базы -c "COPY public.config TO 'путь_к_файлу_конф' WITH BINARY;" - платформо-зависимая.
Может не восстановиться на других релизах и даже при перепрыгивании с х32 на х64.
 
 
   ewgenik
 
134 - 22.11.18 - 03:53
(133) Думаю никому не придет в голову делать переход на другую платформу через SQL backup/restore. Для таких вещей используют средства самой 1С.
   mgk2
 
135 - 22.11.18 - 10:21
(134) в обсуждаемой ситуации выгрузка в dt проходит без проблем, а загрузка вылетает с ошибкой.
См (75)
   stopa85
 
136 - 22.11.18 - 10:49
(134) я имею в виду релиз PostgreSQL.
Когда я менял релиз постгреса - я делал выгрузку/загрузку dt для 1С-овских баз и dump/restore для не 1С-совских.

Если мне не изменяет моя память, то при переходе с релиза на релиз постгреса, например с 8.4 на 9.1, нужно подключится к серверу постгреса 8.4 утилитой pg_dump из 9.1, сделать бекап и восстановить его в 9.1.
Если я что-то путаю или отстал от жизни - поправьте, пожалуйста.

Соответственно в случае краха сервера (пожар/землетрясение/метеорит) бекапы нужно восстанавливать на том же релизе постреса с той же разрядностью.
   ewgenik
 
137 - 22.11.18 - 11:05
(135) Не факт.
Была проблема, что конфигурация из .dt`шника не загружалась. Причина была в том, что на виртуалке с PGSQL было всего 1Гб ОЗУ. Увеличил до 2Гб - все загрузилось. Речь идет о базе как раз подпадающую под обсуждаемую ситуацию.
   ansh15
 
138 - 22.11.18 - 11:25
(135)Потому что при загрузке из dt сервер приложений 1C пишет в базу данных при помощи COPY.
При выгрузке в dt сервер приложений получает данные из СУБД посредством через курсор FETCH, видимо там другой алгоритм выделения памяти, который не приводит к такой ошибке.
Посмотрел сейчас лог PostgrSQL - при выгрузке в dt создается declare cursor mycursor binary специально для таблицы config, и потом fetch.
   ansh15
 
139 - 02.12.18 - 12:19
   mgk2
 
140 - 04.12.18 - 13:17
Жесть какая. Давно я оленей не кормил.
Оказывается в марте уже объявили.
   mgk2
 
141 - 04.12.18 - 13:18
Вопрос к франчам : сколько будет стоить апгрейд с КА 1.1 на УПП 1.3 ?
   spectre1978
 
142 - 04.12.18 - 18:23
(141) а могет быть такой апгрейд? Разные продукты вроде как совсем. Да и УПП уже просто так не купить, нужно долго доказывать что она тебе нужна. Апгрейд только на КА2...
   Фрэнки
 
143 - 04.12.18 - 18:53
(142) для КА 1.1 есть халявный апгрейд на КА 2.4
   Фрэнки
 
144 - 04.12.18 - 18:54
А вообще, могут зачесть стоимость, как это всегда бывает при смены конфигурации на более дорогую.
   NorthWind
 
145 - 04.12.18 - 20:10
(143) на КА2 понятно что есть в том или ином виде. Человек же на УПП хочет :)
   gni
 
146 - 17.12.18 - 10:18
Здравствуйте!

(124) А как решили проблему (если решили) с индексацией?

Спасибо.
   NorthWind
 
147 - 18.12.18 - 21:59
(146) если схема по команде №2 выгружается с командами создания индексов, то проблемы как будто и нет...
   avm7
 
148 - 21.12.18 - 15:14
(146) насколько я помню, в полной выгрузке таблица config не упоминается в создании индексов. Т.е. проблем быть не должно.
  1  2

Список тем форума
  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует