Распределенная информационная база 1С: что это такое и как она работает

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

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

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

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

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

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

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

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

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

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

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

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

Когда РИБ — правильный выбор, а когда нет

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

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

РИБ или единая база

Распределенная база (РИБ)

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

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

Оптимально при стабильном канале связи. Данные актуальны в реальном времени, но при обрыве связи филиал работать не может.

Обмен по правилам (конвертация данных)

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

Коллизии и ограничения технологии

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

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

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

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

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

Отдельная группа проблем — попытка восстановить узел из обычной копии базы. Файловая копия (.dt или копия каталога) подчинённого узла сохраняет его «роль», и после восстановления из старой копии номера принятых и отправленных сообщений перестанут совпадать с главным узлом. В такой ситуации обмен начнёт отклонять сообщения, и потребуется корректировка номеров сообщений или повторное создание узла.

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

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

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

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

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

Норма

Обмен выполнялся в пределах установленного расписания, сообщения отправлены и приняты

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

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

Журнал регистрации при обмене

Норма

События выгрузки и загрузки завершаются без ошибок

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

Ошибки загрузки объектов, сообщения о коллизиях в большом количестве

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

Норма

Номер принятого в подчинённом узле совпадает с номером отправленного в главном

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

Расхождение номеров — сообщения теряются, потребуется корректировка или повторная выгрузка

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

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

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

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

Часто задаваемые вопросы

Чем РИБ отличается от обычного обмена между базами 1С?

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

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

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

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

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

Можно ли настроить обмен между узлами через интернет?

Да. Для передачи файлов обмена используются FTP, веб-сервисы или синхронизация через защищённый каталог. При использовании открытых каналов обязательно применяйте защищённые протоколы (HTTPS, FTPS) и ограничивайте доступ к каталогам обмена, так как файлы содержат полные данные информационной базы.

Почему в подчинённом узле нельзя изменить конфигурацию?

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

Сколько узлов может быть в распределенной базе?

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