Восстановление ЦБ в РИБ #780799

Здравствуйте друзья. У клиента было настроено РИБ. ЦБ и УБ соотв. была настроена между ними синхронизация в один прекрасный момент ЦБ база упала (винт) последний архив ЦБ от июня 2016 в УБ все изменения последние на текущий момент пытаясь пойти логическим путем подцепили архивную базу (настройки синхронизации там все прописаны) при запуске обмена (получение) выдает следующую информацию в логах: Ошибка чтения файла сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта}: Ошибка при вызове метода контекста (ПрочитатьИзменения): Конфигурация узла распределенной ИБ не соответствует ожидаемой! соответственно из УБ ничего не попадает в ЦБ базу. Подскажите куда копать, как восстановить работоспособность? Возможно ли из УБ сделать ЦБ?

"УБ" содержит ВСЕ нужные данные?

тогда /resetmasternode в УБ и используем её в качестве центральной, отпочковываем от неё новый узел и вперед

каким образом это можно проверить? и этот ключ где прописывать?

проверить могут пользователи, где ключ прописывать - ну прояви сам хоть немного усилий, да?

Ок. Отключу я перифирийную базу от центрального узла.  Но как мне из неё всю актуальную информацию загрузить в центральный узел (базу)?

->

что значит отпочковываем узел?

тоесть делая из УБ - ЦБ. Потом из этой новой ЦБ уже делаем НОВУЮ УБ? А та которая была УБ убираем её?

ну, лично я - не возражаю. Главное -

Штатно ЦБ обновляем до версии конфигурации УБ. Потом выгружаем конфигурацию из УБ и загружаем в ЦБ. Обнуляем счетчики загрузки/выгрузки в базах, регистрируем изменения в УБ по всем нужным объектам, выгружаем в ЦБ. Можно пачками регистрировать. Ну вот как-то так.

это второй способ решения? первый от тоже подойдет?

Первый способ самый простой, если у тебя до этого в филиал все данные сливались

у тебя в периферийной есть в наличии и главный узел тоже, поскольку на него отправлялись выгрузки. Как только будет включено, что установленный узел ЦБ станет рабочим в базе ЦБ - нужно просто включить в УБ обратно подчиненность главному и все. Протестировать обмены в обе стороны.

и не надо ничего пачками перегружать - базы и так откопированы друг от друга. Ну регистрированные изменения очистить, чтоб зря не выгружались

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

можно по подробнее мне нужно /resetmasternode в УБ делать? или ваш совет относится ко второму способу? как мне сделать проще? допустим упала вообще ЦБ и нужно сделать ЦБ из УБ и заново настроить синхрон. сделать /resetmasternode в УБ, удалить синхронизацию и из неё создать уже новую ЦБ?

1. УБ не трогаешь и ничего в ней не ломаешь - она твой оригинал 2. Копируешь из нее заготовку ЦБ - данные в ней твои и других там просто нет. 3. Ставишь в заготовке /resetmasternode затем смотришь в ПланОбмена - там же два узла? Один с шариком, в качестве текущего узла. Вот этот узел теперь будет называться ЦБ - как он там раньше был назван. А второй узел, должен называть УБ. Они там, по идее, определяются символами из стандартного Код, а не из Наименование. Обнуляешь счетчики, как выше говорили. Обнуляешь регистрацию. Тестишь, что пакеты обменов создаются и выгружаются/загружаются.

а как из неё скопировать заготовку ЦБ? Просто базу скопировать?

другое дело, если для обменов узлов было много. Когда создавались/выгружались Первичные образы баз подчиненных, то в каждую подчиненную в план обмена записываются только пара узлов, а не вообще все. Один в качестве текущего для периферийной и второй чтоб был "мастер"

да

20+ ну регистрацию изменений можешь сбросить до или после копирования - без разницы, но в ЦБ она естественно должна начаться "с чистого листа"

если же вдруг базы в скл-режимах были, то можно и через дт-файл их размножать. Обменам по РИБ главное, чтоб коды узлов были парно-совпадающие и чтоб конфиг был абсолютно одинаков.

так что мне в итоге нужно менять в заготовке? как обнулить счетчики и регистрацию 1с 8.3

эх... В заготовке есть список узлов в Плане обмена. Их там будет два. Один с шариком. Тот узел, что с шариком - это текущий и У него должно стоять имя и код узла, как это нужно в центральной. Т.е. просто имена и коды узлов поменять местами, да и все. Как сбросить счетчики пакетов - яндекс подскажет. Обработочку обычно делают и админ ее прячет в свой загашник. Как и обработочки есть для сброса и установки Главный/подчиненный. Может быть найдется вообще собранная до кучи. И номера пакетов и установка главного и т.п. Как сбросить регистрацию изменений - опять таки процедура для этого существует. Почитай описание в платформе для Планов обмена. Зачем тут пересказывать документацию?!

"Как сбросить счетчики пакетов - яндекс подскажет. Обработочку обычно делают и админ ее прячет в свой загашник." - небольшое замечание: в некоторых типовых конфигурация, где есть "Монитор обмена данными", это штатный функционал.

я помню, что есть, но в большинстве случаев эти поля для счетчиков показываются "только просмотр"

автор бы уже давно сделал из периферийки новый центр и из него новую периферийку, а вы его запутали

Да ладно... хотел бы сделать, так давно сделал бы хоть по Вашему описанию, хоть по моим советам. Все это на тестовых копиях делают нормальные спецы, обыгрывают ситуацию, а затем уже на боевых база выполняют. А как при отключенной подчиненности главному узлу сделать Главный узел? Да что там еще делать-то, если база уже ничему не подчинена, т.к. подчиненность уже отключена?! Она уже главная сама в себе. Правильное наименование и код в текущем узле базы перезаписать как надо и все.

спасибо, сделал по вашему совету.

сделать НОВЫЙ подчиненный

еще, говорят, ЭтотУзел можно менять как-то, но я не пробовал

вот я и называю его текущим. Менял много раз, при необходимости Когда меняешь его реквизиты, то тем самым можно из одной базы условной "первой заготовки" сделать произвольное множество разных "Узлов РИБ". Каждый ЭтотУзел можно сделать как главным, так и подчиненным и задать ему новые значения реквизитов. А для типовых обменов между базами все значения реквизитов узлов в базах должны парно (источник-приемник и обратно) друг другу соответствовать.

не код узла, а именно признак "этот узел". чтобы ГУИДы сохранились.

Имхо: ещё не известно кто, кого путал и запутал. При создании "ЦБ" из "УБ" (ошибочные термины, ну да бог с ними) теряется уникальная информация, которая находилась в "ЦБ" и не мигрировала в "УБ". Даже если это обмен по плану "Полный". Поэтому я и рекомендовал восстанавливать "ЦБ" из "последний архив ЦБ от июня 2016" за счет актуализации объектов из "УБ".

конечно, это самое правильное, образ ЦБ не терять и почковать периферийки из нее, а не наоборот. Вплоть до того, что забакапить на вечное хранение ЦБ после отпочковывания подчиненых и регулярно, после существенных доработок в ЦБ сохранять эти бакапы. Т.е. пусть даже и не каждый день бакапить, но так, чтобы при поднятии базы ЦБ из архива с запуском обменов не было сообщения << Ошибка при вызове метода контекста (ПрочитатьИзменения): Конфигурация узла распределенной ИБ не соответствует ожидаемой!  >>

какая например информация?

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