← На главную

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

Технические особенности последовательного и прямого обновления

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

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

Возможные риски при пропуске обменов между релизами

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

1. Ошибки в обработчиках обновления данных: Процедуры обновления на периферийном узле могут иметь жесткие зависимости от данных, созданных в прошлых версиях. Если данные не были обработаны последовательно, пересчет может завершиться ошибкой.
2. Расхождения в регистре сведений версий подсистем: В подчиненных узлах может сбоить регистрация текущих версий подсистем. На практике это приводит к тому, что после получения конфигурации из центрального узла периферийная база отказывается запускаться в режиме «1С:Предприятие».
3. Увеличенный объем сообщения обмена: При изменении реструктуризации за несколько релизов файл обмена между узлами существенно возрастает. Это повышает нагрузку на сеть и требования к оперативной памяти при распаковке сообщения.
4. Конфликты с отложенными обработчиками и патчами: Если в главном или подчиненном узле не завершились отложенные процедуры или установлены исправления (патчи), обмен может заблокироваться.

Варианты решения и порядок действий

Выясним, какие подходы позволяют успешно обновить распределенную базу сразу на несколько релизов.

Стандартный обмен через файл конфигурации

Если разрыв между релизами небольшой и в конфигурации не происходило кардинальных изменений структуры данных, процесс выглядит следующим образом:

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

В случае возникновения ошибок с версиями подсистем в подчиненном узле иногда требуется скорректировать записи в регистре сведений ВерсииSubsystem (или ВерсииПодсистем) вручную либо с помощью специальной обработки.

Обновление через временный отход от РИБ (отвязка узла)

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

1. В подчиненном узле отключаем связь с главным узлом. Это можно сделать запускающим параметром /ResetMasterNode или программно: ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
2. Загружаем в отвязанную периферийную базу полный файл конфигурации (.cf) целевого релиза через Конфигуратор.
3. Запускаем периферийный узел в режиме «1С:Предприятие» (при необходимости с ключом командной строки /C ВыполнитьОбновлениеИБ) и дожидаемся полного выполнения всех обработчиков.
4. Восстанавливаем связь с главным узлом программным путем:
   Скопировать код

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

5. Выполняем двусторонний обмен для выравнивания номеров сообщений.

Создание нового начального образа

Если разрыв составляет десятки релизов или структура данных в периферийной базе повреждена, наиболее надежным решением будет обновление только главного узла и последующее пересоздание периферийной базы из нового начального образа через метод ПланыОбмена.СоздатьНачальныйОбраз().