При администрировании баз данных 1С на платформе PostgreSQL (особенно версий от Postgres Pro с патчами для 1С) специалисты часто сталкиваются со специфическими проблемами. Одной из наиболее острых является восстановление базы из дампа в уже существующую структуру. Использование стандартных ключей очистки приводит к конфликтам с внутренними типами данных 1С, такими как mvarchar, а активные соединения со стороны кластера 1С блокируют операции удаления и модификации таблиц.
В этой статье мы подробно разберем, как автоматизировать процесс создания резервных копий, как обойти типичные ошибки при восстановлении и внедрим алгоритм безопасной замены рабочей базы данных без риска потери информации.
Разберем ситуацию: при выполнении команды pg_dump с ключом --clean генерируется SQL-скрипт, содержащий команды DROP для всех объектов. Однако в сборках PostgreSQL, оптимизированных под 1С, существуют системные типы данных (mvarchar, mchar, mvarchar_hash), которые создаются патчами в схеме public. Попытка их удаления или повторного создания в процессе загрузки дампа через psql вызывает ошибку: «тип "public.mvarchar" не существует» или конфликты зависимостей.
Это происходит потому, что pg_dump не всегда корректно определяет эти типы как системные зависимости. Выясним причину: при использовании ключа --clean утилита пытается «вычистить» базу до основания, но структура 1С настолько тесно переплетена с этими типами, что стандартный механизм очистки ломается. Проанализируем способы обхода этой проблемы.
Вместо использования проблемного ключа --clean в pg_dump, рассмотрим более надежный метод подготовки существующей базы — полное удаление и пересоздание схемы public. Это позволяет сбросить все таблицы, индексы и вьюхи, не затрагивая саму базу данных на уровне системного каталога кластера СУБД.
Для этого перед началом восстановления базы выполним следующий набор команд через psql:
-- Принудительно удаляем схему со всеми объектами
DROP SCHEMA public CASCADE;
-- Создаем чистую схему
CREATE SCHEMA public;
-- Назначаем права (важно для корректной работы 1С)
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO public;
Этот подход гарантирует, что в базе не останется «хвостов» от старых данных, и при этом специфические типы 1С, если они прописаны на уровне расширений или системных зависимостей, будут обработаны корректно при последующей загрузке данных.
Если нам критически важна отказоустойчивость, разберем по шагам алгоритм «безопасной подмены». Его суть заключается в том, что мы не трогаем рабочую базу до тех пор, пока не убедимся, что архив успешно развернут в промежуточной емкости. Посмотрим, как это реализовать программно.
Шаг 1. Создание резервной копии. Используем формат plain (текстовый SQL) или custom (сжатый бинарный формат). Формат custom предпочтительнее для крупных баз, так как позволяет выполнять восстановление в несколько потоков.
pg_dump.exe --host="HOST" --port=5432 --username="postgres" --format=custom --blobs --dbname="WorkBase" --file="backup.dump"
Шаг 2. Подготовка временной базы. Создаем новую пустую базу в СУБД, в которую будем заливать архив.
createdb.exe --encoding=utf8 --template=template1 --username="postgres" temp_restore_db
Шаг 3. Загрузка данных. Восстанавливаем дамп во временную базу. Проанализируем использование ключа --single-transaction: он позволяет выполнить восстановление как одну операцию, что гарантирует целостность (либо всё, либо ничего).
pg_restore.exe --dbname=temp_restore_db --username="postgres" --single-transaction --exit-on-error "backup.dump"
Шаг 4. Управление сессиями и кластером 1С. Прежде чем переименовывать базы, необходимо разорвать все соединения. Рассмотрим, как это сделать на стороне PostgreSQL, чтобы не зависеть от зависших сессий в консоли администрирования 1С:
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'WorkBase' AND pid <> pg_backend_pid();
После этого программно (через COM-соединение или AdminStation) в кластере 1С следует временно очистить свойство «Имя базы данных», чтобы кластер «отпустил» ресурс.
Шаг 5. Ротация баз. Переименовываем старую рабочую базу в архивную, а новую (восстановленную) — в рабочую.
ALTER DATABASE "WorkBase" RENAME TO "WorkBase_Old";
ALTER DATABASE "temp_restore_db" RENAME TO "WorkBase";
Этот метод позволяет в любой момент «откатиться» назад, просто переименовав базы обратно, если проверка данных после восстановления выявит ошибки.
Выясним причину, почему DROP DATABASE часто не срабатывает. Кластер 1С постоянно держит пул соединений. Даже если вы выгнали пользователей, регламентные задания могут мгновенно переподключиться. Для полной автоматизации процесса восстановления в скриптах администрирования рекомендуется использовать принудительный разрыв соединений именно на уровне СУБД, как показано в примере выше.
Также важно помнить про расширения (Extensions). Некоторые конфигурации 1С требуют наличия расширения fasttrun. При создании новой базы через createdb убедитесь, что в template1 (шаблоне, на основе которого создаются новые базы) уже установлены все необходимые расширения, иначе psql выдаст ошибку при попытке обращения к соответствующим функциям.
Проанализируем ситуацию, когда база 1С имеет размер в несколько сотен гигабайт. Восстановление через psql из plain sql файла может занять десятки часов. Посмотрим на методы ускорения процесса:
pg_restore с ключом -j N, где N — количество ядер процессора. Это возможно только при использовании формата дампа -Fc (custom).fsync = off и full_page_writes = off. Это значительно снизит нагрузку на дисковую подсистему, так как СУБД перестанет подтверждать запись каждой порции данных на физический носитель в реальном времени.maintenance_work_mem на время восстановления. Это ускорит создание индексов, которые 1С создает в огромном количестве после загрузки самих данных в таблицы.Пример команды для быстрого многопоточного восстановления:
pg_restore -h localhost -U postgres -d WorkBase -j 4 -v "C:\backups\1c_prod.dump"
Подводя итог, можно сказать, что для создания надежной системы резервного копирования 1С на PostgreSQL не стоит полагаться на стандартный ключ --clean из-за особенностей типов mvarchar. Рассмотрим основные правила качественного бэкапа:
public после её пересоздания или создания новой БД.LC_COLLATE = 'Russian_Russia.1251' (или аналогичной для вашей ОС) и кодировкой UTF8.Использование предложенных скриптов и алгоритмов позволит вам создать профессиональный инструмент для администрирования 1С, который минимизирует время простоя системы при сбоях или плановых обновлениях.