Как отключить РИБ в 1С: пошаговая инструкция

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

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

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

Что значит «отключить РИБ» и какие есть сценарии

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

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

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

Подготовка: что сделать до отключения

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

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

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

Штатное отключение узла РИБ

Штатный сценарий начинается в главной (центральной) базе. Откройте план обмена, по которому работает РИБ: в типовых конфигурациях это раздел «Администрирование» → «Синхронизация данных» → «Настройки синхронизации данных», либо напрямую список узлов плана обмена через «Все функции» → «Планы обмена». Найдите узел отключаемой периферийной базы.

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

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

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

Программное снятие признака РИБ

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

Для главной базы логика обратная: у центральной базы главного узла нет, но она хранит узлы плана обмена. Чтобы окончательно убрать РИБ, удалите все подчинённые узлы из плана обмена. Сам план обмена как объект метаданных можно оставить — без узлов он не выполняет никаких действий.

// Выполнять в монопольном режиме, после резервной копии
// Снятие признака РИБ с периферийной базы:
УстановитьГлавныйУзел(Неопределено);
// Проверка результата:
Если ГлавныйУзел() = Неопределено Тогда
    Сообщить("База больше не является периферийной");
КонецЕсли;

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

Отключение РИБ в клиент-серверном варианте

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

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

Проверка результата и восстановление при ошибках

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

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

Типичные ошибки при отключении РИБ

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

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

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