Работа с распределенными информационными базами (РИБ) в 1С:Предприятии на практике часто сопровождается техническими вызовами. Администраторы систем нередко сталкиваются с ситуацией, когда стабильно работающий обмен внезапно прерывается, а Журнал регистрации (ЖР) за выходные дни раздувается на десятки гигабайт. В дополнение к этому регулярные ошибки вида «Конфигурация узла распределенной ИБ не соответствует ожидаемой!» могут поставить в тупик даже опытных специалистов, особенно когда эта ошибка исчезает «сама собой» после десятка повторных попыток запуска обмена.
В этой статье мы подробно разберем физические причины обеих проблем, проанализируем механизмы работы платформы 1С при обмене данными и выработаем надежные пошаговые инструкции для стабилизации работы РИБ.
---
Для того чтобы понять, почему неудачный обмен приводит к забиванию дискового пространства логами, рассмотрим внутреннюю кухню процесса сериализации и десериализации данных в 1С. Когда инициируется обмен (неважно, по расписанию или вручную), платформа выполняет стандартный цикл операций:
Но почему Журнал регистрации увеличивается, если транзакция откатилась?
Это ключевой нюанс работы платформы 1С. Журнал регистрации ведется независимо от транзакционного механизма базы данных. Все события начала транзакции _$Transaction$_.Begin, попыток записи объектов и последующего отката транзакции _$Transaction$_.Rollback физически записываются в ЖР и остаются там навсегда. Откат транзакции в базе данных НЕ удаляет записи об этой транзакции из логов.
Если в вашей базе настроен автоматический обмен (например, каждые 2–5 минут), то при возникновении постоянной ошибки обмена система попадает в бесконечный цикл. Каждые несколько минут регламентное задание запускается, пытается записать тысячи объектов, падает по ошибке, откатывает транзакцию и пишет гигабайты логов. За выходные дни (около 60 часов) при ежеминутном обмене система совершит 3600 попыток обмена. Каждая попытка запишет сотни мегабайт технической информации о неудачной сериализации, что легко может превратить Журнал регистрации в десятигигабайтный нечитаемый монолит.
Дополнительной проблемой является формат хранения Журнала регистрации. Начиная с платформы 8.3, по умолчанию используется формат SQLite (файл 1Cv8.lgd). Особенность архитектуры SQLite заключается в том, что при удалении записей или отмене транзакций размер файла на диске физически не уменьшается — освободившееся место просто резервируется внутри файла для будущих записей. Без принудительного сжатия диск продолжит оставаться переполненным.
---
Рассмотрим пошагово, как настроить систему, чтобы избежать подобных инцидентов в будущем.
По умолчанию в 1С установлен режим логирования «Регистрировать все». Для рабочих баз, особенно в режиме РИБ, это избыточно. Чтобы снизить нагрузку:
При таких настройках успешные записи объектов и рядовые системные транзакции перестанут фиксироваться в логах, а будут записываться исключительно критические сбои, что снизит объем поступающей информации на 90–95%.
Не допускайте слишком частого запуска обменов по умолчанию при нестабильных каналах связи. Проанализируем настройки регламентного задания ВыполнитьОбменДанными:
Если Журнал регистрации уже раздулся, его необходимо сжать. Простое удаление записей через интерфейс не уменьшит размер файла на диске. Выполним процедуру физического сжатия базы данных SQLite.
Для регулярного сокращения ЖР можно настроить пакетный скрипт автоматизации:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" DESIGNER /F "C:\PathToYourBase" /N "Admin" /P "Password" /ReduceEventLogSize 2023-12-31 -KeepAnomalies
Если после сокращения логов файл 1Cv8.lgd по-прежнему занимает много места, воспользуемся утилитой SQLite для дефрагментации файла (выполняется при остановленной службе сервера 1С):
sqlite3.exe.C:\Program Files\1cv8\srvinfo\reg_1541\<UID_базы>\1Cv8Log\).
sqlite3.exe 1Cv8.lgd "VACUUM;"
Эта команда перестроит базу данных логов, удалит пустые страницы и физически вернет свободное место операционной системе.
---
Перейдем ко второй проблеме, упомянутой автором. Симптом крайне специфичен: обмен выдает ошибку несоответствия конфигурации раз 10 подряд, а на 11-й раз все неожиданно проходит успешно. Разберем технические причины этого поведения.
1. Динамическое обновление («демоническое обновление») в центральной базе
Динамическое обновление — главный враг стабильной работы распределенных баз данных. При таком обновлении платформа не обновляет структуру конфигурации монопольно, а создает новые версии объектов «на лету», сохраняя старые версии для работающих пользователей. При этом хэш-код структуры метаданных становится непредсказуемым. Когда центральный узел формирует пакет обмена, он записывает туда актуальный хэш структуры конфигурации. Периферийная база, принимая пакет, сравнивает свой хэш с пришедшим из центра. Из-за динамического обновления эти хэши гарантированно расходятся, вызывая блокировку обмена.
2. Кэширование метаданных процессами rphost и локальным кэшем
Платформа 1С активно кэширует конфигурацию для ускорения работы. Кэширование происходит на двух уровнях:
rphost сервера приложений 1С.Когда вы запускаете обмен, серверный процесс rphost считывает конфигурацию из своего кэша. Если кэш устарел или поврежден динамическим обновлением, хэши не совпадут, и обмен выдаст ошибку.
Почему же обмен успешно проходит на 11-й раз?
Все дело в утилизации и перезапуске рабочих процессов сервера 1С. В настройках кластера серверов 1С по умолчанию заданы параметры перезапуска процессов rphost (например, по времени работы, по превышению лимита памяти или при простое). Как только «проблемный» процесс rphost, который хранил в оперативной памяти старый кэш метаданных, завершает свою работу и перезапускается, кэш сбрасывается. При следующем запуске обмена платформа считывает актуальную конфигурацию из СУБД, хэши совпадают, и обмен «чудом» завершается успешно.
3. Активные пользовательские сеансы в периферийной базе
Для того чтобы периферийная база могла применить изменения конфигурации, пришедшие из центра, ей требуется монопольный доступ к таблицам метаданных. Если в момент загрузки обмена в периферийной базе работают пользователи, конфигурация базы данных примениться не может. Обмен «зависает» в промежуточном состоянии. Когда пользователи наконец выходят из базы (например, в конце рабочего дня), блокировка снимается, конфигурация применяется, и обмен восстанавливается.
---
Выяснив причины, выработаем системный подход к решению этой проблемы.
Любые изменения метаданных в центральной базе должны выполняться строго монопольно. Выгоняйте пользователей, снимайте задачу с динамического обновления и обновляйте конфигурацию через классическое нажатие клавиши F7 (применить изменения конфигурации).
Если ошибка уже возникла, и вы не хотите ждать естественного перезапуска процессов сервера, выполните ручную очистку:
rphost).%userprofile%\AppData\Local\1C\1Cv8 и %userprofile%\AppData\Roaming\1C\1Cv8).Бывают ситуации, когда обмен заблокирован окончательно, и штатные методы обновления конфигурации в периферийной базе не помогают. В этом случае применим проверенную схему временного перевода периферийной базы в автономный режим.
Проанализируем этот алгоритм по шагам:
1cv8.cf).
// Отключаем связь с главным узлом РИБ
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После выполнения этого кода периферийная база становится полностью самостоятельной, и в ней открывается возможность вносить изменения в конфигурацию напрямую.
1cv8.cf из Центральной базы.
// Восстанавливаем связь с главным узлом
// Вместо "НашПланОбмена" укажите имя вашего плана обмена в конфигураторе
// Вместо "001" укажите код центрального узла в вашей системе
СсылкаНаЦентр = ПланыОбмена["НашПланОбмена"].НайтиПоКоду("001");
Если Не СсылкаНаЦентр.Пустая() Тогда
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦентр);
Сообщить("Связь с главным узлом успешно восстановлена."); Иначе
Сообщить("Не удалось найти главный узел по указанному коду!");
КонецЕсли;
Используя предложенные методики настройки Журнала регистрации и правила обновления конфигураций в РИБ, вы сможете полностью исключить непредвиденный рост файлов логов на дисках и обеспечить бесперебойную синхронизацию распределенной инфраструктуры вашего предприятия.