При длительной эксплуатации распределенной информационной базы нередко возникает ситуация, когда центральный узел существенно отстает от актуальной версии программы. При попытке обновить систему сразу на несколько релизов (например, на 10 ключевых версий) возникает вопрос: можно ли применить финальное обновление сразу в центральной базе и отправить его в периферийный узел через штатный обмен, либо необходимо последовательно обновлять каждый релиз шаг за шагом? Проанализируем устройство механизма РИБ, выясним технические ограничения платформы и разберем проверенные способы решения этой задачи.
Как платформа 1С передает изменения конфигурации в РИБ
Разберем распространенное заблуждение о том, что периферийный узел при получении пакета обновлений через 10 релизов будет последовательно запрашивать запуск конфигуратора 10 раз. Это утверждение технически неверно.
В распределенной информационной базе файл обмена (сообщение РИБ) не ведет и не сохраняет историю промежуточных состояний. Пакет выгрузки содержит исключительно итоговое состояние структуры метаданных на момент формирования сообщения. Подчиненный узел принимает эти изменения единоразово. Соответственно, при получении такого файла конфигурация периферийной базы потребует обновление ровно один раз для перехода на финальную структуру.
Почему скачок через несколько релизов приводит к ошибкам
Несмотря на то что платформа технически способна передать итоговую конфигурацию в одном пакете, такой переход несет в себе критические риски для целостности данных:
Пропуск промежуточных обработчиков Библиотеки стандартных подсистем (БСП). Современные типовые конфигурации выполняют миграцию данных с помощью штатных и отложенных процедур обновления. Эти алгоритмы последовательно трансформируют старые структуры реквизитов и регистров в новые от релиза к релизу. Если перепрыгнуть промежуточные версии, обработчики финального релиза обратятся к данным, которые еще не были сконвертированы предыдущими версиями. В результате алгоритмы завершаются аварийно, а данные в подчиненном узле повреждаются.
Несовместимость форматов сообщений обмена. Если за несколько версий состав объектов или состав реквизитов плана обмена кардинально изменился, узел не сможет разобрать пакет данных и завершит обмен ошибкой чтения XML.
Превышение лимитов памяти и таймауты. При масштабном расхождении структур метаданных пакет изменений получается аномально большим, что приводит к нехватке памяти или сбоям связи при передаче и разборе файла.
Способ 1. Итерационный штатный цикл обновления
Рассмотрим классический и максимально безопасный вариант обновления РИБ по цепочке релизов. Этот способ применяется без отключения узлов от плана обмена, но требует строгого соблюдения последовательности действий.
Разберем по шагам регламент для каждого промежуточного релиза:
Отключаем автоматические регламентные задания обмена в центральной и периферийной базах, чтобы избежать отправки сообщений в процессе конвертации.
В центральной базе применяем один промежуточный релиз через Конфигуратор, запускаем программу в режиме «1С:Предприятие» и обязательно дожидаемся полного завершения штатных и отложенных обработчиков обновления.
Формируем и выгружаем пакет изменений РИБ из центральной базы в периферийный узел.
В периферийной базе загружаем сообщение обмена. После предупреждения о приеме изменений конфигурации открываем Конфигуратор и применяем изменения структуры базы данных (клавиша F7).
Запускаем периферийную базу в режиме «1С:Предприятие», чтобы отработали локальные обработчики данных.
Выполняем ответную выгрузку из периферии в центр для подтверждения успешного приема конфигурации.
Повторяем весь цикл для следующего релиза цепочки.
Способ 2. Временная отвязка периферийного узла
Когда узлов много, а канал связи узкий, пересылка тяжелых пакетов по цепочке может затянуться на длительное время. В таком случае эффективнее временно отключить подчиненный узел от распределенной базы и обновить обе базы автономно через файлы обновлений (.cfu или .cf).
Разберем по шагам реализацию этого метода:
Выполняем полный двусторонний обмен данными, чтобы очистить очереди регистрации изменений в обоих узлах. Убеждаемся, что все документы и справочники синхронизированы, после чего останавливаем регламентный автообмен.
Отвязываем подчиненный узел от центра. Для этого можно запустить Конфигуратор периферийной базы со специальным командным ключом /ResetMasterNode либо выполнить программный код во внешней обработке:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После выполнения этой команды база перестает быть подчиненной и становится автономной. Теперь ее можно последовательно обновлять по всей цепочке релизов стандартным путем, обязательно запуская каждый релиз в режиме «1С:Предприятие» для корректной отработки процедур БСП.
Центральный узел обновляется параллельно или предварительно до того же финального релиза.
После того как конфигурации центра и периферии стали полностью идентичными по структуре и версии, восстанавливаем признак подчиненности. Выполняем программную привязку к главному узлу:
Проверяем соответствие номеров принятых и отправленных сообщений в планах обмена и возобновляем штатную синхронизацию.
Способ 3. Пересоздание начального образа
Рассмотрим альтернативный вариант, который подходит для небольших баз удаленных точек (например, рабочих мест кассиров), где объем данных невелик, а вся первичная информация уже передана в центр.
Центральную базу последовательно обновляют через все необходимые релизы до финального состояния, завершая все процедуры миграции данных.
Для подчиненного узла формируют новый начальный образ с помощью команды СоздатьНачальныйОбраз соответствующего плана обмена.
Старую периферийную базу архивируют и заменяют вновь созданной базой из начального образа.
Обратите внимание: при использовании этого способа потребуется заново настроить рабочие места, торговое оборудование и локальные параметры операционной системы на периферии.
Обязательные технические правила при обновлении РИБ
Перед началом работ необходимо учесть несколько критических моментов:
Резервное копирование: перед любыми манипуляциями создаем полные резервные копии как центральной, так и всех подчиненных информационных баз.
Отложенное обновление: пока в центральном узле активны отложенные обработчики обновления данных (раздел «Администрирование» — «Обслуживание» — «Обновление программы»), выгружать конфигурацию в РИБ категорически запрещено.
Исправления и патчи: перед обновлением конфигураций с активным обменом необходимо удалить или деактивировать установленные расширения-патчи, чтобы избежать ошибок несоответствия контрольных сумм метаданных при передаче изменений.