Каждый администратор баз данных 1С:Предприятие рано или поздно сталкивается с дилеммой выбора оптимального формата ведения журнала регистрации. С выходом платформы 1С 8.3 разработчики предложили новый формат на базе СУБД SQLite (файлы с расширением .lgd), который должен был решить проблемы быстродействия. Однако на практике многие специалисты поспешили вернуться к классическому последовательному формату (файлы с расширениями .lgf и .lgp). В этой статье мы подробно разберем, почему новый формат не оправдал надежд, проанализируем технические проблемы обоих вариантов и рассмотрим пошаговые инструкции по безопасному переходу на надежную классику.
История развития и текущий статус форматов в 1С
Для начала кратко проанализируем хронологию развития этой технологии, чтобы понять логику фирмы «1С»:
Появление формата SQLite (платформа 8.3.5): В 2014 году разработчики внедрили формат .lgd. Главной целью было ускорение процессов поиска, фильтрации событий и повышение отказоустойчивости за счет механизмов транзакционности SQLite.
Откат рекомендаций (платформа 8.3.12): На практике новый формат показал себя крайне нестабильно на высоконагруженных и крупных базах данных. Начиная с версии 8.3.12, фирма «1С» вернула старый последовательный формат в качестве рекомендуемого по умолчанию.
Полный отказ (платформа 8.3.22): В версиях платформы начиная с 8.3.22 (вышедших в 2022 году) поддержка формата SQLite (.lgd) была полностью прекращена. Возможность конвертации логов в этот формат была исключена из платформы. Для современных систем данный вопрос решился автоматически в пользу классического формата.
Почему новый формат на базе SQLite (.lgd) оказался неудачным?
Рассмотрим подробнее технические проблемы, из-за которых формат SQLite стал главным источником головной боли системных администраторов:
Критическая проблема с блокировками при записи. СУБД SQLite блокирует всю базу данных при выполнении транзакции записи. В многопользовательских системах с высокой интенсивностью транзакций или активной работой фоновых заданий это приводило к образованию очередей, зависаниям рабочих процессов сервера 1С и резкому падению производительности дисковой подсистемы.
Постоянная угроза повреждения данных. При аварийном завершении работы сервера 1С или перезапусках кластера монолитный файл .lgd регулярно повреждался. В логах появлялась фатальная ошибка database disk image is malformed. Для восстановления данных администраторам приходилось использовать сторонние консольные утилиты SQLite для выгрузки схемы и данных в SQL-дамп с его последующей ручной перезаписью. Пример схемы аварийного восстановления через командную строку выглядит следующим образом:
Сложность обслуживания и монолитность файла. В отличие от старого формата, файл SQLite невозможно автоматически разделять по периодам (дням, неделям, месяцам). Он растет единым огромным файлом. При этом обычное сокращение журнала через Конфигуратор лишь удаляет записи из базы данных, но размер самого файла на диске не уменьшается. Чтобы вернуть свободное место операционной системе, требуется выполнять блокирующую операцию сжатия VACUUM с помощью сторонних утилит, что требует полной остановки работы пользователей.
Проблемы при чтении тяжелых логов. Попытка открыть журнал регистрации размером более 10–20 Гб штатными средствами Конфигуратора 1С очень часто приводила к исчерпанию оперативной памяти и падению приложения.
Преимущества старого формата (LGF / LGP)
Давайте выясним, почему старый последовательный формат остается эталоном стабильности:
Быстрая и бесконфликтная запись. События записываются в конец текстового файла «на лету» (метод append). Этот процесс происходит практически мгновенно и не вызывает транзакционных блокировок, что гарантирует стабильную работу высоконагруженных систем.
Разделение файлов по периодам. Администратор может настроить автоматическую нарезку файлов журнала по дням, неделям или месяцам. Это позволяет легко архивировать старые логи: файлы за прошлые периоды можно просто перенести на другой диск или удалить средствами ОС без остановки системы.
Высокая отказоустойчивость. При сбое файловой системы может пострадать только текущий файл за сегодняшний день. Все остальные файлы за предыдущие периоды останутся в полной сохранности. Даже поврежденный лог можно открыть и прочитать в любом текстовом редакторе.
Как переключить формат журнала регистрации обратно на старый?
Если ваша база данных работает на версиях платформы от 8.3.5 до 8.3.21 и в ней до сих пор активен формат SQLite, мы настоятельно рекомендуем перевести ее на стабильный классический формат. Разберем по шагам два способа решения этой задачи.
Способ 1. Штатный переход через Конфигуратор
Этот способ подходит в тех случаях, когда база данных работает в штатном режиме, а файл журнала регистрации не поврежден.
Запустите информационную базу в режиме Конфигуратор с правами администратора.
Откройте меню Администрирование и выберите пункт Настройка журнала регистрации....
В появившемся диалоговом окне нажмите кнопку Изменить формат....
Выберите классический последовательный формат и подтвердите действие. Система автоматически выполнит конвертацию накопленных данных. Обратите внимание, что для больших баз данных процесс конвертации может занять длительное время.
Способ 2. Ручной сброс формата (если Конфигуратор зависает)
Если файл .lgd поврежден, база данных работает со сбоями, а Конфигуратор зависает при попытке открыть настройки, проанализируем алгоритм ручного перевода:
Полностью остановите службу сервера 1С:Предприятия (через консоль служб Windows или терминал Linux).
Перейдите в каталог расположения файлов журнала регистрации. По умолчанию на сервере Windows путь выглядит следующим образом:
Найдите и переместите все файлы с расширением .lgd в резервную папку на другом диске (для сохранения архива).
В текущей папке 1Cv8Log создайте пустой текстовый файл и переименуйте его в 1Cv8.lgf (убедитесь, что расширение изменилось с .txt на .lgf). Наличие этого пустого файла является для платформы сигналом использовать классический формат логов.
Запустите службу сервера 1С:Предприятия.
После запуска сервер обнаружит управляющий файл 1Cv8.lgf и начнет последовательную запись событий в новые файлы формата .lgp. Таким образом, мы быстро возвращаем систему к стабильной работе без потерь производительности.