Администрирование · 11 мин
Как отвязать базу 1С от РИБ
Как отвязать базу 1С от РИБ: снятие признака главного и подчинённого узла через конфигуратор, обработки и запросы. Риски, проверка результата, типичные ошибки.
Распределённая информационная база (РИБ) связывает узлы жёсткой иерархией: у каждой базы есть роль главного или подчинённого узла, и платформа блокирует действия, нарушающие эту структуру. Пока база считает себя частью РИБ, в ней нельзя свободно менять конфигурацию, обновляться вручную и работать как с обычной автономной базой. Поэтому задача «отвязать базу от РИБ» возникает регулярно: при выводе филиала из обмена, восстановлении копии для тестов, переходе на другой механизм синхронизации.
Суть отвязки — снять с базы признак принадлежности к распределённой системе. Технически это делается двумя способами: штатной командой в конфигураторе или программным сбросом главного узла через встроенный язык. Оба варианта рабочие, но у каждого есть условия применения и последствия, которые нужно понимать до начала работы.
Главное правило безопасности: любые манипуляции с привязкой к РИБ выполняются только после создания резервной копии. Отвязка — операция необратимая в том смысле, что обратно «приклеить» базу к той же РИБ без повторной инициализации уже не получится. Связь узлов придётся создавать заново с полной начальной выгрузкой.
Когда отвязка от РИБ действительно нужна
Не каждая проблема с обменом требует отвязки базы. Часто достаточно перерегистрировать изменения или восстановить нумерацию сообщений. Отвязка оправдана в ограниченном наборе ситуаций, и важно отличать их от обычных сбоев синхронизации.
Типичные обоснованные сценарии: филиал закрывается и его база должна жить автономно; тестовая копия подчинённого узла мешает работе, требуя обмена с главным узлом; главный узел потерян безвозвратно, и подчинённый нужно сделать самостоятельным; компания отказывается от РИБ в пользу другого механизма обмена, например через EnterpriseData или веб-сервисы.
Как выбрать действие
Подготовка: что сделать до отвязки
Первый шаг — полная резервная копия. Для файловой базы достаточно скопировать каталог с файлом 1Cv8.1CD при остановленной работе пользователей. Для клиент-серверной базы делайте выгрузку в dt через конфигуратор или средствами СУБД. Копия должна быть проверена на восстановление, а не просто лежать в папке.
Второй шаг — завершить все сеансы пользователей и фоновые задания. Отвязка при активных сеансах может пройти некорректно или быть заблокирована. В конфигураторе проверьте список активных пользователей, в клиент-серверном варианте — консоль кластера.
Третий шаг — зафиксировать текущее состояние обмена. Сохраните скриншоты или выгрузите список узлов плана обмена, номера отправленных и принятых сообщений. Если отвязка выполняется по ошибке и структуру придётся восстанавливать, эта информация сэкономит часы работы.
Способ 1: отвязка через конфигуратор
Штатный путь подходит, когда база открывается в конфигураторе без ошибок и вы работаете с подчинённым узлом в обычном режиме. Откройте конфигуратор под пользователем с полными правами и перейдите в меню «Администрирование».
В зависимости от версии платформы и роли базы пункт называется по-разному: «Распределённая информационная база» с подпунктами снятия признака главного или подчинённого узла. Для подчинённого узла команда снимает привязку к главному, для главного — убирает роль корня распределённой системы. Платформа запросит подтверждение и предупредит о необратимости.
- 1Создайте и проверьте резервную копию базы
- 2Завершите все сеансы пользователей и фоновые задания
- 3Откройте конфигуратор под пользователем с полными правами
- 4Откройте «Администрирование → Распределённая информационная база»
- 5Выберите команду снятия признака главного или подчинённого узла
- 6Подтвердите операцию и дождитесь завершения
- 7Перезапустите базу и проверьте доступность конфигурации для изменений
После снятия признака узлы плана обмена остаются в базе как справочные данные, но платформа больше не считает базу частью РИБ. Это значит, что конфигурацию можно обновлять вручную, а план обмена при желании — очистить или удалить узлы.
Способ 2: программный сброс главного узла
Конфигураторный способ не всегда доступен. Классическая ситуация: подчинённый узел восстановлен из копии, а платформа при попытке обновления конфигурации выдаёт «Изменения конфигурации могут быть получены только из главного узла». В этом случае привязку снимают кодом через метод плана обмена.
Сброс выполняется вызовом ПланыОбмены.УстановитьГлавныйУзел(Неопределено) — в файловом варианте через внешнюю обработку, запущенную в режиме предприятия, либо через консоль кода. После выполнения база становится автономной: признак подчинённости снимается, и конфигурацию можно изменять напрямую.
// Выполняется в режиме предприятия под полными правами
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Сообщить("Главный узел сброшен. База отвязана от РИБ.");Обратная операция — установка главного узла — выполняется тем же методом, но с ссылкой на узел плана обмена вместо Неопределено. Это полезно знать, если отвязка была тестовой и структуру нужно вернуть. Однако помните: установка узла «вручную» не восстанавливает корректную нумерацию сообщений, и обмен придётся перенастраивать.
Отвязка главного узла и особые сценарии
Главный узел отвязывается теми же способами, но последствия шире: после снятия признака все подчинённые узлы остаются «сиротами» — они продолжают считать себя частью РИБ, главного которой больше нет. Если вы отвязываете главный узел осознанно, параллельно решите судьбу подчинённых: либо отвяжите их тоже, либо назначьте новый главный.
Тестовая копия подчинённого узла
Самый частый сценарий. Копия подчинённой базы при открытии ругается на обмен и не даёт менять конфигурацию. Здесь достаточно программного сброса главного узла через обработку — после этого копия работает как обычная автономная база. Никаких дополнительных действий в «боевом» главном узле делать не нужно, копия на него не влияет.
Потерян главный узел
Если главная база утеряна без резервной копии, выберите наиболее актуальный подчинённый узел, сбросьте у него главный узел программно и назначьте его новым центром. Затем для остальных подчинённых выполните повторную инициализацию: связь со старой структурой всё равно потеряна, и честного продолжения нумерации сообщений не будет.
Сравнение способов отвязки
Штатно и наглядно, но недоступно, если платформа блокирует изменения из-за роли подчинённого узла
Работает в любой ситуации, включая восстановленные копии; требует полных прав и аккуратности с последующей очисткой регистрации
Не отвязка, а пересоздание связи; подходит, когда узел должен остаться в РИБ, но обмен разрушен
Проверка результата и очистка после отвязки
Признак успешной отвязки — база открывается в конфигураторе, кнопка обновления конфигурации базы данных активна, а при запуске предприятия нет требований выполнить обмен с главным узлом. Дополнительно проверьте, что в плане обмена у предопределённого узла «Этот узел» пропала связь с главным.
После отвязки выполните хозяйственную очистку. Удалите регистрацию изменений по узлам бывшей РИБ — для этого в типовых конфигурациях есть команда удаления регистрации в карточке узла, либо используйте метод ПланыОбмена.УдалитьРегистрациюИзменений. Без этого таблицы регистрации будут копиться и раздувать базу.
Как проверить результат
Команда доступна и выполняется без ошибок
Ошибка «изменения могут быть получены только из главного узла»
База открывается без требований обмена
Появляются напоминания или блокировки, связанные с РИБ
Главный узел не задан, признак РИБ снят
У узла по-прежнему указан главный, обмен «висит»
Регистрация по узлам РИБ удалена
Таблицы регистрации продолжают расти
Типичные ошибки при отвязке
Большинство проблем после отвязки связано не с самой операцией, а с тем, что забыли сделать до или после неё. Разберём самые частые просчёты.
Отдельно отметим попытку «отвязать» базу удалением плана обмена из конфигурации. Это не отвязка, а слом структуры: признак РИБ хранится не в метаданных плана обмена, а в служебных данных базы. Удаление плана обмена из конфигурации без снятия признака приведёт к ошибкам при обновлении и не решит исходную задачу.
Что важно запомнить
Отвязка от РИБ — необратимое снятие признака узла через конфигуратор или метод ПланыОбмена.УстановитьГлавныйУзел(Неопределено). Всегда начинайте с проверенной резервной копии, завершайте очисткой регистрации изменений и проверкой доступности обновления конфигурации. Если узел нужен в обмене — чините обмен, а не отвязывайте базу.
Частые вопросы
Можно ли отвязать базу от РИБ без конфигуратора?
Да. Сброс главного узла выполняется в режиме предприятия через внешнюю обработку или консоль кода вызовом ПланыОбмена.УстановитьГлавныйУзел(Неопределено). Нужны полные права и монопольный доступ к базе на время операции.
Что будет с данными после отвязки?
Сами данные — документы, справочники, регистры — не пострадают: отвязка меняет только служебный признак принадлежности к РИБ. Потеряются зарегистрированные к отправке изменения и связь с другими узлами, поэтому перед отвязкой рабочего узла завершите обмен.
Можно ли после отвязки снова включить базу в ту же РИБ?
Формально да, но фактически это новая инициализация: узел создаётся заново, выполняется начальная выгрузка образа подчинённой базы, нумерация сообщений начинается с нуля. «Приклеить» базу обратно с сохранением истории обмена нельзя.
Почему после отвязки всё равно появляется ошибка про главный узел?
Чаще всего сброшен не тот признак: например, снят признак у одной копии базы, а открывается другая. Также проверьте, что обработка выполнилась без ошибок и под полными правами, и перезапустите сеанс — кэшированные параметры сеанса могут показывать старое состояние.
Нужно ли отвязывать тестовую копию, если она используется только для просмотра?
Для простого просмотра данных отвязка не обязательна. Но если на копии нужно обновлять конфигурацию, тестировать доработки или запускать обмены с другими системами, отвяжите её — иначе платформа заблокирует изменения требованием получать их из главного узла.
Чем отвязка отличается от удаления узла в плане обмена?
Удаление узла в главной базе лишь убирает получателя обмена — подчинённая база при этом продолжает считать себя частью РИБ и блокирует изменения конфигурации. Отвязка снимает именно этот служебный признак на стороне самой базы. Для полного вывода филиала нужны оба действия: отвязка его базы и удаление узла в центре.