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

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

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

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

Когда РИБ подходит, а когда лучше выбрать другой механизм

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

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

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

РИБ

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

Обмен по правилам конвертации

Разные конфигурации, гибкие правила отбора данных. Требует разработки и поддержки правил, нет автономной полноценной копии.

Клиент-серверный доступ через веб/тонкий клиент

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

Подготовка: что проверить до создания узлов

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

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

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

Создание подчинённого узла и начального образа

Работа начинается в центральной (главной) базе. Откройте раздел настройки синхронизации данных (в типовых конфигурациях это обычно «Администрирование» → «Синхронизация данных» или список планов обмена), включите использование синхронизации и создайте новый узел нужного плана обмена. Задайте код и наименование узла — код должен быть уникальным в пределах всей распределённой системы.

После создания узла сформируйте начальный образ подчинённой базы. В типовых конфигурациях это делается командой «Создать начальный образ» из формы узла или помощника настройки. В результате создаётся файл информационной базы (обычно 1Cv8.1CD в указанном каталоге), который уже содержит служебную информацию о связи с главным узлом и, при соответствующих настройках, начальную выгрузку данных.

Готовый образ перенесите на компьютер подчинённого узла и подключите как обычную файловую базу (или загрузите на сервер 1С, если узел клиент-серверный). При первом запуске база уже «знает», что она подчинённый узел конкретной центральной базы, — не пытайтесь подключить к ней другой главный узел или использовать образ повторно для второго узла.

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

Настройка транспорта сообщений обмена

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

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

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

Файлы сообщений обмена имеют формат Message_КодОтправителя_КодПолучателя.xml. Если обмен «не идёт», первым делом посмотрите в каталог обмена: появляются ли файлы, забираются ли они получателем. Застрявший файл обычно означает ошибку загрузки на стороне получателя — подробности будут в журнале регистрации.

Проверка работы и контроль обмена

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

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

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

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

Счётчики сообщений в узле

Норма

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

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

Сообщения отправлены, но не приняты; номера «замерли»

Тестовый документ

Норма

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

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

Документ отсутствует или перенёсся без обязательных ссылок

Каталог обмена

Норма

Файлы сообщений появляются и исчезают после загрузки

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

Файлы накапливаются или не создаются вовсе

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

Норма

События обмена без ошибок

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

Ошибки доступа, коллизий или загрузки данных

Коллизии, обновление конфигурации и типичные ошибки

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

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

Частые вопросы по настройке РИБ

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

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

Как ограничить данные, которые попадают в филиал?

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

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

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

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

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

Можно ли объединить РИБ в сеть из трёх и более узлов?

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

Почему в подчинённом узле не открывается база после получения сообщения с конфигурацией?

База получила изменения конфигурации и требует обновления конфигурации базы данных. Запустите конфигуратор подчинённого узла и выполните обновление — после этого работа разблокируется. Это штатное поведение, а не ошибка.