← На главную

При администрировании распределенных информационных баз (РИБ) после перехода на новую версию платформы 1С:Предприятие может возникнуть неприятная ситуация: обмен данными документов и справочников продолжает функционировать в штатном режиме, однако изменения самой конфигурации из центрального узла (ЦБ) в подчиненные периферийные базы (ПБ) не уходят. При этом в формируемых XML-сообщениях обмена полностью отсутствует секция метаданных v8md:Metadata и версия v8de:Version.

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

Как работает механизм передачи метаданных в РИБ

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

1. При обновлении конфигурации базы данных в центральном узле рассчитываются контрольные суммы и сигнатуры структуры метаданных (хеши Digest1, Digest2).
2. Во время формирования файла выгрузки платформа сверяет текущую версию конфигурации ЦБ с ожидаемым состоянием узла-получателя.
3. Если обнаружено расхождение, в заголовок файла сообщения добавляется служебный блок с тегом v8md:Metadata, содержащий дельту изменений структуры, а также обновленный номер версии v8de:Version.

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

Причины сбоя фиксации изменений

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

1. Ошибки конкретных релизов платформы. В отдельных линейках (в частности, при переработке механизма расширений и версионирования в ветке 8.3.11) присутствовали платформенные ошибки. Для конфигураций на обычных формах или работающих в устаревших режимах совместимости (например, 8.2 или 8.3.6) расчет дельты метаданных переставал инициироваться.
2. Разнородные СУБД в узлах обмена. Использование разных систем управления базами данных (например, Microsoft SQL Server в главном узле и PostgreSQL в подчиненных) в некоторых сборках платформы приводило к сбоям сверки служебных таблиц версий.
3. Несовпадение версий платформы между узлами. Эксплуатация главного и подчиненных узлов на разных сборках технологической платформы приводит к ошибкам десериализации пакетов и предупреждениям о несовпадении наборов расширений.

Способ 1. Выравнивание и обновление версий платформы

Рассмотрим основной и самый надежный способ устранения проблемы, если сбой вызван ошибкой релиза платформы 1С:

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

Способ 2. Принудительный пересчет хешей метаданных в центральной базе

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

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

Способ 3. Ручная синхронизация через временное отключение главного узла

Разберем по шагам аварийный вариант обновления конфигурации подчиненного узла без использования автоматической передачи через файл обмена.

1. В центральной информационной базе сохраним файл конфигурации: меню Конфигурация -> Сохранить конфигурацию в файл... (получаем файл 1Cv8.cf).
2. Запустим периферийную базу в режиме «1С:Предприятие» и временно снимем признак подчиненности с помощью программного кода:
   Скопировать код

   
   // Отключаем главный узел в подчиненной базе
   ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
   

   Альтернативно можно запустить конфигуратор периферийной базы из командной строки с параметром: 1cv8.exe DESIGNER /IBConnectionString "..." /ResetMasterNode
3. Откроем конфигуратор подчиненной базы, перейдем в меню Конфигурация -> Загрузить конфигурацию из файла... и выберем выгруженный ранее файл 1Cv8.cf.
4. Применим изменения к базе данных (F7).
5. Восстановим привязку к центральному узлу, выполнив в режиме «1С:Предприятие» код:
   Скопировать код

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

6. После выравнивания структуры конфигураций повторим штатный сеанс обмена данными.

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