Почему пропадают записи журнала регистрации в кластере серверов 1С и как их объединить?

← На главную

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

Причина фрагментации журнала регистрации в кластере

Для начала выясним причину такого поведения. По умолчанию платформа 1С запускает различные сервисы кластера, включая Сервис журналов регистрации. Если у нас нет жесткого распределения сервисов, возникает предсказуемая проблема.

Служба кластера случайным образом балансирует Сервис журналов регистрации между доступными центральными серверами. Поскольку этот сервис не умеет автоматически синхронизировать и склеивать данные между физическими узлами, события пишутся исключительно локально — на жесткий диск того сервера, к которому был маршрутизирован конкретный пользовательский сеанс. Физически такие файлы располагаются в рабочих каталогах агента сервера, обычно по пути srvinfo/reg_1541/<GUID_базы>/1Cv8Log.

Настройка Требований назначения функциональности (ТНФ)

Разберем, как сделать так, чтобы журнал регистрации писался централизованно в одно место, сохраняя при этом отказоустойчивость кластера. Для этого нам необходимо строго настроить Требования назначения функциональности (ТНФ).

Откроем консоль администрирования серверов 1С.
Перейдем в свойства нужного кластера и откроем раздел Требования назначения функциональности.
Добавим новое правило для объекта Сервис журналов регистрации.
Для основного центрального сервера установим правило Назначать.
Для резервных серверов зададим более низкий приоритет резервирования или установим правило Автоматически.

Благодаря этой настройке, 1С будет принудительно держать сервис и писать весь журнал на основной сервер. И только в том случае, если этот сервер физически выйдет из строя, запись автоматически переключится на резервный узел.

Как объединить фрагментированные логи

Что делать с уже записанными разрозненными логами на двух серверах? Физическое копирование или банальная замена файлов здесь не поможет. Посмотрим на встроенные возможности платформы. Для штатного объединения логов мы можем использовать метод СкопироватьЖурналРегистрации.

Рассмотрим пример кода, который можно оформить в виде небольшой внешней обработки для загрузки недостающих кусков из фрагмента в основную базу логов:


Процедура ОбъединитьЖурналыРегистрации()
    
    ПутьКФрагменту = "C:\Temp\LogFragment\1Cv8.lgd"; // Путь к скопированному с другого сервера логу
    ПутьКОсновному = "C:\Program Files\1cv8\srvinfo\reg_1541\GUID\1Cv8Log\1Cv8.lgd";
    
    // Настраиваем фильтр, если необходимо перенести только конкретный период
    Отбор = Новый Структура;
    Отбор.Вставить("ДатаНачала", НачалоМесяца(ТекущаяДата()));
    
    Попытка
        СкопироватьЖурналРегистрации(ПутьКФрагменту, ПутьКОсновному, Отбор);
        Сообщить("Журнал успешно объединен.");
    Исключение
        Сообщить("Ошибка объединения: " + ОписаниеОшибки());
    КонецПопытки;

КонецПроцедуры

Проблемы формата SQLite и скрытые записи

В анализируемой проблеме упоминается формат базы данных SQLite (файл 1Cv8.lgd), в котором в конфигураторе 1С записи не видны, но прямыми запросами к SQLite они обнаруживаются. Проанализируем технические нюансы этого формата:

Повреждение структуры файла. Часто причиной "пропадания" записей в интерфейсе 1С является логическое повреждение структуры (ошибка database disk image is malformed). 1С прерывает чтение, как только натыкается на битый блок данных, в то время как сторонние утилиты могут считывать уцелевшие записи. Чтобы это исправить, используем консольную утилиту sqlite3.exe. Командой .dump мы можем выгрузить здоровые данные в текстовый дамп, а из него собрать новый, исправный файл логов 1Cv8.lgd.
Очистка пустого места. В SQLite удаление старых записей через конфигуратор не уменьшает размер файла. Страницы просто помечаются как пустые. Для реального высвобождения места (дефрагментации) необходимо остановить сервер 1С и выполнить команду VACUUM через любой SQL-редактор.

Рекомендация: переход на новый последовательный формат

Подведем итог и рассмотрим лучшие практики. Формат SQLite показал себя не с лучшей стороны в высоконагруженных системах из-за монолитности и частых дисковых блокировок. Фирма 1С вернула и глубоко модернизировала старый текстовый формат.

Мы настоятельно рекомендуем переключить базу на новый последовательный формат с обязательной настройкой сегментации. Установите разделение логов По дням (или по часам, для огромных баз). Это кардинально снизит дисковые блокировки, повысит скорость работы кластера, а обслуживать логи (архивировать, удалять старые куски) станет намного проще.