0. vsasav 424 03.12.18 20:26 Сейчас в теме

PostgreSQL для 1С 8.3: ускоряем резервное копирование и восстановление для отдельной базы очень большого размера

В этой статье разберем оптимизацию работы с моментальным снимком отдельной базы 1С в кластере PostgreSQL средствами pg_dump.exe, pg_restore.exe, psql.exe в среде Windows Server 2008,2012,2016. А также разберем проблемные ситуации и неожиданные ограничения при работе 1С в связке с PostgreSQL. Для Linux все аналогично.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. PbI4 1 04.12.18 23:40 Сейчас в теме
02.11.18 14:48

А ни у кого не случается иногда такая ошибка при ресторе?

pg_restore: обрабатываются данные таблицы "public._usersworkhistory"
pg_restore: обрабатываются данные таблицы "public._yearoffset"
pg_restore: обрабатываются данные таблицы "public.config"
pg_restore: [внешний архиватор] не удалось прочитать входной файл: конец файла


Причём всегда после конфига и иногда рестор отрабатывает без ошибки на том же самом дампе

месяц прошёл в старой теме (https://infostart.ru/article/rezervnoe-kopirovanie-i-vosstanovlenie-bazy-1s-sredstvami-postgresql-540298/), повторим - может есть адекватные ответчики, спасибо
3. vsasav 424 05.12.18 09:31 Сейчас в теме
(1) Это и есть грабли, которые описаны в статье, когда pg_dump не может выгрузить public.config. Для этого и применяется команда COPY в статье.
Сам недавно наткнулся на них. Это означает - ваш архив базы - битый, но это вы не увидите, пока не используете pg_restore. Используйте мой вариант, когда отдельно выгружается public.config с помощью COPY WITH BINARY. Он будет работать всегда, т.к. конфигурация относительно редко меняется.
4. vsasav 424 05.12.18 10:57 Сейчас в теме
(1) Теперь можете свой -1 поменять на +1 ;)
2. frkbvfnjh 513 05.12.18 08:57 Сейчас в теме
Спасибо, много нового узнал! И главное описано очень понятно и детально.
5. starik-2005 1853 05.12.18 12:47 Сейчас в теме
+ просто за то, что кто-то пишет про постгри.
6. DonAlPatino 53 05.12.18 13:20 Сейчас в теме
Т.е. "просто" как в MS SQL бэкап во время работы пользователей на лету сделать нельзя? Это для всех версий postgress актуально?
8. vsasav 424 05.12.18 13:49 Сейчас в теме
(6) pg_dump - это и есть бэкап на лету (моментальный снимок), актуально для PostgreSQL 9.Х и выше
11. DonAlPatino 53 05.12.18 15:08 Сейчас в теме
(8) "просто" - это по одной кнопке все-таки (простите человек, испорченного MS), а не набором скриптов, с последовательной выгрузкой отдельных таблиц. Вот это "спотыкание" на отдельных таблиц - это стандартная ситуация или просто "временами бывает"?
12. starik-2005 1853 05.12.18 15:29 Сейчас в теме
(11)
"просто" - это по одной кнопке все-таки (простите человек, испорченного MS), а не набором скриптов
ИМХО, любой скрипт плавно превращается в одну кнопку. Не?
15. TODD22 17 05.12.18 18:02 Сейчас в теме
(12)после 3х дней гугла и чтения мануалов. Набор запчастей превращается в автомобиль после трех дней сборки. А хотелось бы взять готовый, сесть и поехать сразу.
Fox-trot; +1 Ответить
18. vsasav 424 05.12.18 21:45 Сейчас в теме
(11) Тут ничего не поделаешь: ограничение PostgreSQL на 1 Гб в длине поля типа binary по чтению в stdout. Аналогичные грабли мы нашли бы, думаю, и в MSSQL на 1С, если бы размер изменений конфигурации приблизился к 2 Гб, но на практике никто такого еще видимо не испытывал. Так что все впереди. PostgreSQL тут ни при чем. Это особенность реализации от 1С. Можно было бы не в одну запись пихать изменения, а в несколько. К счастью ошибка обходится с помощью COPY WiTH BINARY.
7. TarasovAV 05.12.18 13:38 Сейчас в теме
Т.е., если база небольшая, скажем до 500 МБ, то бэкапирование с помощью --format custom пройдет успешно? И при восстановлении не возникнет указанная ошибка?
9. vsasav 424 05.12.18 14:04 Сейчас в теме
--format custom пройдет успешно на базе любого размера, только если размер ни одной из записей таблицы public.config (конфигурация) после чтения и распаковки в стандартный поток вывода stdout не превысит 1 Гб, то же самое касается формата --format directory. Для небольших по объему размеров конфигураций - прокатит, но для больших в один самый неожиданный момент завершится с ошибкой, повторяюсь:

--exclude-table=config - исключить из выгрузки таблицу config. Это требуется, когда база находится на поддержке у двух и более конфигураций поставщика и (или) очень много изменений внесено в конфигурацию. При этом размер изменений основной конфигурации относительно конфигурации одного из поставщиков приближается к 1Гб, что является пределом для поля большого размера в PostgreSQL. А 1С хранит изменения только в одной из записей таблицы config. При небольшом размере конфигурации можно не использовать этот параметр. Но при критическом pg_dump.exe завершится с ошибкой:

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

Если используется --format custom, то архив выгружается в виде одного файла, и ошибка создания архива на таблице public.config обнаружится при выполнении команды pg_restore, что и есть самое неприятное:

pg_restore: обрабатываются данные таблицы "public._usersworkhistory"
pg_restore: обрабатываются данные таблицы "public._yearoffset"
pg_restore: обрабатываются данные таблицы "public.config"
pg_restore: [внешний архиватор] не удалось прочитать входной файл: конец файла

(кроме того --format custom не позволит использовать --jobs - распараллеливание)

Наблюдается на больших конфигурациях KA 1.1-2.4, УПП 1.3, ERP 2.4.
teflon; DonAlPatino; A_Max; Fox-trot; neyasytyf; TarasovAV; +6 Ответить
20. DonAlPatino 53 06.12.18 10:21 Сейчас в теме
(9)Спасибо большое - вот теперь все понятно.
10. TarasovAV 05.12.18 14:10 Сейчас в теме
Спасибо за развернутый ответ.
13. neyasytyf 05.12.18 16:03 Сейчас в теме
Спасибо за третий шаг
Шаг 3. Загружаем с помощью psql.exe таблицу public.config с помощью COPY WITH BINARY


Сам делал через:
psql -c "COPY (select * from public.config where datasize < 629605263) TO '/var/lib/pgsql/arhiv/$filename.config'" db
Но потом необходимо cf подгружать.

Вместо --exclude-table можно использовать --exclude-table-data=config, тогда структура таблицы config выгрузится без данных, и можно в два шага выгружать.
A_Max; CSiER; Fox-trot; vsasav; +4 Ответить
14. vsasav 424 05.12.18 17:36 Сейчас в теме
(13) Да, про --exclude-table-data=config - ценное замечание. Пожалуй, откорректирую статью. Во всем должна быть минимизация.
A_Max; neyasytyf; +2 Ответить
17. vsasav 424 05.12.18 18:39 Сейчас в теме
(13) Минимизировал статью в соответствии с указанным выше замечанием. СПАСИБО !
19. neyasytyf 06.12.18 09:44 Сейчас в теме
(17) Ну тогда еще стоит упоминуть, что создать базу можно командой createdb из консоли. Так удобней в скриптах для восстановления делать, чтобы не использовать psql.
22. vsasav 424 06.12.18 12:42 Сейчас в теме
(19) Хорошо, тогда уж и dropdb для кучи для удаления базы. Приведу примеры в следующей модификации статьи.
25. vsasav 424 06.12.18 17:44 Сейчас в теме
Внимание!!! По просьбе (19) и к счастью для всех, кто хочет все одной кнопкой статья была доработана!!!

Теперь будьте очень осторожны при восстановлении базы. По просьбам читателей и пользователей в bat-файлы добавлены команды автоматического удаления и создания восстанавливаемой базы в случае ее существования. Не ошибитесь в наименовании базы в команде SET ar_base_to=<Имя базы, куда восстанавливаем> !!! Иначе можно легко порушить существующие базы.
53. user1032109 09.04.19 10:44 Сейчас в теме
(25)Подскажите, как можно с вами связаться?
16. Gavris 05.12.18 18:14 Сейчас в теме
Приветствую.
Побилась база 1с.
Есть бекап в виде выгрузки 1c из postgres 9.4 формат *.sql
Весит 100 гигов.
Обратно не загружается. Ввожу вот такую команду
"C:\Program Files\PostgresPro 1C\9.4\bin\psql.exe" -U postgres gef_restore < E:\BackUp\gef201811300311.sql

Выводит вот такое: http://joxi.ru/p27K7a9UoXZ332
Посоветуйте что можно сделать. Готов заплатить.
21. vsasav 424 06.12.18 12:22 Сейчас в теме
(16) В данном случае копия БД скорее всего не является целостной, т.к. использована сторонняя программа с неизвестной внутренней реализацией.
Необходимо для создания архива использовать pg_dump, pg_restore. Вот что написано в документации: https://postgrespro.ru/docs/postgresql/9.4/app-pgdump

pg_dump
Название
pg_dump -- выгрузить базу данных PostgreSQL в формате скрипта в файл или архив
Синтаксис
pg_dump [ параметр-подключения ...] [ параметр ...] [ база_данных ]

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

Приложение выводит данные либо в скрипты, либо в архивные форматы файлов. Скрипты представляют собой текстовые файлы, содержащие SQL-команды, необходимые для воссоздания базы данных до состояния на момент создания скрипта. Для восстановления из скрипта его содержимое можно передать утилите psql . Скрипты можно использовать для восстановления на других машинах, в том числе с иной архитектурой. Также скрипты с некоторыми изменениями можно использовать в других базах данных SQL.

Для восстановления из архивных форматов файлов используется утилита pg_restore. Эти форматы позволяют указывать pg_restore какие объекты базы данных восстановить, а также позволяют изменить порядок следования восстанавливаемых объектов. Архивные форматы файлов спроектированы так, чтобы их можно были переносить на другие платформы с другой архитектурой.

Применение архивных форматов в сочетании утилит pg_restore и pg_dump позволяет организовывать эффективный механизм архивации и переноса данных. pg_dump можно использовать для резервирования всей базы данных, а затем при применении pg_restore выбрать нужные объекты для восстановления. Наиболее гибкие форматы резервных файлов это "custom" (-Fc) и "directory" (-Fd). Они позволяют выбрать и изменить порядок объектов, поддерживают восстановление в несколько потоков, а также сжимаются по умолчанию. При этом формат "directory" единственный, позволяющий выгружать данные в несколько потоков.

Во время работы pg_dump следует обращать внимание на предупреждения, которые печатаются в стандартный поток ошибок, особенно ввиду рассмотренных далее ограничений.
23. starik-2005 1853 06.12.18 14:27 Сейчас в теме
(16)
Выводит вот такое: http://joxi.ru/p27K7a9UoXZ332
По всей видимости в таблице Документ242 в одном из полей содержится что-то в поле флд6173, что делает уникальный индекс неуникальным. Можно в скульной выгрузке найти скрипт создания таблицы и удалить из него команды создания индексов. Ну а потом уже в 1С ТиИ с реструктуризацией.
24. vsasav 424 06.12.18 15:27 Сейчас в теме
(23) Да, кроме копания в коде SQL ничего не остается. Скорее всего строка № 97413 таблицы документа 242 порушена, но я могу ошибаться, т.к. текст ошибки нечитабельный. Нужно искать по содержимому поля fld и пробовать удалять битые записи и связанные с ними записи других таблиц документа.
26. trdm 08.12.18 09:32 Сейчас в теме
(24)
Да, кроме копания в коде SQL ничего не остается.

В 100 гиговом файле копаться - это не сахар.
Надо бы какую нить утилиту придумать, которая шринкает этот файл на маленькие и загружает их частями.
ПС. Какой-то из MS SQL рестореров так и делал: шринковал на кучу маленьких файлов.

(23) А сколько в архиве весит файло?
27. starik-2005 1853 08.12.18 21:03 Сейчас в теме
28. user1105457 10.12.18 11:16 Сейчас в теме
Огромное спасибо за статью!
Жаль не нашел её месяцем раньше, и вот почему.

Столкнулся тут недавно с проблемой выгрузки таблицы config после обновления релиза 112,5 конфигурации УПП 1.3 на платформе 8.3
Решил что таблица битая, нашёл и удалил строку на которой процесс дампа вылетал с ошибкой.
Теперь наткнулся на эту статью и понимаю что скорее всего удалил нужные данные.
У меня несколько вопросов.

1. Можно как-то найти теперь данные что были удалены ?
Есть дамп до обновления и текущая рабочая база.

2. Размер таблицы config до обновления - 671 MB, а после обновления он разрастается до 5939 MB. Мне одному кажется это странным ?

3. В чём профит использования формата выгрузки "directory" кроме возможности распараллеливания задачи?
Дампы делаются ночью и времени на их выполнение вполне хватает при использовании формата "custom". Важнее быстро восстановить бэкап и формат "custom" позволяет использовать распараллеливание задач при восстановлении.

Спасибо!
29. vsasav 424 10.12.18 13:39 Сейчас в теме
(28) 1. Вы удалили данные конфигурации поставщика, или изменений. Я проверял - все так и есть. Вернуть - маловероятно, т.к. следующее обновление создает уже другие записи с изменениями.

2. Я с той же проблемой тоже столкнулся месяц назад, пробовал удалять записи из config и проверять обновление, но вовремя остановился, т.к. следующее обновление пошло не совсем корректно. Странностей нет в таблице config: при обновлении подгружаются все изменения основной конфигурации от всех конфигураций поставщика, сама конфигурация поставщика.

3. Если не критично время создания архива, можно использовать формат "custom". Кроме параллельности создания архива "directory" лишь обеспечивает хранение каждой таблицы в отдельном файле, соответственно можно просматривать содержимое для каждой таблицы отдельно, не загружая в бд. Скорость распаковки в "directory" также выше, поскольку чтение и распаковка идет в несколько потоков. Но потом, после чтения время уходит на создание индексов - оно одинаково, что для "custom", что и для "directory"
44. ansh15 16.01.19 20:46 Сейчас в теме
(29)
Но потом, после чтения время уходит на создание индексов - оно одинаково, что для "custom", что и для "directory"

Надо подождать 11-ю версию(подтверждения ее работоспособности с 1С), там предусмотрено параллельное создание индексов.
30. user1105457 10.12.18 14:03 Сейчас в теме
1. Попутный вопрос. Насколько это критично и стоит ли заморачиваться с восстановлением ?
2. Спасибо за разъяснение.
3. Каждая таблица отдельно, но не с нормальными именами, а в виде номеров. Можно как-то вытащить соответствие этих номеров именам таблиц ?
С использованием формата "custom" распаковка тоже возможна в несколько потоков(собственно так и делаю).
Можно протестировать разницу, замерив скорость восстановления одной и той же базы из дампов разных форматов.
34. vsasav 424 10.12.18 18:26 Сейчас в теме
(30) 1. Конфигурацию уже обновляли? Если конфигурация обновляется и работает нормально, то не стоит заморачиваться.
3. Вероятно, можно, но зачем. На порченную таблицу все равно ругнется при восстановлении. Там уже будет нормальное наименование таблицы. Извлечь легко прямо в базу с помощью --table.
31. acanta 55 10.12.18 14:51 Сейчас в теме
Согласно чьей-то мудрости "Ничто очень хорошее или очень плохое не может длиться очень долго". Если бакап и восстановление действительно слишком долго делаются, то как оно должно работать? Репликация/зеркалирование? Настройка периферийной базы средствами 1С?:
33. vsasav 424 10.12.18 18:06 Сейчас в теме
(31) Вот что рекомендует фирма 1С (но это работает, насколько я понял, только для всего кластера целиком, а в нем может быть много разных довольно крупных баз):
настроить резервное копирование с помощью утилиты pg_basebackup:
https://www.postgresql.org/docs/9.4/static/app-pgbasebackup.html
Подробно о настройке можно прочитать: https://its.1c.ru/db/metod8dev#content:5947:hdoc
32. vsasav 424 10.12.18 17:58 Сейчас в теме
(30) 1. Конфигурацию уже обновляли? Если конфигурация обновляется и работает нормально, то не стоит заморачиваться.
3. Вероятно, можно, но зачем. На порченную таблицу все равно ругнется при восстановлении. Там уже будет нормальное наименование таблицы. Извлечь легко прямо в базу с помощью --table.
35. user1105457 11.12.18 06:31 Сейчас в теме
(32) 1. Попробовали обновить - не обновляется, пишет что не может сравнить, типа не с чем. Что можно сделать ?
36. vsasav 424 11.12.18 09:04 Сейчас в теме
(35) Снять конфигурацию с поддержки и снова установить на поддержку. Но нужен полный релиз поставщика (не обновление). Но это может занять много времени. Поэтому если сохранился старый cf-ник, который содержал конфигурации поставщика, и ваша конфигурация за этот месяц не менялась, то проще попробовать Загрузить конфигурацию из этого cf-ника и проверить работосбособность наката обновлений и самой базы (естественно на копии рабочей базы)
37. user1105457 11.12.18 09:32 Сейчас в теме
41. user619273_alevtina 30.12.18 18:26 Сейчас в теме
38. gni 17.12.18 11:00 Сейчас в теме
Здравствуйте!

А для родственной проблемы с индексацией есть какое-то решение (кроме снять/поставить на поддержку)?

Выходит такое сообщение при индексации:

reindexdb: переиндексировать базу данных "upp" не удалось: ОШИБКА: could not open relation with OID 8159083


Спасибо.
39. vsasav 424 17.12.18 13:29 Сейчас в теме
(38) Такая ошибка у меня на базе не возникала, так что ничем помочь не смогу.
42. XOCTEP 114 16.01.19 16:53 Сейчас в теме
(39) Добрый день!
Подскажите, УПП обновили на 114.1. После этого не смогли обновиться дальше, т.к. при попытке сравнения конфигурации с конфигурацией поставщика сразу же выпадает ошибка - "Недостаточно памяти для получения результата запроса к базе данных". У нас текущая связка ПГ-64бит и Сервер 1С 32бит.
Было испробовано много разных вариантов, но все без толку. Затем обнаружили, что перестали выполняться дампы ПГ с ошибкой "pg_dump: Error message from server: ERROR: invalid memory alloc request size ‎1117677223".

Теперь вроде как понятно, что это проблема с ПГ, НО остается такой вопрос - мы взяли эту базу и протестили ее на других серваках. Связка SQL и Сервер32, связка SQL и Сервер64 - работают без проблем. Связка PG64 + Сервер64 - тоже работает! Получается не работает только PG64 + Сервер32. У всех так? И при чем тут сервер 1С?
43. ansh15 16.01.19 20:26 Сейчас в теме
(42)
И при чем тут сервер 1С

Потому что ему, как клиентскому приложению(с точки зрения СУБД), и не хватает памяти для получения результата, получаемого от СУБД. 32-х разрядное приложение использует ограниченное адресное пространство
45. XOCTEP 114 16.01.19 22:23 Сейчас в теме
(43) т.е. переход на сервер64 должен решить эту проблему?
46. ansh15 20.01.19 12:02 Сейчас в теме
(45)
Связка PG64 + Сервер64 - тоже работает!

В Вашем случае - вполне возможно. В ряде случаев может помочь и установка 64-х разрядной клиентской части платформы 1С.
Поиск в сервисе публикации ошибок(1С) по фразе "недостаточно памяти" показывает, что при работе в конкретных конфигурациях также может возникать такая ошибка, например, из-за большого объема получаемых(загружаемых) данных.
По хорошему - все компоненты системы должны быть 64-х разрядными и самой памяти должно быть достаточно. Понятно, что это вопрос денег...
47. vsasav 424 21.01.19 10:10 Сейчас в теме
(42) Не успел ответить из-за сильной занятости. Ваш вариант Связка PG64 + Сервер1С 64 - только так будет работать. Рекомендации. Вся архитектура должна быть однозначно 64-х разрядная и как минимум 32 Гб памяти для компа, который сервер. (если у вас PG и Сервер 1С на одном физическом сервере, то желательно 48 Гб, но лучше разнести PG и Сервер 1С по разным физическим серверам, конечно если имеется финансовая возможность).
48. XOCTEP 114 21.01.19 13:55 Сейчас в теме
(47) и (46) - спасибо за ответы!
40. starik-2005 1853 17.12.18 13:36 Сейчас в теме
(38)
Выходит такое сообщение при индексации:
На просторах интернетов есть вот такой интересный тред...
49. mirco 72 29.01.19 22:32 Сейчас в теме
(0)
pg_dump could not stat file unknown error
И это при --exclude-table-data=public.config
Подскажите куда копать
50. mirco 72 30.01.19 11:18 Сейчас в теме
(49)
))))
Вопрос отменяется... Просто не заметил еще одну большую табличку.
51. user1032109 09.04.19 10:29 Сейчас в теме
--command "COPY public.config TO '<имя каталога архива только с таблицей config с разделителями \\ для винды>' WITH BINARY;"
Кто может объяснить параметры?
52. user1032109 09.04.19 10:29 Сейчас в теме
--command "COPY public.config TO '<имя каталога архива только с таблицей config с разделителями \\ для винды>' WITH BINARY;"

Объясните пожалуйста параметры??
<имя каталога архива только с таблицей config с разделителями \\ для винды>
56. vsasav 424 09.04.19 20:01 Сейчас в теме
(52)
Вот пример ниже.

1. копируем таблицу public.config в файл c:\backup\config :

--command "COPY public.config TO 'c:\\backup\\config' WITH BINARY;"

2. восстанавливаем таблицу public.config из файла c:\backup\config :

--command "\COPY public.config FROM 'c:\\backup\\config' WITH BINARY;"
54. tolkit 09.04.19 12:02 Сейчас в теме
Спасибо за решение.

Ограничение Postgres в 1Гб также не дает обновить конфигурацию, которая находится на поддержке, из-за размера таблицы config.

Я не силен во внутреннем устройстве 1С, но получается, что можно снять с поддержки, обновиться, поставить на поддержку и загрузить изменения конфигурации как-то. Я сейчас на уровне проектирования решения. Вообще не уверен, что можно как-то объединить config до обновления и после.

Как вы обходите это? Или конфигурация на поддержке несовместима с Postgres, если размер больше 1ГБ?
55. vsasav 424 09.04.19 19:55 Сейчас в теме
Обошел просто. Перестал обновлять одну из конфигураций (от 1С), т.к. конфигурация с модулем от БИТ.ФИНАНС при обновлении вносила нужные изменения, хотя и с задержкой для пользователей. С поддержки 1С при этом не снимал.

В крайнем случае, можно попробовать накатить ваши изменения заново на свежий полный релиз от 1С, минимально снимая объекты с замка ("Поддержка с возможностью изменений"). Результат не гарантирован. Если полученный после объединения cf загрузить в рабочую базу, то объекты, случайно снятые с замка в рабочей базе встанут обратно на замок. А те, которые были в статусе "Поддержка с возможностью изменений" будут минимизированы.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Санкт-Петербург
Полный день

Программист 1С
Санкт-Петербург
Полный день

Консультант 1С
Нижний Новгород
зарплата до 100 000 руб.
Полный день


Программист 1С
Бобров
зарплата от 100 000 руб. до 150 000 руб.
Временный (на проект)