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

← На главную

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

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

Глубинные технические причины проблемы: почему ломается механизм РИБ

Механизм распределенных баз данных 1С отслеживает идентичность конфигураций в узлах с помощью расчета специальных контрольных сумм (хэшей). В XML-файлах обмена эти данные передаются в заголовке сообщения внутри системного блока v8de:Config в виде тегов v8de:Digest1 и v8de:Digest2.

Digest1 — это уникальный хэш схемы метаданных (структуры таблиц базы данных). Если вы добавили реквизит, справочник или документ, этот хэш гарантированно меняется.

Digest2 — это хэш прикладного кода (текстов программных модулей, экранных форм, макетов). Он меняется при изменении логики без изменения структуры СУБД.

Рассмотрим, как происходит сбой синхронизации. Если в центральной базе было выполнено динамическое обновление (так называемое «демоническое» обновление) или произошел сетевой сбой во время отправки/приема пакета, хэши в ЦБ пересчитываются, но в периферийную базу уходит некорректная информация. Если ПБ отправляет ответное сообщение со старыми хэшами, а ЦБ его успешно принимает, в таблицах регистрации изменений центральной базы (в частности, в системной таблице Config) сбрасывается признак того, что конфигурация ПБ устарела. С точки зрения платформы «все хорошо», обмен идет, но конфигурация в ПБ физически не обновляется.

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

Также не стоит забывать про кэш сервера приложений. При динамическом обновлении новые метаданные записываются в базу данных, но служба сервера 1С продолжает удерживать в оперативной памяти старую версию конфигурации. При формировании файла обмена платформа берет старые хэши из серверного кэша, из-за чего ПБ считает, что обновлений нет.

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

Метод 1. Подергивание свойств корня конфигурации (Без динамического обновления)

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

Выполним следующие шаги:

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

Этот метод гарантированно перезапишет контрольные суммы и принудительно выставит признак необходимости обновления для всех зарегистрированных узлов обмена.

Метод 2. Принудительное изменение структуры базы (Реструктуризация)

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

Разберем по шагам, как это сделать:

В конфигураторе центральной базы создадим новый пустой объект метаданных. Лучше всего использовать простую Константу с типом Булево и назвать ее, например, ВременнаяКонстантаДляСинхронизации.
Обновим конфигурацию базы данных (клавиша F7) в монопольном режиме.
Это действие инициирует создание физической таблицы в СУБД. Платформа сформирует новую версию схемы метаданных и автоматически зарегистрирует изменения конфигурации для всех подчиненных узлов плана обмена.
Выполним выгрузку обмена из ЦБ и загрузку в ПБ.
После того как все периферийные базы успешно примут обновление и обновят свои структуры данных, эту временную константу в центральной базе можно будет безболезненно удалить и снова запустить штатный обмен.

Метод 3. Сброс номеров сообщений в плане обмена

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

Для этого в периферийной базе выполним следующий код (например, через групповую обработку данных или внешнюю обработку):


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

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

Метод 4. Очистка кэша сервера приложений 1С

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

Выполним процедуру по следующему алгоритму:

Остановим службу сервера 1С:Предприятие (1C:Enterprise 8.3 Server Agent).
Перейдем в каталог расположения файлов сервера приложений. По умолчанию на ОС Windows это: C:\Program Files\1cv8\srvinfo\reg_1541\.
Найдем внутри рабочего каталога базы папки с именем snccntx. Это кэш сеансовых данных. Полностью удалим содержимое этих папок.
Также рекомендуется очистить каталоги временных файлов сервера (папки формата dbg и временные файлы пользователя, под которым запускается служба сервера 1С).
Запустим службу сервера заново. При первом обращении к базе хэши Digest1 и Digest2 пересчитаются физически из таблиц СУБД, и корректный пакет обмена будет готов к отправке.

Метод 5. Обход проверки хэшей через редактирование XML (Dirty Hack)

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

Рассмотрим этот алгоритм детально:

Сформируем файл выгрузки из центральной базы (например, Message_ЦБ_ПБ.xml).
Откроем этот файл в текстовом редакторе, поддерживающем работу с крупными файлами (например, Notepad++ или VS Code).
Найдем в самом начале структуру заголовка и блок <v8de:Config>.
Заменим значение тега <v8de:Digest1> на нулевую последовательность: <v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>.
Сохраним изменения в файле.
Попробуем выполнить загрузку измененного файла в периферийной базе. Увидев нулевой хэш схемы, платформа пропустит строгую сверку метаданных структуры и позволит успешно применить и обновить прикладной код конфигурации.

Метод 6. Экстренное отключение главного узла через командную строку

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

Чтобы не использовать сторонние обработки, отключить главный узел в периферийной базе можно напрямую через командную строку Windows (cmd):


"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" CONFIG /F "C:\Put_K_Base\PeripheralDB" /ResetMasterNode /N "Администратор" /P "Пароль"

После выполнения этой команды база мгновенно становится автономной (не подчиненной). Теперь мы можем выполнить следующие действия:

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


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

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

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