Распределённые базы данных 1С: что это и как они работают

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

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

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

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

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

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

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

Чем РИБ отличается от обычного обмена данными

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

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

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

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

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

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

Филиал должен работать при полном отсутствии связи с центромРассмотрите РИБ — автономность узлов её главное преимущество

Связь стабильная и достаточная для тонкого или веб-клиентаПредпочтительнее единая база с удалённым доступом — проще администрирование

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

Точек много, а регламент обмена сложныйОцените нагрузку на администрирование РИБ: каждый узел требует сопровождения

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

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

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

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

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

Как проходит обмен и что делать при коллизиях

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

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

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

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

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

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

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

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

Приём и отправка сообщений

Норма

Номера отправленных и принятых сообщений в обоих узлах последовательно увеличиваются, ошибок в журнале нет

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

Номера зафиксированы на одном значении, сообщения копятся в каталоге обмена

Актуальность данных в узлах

Норма

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

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

Документы есть только в одном узле, расхождения накапливаются

Соответствие конфигураций

Норма

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

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

Платформа отказывается загружать сообщение из-за различий конфигурации

Альтернативы распределённой базе

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

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

РИБ

Полная автономность узлов без связи; ограничение — сложное администрирование, коллизии, обновление только через центр

Единая база + веб-клиент

Простое сопровождение и актуальные данные в реальном времени; ограничение — зависимость от качества канала связи

Обмен через EnterpriseData

Гибкая интеграция разных систем и выборочный состав данных; ограничение — нужна настройка правил и сопоставления объектов

Сервисные модели (1С:Фреш и аналоги)

Централизованное обновление и доступ из любой точки; ограничение — требования к связи и ограничения облачного режима

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

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

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

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

Что будет, если периферийный узел долго не проводил обмен?

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

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

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

Чем опасно восстановление узла из старой резервной копии?

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

Нужна ли одинаковая платформа на всех узлах РИБ?

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

Как понять, что РИБ больше не нужна?

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