При обновлении платформы 1С до последних релизов (особенно версий 8.3.22, 8.3.23 и выше) системные администраторы и программисты часто сталкиваются с критическим сбоем в работе распределенных информационных баз (РИБ). Проблема проявляется в невозможности завершить обмен: даже после ручного обновления конфигурации периферийной базы (ПБ) через .cf файл, система выдает ошибку соответствия конфигурации или сообщает о невозможности загрузки «приоритетных данных». Рассмотрим подробно, почему это происходит и как восстановить работоспособность обмена по шагам.
Первым делом проанализируем ситуацию. Ошибка «Конфигурация узла распределенной ИБ не соответствует ожидаемой» означает, что в сообщении обмена из центральной базы (ЦБ) пришел блок с изменениями метаданных, который платформа считает несовместимым с текущим состоянием периферийной базы. В современных версиях конфигураций, построенных на БСП (Бухгалтерия предприятия 3.0, ЗУП 3.1, УТ 11), к этому добавляется проблема приоритетных данных.
К приоритетным данным относятся Идентификаторы объектов метаданных и Предопределенные элементы. Если после обновления платформы или конфигурации внутренние идентификаторы (GUID) в базах разошлись, стандартный механизм РИБ блокирует загрузку любых данных до тех пор, пока структура не станет идентичной. Ситуация осложняется тем, что обычная выгрузка/загрузка конфигурации через файл .cf не всегда сбрасывает флаг «ожидаемого обновления» в служебных таблицах базы данных.
Выясним, как заставить центральную базу «забыть» о том, что она должна отправить изменения конфигурации в периферийный узел. Даже если мы обновили ПБ вручную, в ЦБ в плане обмена может висеть регистрация изменений метаданных. Проанализируем программный способ очистки.
Для этого в центральной базе воспользуемся обработкой «Консоль кода» или создадим внешнюю обработку со следующим фрагментом:
// Выбираем узел, для которого нужно очистить регистрацию
УзелОбъекта = ПланыОбмена.РИБ_По_Организациям.НайтиПоКоду("УБ001");
// Замените на ваш план обмена и код узла
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбъекта);
Метод УдалитьРегистрациюИзменений с передачей только одного параметра (ссылки на узел) полностью очищает все зарегистрированные изменения для этого узла, включая данные и конфигурацию. Это позволит сформировать «пустой» файл обмена, который поможет синхронизировать номера сообщений без попытки обновить метаданные.
Если после очистки регистрации возникла ошибка «Ошибка загрузки приоритетных данных из сообщения обмена», это явный признак проблем со справочником ИдентификаторыОбъектовМетаданных. Рассмотрим, как принудительно обновить этот справочник в периферийной базе. Для этого в ПБ нужно запустить следующий код:
ПараметрыОбновления = Справочники.ИдентификаторыОбъектовМетаданных.ПараметрыОбновленияДанных();
ПараметрыОбновления.ВыполнятьОбновление = Истина;
ПараметрыОбновления.ЗаписыватьТолькоИзмененные = Ложь;
Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника(Истина, Истина);
Этот процесс может занять несколько минут. После завершения система перечитает все объекты метаданных и актуализирует их GUID в справочнике. Проанализируем ситуацию: часто именно это действие позволяет платформе корректно сопоставить данные из XML-файла с объектами в базе.
Посмотрим на ситуацию, когда очистка регистрации не помогла, и файл обмена все равно содержит информацию об обновлении, которую ПБ не может принять. В этом случае применим «хирургический» метод — редактирование самого файла сообщения. Разберем по шагам:
v8:ConfigChanges. Внутри этого тега находится описание изменений структуры базы данных.<v8:ConfigChanges> и закрывающим </v8:ConfigChanges> тегами.Этот метод заставляет периферийную базу думать, что изменений в конфигурации нет, и она приступает к загрузке обычных данных. Это эффективный способ «протолкнуть» обмен, если вы точно знаете, что конфигурации в обеих базах уже идентичны (например, после ручной загрузки .cf).
Проанализируем методику ручного обновления, которая исключает появление подобных ошибок. Если стандартный обмен «лёг», рекомендуем следовать строгому алгоритму восстановления связи через временное снятие ПБ с поддержки РИБ. Рассмотрим эту последовательность:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
.cf), выгруженную из центральной базы.
ЦентральныйУзел = ПланыОбмена.РИБ_По_Организациям.НайтиПоКоду("ЦБ");
ПланыОбмена.УстановитьГлавныйУзел(ЦентральныйУзел);
Такой подход гарантирует, что на момент восстановления связи конфигурация ПБ полностью соответствует ЦБ, а все служебные данные (те самые «приоритетные данные») уже корректно инициализированы в пользовательском режиме.
Выясним, какие еще факторы могут влиять на ошибку. На новых платформах 1С (начиная с 8.3.22) работа с кэшем конфигурации стала более сложной. Иногда «призрак» старой конфигурации остается в серверном кэше. Рекомендуем выполнить следующие действия:
srvinfo (содержимое папок reg_1541, исключая файлы журналов регистрации).Рассмотрим также влияние фоновых заданий. Перед загрузкой «тяжелого» обновления в РИБ рекомендуется отключить регламентные задания, особенно полнотекстовый поиск. Индексация может блокировать таблицы метаданных, что приводит к ошибке при попытке системы прочитать приоритетные данные из файла обмена.
Мы проанализировали основные способы решения проблемы с РИБ на новых платформах. Главный секрет успеха заключается в синхронизации не только объектов метаданных (через .cf), но и системных идентификаторов. Использование метода ПланыОбмена.УдалитьРегистрациюИзменений(Узел) в сочетании с обновлением справочника идентификаторов объектов метаданных в большинстве случаев позволяет восстановить обмен без потери данных. Если же ситуация критическая — ручная правка XML-файла остается самым надежным инструментом «реанимации» распределенной системы.