← На главную

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

Выясним причину: архитектура подключения информационных баз к СУБД

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

1. Имя информационной базы в кластере — логическое имя, которое отображается в списке кластера и к которому подключаются клиентские приложения.
2. Сервер баз данных — сетевой адрес или имя экземпляра СУБД (например, MS SQL Server, PostgreSQL, Oracle Database).
3. Имя базы данных в СУБД — фактическое имя физической базы данных на стороне СУБД.

Если при создании копии информационной базы указать новое уникальное имя в кластере (например, Work_Copy), но в поле имени базы данных СУБД ошибочно оставить или заново вписать имя рабочей базы (например, Work_DB), обе записи кластера 1С будут ссылаться на одни и те же физические таблицы на сервере СУБД.

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

Технические риски подключения нескольких баз 1С к одной базе СУБД

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

1. Рассинхронизация серверного кэша и транзакционных блокировок. Сервер 1С:Предприятия кэширует структуру метаданных, информацию о сеансах, нумераторы и транзакционные блокировки в оперативной памяти рабочих процессов rphost. При наличии двух баз в кластере (или на разных физических серверах 1С) их кэши работают изолированно. Это вызывает конфликты транзакций, взаимоблокировки (deadlocks) и чтение устаревших данных пользователями.
2. Повреждение структуры конфигурации. При динамическом обновлении, смене режима совместимости или сохранении конфигурации одной базы процесс 1С перезаписывает системные таблицы Config и ConfigSave в СУБД. Вторая база не получает оповещения об этих изменениях, что приводит к критическим ошибкам (например, «Ошибка формата потока») и нарушению целостности метаданных.
3. Дублирование выполнения регламентных и фоновых заданий. Если в обеих базах в кластере включено выполнение регламентных заданий, планировщики каждого экземпляра будут независимо запускать фоновые процессы. Это приводит к повторному формированию проводок, дублированию расчетов, повторной отправке писем, сообщений клиентам и сбоям в интеграционных обменах.

Рекомендации по предотвращению ошибок и правильному созданию копий

Разберем по шагам правила безопасного развертывания тестовых копий и разделения сред:

1. Разграничение прав на уровне сервера СУБД. Для каждой информационной базы 1С необходимо создавать отдельного пользователя в СУБД с правами владельца (роль db_owner в MS SQL Server или владелец схемы в PostgreSQL) строго на целевую базу данных. В этом случае, если администратор случайно укажет имя рабочей базы при создании копии, сервер СУБД заблокирует подключение из-за нехватки прав у сервисной учетной записи.
2. Использование автоматизации вместо ручного ввода. Рекомендуется создавать тестовые копии с помощью сценариев автоматизации (используя утилиту rac / ras, скрипты PowerShell или Bash). Автоматизация гарантирует создание новой физической базы данных в СУБД и корректную привязку параметров в кластере без риска человеческого фактора.
3. Обязательная блокировка регламентных заданий и сеансов. При создании любой копии базы данных (даже на отдельном сервере) необходимо сразу устанавливать защитные параметры в свойствах информационной базы:
   1. Включить флаг «Блокировка регламентных заданий включена»;
   2. Включить флаг «Блокировка начала сеансов включена».
4. Проверка параметров перед началом работы. Перед внесением структурных изменений в конфигурацию всегда проверяйте фактическую строку соединения через меню Справка -> О программе или глобальное свойство СтрокаСоединенияИнформационнойБазы().