Возможно ли развернуть хранилище 1С на SQL и как правильно настроить сервер хранилищ разных версий

При организации совместной разработки в среде 1С:Предприятие рано или поздно встает вопрос надежности и масштабируемости основного инструмента коллективной работы — Хранилища конфигурации. Стандартный файловый доступ через общий сетевой ресурс (так называемую «файловую помойку») часто приводит к сбоям, зависаниям и даже повреждению базы данных хранилища при сетевых колебаниях или большом количестве разработчиков. Естественным желанием системных администраторов и ведущих разработчиков становится перенос хранилища на СУБД (например, MS SQL Server или PostgreSQL).

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

Почему хранилище 1С нельзя развернуть напрямую в SQL

Архитектура платформы «1С:Предприятие» жестко определяет формат Хранилища конфигурации. Технически оно всегда представляет собой базу данных собственного файлового формата 1С с расширением 1Cv8ddb.1CD. Структура этого файла низкоуровнево оптимизирована именно под хранение версий метаданных и их сборку.

Фирма «1С» не предоставляет и не планирует реализовывать механизмы хранения метаданных репозитория в таблицах реляционных СУБД. Напрямую развернуть базу хранилища на SQL-сервере невозможно.

Однако знание структуры хранения ИБ в MS SQL может помочь в критической ситуации. Если связь с хранилищем аварийно прервалась и рабочая база заблокировалась (при попытке входа возникает ошибка «Нарушена целостность структуры конфигурации»), администраторы могут принудительно «отвязать» информационную базу от хранилища прямо через СУБД. Для этого выполним следующий запрос:

DELETE FROM [Имя_Базы].[dbo].[Files] WHERE [FileName] LIKE '%depot%'

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

Альтернативный путь разработки: Переход на 1C:EDT и Git

Если ваша цель — полностью уйти от устаревших файловых технологий ведения истории разработки, то современным промышленным стандартом является переход на среду разработки 1C:EDT (Enterprise Development Tools) в связке с распределенной системой контроля версий Git.

При такой схеме:

1. Каждый разработчик работает со своей локальной копией кода в EDT.
2. Вся история изменений, ветвление и слияние происходят в репозитории Git.
3. Центральный сервер управления репозиториями (например, корпоративный GitLab, GitHub или Gitea) разворачивается с полноценным использованием СУБД (PostgreSQL, MS SQL) для хранения метаданных, задач, истории коммитов, прав доступа и пулл-реквестов.

Это полностью решает проблему надежности файловых хранилищ, обеспечивает непрерывную интеграцию (CI/CD) и исключает монопольные захваты объектов.

Сервер хранилища 1С (crserver) — компромисс между файлами и надежностью

Если ваша команда пока не готова к переходу на 1C:EDT и Git, оптимальным решением станет отказ от прямого доступа к файлу хранилища через сетевую папку (SMB) и переход на использование специальной службы — Сервера хранилища конфигурации (crserver.exe).

В этом сценарии база хранилища физически остается файловой, но к ней обращается только один процесс — служба crserver.exe. Разработчики подключаются к службе по протоколам TCP или HTTP/HTTPS. Это решает главные проблемы:

• Исключаются сетевые сбои при записи в файлы напрямую с рабочих станций.
• Появляется возможность безопасной работы удаленных разработчиков без использования медленных VPN/SMB-подключений.
• Повышается скорость обновления и помещения объектов.

Инструкция по развертыванию нескольких служб crserver разных версий на одном сервере

Часто в крупных компаниях возникает ситуация: один важный проект работает на платформе версии 8.3.21, а новый проект стартует на платформе версии 8.3.24. Попытка установить обе службы хранилища стандартными методами установщика 1С приводит к конфликту — одна служба принудительно останавливает другую, так как по умолчанию они претендуют на один и тот же системный порт (1542) и имя службы.

Выясним, как запустить параллельно несколько служб сервера хранилища разных версий.

Решение для операционной системы Windows

Для реализации этой задачи нам потребуется зарегистрировать новые уникальные службы в операционной системе вручную с помощью утилиты командной строки sc.exe. Разберем процесс по шагам.

1. Запустим командную строку (cmd) от имени Администратора.
2. Зарегистрируем первую службу (для платформы 8.3.21) на порту 1543, указав уникальный рабочий каталог для баз хранилищ этой версии:
   Скопировать код

   
   sc create "1C_Repository_8.3.21" binPath= "\"C:\Program Files\1cv8\8.3.21.1302\bin\crserver.exe\" -srvc -port 1543 -d \"D:\Repository_8321\"" DisplayName= "1C Configuration Repository Server 8.3.21" start= auto
   

3. Зарегистрируем вторую службу (для платформы 8.3.24) на порту 1544 и укажем другой рабочий каталог:
   Скопировать код

   
   sc create "1C_Repository_8.3.24" binPath= "\"C:\Program Files\1cv8\8.3.24.1691\bin\crserver.exe\" -srvc -port 1544 -d \"D:\Repository_8324\"" DisplayName= "1C Configuration Repository Server 8.3.24" start= auto
   

Важное примечание по синтаксису утилиты sc: после знака равенства (например, binPath=, start=) обязательно должен идти пробел. Все внутренние кавычки в путях должны быть экранированы обратным слэшем (\").

Решение для операционной системы Linux

На операционных системах семейства Linux для управления службами используется systemd. Создадим шаблон службы, который позволит параметризовать запуск разных версий серверов хранилища.

Создадим файл конфигурации службы /etc/systemd/system/crs1cv83@.service со следующим содержимым:

[Unit]
Description=1C:Enterprise Configuration Repository Server (%i)
After=network.target

[Service]
Type=simple
User=usr1cv8
EnvFile=/etc/default/crs1cv83@%i
ExecStart=/bin/sh -c "/opt/1cv8/x86_64/%i/crserver -port ${CRS1CV8_PORT} -d ${CRS1CV8_DATA}"
Restart=always

[Install]
WantedBy=multi-user.target

Теперь для каждого релиза платформы достаточно создать простой конфигурационный файл параметров среды. Например, для версии 8.3.24.1691 создадим файл /etc/default/crs1cv83@8.3.24.1691:

CRS1CV8_PORT=1544
CRS1CV8_DATA=/var/1c/repository_8324

После этого обновим конфигурацию демонов и запустим соответствующую службу:

systemctl daemon-reload
systemctl enable crs1cv83@8.3.24.1691
systemctl start crs1cv83@8.3.24.1691

Настройка HTTP/HTTPS доступа через веб-сервер (IIS) для нескольких версий хранилища

Для того чтобы разработчики могли подключаться к хранилищам через стандартный веб-протокол, настроим веб-сервер IIS. Главное правило безопасности и стабильности в этом случае — разнесение пулов приложений.

Проанализируем пошаговый алгоритм настройки на IIS:

1. Откроем Диспетчер служб IIS.
2. Создадим два разных пула приложений: 1C_Repo_Pool_8321 и 1C_Repo_Pool_8324. Поскольку IIS будет использовать разные библиотеки 1С для работы с веб-расширениями хранилища, запуск их в одном пуле приведет к конфликту версий в памяти процесса w3wp.exe.
3. Для каждого пула приложений в дополнительных параметрах установим разрешение на использование 32-битных приложений (при необходимости) и убедимся, что пулы работают под учетной записью, имеющей права доступа к каталогам с базами хранилищ.
4. Создадим на веб-сервере два виртуальных каталога, указывающих на стандартный обработчик хранилища 1С.
5. Внутри каждого виртуального каталога создадим файл конфигурации удаленного репозитория с расширением .1ccr.

Для первой версии (8.3.21) в файле repo.1ccr пропишем перенаправление на локальный TCP-порт созданной нами ранее службы:

<?xml version="1.0" encoding="UTF-8"?>
<repository connectString="tcp://localhost:1543"/>

Для второй версии (8.3.24) в соответствующем файле repo.1ccr укажем порт второй службы:

<?xml version="1.0" encoding="UTF-8"?>
<repository connectString="tcp://localhost:1544"/>

Теперь разработчики смогут подключаться к своим хранилищам через адреса вида http://имя_сервера/repo_8321/repo.1ccr/ИмяХранилища и http://имя_сервера/repo_8324/repo.1ccr/ИмяХранилища соответственно.

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