УРИБ в 1С: что это такое и как работает распределённая база

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

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

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

Как устроен механизм распределённых баз

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

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

Обмен происходит пакетами сообщений. Каждое сообщение содержит изменения, зарегистрированные с момента предыдущей выгрузки, и номер принятого пакета. Если пакет потерян или повреждён, узел запрашивает его повторно — механизм нумерации сообщений защищает от потери данных при нестабильной связи.

Чем УРИБ отличается от обычного обмена данными

Главное отличие — структурная связанность. В РИБ все узлы содержат одну и ту же конфигурацию и зеркально повторяют данные (полностью или в заданном составе). Обмен через планы обмена без признака РИБ (например, «Синхронизация данных») соединяет разные конфигурации — УТ с БП, ЗУП с ERP — и работает по правилам конвертации.

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

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

Когда УРИБ действительно нужна

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

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

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

Маршрут решения

Как выбрать архитектуру

Филиал должен работать при полном отсутствии связи с центромИспользуйте РИБ — узел будет автономным

Есть стабильный канал и достаточная пропускная способностьРассмотрите работу в единой базе через тонкий клиент или веб-клиент — это проще в поддержке

Нужно связать разные конфигурации, например УТ и БПИспользуйте синхронизацию данных, а не РИБ

Нужен только перенос отчётности из филиалов в центрДостаточно простого обмена без распределённой базы

Как создать подчинённый узел

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

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

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

1. 1
   Сделайте резервную копию центральной базы
2. 2
   Создайте узел в плане обмена РИБ, задайте код и префикс
3. 3
   Сформируйте начальный образ подчинённого узла
4. 4
   Разверните образ в филиале и проверьте, что база открывается
5. 5
   Выполните первый обмен и убедитесь, что пакеты принимаются в обе стороны
6. 6
   Настройте расписание автоматического обмена

Типичные проблемы и их признаки

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

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

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

Как контролировать работоспособность обмена

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

Дополнительно стоит периодически сверять ключевые показатели: количество документов за период в центре и в узле, остатки по регистрам. Полное совпадение не всегда обязательно (состав обмена может быть ограничен), но необъяснимые расхождения — сигнал к разбору.

Контрольные точки

Как проверить, что обмен работает

Дата последнего обмена по узлу

Норма

Свежая, соответствует расписанию

Тревожный признак

Обмена не было сутки и более без объяснимой причины

Очередь пакетов

Норма

Пакеты отправляются и подтверждаются

Тревожный признак

Исходящие пакеты накапливаются, подтверждений нет

Журнал регистрации

Норма

Нет ошибок загрузки и коллизий

Тревожный признак

Повторяющиеся ошибки приёма сообщений

Данные в узлах

Норма

Тестовый документ из центра появляется в узле после обмена

Тревожный признак

Документ не доходит или приходит с искажениями

Ограничения и альтернативы

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

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

Альтернативы УРИБ

Единая база, тонкий/веб-клиент

Подходит при стабильной связи; нет обменов и коллизий, но без сети филиал не работает

Синхронизация данных

Связывает разные конфигурации по правилам; не требует идентичности, но не переносит обновления конфигурации

РИБ

Полная автономность узлов и автообновление из центра; цена — сложность администрирования и риск коллизий

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

Можно ли превратить обычную базу в узел РИБ?

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

Что происходит при коллизии и чьи данные побеждают?

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

Как часто нужно выполнять обмен?

Зависит от интенсивности работы и требований к актуальности. При нескольких обменах в день пакеты остаются компактными, а расхождения между узлами минимальны. Редкие обмены (раз в неделю и реже) приводят к большим пакетам и долгой загрузке.

Узел перестал принимать пакеты с ошибкой о номере сообщения — что делать?

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

Подходит ли РИБ для связи 1С с интернет-магазином или другой системой?

Нет. РИБ работает только между идентичными конфигурациями 1С. Для интеграции с внешними системами используют веб-сервисы, HTTP-API, очереди сообщений или обмен через файлы в согласованном формате.