← На главную

Развертывание распределенных информационных баз (РИБ) — это проверенный и надежный способ масштабирования систем на платформе 1С:Предприятие 8.3. Однако при использовании РИБ с фильтрами (например, с отбором по конкретной организации, складу или подразделению) администраторы и разработчики часто сталкиваются с неочевидными системными сбоями. Одна из самых распространенных и неприятных проблем в конфигурациях на базе Библиотеки стандартных подсистем (БСП), таких как Управление торговлей 11.4, — это сбой инициализации справочника Идентификаторы объектов метаданных при первом запуске нового подчиненного узла.

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

Выясняем причины: почему возникает ошибка «Идентификаторы объектов метаданных»?

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

Проанализируем три главные причины, почему это происходит именно в РИБ с фильтрами:

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

Способ 1. Принудительное обновление и выгрузка метаданных на стороне Главного узла

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

1. Запуск обновления информационной базы через параметр. Попробуем принудительно запустить обработчики обновления БСП. Для этого запустим базу главного узла через командную строку или настройки ярлыка с параметром /C ЗапуститьОбновлениеИнформационнойБазы.
2. Программное обновление справочника идентификаторов. Если стандартное обновление не помогло, выполним полное обновление справочника программным путем. Откроем в главном узле обработку «Групповая обработка справочников и документов» или воспользуемся встроенной обработкой выполнения произвольного кода и запустим следующий метод:
   Скопировать код

   
   Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника(Истина, Истина);
   

   Переданные параметры Истина, Истина указывают системе на необходимость полной перезаписи всех существующих элементов справочника и очистки устаревших записей, включая данные подключенных расширений.
3. Искусственное изменение версии конфигурации. Если БСП считает, что обновлять данные не нужно, мы можем принудительно инициировать этот процесс. Зайдем в конфигуратор главного узла, незначительно изменим номер версии конфигурации (например, увеличим последнюю цифру версии на единицу), сохраним изменения и запустим базу в пользовательском режиме. Это принудительно запустит весь цикл обработчиков обновления.
4. Ручная регистрация идентификаторов к выгрузке. Откроем обработку «Регистрация изменений для обмена» для нашего подчиненного узла. Найдем в списке справочник Идентификаторы объектов метаданных и зарегистрируем абсолютно все его элементы для выгрузки в данный узел. Только после этого запустим создание начального образа заново.

Способ 2. Обходной путь через временную отвязку подчиненного узла

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

Рассмотрим этот алгоритм детально:

1. Запустим подчиненный узел в режиме «1С:Предприятие» и отключим связь с главным узлом. Для программной отвязки в подчиненном узле выполним код: ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
2. Теперь, когда база считает себя автономной, запустим в ней внешнюю обработку «Обновление идентификаторов объектов метаданных» (ее можно найти на официальных ресурсах 1С) либо выполним стандартное обновление через код, аналогично главному узлу.
3. После успешного заполнения справочника восстановим связь с главным узлом, программно указав ссылку на узел главного офиса:
   Скопировать код

   
   УзелГлавногоОфиса = ПланыОбмена.НайтиПоКоду("КодГлавногоУзла");
   Если ЗначениеЗаполнено(УзелГлавногоОфиса) Тогда
       ПланыОбмена.УстановитьГлавныйУзел(УзелГлавногоОфиса);
   КонецЕсли;
   

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

Часто после ручного отключения и обратного подключения подчиненного узла (как описано в Способе 2) администраторы сталкиваются со следующей ошибкой: Нельзя организовать обмен данными с текущим узлом информационной базы. Выясним причину этой неполадки.

Эта ошибка указывает на то, что в подчиненной базе сбилась идентификация «Этого узла» и «Главного узла» в плане обмена. Каждый узел РИБ должен четко понимать свою роль: узел, в котором мы находимся, должен быть помечен как «Этот узел» (зеленый кружок или специальный значок в списке), а узел центрального офиса должен быть обычным элементом списка с соответствующим кодом. Если при ручной привязке коды узлов были перепутаны, стерты или задвоены, система попытается выполнить обмен «сама с собой», что заблокирует процесс.

Выполним следующие шаги для исправления ситуации:

1. Откроем план обмена, по которому настроена синхронизация данных.
2. Найдем элемент, помеченный пиктограммой «Этот узел» (текущая база). Проверим его Код и Наименование. Они должны строго соответствовать коду и наименованию подчиненного узла (например, «ФИЛ01»), заданным в главном узле.
3. Найдем второй элемент — узел главного офиса. Его Код должен строго совпадать с кодом главного узла в центральной базе (например, «ЦБ»).
4. Перейдем в настройки синхронизации данных. Проверим параметры подключения. В сценарии обмена в качестве узла-корреспондента должен быть выбран именно узел главного офиса, а не текущий узел. Если настройки обмена сбились, рекомендуется удалить текущую настройку синхронизации и создать ее заново, указав правильные узлы.

Дополнительный лайфхак: Быстрое создание узла РИБ с фильтрами без долгой генерации образа

Создание начального образа для крупных баз УТ 11.4 с установленными фильтрами — это крайне ресурсоемкий процесс. База данных вынуждена «на лету» рассчитывать правила регистрации для миллионов строк документов и регистров, что часто приводит к зависаниям или ошибкам СУБД.

Рассмотрим альтернативный, значительно более быстрый метод развертывания подчиненного узла:

1. Создадим полную копию (бэкап) базы данных Главного узла.
2. Развернем эту копию на целевом сервере подчиненного узла. На данном этапе эта копия полностью идентична главной базе и считает себя главным узлом.
3. Запустим эту копию в режиме «1С:Предприятие» и выполним программное преобразование ее в подчиненный узел с помощью кода:
   Скопировать код

   
   УзелЦентра = ПланыОбмена.НайтиПоКоду("ЦБ"); // укажите код вашего главного узла
   Если ЗначениеЗаполнено(УзелЦентра) Тогда
       ПланыОбмена.УстановитьГлавныйУзел(УзелЦентра);
   КонецЕсли;
   

4. После выполнения этого кода база перезапустится уже как полноценный подчиненный узел РИБ. Важное преимущество: справочник Идентификаторы объектов метаданных в ней гарантированно заполнен и на 100% совпадает с главным узлом!
5. Теперь нам нужно очистить эту базу от «лишних» данных, которые не должны в ней находиться согласно фильтрам обмена (например, документы по другим организациям). Для этого запустим стандартную обработку БСП «Очистка данных по правилам обмена» или воспользуемся типовым механизмом свертки и удаления неиспользуемых объектов. Этот метод позволяет запустить новый узел за считанные часы вместо многодневных попыток выгрузить начальный образ стандартным путем.

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