Почему изменения конфигурации из главного узла РИБ не передаются в подчиненный узел в 1С и как это исправить?

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

В этой статье мы подробно разберем, почему возникает такое поведение, проанализируем его причины, связанные с особенностями платформы, и рассмотрим все доступные способы решения — от простых административных действий до тонких технических «хаков».

Выясняем причину: системный баг платформы 1С

Описанное поведение не является следствием неправильных действий пользователя или архитектурной ошибки в самой конфигурации (например, в «1С:Бухгалтерия 3.0»). Это известная системная ошибка платформы 1С:Предприятие, которая наиболее остро проявилась в версиях ветки 8.3.13 (в частности, в релизах 8.3.13.1513, 8.3.13.1690) и некоторых сборках 8.3.14.

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

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

Давайте рассмотрим пошаговые сценарии борьбы с этой проблемой и разберем, как восстановить работоспособность РИБ.

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

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

Проанализируем наши действия в зависимости от инфраструктуры:

1. Откат на стабильную ветку 8.3.12. Если ваша конфигурация позволяет работать на более ранних релизах платформы, рекомендуется временно откатиться на стабильный релиз, например, 8.3.12.1714. В этой ветке механизм обмена РИБ работает без сбоев.
2. Обновление на актуальные релизы 8.3.15 и выше. Если конфигурация требует современных возможностей платформы, необходимо обновить 1С на более свежие стабильные релизы (например, ветки 8.3.18, 8.3.20 и старше), где этот критический баг был официально исправлен разработчиками фирмы «1С».

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

Способ 2. Обходной путь через принудительную реструктуризацию

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

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

Выполним следующие действия в главном узле:

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

Способ 3. Правильная отвязка подчиненного узла для ручного обновления

В процессе устранения неполадок часто возникает необходимость временно «отвязать» подчиненный узел от главного, чтобы обновить конфигурацию периферийной базы вручную (через файл конфигурации .cf), а затем вернуть её обратно в состав РИБ.

Автор темы столкнулся с проблемой: выполнение программного кода в режиме «1С:Предприятие» не привело к желаемому результату — замок на редактирование конфигурации в подчиненном узле не снялся:

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

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

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

1. Полностью закроем все сеансы работы с подчиненной информационной базой (включая конфигуратор).
2. Откроем командную строку (cmd) операционной системы от имени администратора.
3. Выполним команду запуска конфигуратора со специальным ключом /ResetMasterNode. В зависимости от типа базы данных команда будет выглядеть следующим образом:

Для файловой информационной базы:

"C:\Program Files\1cv8\8.3.13.1513\bin\1cv8.exe" CONFIG /F "C:\ПутьКВашейБазе" /ResetMasterNode /N "ИмяАдминистратора" /P "Пароль"

Для клиент-серверной базы данных:

"C:\Program Files\1cv8\8.3.13.1513\bin\1cv8.exe" CONFIG /S "ИмяСервера\ИмяБазы" /ResetMasterNode /N "ИмяАдминистратора" /P "Пароль"

После выполнения этой команды запустим конфигуратор подчиненной базы в обычном режиме. Мы увидим, что «замочек» с конфигурации пропал, и теперь мы можем беспрепятственно обновить ее, выгрузив предварительно файл 1cv8.cf из главного узла и загрузив его в подчиненный через меню Конфигурация — Сравнить, объединить с конфигурацией из файла или полную замену через Загрузить конфигурацию из файла.

Для того чтобы вернуть базу обратно в режим РИБ после обновления, запустим в режиме «1С:Предприятие» обработку со следующим кодом:

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

Способ 4. Хак с подменой сигнатур (Digest) в XML-файле обмена

Рассмотрим еще один продвинутый метод, который позволяет обойти ошибку несоответствия конфигураций без полной перезаливки базы или ее пересоздания. Этот способ применяется, когда конфигурация в подчиненном узле фактически совпадает с главной (или вы обновили ее вручную через CF-файл), но платформа отказывается принимать файлы обмена, выдавая ошибку несоответствия версий.

При обмене платформа проверяет уникальные хэши конфигураций (Digest), которые прописываются в заголовке XML-файла обмена. Если они не совпадают с ожидаемыми, загрузка блокируется.

Давайте разберем, как скорректировать XML-файл обмена вручную:

1. Выполним выгрузку данных из проблемного подчиненного узла в файл обмена (например, получим файл Message_ПУ_ЦБ.xml). Этот файл будет содержать актуальные для периферийной базы значения Digest.
2. Откроем этот файл с помощью любого продвинутого текстового редактора (например, Notepad++) и найдем в самом начале структуру заголовка <v8de:Config>:
Скопировать код

<v8de:Config xmlns:v8de="http://v8.1c.ru/8.1/data/enterprise/current-config">
    <v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
    <v8de:Digest2>a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6</v8de:Digest2>
</v8de:Config>

3. Скопируем значение, находящееся внутри тегов <v8de:Digest2> подчиненного узла.
4. Теперь откроем файл обмена, который пришел из Главного узла и не хочет загружаться (например, Message_ЦБ_ПУ.xml).
5. Найдем в нем точно такой же блок <v8de:Config> и заменим значение его тега <v8de:Digest2> на то значение, которое мы скопировали на шаге 3 из файла подчиненной базы.
6. Сохраним изменения в файле обмена из Главного узла и попробуем загрузить его в периферийную базу.

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

Способ 5. Временный переход главного узла в файловый режим

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

Если временно перевести базу Главного узла из клиент-серверного режима (например, под управлением PostgreSQL или MS SQL) в файловый режим работы, то выгрузка изменений конфигурации начинает корректно регистрироваться и отправляться во все без исключения периферийные базы.

Для реализации этого метода:

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

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