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