Обновление тяжелых конфигураций, таких как 1С:ERP Управление предприятием, в условиях распределенной информационной базы (РИБ) — это всегда вызов для технического специалиста. В отличие от старых решений (например, УПП), современная ERP построена на базе Библиотеки стандартных подсистем (БСП), что привносит множество нюансов в процесс миграции данных и обновления метаданных. Проанализируем стандартную методику, разберем возможные коллизии и выясним, как минимизировать риски при переходе на новые релизы.
Рассмотрим классическую последовательность действий, которая считается наиболее безопасной. Нам необходимо обеспечить полную синхронность данных до начала внесения изменений в структуру конфигурации. Разберем этот процесс по шагам:
.cf или .cfu) в центральную базу через конфигуратор. Применяем изменения.Проанализируем важный аспект современной платформы 1С:8.3 — разделение обработчиков обновления на две очереди. В 1С:ERP после обновления конфигурации запускается механизм БиблиотекиСтандартныхПодсистем. Выясним, почему это критично для РИБ:
Оперативные обработчики выполняются немедленно. Они подготавливают структуру данных, без которой работа системы невозможна. Пока они не завершены в центральном узле, передавать изменения в периферию нельзя, так как данные могут оказаться в промежуточном состоянии.
Отложенные обработчики могут выполняться в фоновом режиме в течение нескольких часов или даже дней. Они обрабатывают большие массивы данных (например, пересчет регистров себестоимости). В РИБ эти обработчики запускаются независимо в каждом узле. Хорошей практикой считается дождаться завершения критичных отложенных обработчиков в центре перед началом активного обмена документами.
Часто возникает вопрос: не произойдет ли затирание данных, если и в центре, и в периферии одновременно запустятся процедуры обновления? Посмотрим, как работает механизм разрешения конфликтов в РИБ.
По умолчанию в платформе 1С реализовано правило: приоритет всегда за корневым (центральным) узлом. Если один и тот же объект был изменен процедурой обновления в центре и аналогичной процедурой в подчиненном узле, то при следующем обмене данные из центра «перекроют» данные в периферии. Это нормальное поведение, так как алгоритмы обновления идентичны.
Однако стоит учитывать свойство ОбменДанными.Загрузка = Истина. Большинство типовых обработчиков обновления используют этот флаг, чтобы избежать циклической регистрации изменений. Но в сложных регистрах ERP изменения все равно могут мигрировать, создавая избыточную нагрузку на каналы связи.
Выясним причину одной из самых неприятных ошибок: «Загрузка приоритетных данных завершилась неудачно». Эта ситуация часто связана с обновлением предопределенных элементов. В новых версиях ERP платформа пытается синхронизировать предопределенные данные (справочники, виды характеристик) особым образом.
Если вы столкнулись с такой проблемой, проанализируем возможные варианты решения:
МетаданныеОбъекта = Метаданные.Справочники.ИмяСправочника;
УстановитьОбновлениеПредопределенныхДанных(МетаданныеОбъекта, ОбновлениеПредопределенныхДанных.Авто);
В крайних случаях специалисты прибегают к временному отключению периферийного узла от РИБ, обновлению его как автономной базы и последующему «подключению» обратно с восстановлением первичных идентификаторов.
Рассмотрим ситуацию, когда необходимо обновить ERP, пропустив 3-5 промежуточных релизов. Выполнять последовательно цепочку «Центр — Периферия» для каждого релиза крайне долго. Можно ли упростить процесс?
Опытные разработчики предлагают следующую методику:
.cf) в копии базы, пройдя все этапы обновления последовательно.Важное предупреждение: такой метод значительно повышает риск ошибок в регистрах сведений, которые отвечают за ключи аналитики. Если в промежуточных релизах менялась логика формирования этих ключей, периферийная база может некорректно сопоставить старые данные с новыми структурами без промежуточных обменов.
Чтобы процесс прошел гладко, придерживайтесь следующих правил:
Во-первых, перед обновлением очищайте кэш на серверах и рабочих станциях. Кэш метаданных часто становится причиной «необъяснимых» падений при первом запуске после обновления.
Во-вторых, обратите внимание на расширения конфигурации. В стандартном РИБ расширения не передаются автоматически между узлами. Если ваша логика ERP доработана через расширения, их необходимо обновить в периферийных узлах вручную одновременно с основной конфигурацией.
В-третьих, проанализируйте объем таблиц регистрации изменений после выполнения обработчиков. Процедуры обновления могут пересчитать миллионы строк в регистрах. Чтобы не «положить» канал связи огромным пакетом обмена, можно временно отключить регистрацию изменений для тяжелых регистров (таких как РегистрНакопления.ВыручкаИПродажиЗапасов), если вы уверены, что обработчики на местах отработают идентично.
Для мониторинга состояния обработчиков используйте стандартную форму «Результаты обновления программы» (раздел Администрирование — Обслуживание). Убедитесь, что статус «Все процедуры обновления завершены» достигнут в каждом из узлов распределенной системы.