При администрировании и разработке в крупных распределенных системах на базе конфигурации 1С:Розница (РТ) специалисты часто сталкиваются со сложной технической задачей: как подружить распределенные информационные базы (РИБ), расширения конфигурации и постоянно обновляющиеся платформенные релизы. Связка механизмов РИБ и расширений в среде 1С исторически являлась одним из самых уязвимых мест платформы, порождая множество скрытых и зарегистрированных ошибок обмена.
В этой статье мы подробно разберем, почему «ломается» обмен при обновлении платформы, проанализируем баги популярных релизов линеек 8.3.13, 8.3.14 и 8.3.15, а также выработаем пошаговые инструкции по восстановлению стабильной работы синхронизации данных.
Рассмотрим стандартную ситуацию, с которой часто сталкиваются администраторы розничных сетей. При попытке обновить конфигурацию 1С:Розница до актуальных релизов (требующих платформу не ниже определенного релиза) выполняется апгрейд движка платформы на периферийных и центральном узлах — например, на релиз 8.3.13.1690 или 8.3.14.1565. Сразу после этого обмены данными полностью останавливаются.
Выясним причину этой системной ошибки. На указанных версиях платформы присутствует критический баг механизма динамического обновления расширений в периферийных узлах РИБ:
Важное условие возникновения ошибки: данный сбой воспроизводится исключительно на файловых версиях информационных баз, которые традиционно используются на кассовых узлах и в торговых точках. На клиент-серверных (SQL) базах данная коллизия блокировки практически не проявляется.
Если ваша инфраструктура временно зажата в рамках этих проблемных релизов и быстрый откат платформы невозможен, разберем обходное решение («костыль»). Для корректного применения расширения первый обмен после его модификации в центре нужно запускать не через привычную интерактивную кнопку синхронизации в интерфейсе, а по следующей схеме:
При запуске обмена через механизм сценариев платформа корректно инициализирует монопольный сеанс обновления метаданных и успешно накатывает изменения расширения на периферийный узел.
Тем не менее, для обеспечения долгосрочной стабильности рекомендуется использовать релизы платформы, свободные от этого бага. В рамках ветки 8.3.13 наиболее стабильным релизом для обмена РИБ + расширения признана версия 8.3.13.1513, на которой данная ошибка отсутствует.
Часто в профессиональном сообществе звучат советы полностью отказаться от «глючных» веток 8.3.13 и 8.3.14 и сразу перейти на платформу 8.3.15. Однако этот переход таит в себе новые архитектурные сложности, которые мы сейчас проанализируем.
При переходе на релизы линейки 8.3.15 (в частности, популярный релиз 8.3.15.1565) при первом же автоматическом обмене администраторы массово получают критическую ошибку: «Конфигурация узла распределенной ИБ не соответствует ожидаемой».
Обычное терапевтическое средство — выгрузка файла конфигурации центральной базы (файла 1cv8.cf) и его принудительная загрузка в периферийную базу через конфигуратор — в версиях 8.3.15 перестает приносить результат. Ошибка совместимости конфигураций возникает вновь при первом же сеансе обмена данными.
Выясним внутреннюю причину этого явления. Разработчики платформы в линейке 8.3.15 изменили алгоритмы вычисления контрольных хэш-сумм как основной конфигурации, так и расширений. В файле обмена XML появились изменения в структурах блоков Digest и v8de:Digest2. Из-за расхождения алгоритмов хэширования на разных версиях платформы (или при некорректной очистке кэша метаданных) подчиненные узлы перестают ассоциировать себя с ожидаемой конфигурацией главного узла.
Для исправления этой коллизии на платформе 8.3.15 рекомендуется выполнить следующую последовательность действий:
Для отвязки и повторной синхронизации выполним следующие шаги в периферийной базе:
// Сброс привязки к главному узлу для проведения аварийных работ
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После этого база переходит в автономный режим. Мы можем беспрепятственно удалить проблемные расширения, повторно загрузить актуальный файл конфигурации 1cv8.cf из центральной базы, а затем программно восстановить связь с главным узлом:
// Восстановление связи с главным узлом РИБ
СсылкаНаУзел = ПланыОбмена.Розница.НайтиПоКоду("ЦБ"); // "ЦБ" - код главного узла
Если НЕ СсылкаНаУзел.Пустая() Тогда
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаУзел);
Сообщить("Связь с главным узлом успешно восстановлена.");
КонецЕсли;
Начиная с версии платформы 8.3.12, компания 1С оптимизировала обмен конфигурациями в распределенных базах. Вместо передачи всего тела расширения целиком, платформа пытается передавать только изменившиеся метаданные (так называемую «дельту»). На практике эта оптимизация привела к появлению трудноуловимого бага: неполучение мелких изменений кода расширения.
Если программист вносит точечное изменение в расширение в центральной базе (например, меняет одну строчку кода в общем модуле расширения или корректирует форму заимствованного справочника), платформа может посчитать это изменение незначительным и не зарегистрировать обновление расширения для отправки в подчиненные узлы.
Проанализируем практический прием, как гарантированно заставить платформу выгрузить расширение целиком в РИБ. Для этого необходимо искусственно изменить хэш-сумму структуры расширения:
Посмотрим на пример фиктивного кода, который можно добавить в модуль расширения для принудительного изменения хэш-суммы:
// Фиктивная процедура для принудительной регистрации изменений расширения в РИБ
Процедура Служебная_ОбновитьХэшРасширения() Экспорт
// Изменяем значение переменной при каждом обновлении
ИдентификаторОбновления = "20231124_v1";
КонецПроцедуры
Такое явное изменение структуры метаданных гарантирует, что платформа зарегистрирует изменение расширения для всех узлов планов обмена, и при следующей синхронизации пакет корректно уйдет на периферийные кассы.
Особое внимание уделим архитектуре самих расширений. Расширения бывают двух типов: меняющие только логику (код модулей, формы) и расширения, добавляющие новые структуры данных (собственные реквизиты, табличные части, новые справочники или документы).
Важное правило: Использование расширений, добавляющих собственные структуры данных (реквизиты и таблицы), крайне не рекомендуется в распределенных информационных базах 1С:Розница.
Рассмотрим, почему это опасно. При загрузке изменений такого расширения на кассовом узле платформа обязана провести реструктуризацию базы данных (создать физические таблицы в СУБД или файле 1Cv8.1CD). Для этого требуется жесткий монопольный режим. В файле обмена выставляется специальный внутренний триггер блокировки.
Если в процессе применения этого файла обмена на кассе происходит любая рядовая ошибка (например, аварийно завершается процесс проведения какого-то документа из этого же пакета, или выключается свет), триггер монопольной блокировки «зависает» в незакрытом состоянии. Платформа уходит в бесконечный цикл требований монопольного доступа, полностью блокируя последующие обмены, даже если все пользователи вышли из базы.
Для аварийного вывода базы из этого состояния приходится прибегать к запуску конфигуратора из командной строки с ключом сброса главного узла:
"C:\Program Files\1cv8\8.3.15.1565\bin\1cv8.exe" ENTERPRISE /F "C:\1C_Bases\Retail_Kassa1" /ResetMasterNode
После этого в аварийном режиме удаляется зависшее расширение конфигурации, база повторно привязывается к РИБ и инициируется полная перегрузка данных, что влечет за собой огромные временные затраты и простой торговой точки.
Проанализировав поведение различных веток платформы 1С:Предприятие 8.3 в связке РИБ + расширения, сформируем рекомендации для стабильной работы 1С:Розница: