Добрый вечер, коллеги.

Ситуация, близкая к катастрофе. База 1С:Розница 1, переписанная. 200+ узлов. Узлы разделены на 2 центра(около 100 в каждом). Центры меняются между собой штатно очень неохотно. Для их обмена желательно забанить остальные обмены(между узлами РИБ), обмен между центрами идет очень долго(до 10-12 часов). Проблема заключается именно в обмене между центрами(нестабильно, очень долго).

Решения видятся такие:
1. Перенести все узлы в один центр. Решение не нравится, т. к. для переноса надо будет загрузить остатки из одного центра в другой и перенести документы и движения за определенный период. + перенастроить обмены узлов одного из центров. Можно, конечно, попробовать многопоточно это осуществить, но есть опасения по времени переноса.
2. Настроить обмен между центрами таким образом, чтобы все работало на порядок быстрее.

Вопрос именно по п. 2. Если я в одном центре сделаю новый план обмена, в котором будет, к примеру, 5 магазинов(из магазинов этого центра), во втором центре - такой же план обмена и так столько планов обмена, сколько потребуется(пока магазины не закончатся) - заработает ли такая схема?

Сначала выясните что именно тормозит.

Имхо я бы перенес актуальную НСИ в новую чистую базу (центральную), затем создал бы там 101(2) узла.
И начал по очереди переносить туда только текущие остатки с переводом юзеров на работу в этой базе.

1 ЦБ для обменов (юзеры не работают) у нее 101 ПБ.
Где 1 ПБ это бывшие слитые центра (можно и два сделать если это по территориальной структуре лучше)
И 100 ПБ это прежние узлы.

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

(2)+ Особенность выделенной ЦБ (без юзеров) в том что она без блокировок круглосуточно только обменами и занимается.

(2) Сорри 201(2) узла

(4) Вы все-таки за одну базу...
С одной базой будут проблемы с переносом в нее данных из другого центра.
Сейчас один центр меняется в две стороны со своими узлами в течение получаса. Поэтому сильно не хочется все сливать в один центр, а научить оба центра меняться гораздо быстрее(по пулам узлов. Например, по 5-10 штук)

(5) Какая то хрень если "один центр меняется в две стороны со своими узлами в течение получаса".
То два центра между собой всей инфой должны меняться в течение часа.

(6)+ И так же за этот же один час должен происходить обмен если одна ЦБ и у нее 200+ ПБ.

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

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

(9) Особенность розницы что чеки раньше было обязательно в центр переносить.
Сейчас когда есть онлайн ККТ это уже не обязательно, достаточно что они где то сохраняются помимо одной базы как бэкап.

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

(10)+ "У нас база пропала" не является оправданием для закона, на бэкапы периферийных баз в отделах надеяться никогда нельзя, это я по отрицательному опыту выучил.

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

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

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