Переход на новые версии технологической платформы 1С:Предприятие часто преподносит неприятные сюрпризы системным администраторам и разработчикам. Особенно остро это ощущается при поддержке классических конфигураций, таких как Управление торговлей редакции 10.3 (УТ 10.3), работающих в режиме совместимости с более старыми версиями платформы (например, 8.2.13). Одной из наиболее распространенных проблем при обновлении платформы до ветки 8.3.12 (в частности, релиза 8.3.12.1529) является внезапный сбой распределенной информационной базы (РИБ) с ошибкой:
«Ошибка при вызове метода контекста (ПрочитатьИзменения): Конфигурация узла распределенной ИБ не соответствует ожидаемой!»
При этом физически никаких изменений в конфигурацию центрального узла не вносилось, а на предыдущих версиях платформы (например, 8.3.11.3034) обмен работал абсолютно стабильно. В данной статье мы подробно разберем, почему возникает этот сбой, проанализируем внутренние механизмы платформы и рассмотрим пошаговые методы полного восстановления работоспособности РИБ.
Для того чтобы эффективно бороться со сбоем, необходимо понять физику процесса. Когда происходит обмен данными в распределенной системе, платформа сравнивает конфигурации центрального и подчиненного узлов. Делается это не путем построчного сравнения метаданных, а с помощью расчета специальной хэш-функции (цифрового отпечатка конфигурации, так называемого Digest).
В платформе версии 8.3.12 разработчики 1С существенно обновили внутренние механизмы формирования файлов обмена и алгоритмы вычисления хэш-суммы конфигурации базы данных. В результирующем XML-файле обмена изменилась структура системного тега v8de:Digest2. В нем появились новые атрибуты, учитывающие наличие расширений конфигурации (даже если они не используются в планах обмена), а также изменился сам формат сериализации метаданных.
В результате базы данных, запущенные на платформе 8.3.12, генерируют хэш-код конфигурации по новым правилам. Если в процессе обновления конфигурации или при первом запуске под новой платформой один из узлов не обновил внутреннюю структуру служебных таблиц (например, таблицы Config и DbCfg в СУБД SQL), хэши баз перестают совпадать. Центральная база формирует файл обмена с одним ожидаемым хэшем, а периферийная база при попытке чтения изменений видит несовпадение и блокирует транзакцию, возвращая ошибку выполнения метода ПрочитатьИзменения.
Рассмотрим по шагам рабочие способы решения этой проблемы — от простых к более сложным инженерным методам.
Часто проблема усугубляется тем, что в узлах обмена «зависает» регистрация старых изменений конфигурации, которая продолжает ссылаться на неактуальный хэш-код. В этом случае простая загрузка файла конфигурации .cf не помогает. Нам необходимо полностью очистить регистрацию изменений конфигурации для проблемного узла.
Разберем процесс по шагам:
РегистрацияИзмененийДляОбмена.epf), которую можно найти на диске ИТС или в каталоге установки шаблонов конфигураций в папке EXE/EXTREPS/UNIREPS82/RegistrationChangeForDataExchangeManaged.
// Выбираем узел, для которого нужно очистить регистрацию
УзелОбмена = ПланыОбмена.УдалитьРегистрациюИзменений(СсылкаНаНашУзел, ДанныеПервойНеобходимости);
// Если требуется полностью очистить все зарегистрированные изменения конфигурации:
ПланыОбмена.УдалитьРегистрациюИзменений(СсылкаНаНашУзел, Метаданные.Конфигурация);
После очистки регистрации изменений конфигурации выполните тестовую выгрузку данных из центральной базы и попробуйте загрузить их в подчиненный узел. Если ошибка сохраняется, переходите к следующему радикальному, но самому надежному методу.
Когда стандартное обновление конфигурации подчиненного узла заблокировано из-за несовпадения хэшей, самым надежным решением является временное отключение («отвязка») периферийной базы от главного узла, загрузка чистого файла конфигурации и последующее восстановление связи РИБ.
Проанализируем этот алгоритм подробно:
Шаг 1. Выгрузка актуальной конфигурации из центрального узла
Запустите Конфигуратор центральной базы данных. Перейдите в меню Конфигурация -> Сохранить конфигурацию в файл... и сохраните файл под именем v8config.cf на локальный диск.
Шаг 2. Отключение главного узла в подчиненной базе
Для того чтобы подчиненная база позволила нам внести изменения в свою конфигурацию напрямую, нам нужно временно сделать ее автономной. Лучше всего производить эту операцию через утилиту командной строки, чтобы избежать кэширования старых метаданных в сессии «Предприятия».
Закройте все сеансы работы с подчиненной базой. Откройте командную строку (cmd) и выполните команду запуска Конфигуратора с ключом очистки главного узла:
"C:\Program Files\1cv8\8.3.12.1529\bin\1cv8.exe" CONFIG /F "ПутьКВашейБазе" /ResetMasterNode /N "ИмяАдминистратора" /P "Пароль"
Примечание: Если у вас клиент-серверный вариант базы данных, используйте ключ /S "ИмяСервера\ИмяБазы" вместо ключа /F.
Шаг 3. Загрузка конфигурации в автономную подчиненную базу
Запустите Конфигуратор подчиненной базы данных (теперь она открыта для редактирования). Перейдите в меню Конфигурация. Обратите внимание: функция «Сравнить, объединить с конфигурацией из файла» здесь категорически не подходит, так как она не перезаписывает внутренний уникальный идентификатор (хэш) структуры данных базы.
Используйте строго пункт меню Конфигурация -> Загрузить конфигурацию из файла.... Выберите ранее выгруженный файл v8config.cf из центральной базы. Согласитесь на замену конфигурации и обязательно обновите конфигурацию базы данных, нажав клавишу F7 (или синюю бочку на панели инструментов).
Шаг 4. Очистка локального кэша базы данных
Это критически важный шаг, который часто упускают из виду. В платформе 8.3.12 кэш метаданных работает агрессивнее, чем в старых версиях. Чтобы старый кэш не подменял расчет хэш-суммы, удалите базу из списка запуска 1С и добавьте ее заново (при этом папка кэша на локальном диске пользователя пересоздастся с чистого листа).
Шаг 5. Восстановление привязки к главному узлу
Запустите подчиненную базу в режиме «1С:Предприятие». Откройте внешнюю обработку (или создайте короткий код в групповой обработке) для восстановления связи с центральным узлом. Нам необходимо выполнить следующий код:
// Находим ссылку на узел, который должен быть главным (центральным)
СсылкаНаЦентр = ПланыОбмена.УправлениеПродажами.НайтиПоКоду("ЦБ"); // Укажите ваш план обмена и код узла
Если ЗначениеЗаполнено(СсылкаНаЦентр) Тогда
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦентр);
Сообщить("Связь РИБ успешно восстановлена!");
Иначе
Сообщить("Не удалось найти центральный узел по указанному коду!");
КонецЕсли;
После выполнения этого кода закройте сеанс работы. Теперь база снова стала подчиненным узлом РИБ. Запустите обмен данными — чтение изменений должно пройти без ошибок соответствия конфигурации.
Рассмотрим парадоксальный метод, который часто спасает администраторов баз данных на платформе 8.3.12. Иногда подчиненный узел успешно принимает файлы обмена, но центральная база наотрез отказывается принимать ответные файлы из-за несоответствия ожидаемой конфигурации.
В этой ситуации можно выровнять хэши «снизу вверх»:
.cf)..cf, полученный из подчиненной базы.Этот метод принудительно синхронизирует внутренние таблицы хэш-сумм СУБД центральной базы с теми значениями метаданных, которые сгенерировала платформа на периферийном узле.
В некоторых случаях виновником проблемы становятся так называемые «демоны» динамического обновления в центральной базе. Если в центральной базе часто применялись динамические обновления (без монопольного выталкивания пользователей), структура метаданных в SQL-таблицах может содержать фрагменты старых версий конфигурации, что гарантированно ломает расчет хэша для РИБ на платформе 8.3.12.
Проанализируем, как заставить платформу полностью пересчитать хэш-код конфигурации:
// Фикс хэша обмена платформы 8.3.12 или просто добавьте пробел..cf файл и обновите им подчиненную базу по схеме, описанной в Способе 2.Если в вашей организации на одном сервере крутятся конфигурации разных поколений (например, новая Бухгалтерия предприятия 3.0, требующая платформы версии 8.3.12 или выше, и старая Управление торговлей 10.3), настоятельно не рекомендуется запускать их под одним и тем же релизом платформы без крайней необходимости.
Помните, что технологическая платформа 1С позволяет держать на одном сервере/компьютере несколько установленных версий параллельно. Для баз данных уровня УТ 10.3 вы можете жестко прописать запуск под стабильной и проверенной временем платформой ветки 8.3.11 или даже 8.3.10 в настройках запуска конкретной базы в стартере 1С (поле «Версия платформы» в свойствах информационной базы).
Используя приведенные пошаговые методы и понимая внутренние механизмы расчета хэш-кодов конфигураций платформой 8.3.12, вы сможете оперативно устранить сбой обмена РИБ и обеспечить бесперебойную работу распределенной системы автоматизации вашего бизнеса.