При эксплуатации распределенных информационных баз (РИБ) нередко возникает ситуация, когда центральный узел выводится из эксплуатации, а периферийная база остается единственной рабочей. При попытке обновить конфигурацию или внести изменения в структуру метаданных администратор сталкивается с сообщением о том, что изменения конфигурации заблокированы средствами информационной базы. Это происходит из-за того, что подчиненный узел ожидает обновлений исключительно от своего главного узла.
Разберем подробно, как отвязать подчиненную базу от РИБ, сделать ее полностью автономной или назначить корневым узлом для новой цепочки обмена.
Проанализируем самый быстрый и распространенный вариант — программный сброс ссылки на главный узел плана обмена. Для выполнения этой операции запустим базу в режиме 1С:Предприятие от имени пользователя с полными административными правами и откроем внешнюю обработку или консоль кода.
В теле процедуры выполним следующий код:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Рассмотрим, что происходит в момент выполнения этой строки: платформа очищает внутреннюю ссылку на ведущий узел для текущей информационной базы. Сразу после этого блокировка редактирования метаданных снимается, и база становится автономной.
Если нет возможности запустить режим предприятия или открыть внешнюю обработку, воспользуемся пакетным запуском конфигуратора со специальным ключом /ResetMasterNode.
Разберем по шагам запуск команды для различных вариантов развертывания базы данных:
"C:\Program Files\1cv8\common\1cestart.exe" CONFIG /F "C:\Bases\MyBase" /ResetMasterNode
"C:\Program Files\1cv8\common\1cestart.exe" CONFIG /S "ServerName\BaseName" /ResetMasterNode
При выполнении данной команды конфигуратор запустится в фоновом режиме, сбросит признак подчиненности узла и автоматически завершит работу.
Выясним причину возможных проблем при последующем обновлении конфигурации. В подчиненных узлах РИБ создание и обновление предопределенных элементов по умолчанию заблокировано, чтобы исключить дублирование данных с главным узлом. Если в настройках базы или метаданных был выставлен запрет на обновление, после отвязки базы могут возникать ошибки при обновлении релизов.
Чтобы база корректно инициализировала новые предопределенные элементы при обновлении, проверим и восстановим автоматический режим обновления предопределенных данных с помощью программного кода:
ПланыОбмена.УстановитьОбновлениеПредопределенныхДанныхИнформационнойБазы(РежимОбновленияПредопределенныхДанных.Авто);
Если после обновления релизов в базе все же возникли ошибки поиска системных предопределенных значений, выполним процедуру Тестирование и исправление информационной базы в конфигураторе, установив флаг Создавать предопределенные элементы.
После отвязки узла текущая база все еще хранит информацию о зарегистрированных изменениях для старого главного узла. Это может приводить к лишней нагрузке на СУБД и неоправданному росту таблиц регистрации.
Разберем последовательность завершающих действий:
ПланыОбмена.УдалитьРегистрациюИзменений():
ВыборкаУзлов = ПланыОбмена.ПоОрганизациям.Выбрать();
Пока ВыборкаУзлов.Следующий() Цикл
ТекущийУзел = ВыборкаУзлов.Ссылка;
Если ТекущийУзел <> ПланыОбмена.ПоОрганизациям.ЭтотУзел() Тогда
ПланыОбмена.УдалитьРегистрациюИзменений(ТекущийУзел);
КонецЕсли;
КонецЦикла;
ЭтотУзел, после чего создадим новые подчиненные образы через метод ПланыОбмена.СоздатьНачальныйОбраз().Посмотрим на состояние регламентных и фоновых процессов. В подчиненных узлах РИБ разработчики типовых конфигураций нередко отключают выполнение части системных заданий (загрузка классификаторов, регламентное закрытие месяца, интеграции). После превращения базы в основную обязательно проверим работу расписания регламентных заданий через панель администрирования программы.