Почему в центральном узле РИБ возникает ошибка конфигурация не соответствует ожидаемой и как её исправить?

← На главную

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

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

Анатомия заголовка сообщения РИБ: назначение тегов Digest1 и Digest2

Рассмотрим структуру XML-пакета, который формируется подчиненным узлом при выгрузке данных в центральный узел:


<v8msg:Header>
    <v8msg:ExchangePlan>ПоМагазину</v8msg:ExchangePlan>
    <v8msg:To>дд</v8msg:To>
    <v8msg:From>бо</v8msg:From>
    <v8msg:MessageNo>1373</v8msg:MessageNo>
    <v8msg:ReceivedNo>1525</v8msg:ReceivedNo>
</v8msg:Header>
<v8msg:Body>
    <v8de:Changes xmlns:v8="http://v8.1c.ru/data" xmlns:v8de="http://v8.1c.ru/dataexchange/2005/02">
        <v8de:Signature>083db94f-d53a-493f-b85e-e9bb9b18d864</v8de:Signature>
        <v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
            <v8de:Version>216.0</v8de:Version>
            <v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
            <v8de:Digest2 v2="1883fd09d48778053832d043152fce85">a645a0ddf22d9b29acf73b0c515f4e84</v8de:Digest2>
        </v8de:Config>

Проанализируем ключевые элементы блока Config:

v8de:Digest1 — контрольная сумма конфигурации до применения изменений. В исходящих сообщениях от подчиненных узлов этот тег всегда заполнен нулями (00000000000000000000000000000000), так как подчиненный узел не может передавать изменения конфигурации в центр.
v8de:Digest2 — хэш-сумма текущей конфигурации базы данных, выгрузившей пакет.
Атрибут v2 внутри Digest2 — это алгоритмический хэш структуры метаданных, рассчитываемый платформой «на лету» в момент выгрузки. Именно он сопоставляется центральным узлом с ожидаемым значением. Если атрибут v2 в одном сеансе имеет значение 1883fd09d48778053832d043152fce85, а через некоторое время — 490478325d9db6322ebaa66796df8b3a, центральный узел отвергает файл с ошибкой несовпадения конфигурации.

Основные причины плавающего изменения хэша конфигурации

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

Работа копии базы (базы-клона). Наиболее частая причина на практике: для тестирования, разработки или восстановления после сбоя была развернута копия подчиненного узла. Если в этой копии забыли отключить выполнение регламентных заданий или регламентный скрипт планировщика ОС, обе базы (рабочая и копия) начинают поочередно формировать файлы в один и тот же общий каталог. Если в копии конфигурация хоть немного отличается, центральный узел будет периодически получать файлы с «чужим» хэшем.
Рассинхронизация кэша рабочих процессов кластера (rphost). Если база функционирует в клиент-серверном варианте с несколькими рабочими процессами, а ранее выполнялось динамическое обновление («демоническое обновление»), в оперативной памяти разных процессов rphost может оставаться старый кэш метаданных. Задание на выгрузку, попадая на разные процессы, будет вычислять разный хэш.
Запуск выгрузки разными релизами платформы или разной разрядностью (x86 и x64). Если обмен запускается параллельно несколькими путями (например, регламентным заданием сервера x64 и задачей планировщика Windows через 32-разрядный толстый/тонкий клиент), алгоритм обхода метаданных и сериализации XML может незначительно отличаться, порождая другой v2.
Влияние расширений конфигурации и автоматических патчей. Если в базе включена фоновая загрузка исправлений (патчей) от фирмы «1С» или используются расширения, меняющие структуру данных, их динамическое подключение/отключение в фоновых сеансах приводит к изменению результирующего хэша метаданных.
Повреждение таблицы Config в СУБД. Наличие фантомных записей и рассинхронизация внутренних идентификаторов объектов после сбоев динамического обновления.

Шаг 1: Изоляция каталогов и поиск базы-двойника

Первым делом проверим гипотезу о несанкционированной выгрузке из сторонней копии базы. Выполним следующие действия:

В центральном узле и в проблемном подчиненном узле перенастроим путь обмена на совершенно новую сетевую папку или создадим отдельный FTP-каталог с новыми учетными данными.
Удалим старый общий каталог или заблокируем к нему доступ.
Проверим журнал аудита сетевой папки: если к старому каталогу продолжают поступать попытки записи с неизвестных IP-адресов или рабочих станций, мы обнаружим забытую копию.
В подчиненном узле откроем Журнал регистрации и отфильтруем события по номеру ошибочного сообщения (например, MessageNo 1373). Обратим внимание на имя компьютера, пользователя, версию приложения и идентификатор сеанса, сформировавшего проблемный файл.

Шаг 2: Очистка серверного кэша и перезапуск процессов

Для исключения влияния застрявшего кэша рабочих процессов кластера серверов выполним полную перезагрузку службы:

Завершим все активные пользовательские и фоновые сеансы в проблемной базе.
Остановим службу агента сервера 1С:Предприятия (ragent).
Перейдем в каталог данных кластера (по умолчанию srvinfo) и удалим содержимое папок контекста сеансов (каталоги вида snccntx*).
Очистим временные файлы пользователя, от имени которого работает служба сервера 1С (папки AppData\Local\Temp).
Запустим службу ragent заново.

Шаг 3: Полная пересинхронизация конфигурации через .cf

Если смена каталогов и очистка кэша не помогли, необходимо устранить внутренние расхождения структуры метаданных между центром и подчиненным узлом. Разберем пошаговый алгоритм «лечения» узла РИБ:

Отключим подчиненный узел от главного узла РИБ. Для этого в подчиненной базе выполним в режиме 1С:Предприятие следующий программный код:
```
ПланОбменаУзел = ПланыОбмена.ПоМагазину.ЭтотУзел().ПолучитьОбъект();
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
ПланОбменаУзел.Записать();
```
В центральной информационной базе откроем Конфигуратор и выгрузим эталонную конфигурацию в файл (меню Конфигурация → Сохранить конфигурацию в файл...).
Откроем Конфигуратор подчиненной базы (которая теперь работает как автономная база без главного узла) и выполним полную загрузку конфигурации: меню Конфигурация → Загрузить конфигурацию из файла..., выбрав сохраненный .cf. Применим изменения клавишей F7.

Вернем признак подчиненности РИБ, снова назначив центральный узел главным:


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

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

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