Как принудительно выгрузить обновление конфигурации в узлы РИБ

← На главную

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

Почему конфигурация перестает выгружаться в обмен

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

Рассмотрим ключевые моменты этого процесса:

Регистрация факта обновления: В системных таблицах базы данных создается запись о том, что для каждого узла необходимо выгрузить новую структуру метаданных.
Формирование сообщения: При выполнении обмена платформа включает конфигурацию в файл .xml. В этот же момент увеличивается номер исходящего сообщения для данного узла.
Фиксация отправки: Как только файл сформирован, платформа считает, что долг перед узлом выполнен. Если файл был утерян, поврежден или не загружен на стороне получателя, автоматической «довыгрузки» конфигурации не произойдет, так как с точки зрения ЦУ изменений с момента последней выгрузки не зафиксировано.

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

Способ 1. Программная регистрация изменений (Рекомендуемый)

Самый корректный и «чистый» способ решить проблему — использовать встроенный метод глобального контекста ПланыОбмена.ЗарегистрироватьИзменения(). Этот метод позволяет принудительно поставить «флаг» необходимости выгрузки любого объекта метаданных, включая саму конфигурацию, для конкретного узла.

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


// Выбираем узел, который не получил обновление
УзелОбмена = ПланыОбмена.ПоМагазинам.НайтиПоКоду("М001");

Если Не УзелОбмена.Пустая() Тогда
    // Регистрируем изменение всей конфигурации для выбранного узла
    ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, Метаданные.Конфигурация);
    Сообщить("Конфигурация успешно зарегистрирована для узла: " + УзелОбмена);
КонецЕсли;

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

Способ 2. Изменение описания конфигурации (Метод «Пробела»)

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

Разберем по шагам:

Откройте конфигуратор центрального узла.
Перейдите в свойства корневого объекта Конфигурация.
Найдите поле Комментарий или Описание.
Добавьте в конец текста обычный пробел или любой незначительный символ.
Нажмите клавишу F7 (Обновить конфигурацию базы данных).

Несмотря на простоту, этот метод крайне эффективен. Для платформы любое изменение свойств корневого объекта метаданных является сигналом к тому, что структура базы изменилась. В результате флаг регистрации обновления будет проставлен для всех узлов, включенных в РИБ. Рассмотрим минус этого способа: те магазины (узлы), которые уже успешно обновились, будут вынуждены скачать конфигурацию повторно, что может создать лишнюю нагрузку на каналы связи.

Способ 3. Сброс номера сообщения

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

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

В форме списка плана обмена для проблемного узла можно вручную изменить поля Номер отправленного и Номер принятого. Если установить «Номер отправленного» в значение 0, система может попытаться начать цикл обмена заново, однако в современных конфигурациях на базе БСП (Библиотека стандартных подсистем) этот механизм сильно кастомизирован и может не сработать без очистки регистров сведений, таких как СостояниеУзловИнформационныхБаз.

Способ 4. Очистка кэша и переподключение базы

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

Проанализируем алгоритм очистки:

Завершите все сеансы работы с базой.
Очистите содержимое папок %AppData%\1C\1Cv8\ и %LocalAppData%\1C\1Cv8\ на сервере и у пользователя.
Перезапустите службу 1C:Enterprise 8.3 Server Agent.

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