ResetMasterNode в 1С: сброс главного узла распределённой базы

ResetMasterNode — это параметр командной строки конфигуратора 1С, который сбрасывает назначение главного узла в распределённой информационной базе (РИБ). Он нужен, когда периферийная база «помнит», что у неё есть главный узел, но связь с ним потеряна: центральная база восстановлена из старой копии, пересоздана или узел обмена удалён. Без сброса такая база отказывается принимать конфигурацию и выгружать данные в новый узел.

Типичный признак ситуации — ошибки вида «Изменения конфигурации не могут быть получены из главного узла» или невозможность выполнить обмен, потому что в плане обмена зафиксирован главный узел, которого фактически больше нет. В этой ситуации есть два рабочих способа: запуск конфигуратора с параметром /ResetMasterNode и программный вызов метода ПланыОбмена.УстановитьГлавныйУзел(Неопределено).

Ниже разобраны оба варианта, порядок безопасного выполнения, проверка результата и случаи, когда сброс делать нельзя. Материал ориентирован на администраторов и разработчиков, работающих с РИБ на платформе 1С:Предприятие 8.

Что делает ResetMasterNode и когда он нужен

В распределённой информационной базе один узел назначается главным. Только из главного узла периферийная база может получать изменения конфигурации, и только главный узел может изменять структуру самой распределённой базы — создавать и удалять подчинённые узлы. Эта связь жёстко хранится внутри базы, и платформа контролирует её при каждом обмене.

Сброс главного узла разрывает эту связь: база становится «самостоятельной», в ней можно менять конфигурацию напрямую и заново назначать главный узел. Параметр ResetMasterNode не удаляет данные, не трогает планы обмена и не отменяет регистрацию изменений — он снимает только признак подчинённости конкретному главному узлу.

Практические сценарии, когда сброс оправдан:

• центральная база восстановлена из копии, сделанной до создания периферийного узла, и «не знает» о нём;
• главный узел в плане обмена был удалён или пересоздан с другим кодом;
• периферийную базу нужно превратить в самостоятельную или привязать к другой центральной базе;
• при загрузке сообщения обмена возникает ошибка несоответствия узлов, и узлы требуется переназначить.

Подготовка: что сделать до сброса

Сброс главного узла — операция, обратить которую напрямую нельзя: после неё базу придётся заново привязывать к узлу обмена, а зарегистрированные для старого узла изменения могут потерять смысл. Поэтому первый шаг всегда один — полная выгрузка информационной базы в файл .dt через конфигуратор (Администрирование → Выгрузить информационную базу) или пакетным запуском с параметром DumpIB.

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

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

Способ 1: запуск конфигуратора с параметром /ResetMasterNode

Основной способ — пакетный запуск конфигуратора. Для файловой базы команда выглядит так:

"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F"D:\Bases\Peripheral" /N"Администратор" /P"пароль" /ResetMasterNode

Для серверной базы вместо /F укажите параметры /S (сервер и имя базы в кластере):

"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /S"srv1c\MyBase" /N"Администратор" /P"пароль" /ResetMasterNode

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

1. 1
   Сделайте выгрузку базы в .dt и завершите все сеансы
2. 2
   Откройте командную строку от имени администратора
3. 3
   Выполните команду конфигуратора DESIGNER с параметром /ResetMasterNode
4. 4
   Дождитесь завершения без ошибок и откройте базу в конфигураторе
5. 5
   Проверьте, что конфигурация базы данных доступна для изменения
6. 6
   Назначьте главный узел заново или создайте начальный образ узла

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

Способ 2: программный сброс через УстановитьГлавныйУзел

Тот же результат даёт встроенный метод платформы ПланыОбмена.УстановитьГлавныйУзел(). Если передать в него Неопределено, подчинённость сбрасывается; если передать ссылку на узел плана обмена — этот узел назначается главным. Это удобнее, когда операцию нужно выполнить из обработки, внешнего инструмента или через COM-соединение без запуска конфигуратора.

// Сброс главного узла
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);

// Назначение нового главного узла
Узел = ПланыОбмена.Полный.НайтиПоКоду("ЦБ");
ПланыОбмена.УстановитьГлавныйУзел(Узел);

Код выполняется в монопольном режиме с полными правами — например, через внешнюю обработку, открытую в режиме предприятия, или через консоль кода. Перед выполнением действуют те же требования: резервная копия и отсутствие активных сеансов. Метод не выполняет обмен и не переносит данные — он только меняет служебную привязку базы к узлу.

Что делать после сброса: восстановление обмена

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

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

Типичные ошибки и ограничения

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

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

FAQ