Как снять признак подчиненного узла распределенной базы, если база не запускается и падает /ResetMasterNode?

В процессе сопровождения распределенных информационных баз (РИБ) разработчики и администраторы нередко сталкиваются с ситуацией, когда подчиненный узел блокируется из-за критической ошибки в коде. Типичный пример — сбой в процедуре УстановкаПараметровСеанса общего модуля сеанса (например, при попытке обращения к еще не созданным предопределенным элементам данных). В этом случае войти в режим «1С:Предприятие» невозможно, конфигурация закрыта для редактирования механизмом РИБ, а попытка сбросить признак главного узла через штатный ключ командной строки /ResetMasterNode приводит к аварийному завершению работы платформы с кодом исключения 0xc0000005 в библиотеке backend.dll.

Разберем подробно причины такого поведения системы и рассмотрим надежные способы решения проблемы и восстановления доступа к базе данных.

Причины сбоя платформы и аварийного завершения

Проанализируем природу возникновения описанной ошибки. Сбой обусловлен двумя взаимосвязанными факторами:

1. Ошибка инициализации сеанса: При старте любого клиентского приложения или COM-соединения платформа в первую очередь выполняет инициализацию параметров сеанса. Если в коде происходит исключение, вход блокируется, что делает невозможным программный сброс узла через обработку или внешнее подключение.
2. Отказ утилиты снятия признака узла: Ключ запуска конфигуратора /ResetMasterNode на ряде релизов платформы 1С:Предприятие (в частности, в некоторых сборках 8.3.8–8.3.9) содержит внутреннюю ошибку работы с нарушенными таблицами соответствия предопределенных данных, что приводит к критическому нарушению прав доступа в памяти (Access Violation) в модуле backend.dll.

Способ 1. Запуск сброса главного узла через альтернативный релиз платформы

Наиболее простое и быстрое решение, позволяющее избежать потери накопленных за рабочий день данных, — запустить процесс очистки сведений о главном узле с помощью стабильного или более раннего релиза платформы 1С, в котором ошибка модуля backend.dll отсутствует.

Рассмотрим порядок выполнения по шагам:

1. Обязательно создадим резервную копию файла базы данных (для файлового варианта скопируем файл 1Cv8.1CD).
2. Убедимся, что база полностью свободна от активных сеансов. В файловом режиме закроем все запущенные конфигураторы и клиентские приложения, а также проверим каталог информационной базы на отсутствие файлов блокировок (*.1CL, *.1CD-journal, *.cfl).
3. Вызовем командную строку Windows (cmd) и выполним запуск конфигуратора напрямую через исполняемый файл конкретной стабильной версии платформы (например, ветки 8.3.6), указав ключ /ResetMasterNode:

"C:\Program Files (x86)\1cv8\8.3.6.2076\bin\1cv8.exe" CONFIG /F "D:\Bases\SubNodeBase" /ResetMasterNode /N "Администратор" /P "Пароль"

Обратим внимание на следующие важные моменты при запуске команды:

1. Параметр применяется исключительно в режиме CONFIG (или DESIGNER).
2. Если в информационной базе задан список пользователей, необходимо обязательно передать параметры авторизации пользователя с административными правами (/N "Логин" и /P "Пароль").
3. Команда выполняется в тихом фоновом режиме: процесс запустится, модифицирует служебную таблицу параметров базы данных и завершит работу без открытия диалоговых окон. После этого база становится автономной, а возможность редактирования конфигурации разблокируется.

Способ 2. Программное отключение главного узла

Если в базу удается войти под учетной записью с полными правами, в которой не падает инициализация параметров сеанса, либо если есть возможность выполнить код через внешнее подключение, отключение узла выполняется штатными средствами встроенного языка.

Посмотрим на пример кода, выполняемого в контексте режима «1С:Предприятие»:

ПланыОбмена.УстановитьГлавныйУзел(Неопределено);

Если доступ к графическому интерфейсу заблокирован, но COM-соединение отрабатывает корректно, можно выполнить сброс через внешний скрипт:

Соединитель = Новый COMObject("V83.COMConnector");
База = Соединитель.Connect("File=""D:\Bases\SubNodeBase"";Usr=""Администратор"";Pwd=""Пароль""");
База.ПланыОбмена.УстановитьГлавныйУзел(Неопределено);

Способ 3. Доставка исправленной конфигурации из главного узла

Если сменить платформу невозможно, а восстанавливать базу из старой резервной копии нежелательно из-за потери оперативных данных, можно исправить причину падения в основном узле:

1. В главном узле РИБ откроем конфигуратор и найдем процедуру УстановкаПараметровСеанса.
2. Добавим безопасную проверку инициализации значений (например, проверку на существование предопределенного элемента или конструкцию Попытка ... Исключение).
3. Сохраним конфигурацию и выгрузим файл конфигурации (.cf) либо сформируем штатный файл обмена.
4. В подчиненном узле загрузим файл исправленной конфигурации через командную строку в пакетном режиме:

"C:\Program Files (x86)\1cv8\8.3.9.1818\bin\1cv8.exe" CONFIG /F "D:\Bases\SubNodeBase" /LoadCfg "D:\Updates\FixedConfig.cf" /UpdateDBCfg /N "Администратор" /P "Пароль"

После применения корректного обновления модуль сеанса перестанет аварийно завершать работу, и вход в подчиненную базу восстановится.

Особенности баз на базе Библиотеки стандартных подсистем (БСП)

После того как признак главного узла успешно снят, при первом запуске конфигурации на базе БСП система обнаружит отключение от РИБ и выдаст диалоговое окно с предупреждением. Для корректной автономной работы потребуется подтвердить отключение узла в пользовательском интерфейсе либо очистить служебные константы синхронизации, чтобы исключить запуск фоновых процедур обмена данными.