← На главную

При аварийном сбое кластера серверов «1С:Предприятие 8.3» системный администратор может столкнуться с ситуацией, когда конфигурационные файлы реестра 1CV8Clst.lst и 1CV8Clsto.lst оказываются обнуленными или поврежденными. В результате кластер теряет список зарегистрированных информационных баз. При этом сами базы данных на сервере СУБД (например, MS SQL Server) и подкаталоги баз с журналами регистрации в каталоге srvinfo\reg_1541\<GUID>\ остаются в сохранности.

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

Выясним первопричины повреждения реестра кластера

Прежде чем приступать к восстановлению, проанализируем, почему файлы реестра кластера *.lst выходят из строя:

1. Аварийная перезагрузка или отключение питания: Если процессы ragent.exe или rmngr.exe принудительно завершаются во время записи метаданных кластера, файл реестра может остаться пустым (размером 0 байт).
2. Нехватка свободного места на диске: Переполнение дискового пространства, где расположен рабочий каталог srvinfo, блокирует корректную запись конфигурационных списков.
3. Блокировка антивирусом или ПО резервного копирования: Файловые мониторы безопасности могут заблокировать доступ к файлу 1CV8Clst.lst в момент его ротации сервисом 1С.
4. Сброс пути запуска сервиса: При обновлении платформы без явного указания ключа -d в параметрах службы ragent сервер может начать искать кластер по пути системного профиля по умолчанию, создав пустые конфигурационные файлы.

Шаг 1. Проверка резервных копий и теневых копий Windows

Перед ручным анализом каталогов проверим самый быстрый способ восстановления:

1. Теневые копии (Volume Shadow Copy): Откроем свойства папки srvinfo\reg_1541 в проводнике Windows, перейдем на вкладку «Предыдущие версии» (Previous Versions). Если защита системы включена, можно извлечь рабочую копию 1CV8Clst.lst за предыдущие сутки.
2. Резервные копии сервера: Проверим системные бэкапы каталога srvinfo. Если бэкап есть, достаточно остановить службу 1C:Enterprise 8.3 Server Agent, вернуть файл на место и запустить службу.

Если бэкап отсутствует, переходим к идентификации баз по содержимому их рабочих каталогов.

Шаг 2. Идентификация баз по содержимому журналов регистрации

В каталоге каждого GUID (например, srvinfo\reg_1541\4fdfa05d-5688-46b9-833d-15112c2a1638\) находится подпапка 1Cv8Log. Проанализируем ее содержимое для однозначного сопоставления с базой SQL.

Вариант 1. Журнал регистрации нового формата (.lgd, SQLite)

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

1. Открываем файл 1Cv8.lgd из каталога конкретного GUID.
2. Переходим во вкладку «Данные» и выбираем таблицу MetadataCodes или UserCodes.
3. В таблице MetadataCodes смотрим имя корневого объекта метаданных конфигурации (например, Configuration.БухгалтерияПредприятия или Configuration.УправлениеТорговлей). Это позволяет сразу отсеять базы по типам конфигураций.
4. В таблице UserCodes смотрим список имен пользователей, которые авторизовывались в базе. Сопоставив уникальный список пользователей с пользователями в конкретной базе данных, мы точно определим соответствие.

Вариант 2. Журнал регистрации текстового формата (.lgf и .lgp)

В старом формате журнала регистрации файл 1Cv8.lgf является текстовым словарем метаданных и пользователей. Откроем его в любом текстовом редакторе:

1. В блоках описания пользователей находим строки с именами и внутренними UUID пользователей базы.
2. В блоках метаданных находим идентификаторы прикладных объектов (справочников, документов).

Шаг 3. Идентификация через полнотекстовый поиск и сопоставление с MS SQL

Если журнал регистрации был очищен или отключен, разберем другие способы идентификации:

1. Анализ каталога полнотекстового поиска (1Cv8FTxt): В рабочем каталоге базы рядом с 1Cv8Log находится каталог 1Cv8FTxt. Текстовые сегменты индекса содержат проиндексированные строковые данные: ИНН, названия контрагентов, номера накладных. Найденные уникальные ИНН или названия организаций достаточно сопоставить с данными в таблицах _Reference базы данных MS SQL.
2. Сопоставление списков баз у пользователей (ibases.v8i): Проанализируем файлы ibases.v8i на рабочих станциях или терминальных серверах. В них зафиксированы точные строки подключения и названия баз, которые использовались на сервере 1С.
3. Анализ технологического журнала: Если на сервере включен технологический журнал с событиями CONN или DBMSSQL, в логах сохраняются связки параметра ib (имя базы в кластере 1С) и параметра db (имя базы данных на SQL-сервере).

Шаг 4. Пошаговая процедура восстановления привязки журналов регистрации

Когда соответствие между именами баз на MS SQL и старыми GUID папок установлено, восстановим их работу в кластере:

1. Создание резервной копии каталога: Обязательно делаем полную копию всей папки srvinfo на другой диск.
2. Регистрация баз в новом кластере: Запускаем консоль администрирования серверов 1С (или утилиту rac) и заново регистрируем каждую информационную базу, указав ее имя, сервер СУБД и имя базы в MS SQL. При регистрации служба кластера создаст для каждой базы новый каталог со случайным новым GUID.
3. Остановка службы: Останавливаем службу сервера 1C:Enterprise 8.3 Server Agent.
4. Восстановление привязки: Для каждой базы выполняем один из двух вариантов:
   • Вариант А (через файлы журналов): Удаляем созданный пустой подкаталог 1Cv8Log в папке нового GUID и копируем на его место папку 1Cv8Log (а также 1Cv8FTxt, если требуется) из папки старого идентифицированного GUID.
   • Вариант Б (через редактирование 1CV8Clst.lst): Открываем сформированный новый файл 1CV8Clst.lst в текстовом редакторе (например, Notepad++), находим блок описания нужной базы и заменяем сгенерированный новый GUID на исходный GUID старого каталога. Затем удаляем пустую созданную папку с новым GUID.
5. Запуск кластера: Запускаем службу ragent. Сервер автоматически подключит существующие файлы журналов регистрации, сохранив всю историю событий и действия пользователей.

Рекомендации по защите кластера от повторных сбоев

Чтобы исключить потерю конфигурации кластера в будущем, применим следующие системные настройки:

1. Регулярное резервное копирование srvinfo: Настроим ежедневное копирование файлов *.lst и каталога reg_1541 с помощью скриптов PowerShell или системного планировщика.
2. Явное указание рабочего каталога службы: В свойствах запуска службы ragent в реестре Windows в параметре ImagePath всегда явно указываем ключ запуска рабочего каталога: -d "D:\1C\srvinfo" на надежном отдельном дисковом массиве.
3. Исключения антивируса: Добавим рабочий каталог сервера srvinfo, а также процессы ragent.exe, rmngr.exe и rphost.exe в список исключений антивирусного сканера.
4. Единообразие наименований: Рекомендуется называть базы в кластере 1С точно так же, как они названы на сервере MS SQL Server, что существенно упрощает администрирование и восстановление в аварийных ситуациях.