При эксплуатации распределенных информационных баз (РИБ) системные администраторы часто сталкиваются с ситуацией, когда после обновления платформы (например, переход с версии 8.3.10 на 8.3.12 и выше) обмен данными внезапно прекращается. Сообщение об ошибке гласит: «Конфигурация не соответствует ожидаемой». При детальном анализе файлов обмена (XML) выясняется, что значения в теге v8de:Digest2 в центральной и периферийной базах различаются, хотя визуально конфигурации идентичны.
В этой статье мы подробно разберем, что такое Digest2, почему он «ломается» при обновлении платформы и как привести узлы РИБ к единому знаменателю, используя проверенные методы.
Давайте проанализируем техническую природу этого параметра. Digest2 — это контрольная сумма (хэш), рассчитываемая платформой на основе содержимого системной таблицы Config. В отличие от старых механизмов проверки, второй дайджест учитывает не только структуру метаданных, но и внутренний порядок объектов, а также служебные записи, которые не видны в обычном дереве конфигурации.
Разберем основные причины, по которым хэши могут не совпадать:
Config могут остаться записи-фантомы (например, с префиксами dbConfig...). Они не влияют на работу пользователей, но попадают в расчет Digest2.Как показывает практика, простая загрузка файла конфигурации .cf из центральной базы в узлы часто не дает результата. Это происходит потому, что при обычной загрузке платформа может сохранять часть старых системных записей. Рассмотрим пошаговый алгоритм, который гарантированно выравнивает Digest2.
Шаг 1. Подготовка эталонного файла конфигурации
Выгружаем конфигурацию из центральной базы (ЦБ) в файл .cf. Далее создаем абсолютно новую, пустую информационную базу (без конфигурации). Загружаем в эту пустую базу наш файл .cf и выполняем сохранение (обновление конфигурации базы данных).
Шаг 2. Очистка метаданных
Из этой «чистой» базы снова выгружаем конфигурацию в новый файл .cf. Этот файл теперь содержит максимально очищенную структуру метаданных без истории динамических изменений и специфического мусора конкретной БД.
Шаг 3. Синхронизация узлов
Теперь самое важное: этот «чистый» файл необходимо загрузить последовательно во все узлы РИБ, включая саму центральную базу. Порядок действий для каждой базы:
.cf.После проведения этой операции во всех узлах Digest2 станет идентичным, так как платформа пересчитает хэш на основе абсолютно одинаковых данных.
Если базы работают под управлением MS SQL или PostgreSQL, мы можем попытаться устранить причину расхождения напрямую, удалив следы динамических обновлений. Выясним причину через анализ таблицы Config.
Проанализируем ситуацию: иногда в таблице остаются записи, которые мешают корректному расчету. Мы можем попробовать очистить таблицу от временных данных. Внимание! Перед выполнением любых SQL-запросов обязательно создайте резервную копию базы данных.
Типовой подход заключается в удалении записей, которые могут дублировать основную конфигурацию:
DELETE FROM Config WHERE FileName = 'commit'
DELETE FROM Config WHERE FileName = 'dbConfigConf'
DELETE FROM Config WHERE FileName LIKE 'save%'
После выполнения очистки на уровне СУБД необходимо зайти в конфигуратор, внести любое несущественное изменение (например, добавить и сразу удалить комментарий в каком-либо модуле) и выполнить обновление конфигурации базы данных. Это заставит платформу пересчитать Digest2 с нуля.
Чтобы в будущем не сталкиваться с проблемой v8de:Digest2, придерживайтесь следующих правил:
Local AppData.Рассмотрим также нюанс с расширениями. В некоторых версиях платформы наличие активных расширений может влиять на формирование заголовка сообщения обмена. Если вышеописанные методы не помогли, попробуйте временно отключить расширения во всех узлах и проверить прохождение обмена.
Использование метода с «прокачкой» конфигурации через пустую базу является наиболее надежным, так как оно позволяет решить проблему без прямого вмешательства в структуру таблиц СУБД, сохраняя при этом целостность данных и логику работы платформы 1С:Предприятие 8.