Есть Розница 2 (РИБ) - центральная база и 2 узла от неё. Релиз 2018-го года, нужно обновиться до текущей. Как правильно обновлять? Обновить Центральную базу до последней версии последовательно, а потом сделать обмен с подчиненными узлами, чтобы те обновились тоже до последней сразу? Или по одному обновлению накатывать на Центральную и тут же делать обмен, и так до тех пор, пока на последний релиз всё не обновится?

Две подчиненные используются как фронт на точках. ЕГАИС, маркировки нет.

Отключить узлы, пошагово обновить центр, пересоздать узлы

(1) То есть те базы на точках вообще удалить, получается?
А если там рабочие места с привязанным оборудованием - ФР и банковские терминалы? Это всё не слетит?

(0) надо какой-то промежуточный вариант. По 2-3 обновления. А то сразу на 2 года дотекущей опасно.

(2) перенастроишь заново

(1) поддерживаю. Практика показала, что обновление РИБ на несколько релизов не работает от слова совсем...

(4) А не проще просто обновлять и делать обмен (один раз или несколько)? Почему именно пересоздать? На настройку рабочих мест может уйти больше времени и больше геморроя.

(6) заново настроить придется только обмен, с чего это вдруг все оборудование перенастраивать?

(7) В Центральной рознице в разделе "Подключаемое оборудование" нет того оборудования, которое есть на точках. И если я узлы создам заново - то ведь и оборудование надо будет заново подключать.

(8) а центральный узел и не надо скидывать. Зачем?)

Периферии делаем обычными, обновляем, делаем опять переферийками. И все...
Сотни раз так уже делал.

(9) Тогда не совсем понимаю фразу из (1) "Пересоздать узлы".
Вот у меня есть Розница Центральная, в офисе. В ней сделан РИБ по магазину.
В магазине стоит Розница (файловая база) - узел от Розницы Центральной из офиса.

Фразу из (1) понимаю следующим образом: обновить Центральную Розницу, потом из неё создать заново узлы (базы для магазина) и эти новые базы поместить на компьютеры в магазине, а старые базы вообще убрать.

(10), (11) Возможно, я не так всё понимаю)

(11) ну, не так мысли изложил.
Узлы заново не надо никакие скидывать.
Поменять переферейку в простую и обратно, это 4 раза нажатия кнопки. Тема разжёвана давно и проще не бывает.

(13) единственное, при создании обратно переферийки, требуется указать ее префикс, как там, РР, или ТТ, как у вас было.

(13) То есть имеется в виду из узлов сделать обычные базы, все три базы обновить отдельно друг от друга, а потом обычные в магазинах сделать опять подчиненными?

(15) Совершенно верно.

Вообще, если есть желание на сохранение актуальности Розницы в типовой привязке к обновлениям, то нужно мониторить постоянно и отслеживать появление критических изменений.

И понятно, что даже если это не РИБ, но решили забить болт на получение в базах регулярных обновлений ... - а иногда это весьма разумное поведение.
То все равно нужно каким-то образом состояние мониторить и четко понимать, когда и в каких объемах выполнить обновление.

Ну а дальше надо смотреть уже по конкретике самих баз. Были допилы или не были, как эти допилы дружат с обновлением, тем более, если это обновление в РИБ и т.п.

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

Есть еще высокая вероятность, что база позволит при грамотном обновлении перепрыгнуть через несколько релизов, но без тестирования такое не предложить.
И даже без наличия конфигурации поставщика тоже, можно взять нужный готовый ЦФ или несколько промежуточных ЦФ и обновить базы на переферийках обновлением из ЦФ, а не передавая их в РИБ обменах.

Между прочим, подозреваю, что часто не очень представляют себе , как происходит передача изменений в РИБ и на что эта передача похожа, если это же самое делать вручную.

Если изменение конфигурации передается через РИБ, то это нужно понимать, как просто замену в конфигурации объектов метаданных на объекты из центра. Один в один.
Ни объединения, ни сравнения, ни каких-то загадочных манипуляций - ничего этого нет - если вручную, то берешь CF от центральной базы и загрузкой из файла ставишь его в ПБ и только.

А далее, полученное состояние текущей конфигурации применяется к базе, реструктуризация, реиндексация и в базе устанавливается "конфигурация БД"

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

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

(1) накуа? просто приостанови обмен и всё, йопта.
потом, возможно почисти изменения ненужные, если их много.

(20) слышал звон, да не знает, где он)

(21) А в чём проблема? У меня 6 перифириек и как-то обновляюсь. Правда вначале пробую на своем компе с одной перефирийкой, и да, автоматические обмены при обновлениях отключаю.

(22) вот вот. если че, я живьем видел обновление РИБ на 4 узла. Админ делал даже, не 1сник.

(17) не усложняй без надобности

(23) теперь, ты можешь со спокойной душой сказать, что ты в жизни видел всё)

(25) ну что ты, с 1с бывают извращения и "поинтереснее"

Если есть возможность пересоздать РИБ и это никого не напряжет, это самый удачный путь. Я не так давно обновлял розницу. Чуть моложе чем твоя. 15 релизов обновления. Одно обновление на не очень старом сервере занимает час вместе с обработчиками. Это очень много времени. Выгрузка в РИБ резко начинает весить вместо килобайт поглига. Пропускать релизы опасно пропущенными обработчиками которые изменяют данные которые не ходят между базами.

(27) Погоди, так ведь с пересозданием РИБ времени уходит больше? Если пересоздавать РИБ - то надо каждую базу в отдельности обновить. А без пересоздания (с обновлением только центрального узла) - время уйдёт только на обноление на несколько релизов центральной базы, а потом - одно обновление при выгрузке из центральной базы в узел. Разве не так?

(28) «Всё смешалось в доме Облонских». Пересоздание узла - это простое "Создание начального образа", его уже не надо обновлять. Тяпница сказалась видимо, трезвенники курили бамбук :)

(28)Еще раз. я считаю некорректным выгрузку только последнего релиза. Обмен должен происходить после каждого обновления, причины описал выше. Это мое мнение. Могу ошибаться. Можно выгрузить и конечно в конце единым куском все. Все метаданные, что изменились. Но в этом случае проще пересоздать РИБ конечно(если есть возможность). Потому, что все изменения создадут огромадный xml выгрузки, который платформа будет курить долго, упорно, с большим количеством потребления ресурсов(и процессора и памяти) на обоих компьютерах как на выгружающей стороне, так и на загружающей. Грузить готовый образ сразу в файл базы, проще и быстрее.

(13) Если не сложно, хотел прояснить для себя. Периферийку отвязать, обновить и опять привязать - это я вроде понял )))).
Вопрос - а как с центральным узлом. Когда его обновляем, он же по идее готовит к отправке обновления во все периферийки. А они там не нужны. Значить его тоже нужно "отвязывать"?

(31) после обновлений перефериек, сделай файл обмена для центра и в центре вгрузи и ничего потом центр не приготовит.

(31)Если ты делаешь переферийки копией из центральной базы, то создай под них в центральной узлы заново после обновления с нулевыми изменениями.

(32) Спасиба, попробую.
(33) Нет, не копией. Сделаны были стандартной выгрузкой из центрального узла как я понял. Ситуация счас такая - есть торговля11 и к ней 10 перифериек, не обновлялись давно. Вот и думаю как сподручнее обновить. Вариант с отвязкой перифериек, обновлением и привязкой заново кажется интересным. Буду пробовать на копии.

(34) это один из самых простых вариантов. При желании, после всех обновлений пб можешь загрузить финальный cf от центра, тогда, даже если он и прилетит в первом обмене из центра, в перефирийку загружен не будет, ибо хеш конфы совпадет.

(35) Спасиба, буду знать.

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

(0)Бери копию. Обновляй cf. Смотри на запуск процедур в предприятии.Если ругнётся, что нужен другой релиз, то ищи cf того релиза. И так далее. Когда выяснишь, что на что можно поставить делаешь поэтапно.
1. Накатил первый cf в центральную базу, обновил выгрузил.
2. Загрузил в периферийках. Обновил, отправил в центральную результат.
3. Принял в центральной результат. Сделал ещё синхронизацию для проверки. Если файл выгрузки большой(содержит конфу). Значит что-то пошло не так.
Переходишь к пункту 1 с другим cf.

(38) ЗАЧЕМ? ЗАЧЕМ новичка плохому учите. Просто обновляете в центре на последний релиз или по цепочке и все. Последняя конфа уйдет на точки, изменения, которые сделало обновление - тоже. Все, элементарно. Зачем эти шаманские пляски?

(38) это очень долго...
(39) а этот вариант предлагают только те, кто РИБ только по рассказал слышал...
Самое простое и проверенное в (10)

(40) ну если любите БДСМ, дерзайте, гыгыгы

(39)Если есть "критичные" для обновления релизы, то человек на периферийных базах поймает %опу. Как раз с сообщением, что данный релиз можно ставить только на релиз такой-то или выше. Так что только с синхронизацией после каждого такого обновления.
Также возможен вариант с поэтапным обновлением центральной, а потом выгрузкой образов. Но это уже план Б, если где-то база встанет колом.
(40)А так можно нарваться на то, что периферийная база не захочет подключаться обратно. Да и по времени будет примерно то же самое, что и в (38).

(42) А почему перефферийка не захочет подключиться? Вы забудете префикс?

(41) Серго, а что такое БДСМ?

(39)А разве можно так делать? Ведь при обновлениях много чего происходит, переносятся данные в новые реквизиты, перезаполняются регистры и т.д.

С 2018 года в рознице не так много критичных обновлений было.. отработать их все, не так и долго..

(42) ты уверен? а что, не судьба в ЦБ отрубить этот запрет? Банальным расширением

(45) можно и нужно. не хер страдать извращениями.

(42) это легко проверить - накатил конфу последнюю на начальную копию базы. Если не ругнулась, норм.

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

(48)В Рознице точно было. В прошлом году обновлял. В БП тоже было.

(45) с 2018 года, Розница как минимум перешла с 2.2 на 2.3, поэтому, как минимум, вашей компетенции можно позавидовать.

(36) можешь еще и все изменения прибить на узле, после обновления конфы в цб и во всех пб.

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