Как правильно обновлять периферийные базы в РИБ 1С при пропуске нескольких релизов и выполнять обработчики обновления?

← На главную

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

Разберем механику работы РИБ и Библиотеки Стандартных Подсистем при обновлении

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

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

Что касается данных и обработчиков обновления БСП, проанализируем следующую логику:

Общие (мигрирующие) данные: Если обработчик обновления в ЦБ перезаписывает документы или справочники, которые входят в состав плана обмена и мигрируют по всем узлам, измененные данные передаются из ЦБ в ПБ с файлом обмена. В периферийной базе они загружаются с установленным флагом Загрузка = Истина, что предотвращает их повторную обработку локальными алгоритмами.
Локальные данные узла: В любой базе существуют данные, которые не мигрируют между узлами (настройки пользователей, специфичные регистры сведений, локальные классификаторы, данные с фильтрацией по организациям). Для таких данных обработчики обновления БСП обязательно должны отработать в самой периферийной базе.

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

Пошаговый алгоритм обновления РИБ при пропуске нескольких релизов

Разберем безопасный и проверенный на практике сценарий обновления центрального и подчиненных узлов, когда в ЦБ последовательно накатывается сразу несколько релизов (например, три релиза подряд):

Проведение полного предварительного обмена: Перед началом любых манипуляций выполняем полный сеанс двустороннего обмена между ЦБ и всеми ПБ (схема ПБ -> ЦБ, а затем ЦБ -> ПБ). Это необходимо, чтобы гарантировать синхронизацию всех накопленных изменений и завершить текущие пакеты обмена.
Завершение сеансов пользователей: Блокируем работу пользователей в центральной базе и во всех подчиненных узлах.
Последовательное обновление ЦБ:
В Конфигураторе центральной базы последовательно применяем обновления (Релиз 1 -> Релиз 2 -> Релиз 3). После каждого шага или в самом конце запускаем ЦБ в пользовательском режиме под пользователем с административными правами, чтобы БСП выполнила основные и отложенные обработчики обновления для центрального узла.
Формирование файла обмена в ЦБ: После завершения всех обработчиков в ЦБ выполняем процедуру выгрузки данных в подчиненные узлы. В формируемый файл обмена платформой будет автоматически помещена обновленная конфигурация и все изменения данных.
Загрузка обновления в периферийной базе:
Запускаем сеанс обмена в ПБ. Платформа прочитает файл, загрузит изменения конфигурации и выдаст предупреждение о том, что конфигурация базы данных не соответствует обновленной конфигурации.
Обновление конфигурации БД в ПБ:
Заходим в Конфигуратор периферийной базы и обновляем конфигурацию базы данных (клавиша F7 или меню Конфигурация -> Обновить конфигурацию базы данных).
Запуск ПБ в пользовательском режиме:
Запускаем ПБ в режиме «1С:Предприятие». Подсистема БСП зафиксирует смену версии конфигурации и автоматически выполнит все необходимые локальные обработчики обновления для пропущенных релизов.
Квитирование (подтверждение обмена):
Выполняем отправку сообщения обмена из ПБ в ЦБ, чтобы центральный узел получил подтверждение успешного принятия новой версии конфигурации подчиненным узлом.

Как настроить односторонний обмен и выборочную регистрацию объектов

Рассмотрим ситуацию, когда требуется жестко ограничить направление передачи данных. Например, документы должны передаваться только из периферийных баз в центральную (ПБ -> ЦБ), а справочники НСИ должны создаваться только в ЦБ и рассылаться в ПБ (ЦБ -> ПБ).

В стандартном РИБ на уровне платформы изменения конфигурации всегда передаются сверху вниз (из ЦБ в ПБ), отменить это нельзя. Однако регистрацию самих объектов данных мы можем полностью взять под программный контроль.

Для реализации такой схемы выполним следующие шаги:

Открываем нужный план обмена в Конфигураторе, переходим на вкладку Состав.
Для объектов, регистрацию которых мы хотим контролировать вручную, устанавливаем свойство Авторегистрация = Запретить.
Создаем подписку на событие ПриЗаписи для управляемых объектов.
В модуле подписки прописываем логику проверки узла и режима загрузки.

Проанализируем пример кода для подписки на событие при записи документа, чтобы он регистрировался к отправке только в периферийном узле:


Процедура ЗарегистрироватьДокументПриЗаписи(Источник, Отказ) Экспорт
    
    // Если запись происходит в процессе загрузки обмена, игнорируем регистрацию
    Если Источник.ОбменДанными.Загрузка Тогда
        Возврат;
    КонецЕсли;
    
    // Проверяем, является ли текущий узел подчиненным (периферийным)
    Если ЗначениеЗаполнено(ПланыОбмена.ГлавныйУзел()) Тогда
        
        // Получаем ссылку на главный узел
        ГлавныйУзел = ПланыОбмена.ГлавныйУзел();
        
        // Регистрируем изменения только для отправки в Главный узел
        ПланыОбмена.ЗарегистрироватьИзменения(ГлавныйУзел, Источник.Ссылка);
        
    КонецЕсли;

КонецПроцедуры

Для справочников НСИ в центральном узле логика будет обратной: проверяем, что ПланыОбмена.ГлавныйУзел() не заполнен (мы находимся в ЦБ), и регистрируем созданный элемент для всех подчиненных узлов плана обмена через функцию ПланыОбмена.ВыбратьУзлы().

Дополнительно в модуле плана обмена можно использовать обработчик ПриОтправкеДанныхПодчиненному или ПриОтправкеДанныхГлавному, где с помощью свойства ЭлементДанных.ОбменДанными.Получатели регулируется состав выгружаемого пакета.

Решение проблем при сбое доставки обновления через обмен

При слабом интернет-канале или большом объеме изменений файл обмена с конфигурацией может достигать сотен мегабайт и вызывать ошибки при передаче. В таких случаях выделим альтернативный практический метод обновления периферийной базы путем временного снятия главного узла:

В периферийной базе запускаем внешней обработкой или через контекст конфигурации код для отключения связи с главным узлом: ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После выполнения этой команды периферийная база становится автономной.
В Конфигураторе автономной базы выполняем прямое обновление конфигурации через файл .cf, выгруженный из обновленной центральной базы (Конфигурация -> Загрузить конфигурацию из файла или Сравнить, объединить с конфигурацией из файла).
Запускаем базу в пользовательском режиме, даем БСП отработать все обработчики обновления.

Возвращаем ссылку на главный узел обратно:


СсылкаНаГлавный = ПланыОбмена.НайтиПоКоду("ЦБ"); // Указываем код центрального узла
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаГлавный);

Проводим штатный обмен данными. Системы синхронизируют номера сообщений и продолжат работу в обычном режиме РИБ.

Таким образом, при грамотном использовании встроенных механизмов БСП и подписок на события обновление РИБ даже при пропуске нескольких релизов проходит предсказуемо и без потери данных.