← На главную

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

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

Почему это происходит? Проанализируем причину

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

Способ 1. Стандартная «перепривязка» конфигурации через файл .cf

Этот метод считается базовым и помогает в большинстве случаев, когда конфигурации узлов действительно идентичны, но платформа «потеряла» связь. Разберем его по шагам:

1. Откройте периферийную (подчиненную) базу в режиме Конфигуратор.
2. Для начала необходимо временно разорвать связь с главным узлом. Для этого воспользуемся обработкой или встроенным языком: ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
3. В центральной базе выполните выгрузку конфигурации в файл (Конфигурация -> Сохранить конфигурацию в файл...). Назовем его 1cv8.cf.
4. Вернитесь в периферийную базу (которая теперь стала автономной) и загрузите этот файл через меню Конфигурация -> Загрузить конфигурацию из файла.
5. Выполните обновление конфигурации базы данных (клавиша F7).
6. Теперь необходимо восстановить связь с РИБ. Выполните следующий код в периферийной базе:
   Скопировать код

   
   УзелГлавный = ПланыОбмена.ГлавныйУзел(); // Если узел уже был определен
   // Или найдите ссылку на узел вручную через ПланыОбмена.[ИмяПланаОбмена].НайтиПоКоду("КодЦентра")
   ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦентральныйУзел);
   

7. Попробуйте выполнить обмен заново.

Способ 2. Очистка кэша конфигурации (Важный нюанс)

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

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

• Локальный кэш пользователя: %AppData%\1C\1cv8\ и %LocalAppData%\1C\1cv8\. Удалите все папки с именами-идентификаторами (например, eb34a...).
• Если используется клиент-серверный вариант, попробуйте перезапустить службу 1C:Enterprise Server.

Помните: кэш может «перекочевать» вместе с файлом .dt, если вы создаете новую базу через выгрузку/загрузку данных. Поэтому для чистоты эксперимента всегда пробуйте загрузку через .cf в пустую базу.

Способ 3. Метод «Чистых баз» (Решение от автора темы)

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

1. Выгрузите .cf файл из вашей рабочей базы, используя старую версию платформы (на которой обмен работал).
2. Установите новую платформу и создайте на ней две абсолютно чистые, пустые базы.
3. Загрузите ваш .cf в обе эти базы. Одну назначьте центральной, другую — периферийным узлом.
4. В этих «чистых» базах создайте минимальные настройки (например, заполните данные об организации) и выполните несколько циклов успешного обмена (выгрузка-загрузка).
5. После того как обмен между пустыми базами на новой платформе прошел успешно, выгрузите .cf из этой «новой» центральной базы.
6. Загрузите этот «пролеченный» файл конфигурации в вашу реальную центральную базу и в распределенный узел.

Этот процесс заставляет платформу пересчитать и прописать в файл конфигурации корректные идентификаторы (Digest), специфичные для нового движка 1С.

Способ 4. Исправление Digest в файле сообщения

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

Дополнительные рекомендации

Проанализируем еще несколько моментов, которые могут влиять на результат:

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

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