РИБ в 1С: как устроена распределенная информационная база и как её запустить
Содержание
Распределенная база данных 1С — это не одна база на нескольких серверах, как часто думают. Это набор отдельных информационных баз с одинаковой конфигурацией, которые обмениваются изменениями через план обмена с признаком РИБ. Каждая база живёт на своём сервере или компьютере и работает без связи с остальными.
Типичный пример: головной офис, склад в другом городе и три магазина. У каждой точки своя копия базы, а данные сходятся в главный узел пачками изменений раз в несколько минут или раз в сутки. Ниже — как это устроено, как настроить и что ломается чаще всего.
Из чего состоит РИБ: узлы, план обмена и сообщения
РИБ строится на механизме планов обмена. Обычный план обмена передаёт данные между разными конфигурациями по правилам. В РИБ конфигурация одна и та же, а правила не нужны: передаётся всё, что есть в метаданных, кроме объектов, исключённых из обмена.
Основные понятия:
- 🏠 Главный узел — база, где разрешено менять конфигурацию. Это источник «истины» для структуры.
- 🌿 Подчиненный узел — копия главной базы. Конфигурация в ней закрыта от изменений и обновляется только из главного узла.
- 📦 Сообщение обмена — файл или пакет с изменениями. У каждого сообщения есть номер.
- 🔢 Номера отправленного и принятого — счётчики, по которым узлы понимают, что уже доставлено, а что нет.
- 📝 Регистрация изменений — при записи объекта платформа сама ставит его в очередь на отправку тем узлам, для которых он подходит.
Номера сообщений — главный механизм надёжности. Если узел получил сообщение с номером, который он уже обработал, он его пропустит. Если пришёл номер «с дыркой», обмен остановится с ошибкой.
Чем РИБ отличается от обычного обмена
| Признак | Обычный обмен | РИБ |
|---|---|---|
| Конфигурации | Могут быть разные | Только одинаковые |
| Правила обмена | Нужны, пишутся отдельно | Не нужны |
| Передача конфигурации | Нет | Да, из главного узла в подчинённые |
| Начальная выгрузка | Часто не нужна | Обязателен начальный образ |
| Состав данных | Выбирается правилами | Всё, кроме исключённого |
Какие схемы узлов бывают
Схема — это то, кто с кем разговаривает. Платформа допускает несколько вариантов, и выбор зависит от числа точек и качества связи.
Звезда
Один главный узел, вокруг него подчинённые. Подчинённые общаются только с центром. Это самый распространённый вариант: просто отладить, понятно, где искать причину сбоя.
Многоуровневая схема
Главный узел, под ним региональные подчинённые, а под ними — свои подчинённые. Региональный узел одновременно главный для нижнего уровня и подчинённый для верхнего. Подходит для сетей с филиалами в нескольких регионах, но ошибки обмена в такой цепочке искать труднее: сбой наверху не даёт данным дойти до самого низа.
Несколько независимых РИБ
Иногда держат отдельные РИБ под разные задачи: одну для розницы, другую для бухгалтерии филиалов. Конфигурации в них могут различаться, главное — внутри каждой РИБ они совпадают.
| Схема | Когда подходит | Риск |
|---|---|---|
| Звезда | До 10–20 точек, одна центральная база | Центр — единая точка отказа |
| Многоуровневая | Филиалы с собственными подразделениями | Задержки данных по цепочке |
| Автономное рабочее место (АРМ) | Удалённый сотрудник, плохой интернет | Накопление конфликтов при долгой работе офлайн |
Как настроить РИБ пошагово
Порядок такой: подготовить главную базу, создать узлы, создать начальный образ, развернуть его на месте подчинённого узла и настроить расписание обмена. Точные названия пунктов меню отличаются в разных конфигурациях и версиях интерфейса. Ищите нужный раздел в настройках программы по слову «обмен данными» или «РИБ».
Подготовка главной базы
- Сделайте полную резервную копию. Без резервной копии не переходите к следующим шагам.
- Убедитесь, что в базе нет незавершённых обновлений и все пользователи вышли.
- Проверьте, что конфигурация главной базы не изменена относительно типовой, если хотите потом обновлять подчинённые узлы автоматически.
- Включите в настройках программы использование обмена данными (в типовых конфигурациях это флажок в разделе администрирования).
Создание узлов и начального образа
- Откройте список обменов, создайте новый обмен с признаком распределённой базы и укажите код и наименование подчинённого узла.
- Настройте состав передаваемых данных: например, склад видит только свой остаток, а не весь учёт организации.
- Создайте начальный образ подчинённого узла — полную копию базы с настройками РИБ. Платформа сделает файл (для файловой базы) или попросит указать сервер и имя базы.
- Перенесите образ на целевую площадку и подключите как информационную базу.
Нельзя создавать подчинённый узел простым копированием файла базы. Без начального образа не совпадут идентификаторы узлов и номера сообщений, обмен будет падать с ошибкой.
Настройка связи
Обмен идёт одним из способов:
- 📁 через общую сетевую папку;
- 🌐 через FTP или веб-сервис;
- 📧 через электронную почту;
- 🔗 напрямую, если базы видят друг друга в сети.
Выберите способ в настройках узла и укажите параметры подключения. Затем задайте расписание: для ритейла хватает раза в 10–30 минут, для офисных баз — 1–2 раз в день.
Что происходит при изменении объекта: регистрация и конфликты
Когда пользователь записывает документ или элемент справочника, платформа вызывает механизм автоматической регистрации. Объект попадает в очередь изменений для каждого узла, с которым настроен обмен. При следующем обмене эти изменения упаковываются в сообщение и отправляются.
Что можно изменить в подчинённом узле
По умолчанию в подчинённом узле можно работать с данными, но нельзя менять конфигурацию. Часть объектов можно «закрепить» за главным узлом, чтобы они менялись только там, например, справочник организаций.
Откуда берутся конфликты
Конфликт возникает, когда один и тот же объект изменили в двух узлах до обмена. Классический пример: бухгалтер в главном офисе исправил реквизит контрагента, а менеджер в филиале за то же время поменял его телефон.
Как платформа решает такую ситуацию:
- ✅ по умолчанию побеждает версия из главного узла — подчинённый узел при загрузке заменяет свои изменения;
- 📋 проигравшие правки не теряются бесследно: платформа сообщает о конфликте и записывает событие в журнал регистрации;
- ⚙️ в некоторых конфигурациях есть настройка приоритета и ручное разрешение расхождений.
Лучший способ избежать конфликтов — разделить зоны ответственности. Нормативно-справочную информацию ведёт только центр, подчинённые узлы работают с документами.
Удаление объектов
Удаление в РИБ тоже передаётся. Если в одном узле помечен на удаление документ, а в другом на его основании ввели новый, потом возможны ссылки на несуществующий объект. Выполняйте удаление помеченных только в главном узле после того, как все подчинённые догрузили данные.
Как не уронить производительность и канал связи
Если база большая, а канал слабый, каждый обмен превращается в проблему. Что помогает:
- Уменьшите размер сообщений. Частый обмен малыми порциями легче, чем один раз в сутки на гигабайты.
- Ограничьте состав данных. Подчинённому узлу склада незачем получать всю зарплатную информацию. Настройте фильтр по организациям или подразделениям.
- Включите сжатие. Для файловой передачи платформа умеет упаковывать сообщение в архив.
- Разнесите обмены во времени. Если десять узлов шлют изменения в одну минуту, центральный сервер встанет.
- Не запускайте обмен во время регламентных заданий. Закрытие месяца и обмен одновременно нагружают базу и блокируют друг друга.
Ориентиры по времени
Для канала 10 Мбит/с пакет изменений в 50 МБ при нормальной загрузке передаётся примерно за минуту, а обработка в базе занимает от нескольких минут до часа в зависимости от числа объектов. Эти цифры ориентировочные: ключевую роль играет число записей и индексы, а не размер файла.
Если нагрузка не снижается, посмотрите, не копятся ли необработанные сообщения. Растущее отставание по номерам — признак того, что узел не успевает.
Типичные ошибки при работе РИБ и как их диагностировать
Прежде чем что-то чинить, откройте журнал регистрации и отфильтруйте события по обмену данными. Там видно, какое сообщение, какой номер и на каком шаге произошёл сбой.
Что проверить в первую очередь
- 🔌 Доступна ли папка обмена или сервер с обеих сторон.
- 🔑 Есть ли у пользователя обмена права на загрузку и выгрузку.
- 🔢 Совпадают ли номера отправленных и принятых сообщений на обоих узлах.
- 🧩 Одинаковы ли версии конфигураций.
- 📜 Нет ли в журнале регистрации ошибок записи конкретных объектов, например, блокировок.
Когда проще пересоздать подчинённый узел
Если номера рассинхронизированы и вернуть порядок вручную не выходит, быстрее и надёжнее удалить подчинённый узел и создать новый начальный образ. Данные, внесённые в подчинённом узле и не успевшие уйти в главный, перед этим выгрузите отдельно. Не удаляйте узел, пока не убедитесь, что все локальные изменения доставлены.
Обновление конфигурации в РИБ
Одна из главных причин, почему РИБ вообще используют, — централизованное обновление. Конфигурацию меняют только в главном узле. Затем изменения передаются подчинённым как часть обмена.
Порядок действий:
- Остановите пользователей в главном узле, сделайте копию.
- Обновите конфигурацию главной базы и выполните обновление информационной базы.
- Выполните обмен: подчинённые узлы получат новую версию конфигурации.
- После получения конфигурации подчинённая база попросит обновить информационную базу — подтвердите.
- Проверьте, что обмен данными после обновления прошёл без ошибок.
Не обновляйте подчинённый узел отдельно от главного. Если версии конфигураций разойдутся, платформа заблокирует загрузку данных.
Когда РИБ не нужна
РИБ — тяжёлый инструмент. Её не стоит применять, если:
- нужно обменяться данными между разными конфигурациями (например, Бухгалтерия и Розница) — подойдёт обычный обмен по правилам;
- достаточно переносить пару справочников раз в неделю;
- филиалы не имеют своего ИТ-специалиста и некому разбирать сбои;
- все пользователи могут работать в одной базе через интернет , и задержки некритичны.