Ситуация, когда платформа 1С:Предприятие внезапно требует перезапустить сеанс из-за того, что «была обновлена конфигурация динамически», знакома многим администраторам и разработчикам. Особенно странно это выглядит, когда в отделе разработки никто не признается в обновлении, а беглый осмотр Журнала регистрации не дает быстрых ответов. Более того, сообщение может преследовать пользователей даже после того, как они честно перезашли в программу.
В этой статье мы подробно разберем, как правильно искать следы обновлений, почему возникают «фантомные» требования перезапуска и как бороться с последствиями неудачного динамического обновления. Мы проанализируем как стандартные средства платформы, так и неочевидные технические нюансы работы кластера серверов.
Первое, что мы обычно делаем при возникновении вопросов «Кто это сделал?» — открываем Журнал регистрации. Однако часто мы ищем не там или не то. Давайте определим алгоритм поиска, который позволит нам гарантированно найти виновника торжества.
Многие ошибочно фильтруют журнал по конкретным пользователям или ищут только события изменения основной конфигурации. Это может привести к ложному выводу, что обновлений не было.
Для точного анализа нам необходимо настроить отбор по Событию. В конфигураторе перейдем в меню Администрирование -> Журнал регистрации и установим отбор по следующим событиям:
Если мы не включим в отбор события, связанные с расширениями, мы можем упустить момент, когда программный механизм (например, автообновление патчей от 1С или загрузка модулей интеграции) изменил конфигурацию без участия человека.
Также обратим внимание на колонку Транзакция и Пользователь. Если в колонке «Пользователь» пусто или указано служебное имя (например, «DefUser»), но событие обновления зафиксировано, это может указывать на:
Рассмотрим пример кода, который позволяет программно проверить наличие обновлений за последние 24 часа, если доступ к графическому журналу затруднен или он слишком велик:
СтруктураОтбора = Новый Структура;
МассивСобытий = Новый Массив;
МассивСобытий.Добавить("_$Data$_.ConfigUpdate"); // Внутреннее имя события обновления
МассивСобытий.Добавить("_$Data$_.ExtensionUpdate"); // Событие обновления расширения
СтруктураОтбора.Вставить("Событие", МассивСобытий);
СтруктураОтбора.Вставить("ДатаНачала", ТекущаяДата() - 86400); // За последние сутки
ТаблицаЖР = Новый ТаблицаЗначений;
ВыгрузитьЖурналРегистрации(ТаблицаЖР, СтруктураОтбора);
Для Каждого Строка Из ТаблицаЖР Цикл
Сообщить("Время: " + Строка.Дата + " | Пользователь: " + Строка.ИмяПользователя + " | Событие: " + Строка.ПредставлениеСобытия);
КонецЦикла;
Часто бывает так: мы нашли, кто обновил базу (или выяснили, что это были мы сами, но забыли), перезапустили 1С, но через некоторое время (или сразу) окно с требованием перезапуска появляется снова. И так несколько раз.
Давайте разберемся в механике этого процесса. При динамическом обновлении меняется идентификатор версии конфигурации (GUID). Клиентское приложение должно считать этот новый идентификатор, сравнить его со своим и, при несовпадении, обновить свой локальный кэш метаданных.
Если сообщение появляется циклично, причины могут быть следующими:
Это самая распространенная причина. Локальные файлы кэша на компьютере пользователя могут быть повреждены или заблокированы (например, антивирусом или зависшим процессом). В результате клиентское приложение скачивает новую конфигурацию, но не может корректно сохранить её в кэш. При следующем обращении к серверу 1С снова видит несовпадение версий и снова просит перезапуск.
Решение: В таких случаях помогает полная очистка кэша. Нам нужно удалить временные файлы из папок пользователя:
C:\Users\%Username%\AppData\Local\1C\1cv8C:\Users\%Username%\AppData\Roaming\1C\1cv8Самый простой способ для пользователя — удалить базу из списка запуска 1С и добавить её заново. При этом создается новая папка с чистым кэшем (UID базы в списке меняется).
Кластер серверов 1С может считать процесс обновления незавершенным, если в системе остались «мертвые» сеансы, работающие на старой версии метаданных. Это могут быть:
Когда такой сеанс пытается обратиться к данным, платформа может инициировать повторную рассылку уведомлений о динамическом обновлении всем активным пользователям. Необходимо зайти в Консоль администрирования серверов 1С и принудительно удалить все сеансы, время начала которых раньше времени динамического обновления.
Если мы используем сложную архитектуру с несколькими рабочими серверами в кластере (версии платформы 8.3.20 и выше, и особенно 8.3.24), мы можем столкнуться с ситуацией рассинхронизации.
Механизм работы следующий: один рабочий процесс (rphost) узнал об обновлении и обновил свои структуры в памяти. Другой процесс на соседнем сервере еще «не знает» об этом. Пользовательский сеанс может мигрировать между процессами (или открывать новые соединения). Попадая на «старый» процесс, все работает нормально. Попадая на «обновленный» — пользователь получает требование перезапуска. После перезапуска он может снова попасть на «старый» процесс, который скажет ему, что его (клиента) версия слишком новая, или наоборот.
В этом случае помогает только полный перезапуск службы Агента сервера 1С на всех узлах кластера. Динамическое обновление на высоконагруженных кластерах — это всегда риск, и лучше его избегать.
В обсуждении справедливо замечено: «Кэш портится». Давайте проанализируем, почему многие опытные специалисты избегают «демонического» (динамического) обновления, даже если нужно поправить всего одну строчку кода.
При динамическом обновлении происходит подмена метаданных «на лету». Это может привести к следующим последствиям:
rphost)..dt или чистке таблицы ConfigSave (что требует высокой квалификации).Подводя итог нашему расследованию, сформулируем четкий план действий при возникновении подобных проблем:
Соблюдение этих правил сбережет нервы вам и вашим пользователям, а также обеспечит стабильную работу информационной базы.