1c resetmasternode не работает
В публикации описан один из способов создания тестовой БД для разработки с актуальными данными, быстрого восстановления работоспособности РИБ при "падении" одного из узлов, или "быстрого" создания/восстановления узла РИБ без выгрузки начального образа для конфигураций на основе БСП.
Рассмотрим случай, когда данные во всех узлах синхронизируются полностью. Это идеальный случай — для исходных данных (данных восстановления) можно использовать любой узел РИБ. В случае, когда обмен происходит по собственным правилам или, например, установлен фильтр по организациям, то для исходных данных (данных восстановления) необходимо выбирать узел с наиболее полными данными.
. ВАЖНО. Перед созданием БД необходимо выполнить полную синхронизацию всех узлов РИБ с узлом, из которого планируется создавать новую БД, и на время создания в этом узле отключить синхронизацию данных!
Все действия выполняются в монопольном режиме (т.е. у целевой БД должны отсутствовать активные соединения).
В качестве «исходного узла» выберем «Корневой узел» (см. схему РИБ). В нем аккумулируются данные всех узлов.
ВАЖНО. В качестве «исходного узла» рекомендуется выбирать узел, который впоследствии станет главным узлом для вновь созданного/восстановленного узла.
Это не обязательное условие. Для восстановления РИБ подойдет любой узел с максимально актуальными данными.
0. В режиме предприятия создаем новый узел РИБ в «исходном узле».
Данное действие необходимо, если создается новый узел, в противном случае необходимо перейти к п. 1.
1. Выгружаем базу данных из «исходного узла» в файл (*.dt).
Для «пухлых» БД можно просто скопировать 1Cv8.1CD, для клиент-серверных БД — например, скопировать средствами СУБД.
2. Загружаем полученную в п. 1 выгрузку в «чистую» БД.
3. Запускаем полученную в п. 2 БД в режиме предприятия и отключаем все настроенные синхронизации данных.
4. Отключаем автоматическое обновление предопределенных данных в подчиненной БД.
Это необходимо потому, что в главном узле предопределенные данные обновляется автоматически, а в подчиненные узлы уже «приезжают» с обменами.
Если не выполнить это действие, то после отключения главного узла при следующей реструктуризации БД произойдет задвоение предопределенных данных.
Для отключения необходимо запустить командную строку от имени Администратора (root`a), выполнить запуск конфигуратора с параметрами и дождаться выполнения (сам конфигуратор на экране не появится, но он будет отображаться в дереве процессов системы, т.е. необходимо дождаться когда процесс конфигуратора пропадет из дерева процессов):
для Linux-клиента «файловый» вариант БД:
для Linux-клиента «клиент-серверный» вариант БД:
для Windows-клиента «файловый» вариант БД:
для Windows-клиента «клиент-серверный» вариант БД:
соответственно подставить свои путь к исполнительному файлу 1cv8 или 1cv8.exe и переменные, где:
Недавно столкнулся с такой проблемой: после выгрузки нового узла 1С: Розница по плану обмена "ПоМагазину", при первом старте система пытается выполнить обновление, и выдает ошибку, связанную с обновлением справочника "Идентификаторы объектов метаданных". Самое простое решение - отключить базу от главного узла, запустить обработку обновления идентификаторов из инструментов разработчика, и подключить базу обратно к главному узлу.
Т.к. ошибка возникает при старте базы, и по ее закрытии закрывается и база, а до этого никаких обработок запустить не получается, решил использовать параметр запуска конфигуратора /ResetMasterNode. Прописал данный параметр в дополнительном параметре запуска, и запустил базу в режиме конфигуратора. Но, увы, получил вылет с записью дампа.
Далее ни создание ярлыка, ни запуск 1С через команды в PowerShell, ни запуск с правами администратора, ни изменение режима совместимости не дали никаких результатов. Поиск на просторах сети - тоже не подсказал ничего, что смогло помочь.
Но тщательное изучение параметров командной строки привело к изящному решению:
А именно- использование парамерта запуска /Execute
/Execute [имя файла внешней обработки] — предназначен для запуска внешней обработки в режиме 1С:Предприятие непосредственно после старта системы.
Т.е. сохраняем да диске обработку установки/отключения главного узла, или "Инструменты разработчика обновление вспомогательных данных", в параметр запуска пишем /Execute "Полный путь к обработке", и запускаем базу в режиме Предприятие.
В итоге - после запуска открывается база, обработка обновления, и наша обработка, позволяющая отключить базу от главного узла, либо обновить справочник "Идентификаторы объектов метаданных" (ну, или любая другая обработка, путь к которой был указан)!
Надеюсь, кому-то будет полезен данный метод обхода сложностей, связанных с запуском, при старте системы, обработок, вызывающих закрытие, или критические ошибки!
У одного клиента встала необходимость отключить базы от главного узла и перевести их в работу как самостоятельной информационной базы. Вроде ничего сложного нет, но столкнулся с такой проблемой, что параметр ResetMasterNode не работает на платформе 8.3.16.1148. Ни через запуск через параметр, ни через запуск с ярлыка с запуском от прав администратора.
В итоге выяснилось чисто экспериментальным путём что, ключ ResetMasterNode РАБОТАЕТ на версиях платформы 8.3.12.х и 8.3.13.х, на платформах выше с 8.3.14х-8.3.16.х запуск с параметром приводит просто к закрытию конфигуратора.
Теперь по этапность действий которые 100% рабочие для отвязки периферийной базы от главного узла:
- Ставим любую платформу из линейки 8.3.12.х-8.3.13.х (мною были опробованы платформы 8.3.12.1529, 8.3.12.79, 8.3.13.1644). Так как версия розницы 2.3.3.19 не запускается ниже чем на 8.3.12.х, то работоспособность параметра ResetMasterNode на нижних версиях платформы не представилась возможной. ну и ладно ))
- Далее я создал отдельный ярлык с указанием явного пути до платформы с параметром config /ResetMasterNode (см. рисунок)
- Запускаем конфигуратор и вуаля, он у нас запрашивает аутентификацию пользователя (если в ИБ она есть) и также не запускается (хотя по описанию на ИТС должен открыться конфигуратор с вопросом об отмене главного узла) ))
- Далее запускаем из штатного ярлыка 1С нашу конфигурацию в режиме предприятия (на любой платформе) и нам уже предлагается отвязать или восстановить связь с главным узлом
После того, как произведутся действия по отключению периферийной базы от главного узла РИБ, проверяем для уверенности в том, чтобы всё было в порядке, проверяем две константы через меню Все функции:
первая константа Это автономное рабочее место
и вторая константа Настройка подключенного узла РИБ Завершена.
У обоих констант галки должна быть сняты.
Ну вот как бы и всё. Надеюсь, что кому-то написанное выше сэкономило время в решении возникшей проблемы
15/09/11 - Добавлена версия для работы с 8.2 в режиме обычного приложения.
В принципе ее можно было легко получить и конвертацией.
P.S. Если нужно просто сделать базу не распределенной - есть более простой способ,
запуск в пакетном режиме
". \1cv8.exe" DESIGNER /ResetMasterNode /IBName=mybase /NAdmin /PPass
Специальные предложения
: Ошибка при вызове метода контекста (УстановитьГлавныйУзел): Недопустимое значение параметра (параметр номер '1')
ПланыОбмена.УстановитьГлавныйУзел(ГлавныйУзел);
Я хотела сделать базу главнойФорма.Форма(48)>
(5) Чтобы база стала главной - надо снимать признак главного узла, а не устанавливать. Если у базы нет главной - тогда она главная.
В том то и дело. Если я ставлю на главный узел и нажимаю "Установить главный узел" ничего не происходит
(8) Надо нажимать не "Установить признак главного узла", а "Снять признак главного узла". "Установить" применяется чтобы снова сделать базу подчиненной.
(12) Кнопка выполнить не нужна. Для выполнения действий предназначены соответствующие кнопки. Аватар обновил.
(13) Обновил обработку. Если узел выбран - будет очистка только по выбранному узлу, если узел пустой - очистка по выбранному плану обмена.
Бух 2,0. Продвинутые юзеры удалили центральную базу.
Что осталось - отвязал от УРИБ , опять настроил с нуля. полет нормальный.
Спасибо автору --- удобная штука
использовалась для быстрого развертывания копированием базы и настройки обмена
(не через стандартную процедуру выгрузки базы)
очень удобно и экономит массу времени
(23) dimisa,
Можно поподробнее про копирование? Физическая копия базы а затем привязка к планам? А что, разве у базы нет ID ?
Отлично попробуем. Уже весь форум просмотрел это наиболее полная орбработка для манипуляциями с периферийными узлами. Автору спасибо.
это мне поможет
ситуация такая
нужно из центральной базы сделать подчиненную и запустить между ними обмен
допустим на филиале разворачиваю самый свежий бекап основной базы
как из основной базы сделать дополнительную ?
(35)Вопрос сумбурный несколько. А что Вы собственно хотите?
Сделать так чтоб 2 и более офиса работали как-бы в разных базах и в тоже время видели доки созданные другим офисом.
Почитайте описание - иногда помогает.
Может я в чем не разобрался - прошу помощи. Надо быстро сделать подчиненный узел.
Последовательность выполненных действий в УТ 10.3.13.2:
1. Открыл демо базу - там есть два узла Центральный офис (помечен зеленой точкой как главный) и Магазин.
2. Сделал для Магазина базу стандартным образом - узел Магазин помечен зеленой точкой, Центральный - красный.
3. Сделал копию Центральной базы, запустил эту обработку. Выбрал план обмена Полный, Узел - Магазин.
4. Нажимаю кнопку Очистить регистрацию изменений, Установить главный узел.
Проверяю - Магазин стал красный, и Центральный офис - остался с зеленой точкой (типа он главный).
Мне то надо наоборот.
5. Нажимаю Снять признак главного узла. Все возвращается обратно, как было сразу после копирования.
6. Выбираю Центральный узел - Снять признак главного - ничего не происходит.
7. Нажимаю Установить главный узел - получаю ошибку
: Ошибка при вызове метода контекста (УстановитьГлавныйУзел)
ПланыОбмена.УстановитьГлавныйУзел(ГлавныйУзел);
по причине:
Недопустимое значение параметра (параметр номер '1')
Что я делаю не так и какая последовательность действий для быстрого создания подчиненного узла?
Попробовал вручную изменить наименование узлов - поменял местами наименование и номер у главного и магазина - вроде все заработало. Надеюсь правильно все сделал?
(41) Всплыла фраза из рекламы :"А Вы его кушать пробовали. ".
Минусанул бы Вас ,Jogeedae, да както жалко. и не денег.
mykolap , через полгодика ждем для 8.3 -))
(43) Такой развернутый ответ с конкретикой мне нравится больше.
в 2009 наверное альтернативы небыло, или это решение мне лично понравилось.
в-четвертых : Спасибо, зарядили позитивом на день - пойду поработаю.
Всем спасибо, ХОРОШЕГО НАСТРОЕНИЯ и УДАЧИ.
Маленький вопрос. У меня есть центральная база и куча периферийных, в центральной мне надо внести небольшие изменения без передачи изменений в периферийные. Мне надо запустить обработку и выбрать "снять признак главного узла", а после внесения изменений "установить главный узел"? Слетят ли планы обмена, нужно ли будет их заново создавать?
Включение возможности редактировать конфигурацию имеет смысл именно для подчиненного чтобы в него загрузить конфигурацию идентичную главному.
Ничего при этом не слетает, просто нужно отключить от главной базы, залить конфигурацию, обратно привязать.
Всегда это проделывал успешно (десятки раз проделывал).
Недавно столкнулся с такой проблемой: после выгрузки нового узла 1С: Розница по плану обмена «ПоМагазину», при первом старте система пытается выполнить обновление, и выдает ошибку, связанную с обновлением справочника «Идентификаторы объектов метаданных». Самое простое решение — отключить базу от главного узла, запустить обработку обновления идентификаторов из инструментов разработчика, и подключить базу обратно к главному узлу.
Т.к. ошибка возникает при старте базы, и по ее закрытии закрывается и база, а до этого никаких обработок запустить не получается, решил использовать параметр запуска конфигуратора /ResetMasterNode. Прописал данный параметр в дополнительном параметре запуска, и запустил базу в режиме конфигуратора. Но, увы, получил вылет с записью дампа.
Далее ни создание ярлыка, ни запуск 1С через команды в PowerShell, ни запуск с правами администратора, ни изменение режима совместимости не дали никаких результатов. Поиск на просторах сети — тоже не подсказал ничего, что смогло помочь.
Но тщательное изучение параметров командной строки привело к изящному решению:
А именно- использование парамерта запуска /Execute
/Execute [имя файла внешней обработки] — предназначен для запуска внешней обработки в режиме 1С:Предприятие непосредственно после старта системы.
Т.е. сохраняем да диске обработку установки/отключения главного узла, или «Инструменты разработчика обновление вспомогательных данных», в параметр запуска пишем /Execute «Полный путь к обработке», и запускаем базу в режиме Предприятие.
В итоге — после запуска открывается база, обработка обновления, и наша обработка, позволяющая отключить базу от главного узла, либо обновить справочник «Идентификаторы объектов метаданных» (ну, или любая другая обработка, путь к которой был указан)!
Надеюсь, кому-то будет полезен данный метод обхода сложностей, связанных с запуском, при старте системы, обработок, вызывающих закрытие, или критические ошибки!
Читайте также: