Как восстановить работу РИБ после неудачного обновления с расширениями и патчами?

← На главную

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

Выясним причину бесконечной выгрузки данных

Рассмотрим ситуацию: после обновления ЦБ и установки патчей (например, для поддержки формата ЭДО 5.03) подчиненный узел перестает принимать изменения. При этом каждый последующий сеанс обмена приводит к тому, что центральная база формирует сообщение огромного объема, содержащее сотни тысяч объектов справочника ИдентификаторыОбъектовМетаданных.

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

Проанализируем ошибку «неподтвержденной отмены главного узла»

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

Когда мы пытаемся "починить" базу вручную, отвязывая её от главного узла с помощью команды ПланыОбмена.УстановитьГлавныйУзел(Неопределено), база переходит в особый режим. В этом состоянии блокируются любые операции со справочниками метаданных, так как система ожидает либо окончательного превращения в автономную базу, либо восстановления связи. Попытки загрузить конфигурацию в таком режиме часто приводят к тому, что справочник идентификаторов объектов метаданных становится неконсистентным.

Пошаговое решение проблемы восстановления РИБ

Разберем алгоритм действий, который поможет выйти из этого тупика и нормализовать обмен.

Анализ Журнала регистрации: Прежде всего, в подчиненном узле необходимо открыть журнал регистрации и найти события с уровнем "Ошибка" в момент загрузки данных обмена. Чаще всего там будет фигурировать конкретное расширение или патч (например, с префиксом EF_), который не может быть применен из-за конфликта имен или структуры.
Очистка расширений в центральной базе: Если расширение стало нерабочим после обновления основной конфигурации, его необходимо удалить или обновить в ЦБ. Если проблема вызвана патчем (например, EF_00_00687314_10), попробуем временно удалить его в ЦБ и выполнить обмен, чтобы узлы также получили команду на его удаление.
Сброс регистрации изменений в ЦБ: Чтобы прекратить выгрузку 700 тысяч объектов идентификаторов метаданных, воспользуемся обработкой «Регистрация изменений для обмена данными». Выберем проблемный узел и принудительно снимем с регистрации изменения по справочнику ИдентификаторыОбъектовМетаданных и по самой конфигурации.
Восстановление связи в подчиненном узле: Если узел был "отвязан", выполним программный код для восстановления привязки к главному узлу. Рассмотрим пример кода, который нужно запустить в подчиненном узле:
```
// Устанавливаем ссылку на главный узел (замените "ЦБ" на код вашего главного узла)
УзелГлавный = ПланыОбмена.ПоМагазину.НайтиПоКоду("ЦБ");
ПланыОбмена.УстановитьГлавныйУзел(УзелГлавный);
```
Обновление идентификаторов объектов метаданных: После восстановления связи и удаления проблемных расширений необходимо принудительно обновить справочник идентификаторов. Это можно сделать через функции БСП. Разберем выполнение этой команды:
```
Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника(Истина, Ложь);
```
Это позволит сопоставить текущую конфигурацию с записями в справочнике без блокировок.

Как избежать повторения ситуации

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

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

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

← На главную