РИБ в 1С: что это такое и как работает

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

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

Механизм РИБ встроен в типовые конфигурации («Управление торговлей», «Розница», «ERP» и другие) и не требует покупки отдельных компонентов. Однако он накладывает ограничения на структуру данных и требует дисциплины при обновлении конфигурации: все узлы должны работать на одинаковой версии, иначе обмен остановится.

Что такое РИБ и как устроена распределённая база

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

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

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

Когда РИБ действительно нужен, а когда лучше обойтись без него

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

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

Сравнение вариантов

РИБ

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

Клиент-серверный режим

Все пользователи работают в одной базе через сервер 1С и СУБД. Требует стабильного канала связи и лицензий на сервер, но не нуждается в обменах.

Универсальный обмен данными

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

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

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

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

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

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

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

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

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

Обновление конфигурации в распределённой базе

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

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

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

Типичные проблемы и способы их решения

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

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

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

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

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

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

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

Как проверить результат

Номера сообщений в настройках узлов

Норма

Отправленные номера одного узла равны принятым номерам другого

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

Есть разрыв в нумерации — сообщения потеряны или не загружены

Очередь незагруженных сообщений

Норма

Каталог обмена пуст after цикла обмена, ошибок в журнале нет

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

Файлы копятся в каталоге, в журнале регистрации ошибки загрузки

Данные на контрольную дату

Норма

Остатки и документы совпадают в обоих узлах

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

Есть расхождения по объектам — нужен анализ коллизий и повторная выгрузка

Частые вопросы о РИБ в 1С

Чем РИБ отличается от обычной синхронизации данных?

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

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

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

Что делать, если подчинённая база потеряла связь с главным узлом?

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

Сколько подчинённых узлов можно создать в РИБ?

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

Можно ли работать в подчинённом узле, пока идёт обмен?

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

Как полностью вывести базу из состава РИБ?

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