Восстановили РИБ из бэкапа

Нумерацию сообщений подправить не проблема, но как засинхронить конфигурации?

1. Отвязываем дочку от главного узла
2. Загружаем конф из ЦБ
3. Обратно привязываем.

4. Как ЦБ поймет, что не нужно файл изменений конфигурации готовить для дочки? Файл выгрузки получается с частью конфигурации.

> 4. Как ЦБ поймет, что не нужно файл изменений конфигурации готовить для дочки? Файл выгрузки получается с частью конфигурации.

Ничего страшного от этого не произойдёт.

Там обновление релиза с файлом конф на 2,5 гб
Хотелось бы не включать это в обменный файл..

(2) Открыть файл и "ручками" удалить изменения конфигурации, оставив только изменения данных, не предлагать?

нет, как в ЦБ установить принудительно пометку о принятии конфигурации в периферии?

(4) Никак. Только если принять от подчиненного узла сообщение обмена.

Расшифрую: так, как в ПУ Вы уже изменили конфигурацию, то в сообщении обмена от ПУ будет указана контрольная сумма, соответствующая конфигурации ЦУ и при формировании сообщения обмена для ПУ более не будут отправляться изменения конфигурации из ЦУ... как мне кажется :))

PS: вариант, указанный в (0) может "выйти боком" в актуальных конфигурациях. Например, в ПУ будут запущены обработки обновления, которые должны исполняться только в ЦУ. Или, например, не будут синхронизированы предопределенные данные НСИ.
PSS: впрочем за предопределенные данные можно не волноваться - в актуальных конфигурациях есть функционал принудительной синхронизации этих данных.

(7) То что в ПУ они будут запущены это ладно
Затем обратным обменом это прилетит в ЦУ и там исполнение обработчиков обновления сбросится

(8) По умолчанию приоритет за изменениями ЦУ. Поэтому изменения из ПУ будут отвергнуты в ЦУ, повторно отправлены ЦУ и приняты в ПУ. Как бы ничего страшного, само собой устаканится... но фишка в том, что в ПУ результаты работы обработок могут быть несколько другими (теоретически) и тогда изменения из ЦУ не "перекроют" измененные данные в ПУ. Я с таким уже сталкивался много лет назад, когда разработчики конфигураций не особо думали о корректности работы конфигураций в РИБ.

(7) обработка регистрации предопределенных данных и высокоприоритетных данных у меня уже есть.

(8) если в файле от ПУ в контрольных суммах указать то что теперь выходит из ЦБ, он подумает что конф загржена?

(10) см (5)
после 2. и 3. делаем выгрузку из ПУ в ЦУ (без загрузки, файл из ЦУ удалить предварительно)
в ЦУ загружаем и выгрузка будет (должна быть) без конфы

Но еще встанет вопрос как перевыгрузить из ЦУ в ПУ утерянное после восстановления из бэкапа
Без полной выгрузки всего
Теоретически можно использовать анализ ЖР и УИДов

(12)+ И прямые запросы sql, для регистров например

(12) эти контрольные суммы, наверное, влияют только на конфигурацию, очередь данных регистрируется в плане обмена.

(14) данные уже могли быть выгружены из ЦУ в ПУ, и ответ пришел, из состава отправляемых уже пропало
бэкап ПУ восстановлен без них

"... он подумает что конф загружена?"(10) Хмм... давно с этим не экспериментировал. Насколько я помню в файлах обмена есть идентификаторы конфигураций (ранее использовался <Digest1>, а позднее - <Digest2>) для идентификации конфигураций узлов РИБ... но при идентичности конфигурации эти идентификаторы были не идентичны.

(12) "Теоретически" можно написать обработку сравнения данных двух баз. Ничего сложного :) На просторах интернета гуляют куча подобных бесплатных обработок. Ищем, скачиваем, напильник в руки и нет проблем.

(16) одинаковые, только что проверял, когда нету части конфы в пакете

(17) Это долго когда базы большие с кучей данных за много лет
Чем все сравнивать лучше каким то образом ограничиться по дате изменения

(18) После обновления конфигураций ключи в узлах (атрибут V2) тоже обновятся. И на какие именно Вы "не в курсе" пока не обновите конфигурацию.

(19) Не соглашусь насчет "долго". Всё относительно. Например, у меня обработка, регистрация изменений и обмен данными занимает около часа (файл выгрузки БД в .db - около 10 гиг).

PS: иногда использую чтобы копию базы поднять из архива и "дотянуть" до актуального состояния рабочей.

Доброе утро!

А при выполнении п.2 из темы, расширения надо тоже подтягивать вручную, которые используются в РБД?
Их там несметное количество

(22) Список расширений должен совпадать да

(0) грузани правила РИБ в КД2 , посмотри что там

"Их там несметное количество"
/DumpCfg <имя cf/cfe файла> [-Extension <Имя расширения>]
/LoadCfg <имя cf/cfe файла> [-Extension <Имя расширения>]

Кстати с расширениями это хороший пример "недоработки"
Когда придумывали РИБ про обновление конфы подумали, но расширений еще не было
После появления расширений по идее надо было их так же в РИБ добавить, чтобы они синхронизировались (по правилам да)

(25) не не, спасибо, я пожалуй через
DumpConfigToFiles -AllExtensions