← На главную

При администрировании крупных систем на базе 1С:Предприятие 8.3 системные администраторы часто сталкиваются со странным поведением журнала регистрации: все или большинство записей о действиях пользователей имеют статус «Транзакция не завершена». При этом пользователи не жалуются на ошибки, данные успешно сохраняются в базе, а в самой конфигурации не проводилось никаких глобальных изменений. Рассмотрим подробнее, почему возникает эта «серая зона» в логах и как привести журнал в порядок.

Анализируем причину возникновения статуса «Не завершена»

Для начала разберем внутреннюю механику работы платформы. В журнале регистрации статус транзакции меняется с «Не завершена» на «Завершена» или «Отменена» только тогда, когда Сервис журнала регистрации получает подтверждение (Commit) от рабочего процесса. Если мы работаем в кластере, состоящем из нескольких рабочих серверов, возникает ситуация распределения ролей. Один сервер может отвечать за работу пользователя и запись данных, а другой — за ведение самого журнала.

Выделим основные причины, по которым подтверждение о завершении транзакции не доходит до сервиса:

1. Разрыв связи между узлами кластера: Информация о начале транзакции зафиксирована на центральном сервере, а уведомление об успешном окончании, пришедшее с другого рабочего сервера, «потерялось» или не было обработано вовремя.
2. Некорректное распределение сервисов: Если в кластере не настроены Требования назначения функциональности, сервис журнала регистрации может произвольно перемещаться между серверами, что создает путаницу в очередях сообщений.
3. Проблемы с форматом журнала: На платформе 8.3 используется два формата журнала: старый текстовый (.lgp) и новый на базе SQLite (.lgd). В версиях платформы 8.3.10–8.3.12 наблюдались специфические баги именно в новом формате, когда статусы «подвисали» из-за особенностей работы блокировок SQLite в многопоточном режиме.
4. Рассинхронизация времени: Если время на серверах кластера и сервере СУБД различается хотя бы на секунду, записи в журнале могут ложиться в неверном хронологическом порядке, из-за чего статус в интерфейсе визуально не обновляется.

Способ 1: Настройка требований назначения функциональности

Проанализируем самый эффективный метод, который помог участникам обсуждения. Суть заключается в том, чтобы «принудительно» закрепить критически важные сервисы за конкретным рабочим сервером кластера. Это исключает ситуацию, когда данные «футболят» между узлами.

Разберем по шагам процесс настройки в консоли администрирования кластера 1С:

1. Откроем консоль Администрирование серверов 1С Предприятия.
2. Перейдем в ветку Кластеры -> [Имя вашего кластера] -> Рабочие серверы.
3. Для каждого сервера в списке выберем пункт Требования назначения функциональности.
4. Добавим новое требование для объекта «Сервис журнала регистрации»:
   • Тип требования: Назначать.
   • Имя объекта: Сервис журнала регистрации.
   • Тип объекта: Сервис кластера.
5. Рекомендуется также аналогичным образом закрепить «Сервис управления данными» на том же сервере, чтобы минимизировать сетевые задержки между этими службами.

После применения этих настроек кластер перераспределит нагрузку. Важно понимать, что это изменение может потребовать перезапуска рабочих процессов или небольшого времени для вступления в силу.

Способ 2: Проверка и оптимизация формата журнала регистрации

Если настройка требований не помогла, проанализируем формат хранения данных журнала. Если вы используете формат .lgd (SQLite), попробуйте выполнить следующие действия:

Во-первых, выполните сокращение журнала регистрации. Большие файлы SQLite могут медленно обрабатывать запросы на обновление статусов транзакций. Во-вторых, рассмотрите возможность временного перехода на текстовый формат для проверки. Хотя 1С рекомендует новый формат, на старых версиях платформы (как 8.3.10.2505 из нашего примера) текстовый формат работает стабильнее в плане отображения статусов.

Способ 3: Синхронизация системного времени

Выясним, насколько точно синхронизированы узлы вашей системы. Для корректной работы журнала регистрации необходимо, чтобы на всех серверах 1С и на сервере Microsoft SQL Server было настроено получение времени из одного источника (NTP-сервера).

Важный момент: Даже если визуально часы показывают одинаковое время, разница в миллисекундах может привести к тому, что транзакция в логе будет выглядеть незавершенной, так как событие завершения записалось «раньше» события начала (с точки зрения логики системы).

Ситуации с эквайрингом и терминалами

Иногда сообщение «Транзакция не завершена» возникает не в журнале регистрации, а непосредственно у пользователя при оплате картой. Это совершенно другая проблема, не связанная с настройками кластера. Проанализируем её кратко:

Если терминал списал деньги (вышел чек из терминала), но 1С выдала ошибку и не напечатала кассовый чек, это означает сбой связи на этапе подтверждения транзакции драйвером. В этом случае документ в 1С остается в статусе «Не проведен». Для решения таких ситуаций в современных конфигурациях следует использовать механизм Незавершенные операции эквайринга, который позволяет сопоставить успешный платеж по банку с документом в системе без повторного списания средств у покупателя.

Резюме для администратора

Посмотрим на итоговый алгоритм действий при обнаружении массовых статусов «Не завершена» в 1С:

1. Убедимся, что данные физически записываются в базу (проблема носит чисто визуальный характер в журнале).
2. Настроим Требования назначения функциональности для закрепления сервиса журнала за центральным сервером.
3. Проверим синхронизацию времени по протоколу NTP на всех участниках процесса.
4. Если используется платформа версии ниже 8.3.14, рассмотрим вопрос обновления, так как во многих старых релизах проблема со статусами была признанной ошибкой платформы.

Помните, что корректная работа журнала регистрации — это не только вопрос удобства, но и важный элемент аудита безопасности вашей информационной системы.