Распределённая база 1С: устройство, настройка и ограничения

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

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

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

Как устроен механизм РИБ внутри платформы

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

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

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

Чем РИБ отличается от других способов совместной работы

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

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

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

РИБ

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

Веб-доступ к центральной базе

Данные всегда актуальны, но при обрыве связи работа филиала останавливается

Обмен через планы обмена (не РИБ)

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

Как создать распределённую базу: порядок действий

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

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

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

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

Коллизии и ограничения, о которых нужно знать заранее

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

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

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

Типичные ошибки при эксплуатации РИБ

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

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

Регулярный контроль обмена — обязательная часть эксплуатации. Минимальный набор проверок занимает несколько минут, но позволяет заметить проблему до того, как расхождения станут необратимыми.

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

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

Дата последнего успешного обмена в настройках синхронизации

Норма

Соответствует расписанию, ошибок в журнале нет

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

Обмен не выполнялся давно либо завершился с ошибкой

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

Норма

Номера последовательно растут, подтверждения приходят

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

Номер принятого сообщения «застрял» — пакеты теряются

Контрольный документ, созданный в филиале

Норма

Появился в центральной базе после ближайшего обмена

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

Документа нет — проверяйте отборы узла и регистрацию изменений

Совпадение версий конфигурации в узлах

Норма

Версии идентичны во всех базах

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

Версии различаются — обмен обновлениями не проходит

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

Когда РИБ не подходит и что использовать вместо неё

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

Как выбрать действие

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

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

Точки работают автономно, а данные нужны в центре сводноРИБ — правильный выбор, настройте отборы и расписание обмена

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

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

Частые вопросы о распределённых базах 1С

Можно ли превратить подчинённый узел в самостоятельную базу?

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

Что делать, если файл обмена потерялся или повреждён?

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

Сколько подчинённых узлов может быть у одной базы?

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

Переносятся ли через РИБ права и настройки пользователей?

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

Можно ли использовать РИБ между базами на разных версиях платформы?

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

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

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