При работе с крупными базами данных 1С (такими как УПП, ERP или КА) системные администраторы часто сталкиваются с проблемой при создании резервных копий средствами стандартной утилиты pg_dump. Проблема проявляется в виде ошибки invalid memory alloc request size. В этой статье мы подробно разберем, почему возникает эта ошибка, и рассмотрим проверенные способы её решения.
Разберем техническую сторону вопроса. Ошибка pg_dump: Сообщение об ошибке с сервера: ОШИБКА: invalid memory alloc request size возникает из-за внутреннего ограничения PostgreSQL. В этой СУБД максимальный размер одного блока памяти, который может быть выделен, составляет 1 ГБ. Таблица config в базах 1С хранит данные конфигурации, включая конфигурацию поставщика, в полях типа bytea.
Когда утилита pg_dump выполняет выгрузку, она преобразует бинарные данные (bytea) в текстовое представление (Escape или Hex). В процессе этого преобразования объем данных увеличивается в несколько раз. Если исходный размер конфигурации составляет, например, 600–700 МБ, то при конвертации в текст он превышает порог в 1 ГБ, что и приводит к аварийному завершению процесса. Проанализируем способы, которые позволяют обойти это ограничение.
Это классический и самый надежный способ, не требующий установки стороннего программного обеспечения. Суть метода заключается в том, чтобы выгрузить основную часть базы отдельно, а проблемную таблицу config — в бинарном виде, который не вызывает раздувания данных. Рассмотрим пошагово, как это реализовать.
Шаг 1. Создаем основной дамп базы данных без таблицы config.
Для этого используем ключ -T (или --exclude-table), чтобы исключить таблицу из общего потока выгрузки. Выполним команду:
pg_dump -h localhost -U postgres -Z 9 -T public.config -f /var/lib/postgresql/backups/main_data.dump.gz base_name
Здесь -Z 9 устанавливает максимальное сжатие, а base_name — имя вашей базы данных.
Шаг 2. Выгружаем схему (структуру) проблемной таблицы.
Нам нужно сохранить структуру таблицы config без самих данных, чтобы при восстановлении база знала, как создать эту таблицу. Используем ключ -s (schema-only) и -t (table):
pg_dump -h localhost -U postgres -t public.config -s -f /var/lib/postgresql/backups/config_schema.sql base_name
Шаг 3. Копируем данные таблицы config в бинарном виде.
Для этого воспользуемся командой COPY через psql. Бинарный режим (WITH BINARY) позволяет выгрузить данные «как есть», минуя преобразование в текст и обходя лимит в 1 ГБ:
psql -d base_name -c "COPY public.config TO '/var/lib/postgresql/backups/config_data.bin' WITH BINARY;"
Восстановление базы из такого разделенного дампа:
main_data.dump.gz).config, выполнив скрипт config_schema.sql.psql -d base_name -c "COPY public.config FROM '/path/to/config_data.bin' WITH BINARY;".Если ручной метод кажется слишком трудоемким, рассмотрим использование утилиты pg_dumpbinary. Она специально разработана для обхода проблем с большими полями bytea, так как выгружает все данные в бинарном формате по умолчанию.
Настройка аутентификации
Чтобы утилита работала в автоматическом режиме без запроса пароля, создадим файл .pgpass в домашней директории пользователя postgres:
# формат: hostname:port:database:username:password
localhost:5432:*:postgres:vash_parol
Обязательно установим права доступа chmod 0600 ~/.pgpass, иначе PostgreSQL проигнорирует этот файл в целях безопасности.
Процесс создания бэкапа:
Переходим в директорию, куда будет осуществляться выгрузка (это важно для корректного создания мета-файлов), и запускаем процесс:
cd /opt/backups/
pg_dumpbinary -d base_name -j 2 /opt/backups/full_binary_backup
Параметр -j 2 позволяет выполнять выгрузку в два потока, что значительно ускоряет процесс для больших баз.
Восстановление данных через pg_restorebinary:
Выясним, как правильно восстановить базу. Если вы столкнулись с ошибкой pg_restore error to obtain dump information, убедитесь, что вы указываете полный путь к директории с бэкапом и что у пользователя postgres есть права на чтение всех файлов внутри нее.
createdb new_base_name
pg_restorebinary -d new_base_name -j 2 /opt/backups/full_binary_backup
Рассмотрим еще несколько вариантов, которые могут помочь в долгосрочной перспективе:
pg_dump становится неэффективным. Рекомендуем использовать pg_basebackup или инструменты типа WAL-G. Они копируют файлы данных напрямую, и им не страшны ограничения на размер строк в SQL-запросах.config был изменен — теперь данные разбиваются на небольшие фрагменты (чанки). Если обновить платформу и режим совместимости, проблема с pg_dump может исчезнуть сама собой, так как огромных строк в базе больше не будет.pg_dump, что позволяет выгружать «тяжелые» таблицы без дополнительных манипуляций.Важное замечание по таблице config: Иногда 1С-программисты предлагают удалить конфигурацию поставщика, чтобы уменьшить размер таблицы. Мы не рекомендуем этот метод без крайней необходимости, так как это значительно усложнит процесс последующих обновлений программы 1С. Лучше воспользоваться методом бинарного копирования, описанным выше.
Таким образом, мы рассмотрели основные способы решения проблемы с выгрузкой больших баз 1С. Выбор метода зависит от ваших навыков администрирования и критичности времени простоя базы при восстановлении. Самым универсальным для Linux-систем остается Метод 1 благодаря своей простоте и отсутствию внешних зависимостей.