Ситуация, когда в распределенной информационной базе (РИБ) данные успешно синхронизируются, а изменения метаданных «застревают» в центральном узле, — одна из самых неприятных для администратора 1С. Мы сталкиваемся с тем, что конфигуратор сообщает об успешном обновлении, сообщения обмена улетают в филиалы, но периферийные базы не видят признака обновления конфигурации и продолжают работать на старой версии. Особенно остро эта проблема проявилась на платформе 8.3.14.1565 и смежных релизах.
В этой статье мы подробно разберем причины такого поведения платформы, проанализируем, почему стандартные механизмы дают сбой, и рассмотрим несколько эффективных способов «протолкнуть» обновление в подчиненные узлы — от простых «хитростей» до программных методов.
Прежде всего, разберем ситуацию. В норме при обновлении конфигурации базы данных в центральном узле платформа автоматически должна зарегистрировать изменения для всех узлов, входящих в состав плана обмена РИБ. Однако в релизах ветки 8.3.14 разработчики внесли существенные изменения в механизмы обмена, связанные с поддержкой расширений конфигурации. Это привело к возникновению бага: флаг необходимости обновления конфигурации для узла может сбрасываться преждевременно, или запись в системную таблицу регистрации изменений конфигурации (ConfigChangeRec) просто не создается.
Также проанализируем влияние так называемого «динамического» или «демонического» обновления. Когда мы обновляем конфигурацию без монопольного захвата базы, платформа пытается применить изменения «на лету». В РИБ это часто приводит к тому, что регистрация изменений метаданных для узлов происходит некорректно. Как показывает практика, универсализация алгоритмов обмена привела к тому, что ошибки, ранее свойственные только динамическому обновлению, перекочевали и в обычный режим.
Если конфигурация «не видит» изменений и не хочет их выгружать, мы можем заставить платформу выполнить полную реструктуризацию. Это гарантированно инициирует процесс регистрации изменений для всех узлов РИБ. Рассмотрим, как это сделать наиболее простым способом:
Строка.Важный момент: при изменении структурных свойств объектов платформа потребует монопольного доступа и выполнит реальную реструктуризацию таблиц в базе данных. Как показывает опыт участников обсуждения, именно эта процедура «пробивает» засор в механизме РИБ и заставляет платформу заново сформировать пакет обновлений для периферийных узлов. Динамическое обновление в данном случае нам не поможет — критична именно полная процедура реструктуризации.
Если мы не хотим менять структуру метаданных, мы можем воспользоваться встроенными средствами встроенного языка 1С. Платформа предоставляет метод, который позволяет вручную указать, что для конкретного узла необходимо передать изменения конфигурации. Проанализируем пример кода, который решает эту задачу:
// Создадим небольшую обработку или выполним код в консоли
Процедура ПринудительноЗарегистрироватьОбновление()
// Получаем все узлы конкретного плана обмена
ВыборкаУзлов = ПланыОбмена.Полный.Выбрать();
Пока ВыборкаУзлов.Следующий() Цикл
// Пропускаем этот узел (центральный)
Если ВыборкаУзлов.Ссылка = ПланыОбмена.Полный.ЭтотУзел() Тогда
Продолжить;
КонецЕсли;
// Устанавливаем признак изменения конфигурации для узла
ПланыОбмена.УстановитьИзмененияКонфигурации(ВыборкаУзлов.Ссылка);
Сообщить("Для узла " + ВыборкаУзлов.Ссылка + " зарегистрированы изменения конфигурации.");
КонецЦикла;
КонецПроцедуры
Использование метода УстановитьИзмененияКонфигурации() является наиболее «чистым» способом с точки зрения разработки. Он напрямую обращается к механизму планов обмена и выставляет нужные флаги в системных таблицах, не затрагивая структуру самих данных.
Иногда проблема кроется не в отсутствии регистрации, а в том, что сервер 1С «завис» и отдает старые данные из кэша. Если база работает в клиент-серверном варианте, выполним следующие шаги:
C:\Program Files\1cv8\srvinfo).snccntxt (кэш сеансовых данных).Это помогает в тех случаях, когда даже повторные попытки обновления не дают результата из-за «призрачных» данных в оперативной памяти сервера. Для автоматизации этой процедуры подойдёт скрипт для очистки сеансовых данных и серверного кэша 1С.
Разберем ситуацию, когда в базе используются расширения конфигурации. В новых версиях платформы они также могут передаваться через РИБ. Замечено, что если зарегистрированы изменения расширений, платформа иногда блокирует или игнорирует регистрацию изменений основной конфигурации.
Рекомендация: Если узел «завис», попробуйте сначала выполнить обмен без изменений в основной конфигурации, убедившись, что все расширения синхронизированы. Если это не помогает, можно временно отменить регистрацию изменений для расширений, прогнать обмен основной конфигурации, а затем вернуть изменения расширений «в очередь».
Также крайне не рекомендуется использовать Фоновое обновление конфигурации базы данных в центральном узле РИБ на проблемных платформах. Всегда используйте обычное обновление с завершением всех активных сеансов. Это минимизирует риск рассинхронизации таблиц регистрации. Для автоматизации регулярного обслуживания и безопасного завершения сеансов перед установкой релизов применяют программу для автоматического резервного копирования, тестирования и обновления баз 1С.
Подводя итог, можно сказать, что проблема невыгрузки конфигурации в РИБ на платформе 8.3.14.1565 — это известный технический дефект. Если у вас нет возможности оперативно обновить платформу до исправленных версий (например, 8.3.14.1779 или выше), используйте программный метод УстановитьИзмененияКонфигурации() или метод с изменением длины константы для форсирования реструктуризации.
Помните, что стабильность РИБ напрямую зависит от чистоты процесса обновления: избегайте динамических изменений метаданных и всегда следите за состоянием регистрации изменений в планах обмена. Для автоматизации регламентного применения изменений в узлах можно использовать обработку для автоматического обновления конфигурации в РИБ.