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

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

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

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

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

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

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

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

Чем РИБ отличается от обычного обмена и клиент-серверной работы

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

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

Когда распределенная база действительно нужна

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

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

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

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

Как выбрать архитектуру

Филиалы работают без постоянного интернет-канала до центраВнедряйте РИБ с обменом по расписанию

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

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

Нужно просто разграничить права внутри одной базыНастройте роли и RLS, РИБ для этого не требуется

Как настроить РИБ: порядок действий

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

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

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

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

Коллизии, дубли и другие проблемы эксплуатации

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

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

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

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

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

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

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

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

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

Норма

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

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

Номера расходятся — пакет не дошел или не загружен

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

Норма

Нет ошибок загрузки и предупреждений о коллизиях

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

Ошибки загрузки объектов или массовые коллизии

Количество документов за период

Норма

Совпадает в главном и подчиненном узле

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

Разница растет от обмена к обмену

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

Норма

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

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

Пакеты копятся — обмен фактически остановлен

Ограничения и альтернативы

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

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

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

РИБ

Автономная работа филиалов без связи; ограничение — идентичная конфигурация и иерархия узлов

Обмен через универсальный формат

Связь разных конфигураций по гибким правилам; требует настройки и поддержки правил конвертации

Веб-сервисы

Обмен в реальном времени; не работает при отсутствии связи, требует доработки

Единая база с тонким клиентом

Минимум администрирования; филиал без связи полностью теряет доступ к учету

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

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

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

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

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

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

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

Как избежать дублей контрагентов и номенклатуры в разных узлах?

Заводите ключевые справочники централизованно в главном узле, а в подчиненных ограничьте права на их создание. Дополнительно используйте поиск по ИНН, наименованию и другим ключевым полям перед созданием нового элемента.

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

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

Что будет, если удалить узел из плана обмена?

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