При работе с распределенными информационными базами (РИБ) в конфигурации «1С:Розница 2.3» специалисты часто сталкиваются с ситуацией, когда стандартное создание начального образа становится невозможным. Основная причина — огромный объем накопленных изменений (миллионы записей регистрации), которые система пытается включить в образ, даже если фактические данные по магазину не требуются. В данной статье мы разберем, как корректно выполнить ручную привязку узла, почему метод УстановитьГлавныйУзел() может не срабатывать и как обойти проблему «раздутого» начального образа.
Рассмотрим ситуацию: вы создали пустую базу из cf-файла, перенесли справочники и пытаетесь программно назначить главный узел. Процедура выполняется без ошибок, но узел не устанавливается. Проанализируем основные причины этого поведения.
Первая и самая важная причина — рассинхронизация внутренних идентификаторов (UUID). Платформа 1С:Предприятие идентифицирует объекты обмена не по коду или наименованию, а по уникальному идентификатору. Если вы создали узел «Центральный склад» в новой базе вручную, его GUID будет отличаться от того, который имеет «ЭтотУзел» в центральной базе. В результате система «не узнает» базу при попытке обмена.
Чтобы убедиться в идентичности GUID, мы можем выполнить следующий запрос в консоли в обеих базах:
ВЫБРАТЬ
Ссылка,
Ссылка.УникальныйИдентификатор() КАК УИД
ИЗ
ПланОбмена.ПоМагазинам
ГДЕ
ЭтотУзел = ИСТИНА
Важное решение: при ручном переносе узлов через обработку «Выгрузка и загрузка данных XML» обязательно устанавливайте флаг «Загружать объекты с сохранением их уникальных идентификаторов». Только в этом случае программная привязка через ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаУзел) отработает корректно.
Выясним причину, по которой создание начального образа может генерировать 6 миллионов записей. Это происходит из-за механизма автоматической регистрации изменений для новых узлов. Рассмотрим эффективный алгоритм создания «легкого» образа, который позволит избежать многочасового ожидания:
UUID.После успешной привязки узла вы можете столкнуться с тем, что при каждом запуске программы «Розница» запускается процедура обновления информационной базы. Разберем, почему это происходит в базах на базе БСП (Библиотеки стандартных подсистем).
Система хранит сведения о версии конфигурации и статусе обновления в специализированных регистрах и константах. Если база была создана путем «накатывания» cf на пустую оболочку, справочник ИдентификаторыОбъектовМетаданных может быть заполнен некорректно или содержать ссылки, не соответствующие реальным таблицам базы.
Для исправления ситуации попробуем запустить базу с параметром командной строки:
/C ЗапуститьОбновлениеИнформационнойБазы
Также проанализируем состояние константы СведенияОбОбновленииИБ. Если программная привязка была выполнена некорректно, БСП может считать, что база находится в процессе миграции, и бесконечно пытаться завершить обработчики обновления.
Даже если узел привязан и база открывается, обмен может не идти, так как «центр и дочка не видят файлы». Проанализируем настройки планов обмена. В каждом узле есть два ключевых реквизита: Номер отправленного и Номер принятого.
В новой базе эти счетчики сброшены в 0. Если центральная база уже отправила в сторону этого магазина (или его предшественника) 500 сообщений, она будет ожидать от дочерней базы подтверждение получения именно 500-го сообщения. Сообщение с номером 1 будет просто проигнорировано.
Посмотрим, как выровнять номера сообщений программно в дочерней базе:
ОбъектУзла = ПланыОбмена.УстановитьГлавныйУзел().ПолучитьОбъект();
ОбъектУзла.НомерОтправленного = 0; // Начинаем с нуля
ОбъектУзла.НомерПринятого = НужныйНомерИзЦентра;
ОбъектУзла.Записать();
Обратим внимание на нюанс, упомянутый в обсуждении: иногда метод УстановитьГлавныйУзел() не срабатывает на серверной (SQL) базе, но успешно отрабатывает после выгрузки в файловую (через .dt). Это связано с необходимостью монопольного доступа к базе данных для изменения статуса главного узла.
В серверном режиме фоновые задания (регламентные операции БСП) могут запускаться автоматически сразу после старта службы, блокируя монопольный режим. В файловом варианте контролировать отсутствие подключений проще. Если вы работаете на сервере, перед выполнением кода привязки убедитесь, что все сеансы и фоновые задания завершены через консоль администрирования кластера 1С.
Подведем итоги. Чтобы вручную и корректно настроить РИБ, когда стандартный механизм не справляется, мы должны соблюдать следующую последовательность действий:
ПрефиксУзлаРаспределеннойИнформационнойБазы.ИдентификаторыОбъектовМетаданных через стандартные обработки поддержки БСП.Следуя этим шагам, мы сможем восстановить работоспособность распределенной сети даже в самых сложных случаях, когда типовые средства 1С выдают ошибки из-за объема данных или конфликта метаданных. Для наглядного контроля дат и состояния синхронизации по всем узлам можно использовать обработку для мониторинга обменов по планам обмена.