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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Клиент-серверный режим с тонким клиентом

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

Обмен через правила конвертации (не РИБ)

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

Частые проблемы и как их решать

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

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

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

Ограничения и правила безопасной эксплуатации

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

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

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

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

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

Статус последнего обмена в мониторе синхронизации

Норма

Обмен завершён без ошибок, дата актуальная

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

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

Наличие тестового документа в обеих базах

Норма

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

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

Документ отсутствует или появился с искажёнными данными

Очередь зарегистрированных изменений

Норма

После обмена очередь пуста или минимальна

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

Очередь постоянно растёт — изменения не уходят

Отличие РИБ от других механизмов обмена

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

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

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

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

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

Что будет, если один и тот же документ изменили и в центре, и в филиале?

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

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

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

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

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

Нужно ли резервное копирование на каждом узле?

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