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