Администрирование · 12 мин
Распределённая информационная база 1С: для чего нужна и как устроена
Что такое распределённая информационная база 1С (РИБ), для чего она нужна, как работает обмен между узлами, когда стоит внедрять и какие есть альтернативы.
Распределённая информационная база (РИБ) — штатный механизм платформы 1С:Предприятие, который позволяет вести учёт одновременно в нескольких автономных базах и автоматически синхронизировать данные между ними. Каждый узел РИБ — это полноценная информационная база со своей копией данных, а обмен между узлами происходит через файлы сообщений: изменения упаковываются в пакеты и передаются в другие узлы по расписанию или вручную.
Механизм появился как ответ на типовую задачу: у компании есть центральный офис и несколько филиалов, магазинов или складов, где интернет-канал нестабилен или его пропускной способности недостаточно для комфортной работы в тонком клиенте. РИБ позволяет каждой точке работать локально, не завися от связи, а данные при этом остаются согласованными.
Важно понимать: РИБ — это не способ масштабирования производительности и не инструмент резервного копирования. Это механизм территориального распределения учёта с автономной работой узлов. Ошибочные ожидания от РИБ — одна из главных причин неудачных внедрений, поэтому ниже разобраны реальные сценарии применения, ограничения и альтернативы.
Как устроена распределённая база: центральный узел и периферийные базы
РИБ строится по иерархической схеме. Существует один главный (центральный) узел и один или несколько подчинённых (периферийных) узлов. Конфигурация — состав объектов метаданных, права, структура данных — жёстко управляется из центра: изменить структуру метаданных можно только в главном узле, после чего обновление распространяется на периферийные базы вместе с обменом.
Обмен данными происходит через сообщения — файлы в формате XML, которые содержат зарегистрированные изменения: созданные и изменённые документы, элементы справочников, записи регистров. Платформа отслеживает изменения через механизм регистрации изменений: каждый узел «помнит», какие объекты изменились с момента последней отправки, и включает их в очередной пакет.
Подтверждение приёма работает через номера сообщений. Отправитель не считает данные доставленными, пока не получит от подчинённого узла квитанцию с номером принятого сообщения. Если квитанции нет — пакет будет сформирован повторно. Это защищает от потери данных при обрывах связи, но создаёт побочный эффект: при долгом отсутствии обмена объём регистрации растёт.
Для каких задач РИБ подходит
Классический сценарий — розничная сеть. Каждый магазин работает в своей базе: оформляет продажи, приёмки, инвентаризации. В конце дня или по расписанию данные о продажах уходят в центральную базу, а из центра в магазины приходят обновлённые цены, номенклатура, штрихкоды и остатки по сети. Даже если связь пропала на несколько дней, магазин продолжает торговать.
Второй типовой случай — удалённые склады и производственные площадки, где сеть нестабильна или пропускная способность канала низкая. Работа тонкого клиента через слабый канал превращается в мучение: каждая форма открывается секундами. Локальная периферийная база решает проблему радикально — скорость работы перестаёт зависеть от канала.
Третий сценарий — разделение контуров учёта. Например, филиалы ведут оперативный учёт в своих базах, а в центре консолидируется управленческая и бухгалтерская отчётность. Топология обмена настраивается так, чтобы каждый филиал видел только свои данные, а центр — всё.
Если между точками нет надёжного канала от 5–10 Мбит/с, клиент-серверная работа будет некомфортной
Магазин или склад обязан продолжать работу при полном отсутствии интернета
В узел реально передавать только нужные справочники и документы, а не всю базу
При сотнях точек администрирование РИБ становится самостоятельной сложной задачей
Когда РИБ не нужна: альтернативы
Если между офисами есть стабильный канал связи, распределённая база чаще всего избыточна. Клиент-серверная архитектура с тонким клиентом или веб-клиентом даёт всем пользователям единую актуальную базу без задержек синхронизации, без конфликтов и без затрат на администрирование обменов. Это первый вариант, который стоит рассматривать.
Для редкого обмена между разнородными конфигурациями (например, между «Управлением торговлей» и «Бухгалтерией») правильнее использовать планы обмена с правилами конвертации данных или универсальный формат EnterpriseData, а не РИБ. РИБ требует идентичности конфигураций узлов — это её принципиальное ограничение.
Ещё одна ошибка — использовать РИБ как резервную копию. Периферийная база не является бэкапом: в неё реплицируются и ошибочные изменения, и удалённые объекты. Резервное копирование делается штатными средствами СУБД или файлового копирования, независимо от наличия РИБ.
Способы организации работы нескольких точек
Одна база, все работают онлайн. Подходит при стабильном канале; не работает при обрыве связи
Автономные базы с синхронизацией. Подходит при слабой связи; требует администрирования обменов и контроля версий
Связывает разные конфигурации и сторонние системы. Гибче РИБ, но требует настройки правил и не даёт автономной идентичной копии
Доступ через браузер без установки платформы. Зависит от канала так же, как тонкий клиент
Как настроить РИБ: порядок действий
Настройка начинается в центральной базе. В разделе настроек синхронизации данных включается использование планов обмена, затем создаётся узел плана обмена «Полный» (или «По организации», если нужна фильтрация) для будущей периферийной базы. Для узла указывается префикс — он добавляется к номерам документов и кодам справочников, чтобы исключить пересечения нумерации между узлами.
Далее создаётся начальный образ периферийной базы — готовая копия центральной базы, уже привязанная к узлу. Образ разворачивается на целевой площадке, после чего настраивается транспорт обмена: каталог на общем ресурсе, FTP, электронная почта или прямое подключение. Последний шаг — расписание автоматического обмена и контрольный прогон: создать тестовый документ в периферийной базе и убедиться, что он появился в центре.
- 1Включите в центральной базе использование планов обмена и задайте префикс центрального узла
- 2Создайте новый узел плана обмена, укажите префикс и состав выгружаемых данных
- 3Создайте начальный образ периферийной базы штатной командой
- 4Разверните образ на площадке узла, проверьте, что база открывается и содержит актуальные данные
- 5Настройте канал обмена (каталог, FTP, почта) и расписание синхронизации
- 6Выполните тестовый обмен в обе стороны и сверьте документы и справочники
Типичные проблемы и как их диагностировать
Самая частая проблема — «застревание» обмена: сообщения формируются, но не принимаются, или наоборот. Причины обычно простые: недоступен каталог обмена, закончилось место на диске, изменился пароль FTP. Диагностика начинается с журнала регистрации и формы настройки синхронизации, где видны номера отправленных и принятых сообщений.
Вторая группа проблем — коллизии: один и тот же объект изменён в двух узлах между сеансами обмена. По умолчанию платформа разрешает коллизию в пользу главного узла: данные центра перезаписывают данные периферийной базы. Если в филиале правили документ, который одновременно правили в центре, изменения филиала будут потеряны. Это нужно учитывать при организации работы: договориться, кто и где редактирует ключевые справочники.
Третья типовая ситуация — рассинхронизация после обновления конфигурации. Периферийная база не примет обмен, если её конфигурация отличается от конфигурации главного узла. Обновление всегда выполняется сначала в центре, затем пакет с обновлением доставляется в узлы, и только после этого обмен продолжается. Попытка обновить периферийную базу напрямую из файла поставки сломает РИБ.
Ограничения и риски, о которых нужно знать заранее
РИБ не масштабирует производительность. Каждый узел — отдельная база со своей нагрузкой, и добавление узлов не ускоряет работу центра. Более того, на больших объёмах сам обмен становится нагрузкой: формирование и разбор XML-пакетов потребляет ресурсы и время.
Данные в узлах никогда не актуальны «прямо сейчас» — актуальность определяется частотой обмена. Если склад отгружает товар по остаткам из своей базы, а соседний магазин уже продал этот товар час назад, но обмен ещё не прошёл, возможны отрицательные остатки и конфликты. Для процессов, требующих онлайн-контроля остатков, РИБ подходит плохо.
Администрирование РИБ — постоянная работа: контроль очередей обмена, мониторинг ошибок, согласованные обновления, периодическая сверка данных между узлами. Перед внедрением честно оцените, есть ли ресурс на это сопровождение.
Как проверить, что обмен работает корректно
Номер отправленного сообщения совпадает с номером принятого на другой стороне
Номера расходятся, очередь неподтверждённых пакетов растёт
Документ, созданный в узле, появляется в центре после обмена без дублей
Документ не приходит, приходит дважды или с неверными данными
События обмена завершаются без ошибок
Ошибки приёма/отправки, сообщения о несоответствии конфигураций
Остатки по складу в узле и в центре совпадают после обмена
Расхождения накапливаются от обмена к обмену
FAQ: частые вопросы о распределённых базах 1С
Можно ли настроить РИБ между разными конфигурациями, например УТ и БП?
Нет. РИБ требует идентичности конфигураций во всех узлах: структура метаданных управляется централизованно. Для обмена между разными конфигурациями используются планы обмена с правилами конвертации данных или универсальный формат EnterpriseData — это другой класс механизмов.
Как часто нужно выполнять обмен между узлами?
Частота определяется требованиями к актуальности данных и объёмом изменений. Для магазинов типичен обмен от нескольких раз в день до одного раза в конце смены. Слишком редкий обмен опасен накоплением очереди регистрации и конфликтами; слишком частый при больших объёмах создаёт постоянную нагрузку. Начните с обмена 1–2 раза в день и скорректируйте по фактическому времени синхронизации.
Что делать, если периферийная база долго не выходила на связь?
Сначала проверьте, не истёк ли срок актуальности узла и не разрослась ли очередь регистрации до неприемлемого размера. Если узел простаивал месяцами, часто быстрее и надёжнее создать новый начальный образ и развернуть узел заново, чем прогонять накопленные пакеты. Предварительно выгрузите из старого узла документы, которые не успели уйти в центр.
Подходит ли РИБ для объединения баз после слияния компаний?
Как правило, нет. РИБ — механизм для заранее спроектированной иерархии с единой конфигурацией, а не инструмент миграции. Для разового объединения данных из разных баз используются обработки переноса на основе конвертации данных. РИБ можно развернуть после объединения, если новая структура компании требует автономных узлов.
Можно ли работать в периферийной базе, пока идёт обмен?
Технически да, обмен выполняется в фоновом сеансе и не блокирует базу целиком. Однако при разборе пакета объекты, которые в этот момент редактирует пользователь, могут вызвать конфликты блокировок. На практике обмены удобно ставить на нерабочие часы — это снижает число ошибок и ускоряет разбор пакетов.
Чем РИБ отличается от обычной синхронизации данных?
РИБ — частный, самый «жёсткий» вид синхронизации: идентичные конфигурации, иерархия узлов, централизованное управление структурой. Обычная синхронизация (планы обмена с правилами) гибче: работает между разными конфигурациями и версиями, позволяет произвольно преобразовывать данные, но не даёт автономной идентичной копии базы и требует сопровождения правил.
Что важно запомнить
РИБ нужна для автономной работы территориально удалённых точек без стабильной связи: каждый узел ведёт учёт локально, данные синхронизируются пакетами через главный узел. Конфигурация управляется только из центра, коллизии разрешаются в пользу главного узла, а РИБ не заменяет ни резервное копирование, ни клиент-серверную архитектуру при хорошем канале связи.