← На главную

Рассмотрим ситуацию, с которой иногда сталкиваются системные администраторы при переходе с одной версии платформы на другую. Например, у нас была рабочая база на платформе 1С:Предприятие 8.2. Мы установили сервер 1С 8.3 и в его консоли создали информационную базу, указав ссылку на ту же самую физическую базу MS SQL, с которой продолжает работать сервер 8.2. На первый взгляд, на тестовом стенде всё может работать, но проанализируем, к каким фатальным последствиям это приведет в продуктивной среде и какие подводные камни скрывает такая архитектура.

Официальная позиция 1С и главная опасность

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

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

Детальные причины проблем и скрытые ограничения архитектуры

1. Изолированность серверных кэшей

Каждый кластер серверов (в нашем примере и 8.2, и 8.3) поддерживает собственный независимый кэш метаданных и объектных данных. Если пользователь, подключенный через сервер 8.3, изменит и запишет документ, сервер 8.2 об этом никак не узнает. При следующем обращении пользователя через сервер 8.2 платформа выдаст ему устаревшие данные из своего локального кэша, а при попытке их записать — затрет новые данные, сохраненные первым пользователем. Будут возникать ошибки сырого чтения данных и нарушения атомарной целостности транзакций.

2. Конфликт механизмов блокировок

Сервер 1С управляет пессимистическими блокировками объектов на уровне приложения (например, когда пользователь открывает форму документа). Если два пользователя зайдут в одну и ту же базу, но через разные серверы (один через 8.2, другой через 8.3), они будут "слепы" по отношению к сеансам друг друга. Платформа позволит им одновременно открыть и редактировать один и тот же объект. Сообщение «Объект заблокирован пользователем...» не появится. Запись данных одним поверх другого неизбежна, а менеджер управляемых блокировок будет работать некорректно.

3. Дублирование регламентных и фоновых заданий

Если расписание фоновых заданий активно, оба кластера начнут параллельно инициировать выполнение одних и тех же регламентных процедур. Разберем, к чему это приведет:

1. Запуск дублей обменов данными с другими системами.
2. Задвоение автоматически создаваемых документов.
3. Двойное списание по регистрам накопления или бухгалтерии.
4. Возникновение тяжелейших конфликтов (Deadlocks) на уровне SQL-сервера из-за одновременной записи в одни и те же таблицы.

4. Разделение журнала регистрации и поломка поиска

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

Альтернативные (безопасные) варианты решения задачи

Если вам нужно протестировать работу базы на новой платформе (например, перед обновлением), рассмотрим правильные подходы:

1. Работа с копией на уровне СУБД. Единственный корректный способ — сделать полный бекап SQL-базы (.bak) и развернуть его рядом под другим именем (например, Base_Test_83). В кластере 8.3 создайте новую информационную базу, которая будет ссылаться только на эту независимую копию.
2. Разделение портов кластеров (на одном физическом сервере). Если вы хотите запустить службы серверов 8.2 и 8.3 на одной машине, разнесите их по разным сетевым портам. Службе 8.2 оставьте стандартные порты (1540, 1541, 1560-1591), а при установке 8.3 укажите альтернативный диапазон (например, 2540, 2541, 2560-2591). Но помните: в консолях этих кластеров должны быть прописаны разные базы данных SQL.
3. Запрет работы пользователей через старый кластер. Если вы осуществляете боевой переход, необходимо предварительно удалить базу из кластера 8.2 (или полностью остановить службу старого сервера), и только после этого прописывать её в кластере 8.3.

Как восстановить базу, если эксперимент уже привел к сбоям

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

1. Отключите один из серверов. Строго изолируйте базу, оставив подключение только через один кластер (рекомендуется целевой, новый).
2. Очистка кэша. Выполните полную очистку папок с сеансовыми данными и серверным кэшем в каталоге кластера серверов, так как там могла «застрять» сломанная структура метаданных.
3. ТИИ (Тестирование и исправление). Выполните монопольный запуск Конфигуратора и запустите «Тестирование и исправление информационной базы». Обязательно отметьте проверку логической и ссылочной целостности, а также полный пересчет итогов.
4. Проверка на уровне SQL. Используйте средства проверки самой СУБД. Выполните команду DBCC CHECKDB, так как одновременная запись могла повредить индексы SQL-таблиц.

Важно: Если параллельная работа привела к фатальному разрушению структуры таблиц (что вполне вероятно), поможет только восстановление из последней исправной резервной копии.