Что произойдет при одновременном подключении двух серверов 1С к одной базе SQL и как исправить последствия?

В практике системного администрирования иногда возникает ситуация, когда при миграции с одной версии платформы на другую (например, при переходе с релиза 8.2 на 8.3) администраторы временно оставляют активными оба сервера приложений 1С, направленными на одну и ту же базу данных в СУБД. Мотивом обычно служит желание обеспечить непрерывность работы пользователей, пока клиентские приложения обновляются постепенно. Однако в результате администраторы сталкиваются со сбоями бизнес-логики: слетает автонумерация, зависают сеансы, задваиваются регламентные задания.

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

Официальная позиция фирмы 1С и архитектура взаимодействия

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

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

Какие службы кластера дают сбой в первую очередь

Рассмотрим сервисы кластера, которые выделяются платформой строго по принципу «один сервис на одну информационную базу», и выясним, к чему приводит их дублирование:

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

Скрытые последствия для данных и СУБД

Помимо явных ошибок интерфейса, параллельная работа двух серверов (в особенности разных версий, таких как 8.2 и 8.3) создает скрытые угрозы целостности базы данных:

1. Рассинхронизация серверного кэша метаданных. Процессы rphost кэшируют в оперативной памяти константы, параметры функциональных опций и схемы таблиц. Изменения, внесенные через один сервер, второй сервер не увидит до перезапуска своих процессов. Возникает эффект «фантомного чтения», когда запись перезаписывается устаревшими данными из кэша.
2. Искажение итогов регистров. Механизм управления итогами регистров накопления и бухгалтерии рассчитывает остатки на определенные даты среза. При параллельном смещении границы итогов двумя серверами табличные итоги рассинхронизируются, что ведет к некорректным движениям при контроле остатков.
3. Конфликты фоновых и регламентных заданий. Планировщики заданий на обоих серверах запускают задачи независимо. В результате регламентные процедуры (закрытие месяца, расчет себестоимости, обмен данными с внешними системами) запускаются дважды, вызывая дублирование проводок и блокировки.
4. Различия внутренних форматов версий 8.2 и 8.3. Платформы используют разные форматы служебных таблиц (Config, Params), механизмы сериализации и генерации временных таблиц SQL. Попытка сервера 8.2 работать со структурами, модифицированными сервером 8.3, может нарушить физическую целостность конфигурации.

Пошаговый регламент восстановления базы после сбоя

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

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

Шаг 2. Восстановление автонумерации документов. Для устранения сбоев нумерации документов и кодов справочников воспользуемся встроенной процедурой глобального контекста. Выполним программный пересчет в контексте внешней обработки или сеанса с административными правами:

// Восстановление механизма автонумерации для метаданных конфигурации
ОбновитьНумерациюОбъектов();

Метод ОбновитьНумерациюОбъектов() выполняет сброс внутренних счетчиков номеров в кэше и заново определяет максимальный существующий номер в таблицах базы данных для всех типов объектов. Если сбой затронул конкретный вид документов, передайте в процедуру метаданные этого объекта:

// Сброс и актуализация нумератора для конкретного документа
ОбновитьНумерациюОбъектов(Метаданные.Документы.РеализацияТоваровУслуг);

Шаг 3. Очистка кэша сервера приложений. Остановите службу рабочего сервера 1С. В каталоге данных кластера (по умолчанию srvinfo) удалите кэш метаданных и сеансовых данных. Это гарантирует, что рабочие процессы не поднимут в память устаревшие структуры.

Шаг 4. Проверка целостности на уровне СУБД. До запуска пользователей выполните служебную проверку средствами СУБД, чтобы убедиться в отсутствии повреждений страниц данных. Для MS SQL Server выполним команду:

DBCC CHECKDB (ИмяБазыДанных) WITH NO_INFOMSGS, ALL_ERRORMSGS;

Шаг 5. Полный пересчет итогов регистров. Перейдите в режим «1С:Предприятие» под учетной записью администратора. Откройте стандартную обработку управления итогами (или используйте процедуру в конфигураторе) и выполните полный пересчет итогов по всем регистрам накопления и бухгалтерии.

Шаг 6. Тестирование и исправление в конфигураторе. Запустите конфигуратор в монопольном режиме и откройте меню Администрирование -> Тестирование и исправление... Отметьте следующие обязательные пункты:

1. Реиндексация таблиц информационной базы;
2. Проверка логической целостности информационной базы;
3. Проверка ссылочной целостности информационной базы;
4. Пересчет итогов;
5. Реструктуризация таблиц информационной базы.

Шаг 7. Сброс индекса полнотекстового поиска. Поскольку поисковые индексы на серверах разделились, выполните программную или интерактивную очистку индекса полнотекстового поиска через меню администрирования, после чего запустите полное обновление индекса через регламентное задание ОбновлениеИндексаППД.

Корректные альтернативы для плавного обновления

Чтобы избежать одновременного подключения разных платформ к единой базе в будущем, разберем штатные архитектурные сценарии перевода пользователей:

1. Публикация на веб-сервере. Опубликуйте базу данных через IIS или Apache на актуальной версии платформы 8.3. Пользователи смогут мгновенно подключиться через веб-браузер или тонкий клиент без необходимости локального обновления толстых клиентов на рабочих местах.
2. Централизованное распространение платформы. Используйте политики домена (GPO) или распространение инсталляторов через общие сетевые каталоги. Новая версия платформы может быть установлена на клиентские ПК параллельно со старой заранее, до момента переключения службы сервера 1С.
3. Кластеризация при распределении нагрузки. Если требуется распределить нагрузку на несколько физических серверов, формируйте единый кластер 1С с требованиями назначения функциональности. Все серверы кластера обязаны работать под управлением строго одной и той же сборки платформы.