РИБ в 1С: несколько копий одной базы, которые обмениваются данными
Содержание
Распределённая информационная база (РИБ) — это набор одинаковых по конфигурации баз 1С, которые постоянно сверяют между собой данные и изменения конфигурации. Каждая база в такой схеме называется узлом. Один узел главный, остальные подчинённые. Обмен идёт по плану обмена особого типа «Распределённая информационная база», а не по обычным правилам конвертации.
Зачем это нужно: филиал работает в своей базе без постоянного канала до центра, а руководство видит сводные данные. Или нужна отдельная копия под тяжёлые отчёты. Ниже — как устроена схема, как её развернуть без потерь и что делать, когда обмен встал.
Как устроена РИБ и чем она отличается от обычного обмена
В РИБ все узлы имеют одну и ту же структуру метаданных. Не «похожую», а побайтно одинаковую: те же справочники, документы, регистры, те же формы и модули. Поэтому обмен не нуждается в правилах конвертации: объекты уходят как есть, с теми же внутренними идентификаторами.
Из этого следуют главные свойства схемы:
- 🔗 Объект, созданный в одном узле, появляется в другом с тем же внутренним идентификатором, а не как новая запись.
- 🧩 Конфигурацию правят только в главном узле. Изменения уходят в подчинённые вместе с данными.
- 🔢 Нумерация документов не пересекается, если у каждого узла свой префикс информационной базы.
- 🔒 В подчинённом узле конфигурацию в режиме Конфигуратора менять нельзя: она заблокирована от правки.
Сравнение с обычным обменом через правила конвертации:
| Параметр | РИБ | Обмен по правилам конвертации |
|---|---|---|
| Конфигурации | Одинаковые, всегда | Могут быть разные (БП ↔ ЗУП, БП ↔ УТ) |
| Правила | Не нужны | Нужны, часто дорабатываются |
| Идентификаторы объектов | Сохраняются | Сопоставляются по ключевым полям |
| Изменения конфигурации | Передаются автоматически | Каждая база обновляется отдельно |
| Типичный сценарий | Филиалы, зеркальная копия | Интеграция разных систем |
Если в узлах нужны разные конфигурации, РИБ не подходит — берите обычный обмен.
Узлы, фильтры и схемы распределения
Схема самая простая: звезда. В центре главный узел, вокруг подчинённые. Подчинённый узел общается только со своим главным. Прямого обмена «филиал — филиал» нет: данные идут через центр.
Многоуровневые схемы возможны. Подчинённый узел одного уровня может быть главным для узлов следующего. Но каждый уровень добавляет задержку и поводы для ошибок, поэтому глубже двух уровней на практике уходят редко.
Фильтры по узлу
Передавать каждому филиалу всю базу незачем. В плане обмена РИБ настраивают отбор: что именно попадает в узел. Обычно это:
- по организациям — узел получает документы только своих юридических лиц;
- по складам или подразделениям — если конфигурация такой отбор поддерживает;
- «все данные» — для зеркальной копии.
Набор доступных фильтров определяет сама конфигурация. В типовых БП 3.0 и УТ 11 отбор по организациям есть; для других конфигураций смотрите форму настройки узла.
Условно-постоянная информация (справочники, настройки учёта) передаётся в подчинённые узлы всегда целиком. Фильтр действует на документы и регистры.
Что в РИБ не передаётся
Некоторые данные остаются локальными: настройки пользователей, часть служебных регистров, журнал регистрации. Не рассчитывайте, что права и личные настройки отчётов «приедут» из центра сами.
Подготовка: что проверить до создания узлов
РИБ ломается чаще всего не при обмене, а из-за неподготовленной базы. Пройдитесь по списку.
Несколько пояснений:
- Версия платформы. Рекомендуется одна и та же в центре и на местах. Разница в минорных номерах приводит к странным сбоям при обновлении.
- Префикс. Он задаётся в настройках программы (
Администрирование → Настройки программы → Общие настройки, если в конфигурации есть такой раздел) и вставляется в номера документов. Без него в двух узлах появятся документы с одним номером. - Доработки. Если конфигурация доработана, проверьте, что новые справочники и документы не мешают плану обмена: им нужно быть включёнными в состав плана обмена РИБ, иначе объекты останутся в одном узле.
Перед созданием узла сделайте копию главной базы. Начальный образ выгружается из рабочих данных, и ошибка в исходной базе перейдёт в каждый узел.
Создание узла и начального образа
Подчинённую базу не создают пустой — её делают как копию главной с настройками узла. Это и называется начальным образом.
Шаги в главной базе
- Откройте настройки синхронизации данных: раздел
Администрирование, пункт про синхронизацию данных (название зависит от конфигурации, обычно «Синхронизация данных» или «Настройка синхронизации данных»). - Создайте новую синхронизацию и выберите вариант с распределённой информационной базой.
- Задайте имя узла, его код и префикс.
- Настройте фильтры: организации или другие отборы.
- Укажите, как передать начальный образ: через файл или через каталог на сервере.
- Нажмите создание начального образа. Выгрузка займёт время, пропорциональное размеру базы: для базы на десятки гигабайт — часы.
В результате получится файл начального образа. Он содержит и данные, и конфигурацию.
Шаги в подчинённой базе
- Создайте на сервере или у филиала новую базу из файла: при добавлении базы в списке выберите создание информационной базы из выгрузки и укажите файл образа.
- Запустите базу. Она сразу определится как подчинённый узел.
- Проверьте, что в плане обмена есть главный узел и настройки соединения заполнены.
Для больших баз передавайте образ физическим носителем или по защищённому каналу целиком. Скачивание нескольких гигабайт через нестабильный интернет часто обрывается и повторяется.
Обмен: как настроить и запускать сеансы
После создания узлов нужно решить, как именно будут ходить данные.
Способы передачи
| Способ | Когда подходит | Минусы |
|---|---|---|
| Прямое подключение | Обе базы доступны по сети | Нужен стабильный канал |
| Каталог на диске | Есть общая папка или сетевой диск | Нужны права записи с обеих сторон |
| FTP | Нет прямого доступа между сетями | Вложенные настройки, свои сбои |
| Электронная почта | Только почта, маленькие объёмы | Лимиты размера вложения |
В большинстве случаев берут общий каталог или FTP. Почту оставляют на крайний случай.
Расписание
Обмен запускают вручную из формы синхронизации или по расписанию. Расписание задаётся в самой форме настройки (поле «Автоматическая синхронизация»). В серверной базе обмен выполняется регламентным заданием, поэтому нужно, чтобы регламентные задания были включены.
Разумная периодичность: раз в час для оперативной работы, раз в сутки для отчётных узлов. Чаще, чем раз в 10–15 минут, ставить не стоит — сеансы начнут налезать друг на друга.
Порядок сеанса
Каждый сеанс состоит из двух шагов: получить изменения от соседа и отправить свои. Порядок такой: сначала загрузка, потом выгрузка. Если выгрузить первым, подчинённый узел может отправить объект, который главный уже изменил, и возникнет конфликт.
Конфликты и контроль состояния
РИБ строится на двух правилах:
- Один и тот же объект изменён в двух узлах до обмена — возникает конфликт.
- Побеждает версия главного узла. Версия подчинённого теряется и отмечается в форме обмена.
Поэтому важны два практических приёма.
Разделяйте зоны ответственности
Договоритесь, кто и что вводит. Филиал заводит свои документы, центр — справочники. Нормативно-справочную информацию лучше менять только в главном узле: тогда конфликтов по ней не будет вовсе.
Смотрите на состояние обмена
В форме синхронизации видно:
- дату последнего успешного обмена;
- номера отправленного и принятого сообщения;
- число неподтверждённых сообщений;
- конфликты и ошибки загрузки.
Если счётчики расходятся, значит, одно из сообщений потеряно или не загружено. Не пытайтесь «переотправить вручную» — сначала найдите причину в журнале.
Если узел перестал обмениваться и вы собираетесь пересоздать его, сначала убедитесь, что в подчинённой базе нет данных, которых нет в главной. Иначе они пропадут вместе со старым узлом.
Обновление конфигурации в РИБ
Здесь работает особое правило. Менять конфигурацию можно только в главном узле. Нельзя обновить подчинённую базу отдельно из файла .cf или .cfu: она станет несовместима с главной и обмен остановится.
Правильный порядок:
- Остановите пользователей в главном узле и сделайте копию.
- Обновите конфигурацию главного узла как обычно, дождитесь завершения обработчиков обновления.
- Запустите обмен с подчинённым узлом. В сообщении уйдёт новая версия конфигурации.
- В подчинённой базе примите обновление. Она сама выполнит реструктуризацию и обработчики.
Если подчинённая база большая, процесс занимает время. Пока он идёт, работать в ней нельзя.
Практический вывод: сначала обновляется центр, потом идёт обмен, а филиал получает обновление уже по каналу. Узлы без связи долгое время опасны — они отстанут от конфигурации и потребуют пересоздания.
Производительность и масштабирование
РИБ нагружает базу сильнее, чем кажется. Каждое изменение регистрируется на узлы, и таблицы регистрации растут.
Что помогает держать скорость:
- 🕐 Короткие интервалы между обменами. Чем чаще обмен, тем меньше пакет и тем быстрее сеанс.
- 📉 Узкие фильтры. Узел получает только своё — меньше объём и загрузка.
- 🧹 Своевременное подтверждение. Пока сообщения не подтверждены, система хранит регистрацию изменений.
- 🗄️ Сжатие и разбиение. Для больших выгрузок используйте сжатие и разбиение на части, если конфигурация это поддерживает.
- 🚫 Меньше «тяжёлых» операций. Массовое проведение и перепроведение в центре создают огромный пакет изменений для всех узлов. Планируйте их на ночь и заранее предупреждайте филиалы.
Если узлов больше десяти, пора подумать о том, чтобы вынести обмен на отдельный сервер приложений и мониторить задержки сеансов.
Когда РИБ не нужна. Если филиалу нужен только просмотр отчётов — достаточно терминального доступа или веб-клиента. Если нужна интеграция с другой конфигурацией — берите обычный обмен. РИБ оправдана, когда у узла есть своя оперативная работа и нестабильный канал.
Отдельно о резервных копиях: копируйте не только главный узел, но и подчинённые, причём в разные дни. Если в подчинённой базе случилась авария, восстановление из старой копии даст рассинхронизацию номеров сообщений. Тогда проще создать узел заново из свежего образа, чем разбираться с цепочкой файлов обмена. Восстановленный из копии узел сначала проверьте на тестовом обмене и только потом возвращайте пользователей к работе.