Список баз на сервере 1С 8.3: каталог srvinfo, файл 1CV8Reg.lst и редактирование регистрации

Список баз на сервере 1С для кластера живёт не в реестре Windows и не в ярлыках клиента: платформа складывает регистрацию информационных баз в каталоге srvinfo, в подкаталоге reg_<порт>, в файле 1CV8Reg.lst. Если в консоли кластера висит база без данных в СУБД или штатное удаление упирается в пароль администратора ИБ, задача администратора платформы 8.3 - привести регистрацию в порядок. Сначала пробуем штатное редактирование через администрирование кластера; правку 1CV8Reg.lst оставляем на крайний случай, с остановкой агента и резервной копией.

Где на сервере 1С лежит список информационных баз

metrics: Список баз на сервере 1С 8.3: каталог srvinfo, файл 1CV8Reg.

Менеджер кластера и агент сервера при старте читают служебные данные из srvinfo. Именно там лежит регистрация ИБ: для каждого экземпляра агента (порта) свой подкаталог reg_<номер_порта> и внутри него 1CV8Reg.lst. Консоль кластера и утилита rac показывают тот же перечень, который описан в этом файле, плюс данные, которые агент держит в памяти после изменений.

На Windows для платформы 8.3 путь обычно такой: каталог установки, чаще всего Program Files\1cv8\srvinfo\reg_<порт_кластера>\1CV8Reg.lst. В старых инструкциях для 8.2 фигурировал 1cv82 - у восьмёрки актуальнее 1cv8; если стоят несколько версий платформы, srvinfo может быть у каждой своей. Порт в имени каталога совпадает с портом агента кластера: часто встречаются 1540 и 1541, но ориентируйтесь на свойства кластера в «1С:Консоль кластера» или в оснастке «Администрирование серверов 1С:Предприятия 8», а не на усреднённый пример из чужой статьи.

На Linux srvinfo обычно под /var/1C/ (иногда рядом с каталогом установки платформы). Структура та же: srvinfo, reg_<порт>, 1CV8Reg.lst. Файлы принадлежат пользователю службы, чаще usr1cv8; править lst от root без смены владельца потом мешает запуску агента. Если прав администратора ОС нет, попросите хостинг или админов инфраструктуры остановить ragent и выдать копию файла - без этого ручная правка всё равно недоступна.

Несколько кластеров на одной машине означают несколько reg_* - не удаляйте «лишний» каталог, пока не убедитесь, какой порту и какому экземпляру агента он соответствует. UUID кластера в консоли и блок описания кластера в lst помогают не перепутать экземпляры.

Уточнить порт для reg_* можно в свойствах кластера: поле «Порт агента» должно совпасть с цифрой в имени каталога. Если srvinfo пустой или lst только что создан, список баз ещё не переносили с другого сервера - тогда проблема не в «лишней» строке, а в регистрации нового кластера.

Как устроен 1CV8Reg.lst: блок перечня баз

checklist: Список баз на сервере 1С 8.3: каталог srvinfo, файл 1CV8Reg.

1CV8Reg.lst - текстовый файл с вложенными блоками в фигурных скобках. Для задачи администратора важен фрагмент, где перечислены информационные базы кластера: сначала число зарегистрированных ИБ, затем по одному описанию на каждую базу. Остальные блоки (рабочие процессы, центральный сервер, параметры публикации) при очистке «мёртвой» регистрации обычно не трогают.

У каждой ИБ в lst есть имя (как в списке баз), тип СУБД, сервер и имя базы данных, учётная запись SQL, зашифрованный пароль и строка соединения с параметрами CrSQLDB, DB, DBMS, DBSrvr, DBUID, Ref и др. Пароли и секреты в файле не лежат открытым текстом - платформа хранит их в зашифрованном виде. Статья про удаление и согласование регистрации, а не про обход авторизации: расшифровку полей для входа без пароля здесь не разбираем.

Ниже - условный фрагмент под 8.3 (имена и GUID вымышленные, структура близка к реальной). Цифра после открытия блока перечня - количество баз; каждая база занимает несколько строк до закрывающей скобки с запятой.

{0,
{a1b2c3d4-e5f6-7890-abcd-ef1234567890,"Кластер_prod",1541,"SRV-HOST",0,0,0,0,0,0},
{2,
{f1111111-1111-1111-1111-111111111111,"ut_prod","","MSSQLServer","SRV-HOST\\SQL2019","ut_prod","sql_1c","<зашифрованный_пароль>","CrSQLDB=Y;DB=ut_prod;DBMS=MSSQLServer;DBSrvr=SRV-HOST\\SQL2019;DBUID=sql_1c;Locale=ru_RU;Ref=ut_prod;Srvr=127.0.0.1",0,
{0,00010101000000,00010101000000,"","",""},0,1},
{f2222222-2222-2222-2222-222222222222,"ut_test","","PostgreSQL","pg.local","ut_test","postgres","<зашифрованный_пароль>","CrSQLDB=Y;DB=ut_test;DBMS=PostgreSQL;DBSrvr=pg.local;DBUID=postgres;Locale=ru_RU;Ref=ut_test;Srvr=127.0.0.1",0,
{0,00010101000000,00010101000000,"","",""},0,1}
},
{1,
{4f66c84e-665d-42f5-b572-5d52cadb3353,"SRV-HOST",1,1,
{3.273363228699551e-1,3.210807174887892e-1,6.255605381165919e-3,0,0,223,242.0514093298371,0,95660,0,100,1},1000}
},
{0},
{1,
{4c5b0a73-e356-40af-99bd-20be4fe3275f,"Центральный сервер",1540,"SRV-HOST",1,
{1,
{1560,1591}
},"","<зашифрованные_данные>"}
},
{0},
{0},
{1,
{"SRV-HOST",1541}
}
}

В примере в блоке с {2, перечислены две базы. Удалите одну регистрацию вручную - нужно поставить {1, и вырезать весь фрагмент второй базы, не разорвав скобки. Ошибка на одной запятой или лишней } часто даёт отказ агента загрузить регистрацию; тогда кластер «не видит» базы или падает при старте.

Строка соединения для MS SQL и PostgreSQL читается одинаково по смыслу: DBMS и DBSrvr говорят, куда подключаться, DB и Ref - имя базы на стороне СУБД и ссылка в списке 1С. Если базу уже снесли через SSMS или psql, в lst она всё равно останется до штатного или ручного удаления регистрации.

Штатное редактирование списка баз в администрировании кластера

flow: Список баз на сервере 1С 8.3: каталог srvinfo, файл 1CV8Reg.

Добавление, изменение параметров СУБД и удаление информационной базы штатно делаются через «1С:Консоль кластера» или mmc «Администрирование серверов 1С:Предприятия 8». Подключаетесь к агенту (хост и порт), открываете кластер, раздел информационных баз - операции те же, что описывает документация платформы. В обычной эксплуатации этого достаточно, и к 1CV8Reg.lst лезть не нужно.

На удалённом сервере без RDP мне часто удобнее rac через сервер администрирования ras: не нужно открывать GUI на самой машине. Сначала смотрю перечень, потом удаляю или обновляю регистрацию. Пример для сверки имён (подставьте host:port ras, uuid кластера и uuid ИБ):

rac cluster list localhost:1545
rac infobase summary --cluster=<uuid_кластера>
rac infobase update --cluster=<uuid_кластера> --infobase=<uuid_ИБ> --db-server=NEWHOST --db-name=ut_prod
rac infobase remove --cluster=<uuid_кластера> --infobase=<uuid_ИБ>

Для remove важны те же диалоги, что и в GUI: платформа спросит, что делать с базой на СУБД. Пока регистрация согласована с реальностью, удаление через консоль или rac обновляет lst при работающем агенте - вручную файл не правят.

Если нет прав администратора кластера в 1С, но есть учётка Windows или Linux на сервере, это не заменяет роль администратора платформы: без доступа к консоли или rac под учёткой с правами на кластер вы не удалите регистрацию штатно. Остаётся эскалация к владельцу инфраструктуры 1С; правка lst без согласования рискованна и юридически спорна.

База уже удалена в СУБД и забытый пароль администратора ИБ

Типичный рассинхрон: в MS SQL или PostgreSQL базы уже нет, а в списке кластера запись осталась. При удалении информационной базы в консоли не выбирайте действие, которое снова пытается удалить объект на СQЛ-сервере или в PostgreSQL. Нужен вариант, эквивалентный «Оставить без изменений»: регистрация на сервере 1С снимается, команда DROP на стороне СУБД не выполняется.

Для PostgreSQL в мастере удаления формулировки могут отличаться от MS SQL, смысл тот же: не трогать уже отсутствующую БД. Если выбрать агрессивное удаление «и с сервера 1С, и в СУБД», получите ошибку от СУБД или пугающее сообщение в журнале - регистрация может не сняться.

Сценарий с забытым паролем администратора информационной базы в документации и на практике часто строят так: сначала удаляют базу средствами СУБД (если данные не нужны и есть резервная копия на случай ошибки), затем снимают регистрацию на сервере 1С с «Оставить без изменений». Штатное удаление через консоль может требовать пароль администратора ИБ; тогда без ручной правки lst или восстановления пароля по процедурам вендора не обойтись - ручная правка остаётся крайней мерой из следующего раздела.

Перед DROP на SQL проверьте, что это именно та база: сверьте DB в строке соединения из lst или свойства ИБ в консоли с именем в SSMS или в списке баз PostgreSQL.

SELECT name, create_date
FROM sys.databases
WHERE name IN (N'ut_prod', N'ut_test');

Если строки нет, объект на MS SQL уже отсутствует - удаляйте только регистрацию на сервере 1С. Для PostgreSQL аналогично смотрите pg_database или список баз в psql под суперпользователем.

SELECT datname, pg_catalog.pg_get_userbyid(datdba) AS owner
FROM pg_catalog.pg_database
WHERE datname = 'ut_test';

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

Ручная правка 1CV8Reg.lst: подготовка и удаление записей

Ручное редактирование имеет смысл, когда штатное удаление недоступно, агент при операции падает или lst повреждён после аварийного останова. Алгоритм жёсткий: резервная копия 1CV8Reg.lst, останов службы «Агент сервера 1С:Предприятия 8» (Windows) или ragent (Linux), правка, сохранение в кодировке как у исходника, запуск агента. Пока агент работает, он может перезаписать файл из памяти - правки пропадут или появится конфликт.

Копию кладу рядом с датой в имени и на другой диск, если есть. Открываю lst в редакторе с номерами строк, нахожу блок перечня баз по имени «мёртвой» ИБ и по числу в {N,. Меняю N на новое количество и удаляю целиком описание ненужной базы от строки с GUID до закрывающей }, включая запятую между записями. Соседние блоки кластера и центрального сервера не трогаю.

Частые промахи: забыли уменьшить счётчик; удалили запятую между оставшимися базами; отрезали лишнюю закрывающую скобку у родительского блока. После сохранения пробегаю глазами баланс скобок от начала файла до конца - один проход снижает риск «кластер не стартует».

Несколько «мёртвых» баз удаляют за один заход: новое N равно числу оставшихся регистраций, вырезают все лишние фрагменты. Если сомневаетесь в синтаксисе, сравните с резервной копией диff-ом: измениться должны только счётчик и удалённые блоки ИБ.

Проверка после изменений и откат

Запускаю агент и смотрю журнал регистрации службы (Windows - просмотр событий или лог установки, Linux - файлы ragent и записи systemd). Затем открываю консоль кластера: список информационных баз должен совпадать с ожиданием, лишних имён нет. Пробное подключение тонкого или толстого клиента к оставшейся базе подтверждает, что строка соединения в lst для неё не пострадала.

При ошибке старта агента или пустом списке баз снова останавливаю службу, возвращаю 1CV8Reg.lst из копии, запускаю агент и возвращаюсь к штатному удалению через консоль или rac уже на исправном файле. Журналы ragent и rmngr подскажут, на какой строке парсер споткнулся о синтаксис - ищу эту область в lst.

Если после штатного remove с «Оставить без изменений» база пропала из консоли, но клиент всё ещё показывает её в кэше списка недавних, это клиентская история, а не srvinfo. Обновите список с сервера или очистите кэш подключений - к регистрации на кластере это не относится.

Риски, лицензия и когда lst не трогают

Документация платформы описывает администрирование кластера, а не ручное редактирование 1CV8Reg.lst. Прямая правка недокументированных служебных файлов может трактоваться как нарушение лицензионного соглашения и лишает вас понятной линии поддержки 1С при повреждении кластера. Один неверный символ в lst - реальный простой до восстановления из бэкапа.

Я к lst прихожу, когда штатный путь исчерпан: нет пароля администратора ИБ, база на СУБД уже уничтожена, а remove через GUI зависает или выдаёт ошибку. Во всех остальных случаях rac и консоль быстрее и безопаснее; правка реестра Windows или бинарников платформы вместо srvinfo без крайней нужды только увеличивает зону поражения.

Итог простой: список баз кластера хранится в srvinfo, файл 1CV8Reg.lst в reg_<порт>; меняйте регистрацию через администрирование кластера, при расхождении с SQL или PostgreSQL используйте «Оставить без изменений», а ручную правку сочетайте с остановкой агента, копией файла и проверкой в консоли после запуска. Если прав администратора кластера нет - не правьте lst втихую, согласуйте действие с тем, у кого есть доступ к штатным средствам.