1С РИБ: как отключить главный узел и переназначить его роль

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

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

Ниже разобраны рабочие сценарии: штатная смена главного узла, аварийное восстановление, отключение подчинённого узла от РИБ и удаление узла из плана обмена. Все действия описаны для типовых конфигураций на управляемых формах, но логика справедлива и для обычного приложения.

Как устроены роли узлов в РИБ и что значит «отключить главный узел»

В распределённой базе ровно один узел является главным (корневым), остальные — подчинёнными. Главный узел хранит эталонную конфигурацию, распространяет её изменения по подчинённым узлам через сообщения обмена и определяет состав узлов плана обмена. Подчинённый узел «знает» своего главного — эта связь хранится в самой информационной базе и сопровождается блокировкой изменения конфигурации.

Под формулировкой «отключить главный узел» на практике скрываются четыре разные задачи:

• передать роль главного узла другой базе (сервер переезжает, центральный узел выводится из работы);
• сделать подчинённый узел самостоятельной базой, не связанной с РИБ;
• удалить узел из плана обмена, исключив его из обмена;
• восстановить работу РИБ после потери главного узла.

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

Подготовка: что сделать до изменения ролей узлов

Любые операции со структурой РИБ необратимы в том смысле, что откатить их штатными средствами нельзя — только восстановлением из копии. Поэтому подготовка занимает больше времени, чем сама операция.

1. 1
   Создайте полные резервные копии главного и всех подчинённых узлов (выгрузка в dt или копия средствами СУБД)
2. 2
   Выполните обмен данными со всеми узлами, чтобы очереди сообщений были пустыми
3. 3
   Убедитесь, что все подчинённые узлы получили и загрузили актуальную конфигурацию — версии конфигураций должны совпадать
4. 4
   Завершите работу пользователей в изменяемых базах и запретите новые сеансы
5. 5
   Проверьте, что у вас есть права администратора в обеих базах и доступ к конфигуратору

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

Сценарий 1: штатная передача роли главного узла другой базе

Штатный механизм смены главного узла в типовых конфигурациях не предусмотрен как отдельная операция — роль главного определяется тем, какая база является корневой. Фактически передача роли выполняется через превращение одного из подчинённых узлов в самостоятельную базу, которая затем становится центром новой РИБ, либо через развёртывание копии главного узла на новом сервере.

Перенос главного узла на новый сервер

Самый частый случай — центральная база переезжает на другое оборудование. Здесь роли менять не нужно: достаточно создать выгрузку главного узла (dt) или копию средствами СУБД, развернуть её на новом сервере и перенастроить пути обмена (каталоги обмена, FTP или веб-сервисы) в подчинённых узлах. Главным останется тот же логический узел, просто физически расположенный в другом месте.

Смена главного узла через конфигуратор

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

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

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

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

Сценарий 2: отключение подчинённого узла от РИБ

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

В главном узле откройте список узлов плана обмена (раздел «Синхронизация данных» — «Настройки синхронизации» или соответствующий план обмена в конфигураторе) и удалите нужный узел. После этого главная база перестанет формировать для него сообщения обмена. Сам физический файл базы подчинённого узла при этом не удаляется.

В подчинённой базе выполните ПланыОбмена.УстановитьГлавныйУзел(Неопределено) — это снимет блокировку конфигурации и сделает базу независимой. После этого её можно обновлять и дорабатывать как обычную базу. Данные, накопленные к моменту отключения, сохраняются полностью.

Сценарий 3: главный узел потерян — аварийное восстановление

Если главный узел недоступен из-за аварии и резервной копии нет, единственный путь — «повысить» один из подчинённых узлов до самостоятельной базы описанным выше способом и перестроить РИБ вокруг него. Выбирайте узел с самой полной и актуальной информацией: сравните даты последних успешных обменов и объём данных по ключевым разделам учёта.

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

Проверка результата после изменения ролей

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

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

Типичные ошибки при отключении главного узла

Ограничения и когда лучше привлечь специалиста

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

Помните и об ограничении самой платформы: один узел не может быть подчинён сразу двум главным, а кольцевые и дублирующие связи в РИБ не поддерживаются. Если требуется сложная схема обмена между равноправными базами, рассмотрите альтернативу — стандартную синхронизацию данных между отдельными базами вместо распределённой.

Частые вопросы