Доброго вечера!
Полетел главный узел РИБ, попытки восстановить привели к неожиданному результату. Прошу вразумить, ибо логика, похоже, дала воскресный сбой. Или же это не знание мат. части(((
Что имеется: РИБ, полный обмен по магазину, все данные транслируются через главный узел во все узлы. 4 неповрежденных узла и напрочь убитый главный узел. Есть копия 5-дневной давности главного узла. И, к великой удаче, все данные до сбоя успели синхронизироваться в периферийные узлы. Т.е. имеем копию 5-дневной давности главного узла + все данные за 5 дней, хранящиеся в периферийных узлах + некоторое количество несинхронизированных данных в периферийных узлах (после сбоя 2 дня узлы работали без обмена).

Вроде, все должно быть просто... Изменила номера сообщений в периферийных узлах на те, что зафиксированы в сохранившейся копии главного узла. Синхронизировала.  И.. ничего.. - передались только документы, которые были созданы в периферийных узлах уже после сбоя. А 5-дневный период не перенесся. Как же так???.....
Перепровела документы в периферийны узлах с даты копии главного узла. Так они перенеслись. Ок. Но дальше еще интереснее.
Бегло сверяю остатки (пока просто общее кол-во всего на каждом складе) на дату сохраненной копии главного узла с остатками той же даты в копиях узлов до начала восстановления. Не сходятся!!
Т.е. на 10 апреля во всех узлах остатки одинаковые, а после восстановления описанным выше способом эти цифры по остаткам также совпадают во всех узлах, но отличаются от исходных...

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

"Полетел главный узел РИБ"
Как это выражается?

(0) вроде ничего удивительного, если просто поменять номер сообщения, то конечно ничего не зарегистрируется для обмена, и ничего обмениваться не будет. А как только вы перепровели, естественно эти документы зарегистрировались и попадают в обмен.

(0) После "восстановления" базы главного узла и обмена, в главный узел были преданы 5-дневные изменения, сделанные в периферийных узлах. Данные, которые вы потеряли в главном узле, нужно повторно зарегистрировать для обмена. Флаг Вам в руки, журнал регистрации - в зубы и дай Вам бог удачи выявить и зарегистрировать все "потерянные" данные.

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

(2) - очередное отключение света, после которого список поврежденных таблиц ChDbfl на 2 листа, несколько сотен невосстановленных записей по документам, регистрам. Решила, проще будет взять живую копию да перенести данные, благо, в периферийные все передалось прям в аккурат за пару минут до сбоя.

(3), (4) - благодарю! Вот смотрела на эти кнопки  - "Зарегистрировать объекты при помощи отбора " и "Отменить регистрацию объектов.. "   в обработке "Регистрация изменений для обмена" (конф Розница 2.2).. интуиция пискнула и была проигнорирована)
Я верно поняла, что нужно отобрать документы, спр, рег и тд в каждом узле с момента сбоя и выбрать "зарегистрировать"? После чего сделать синхронизацию. Номера сообщений предварительно все равно меняю на те, что успели передаться в копии за 5 дней до сбоя?

Этот вариант для простого случая, когда точно известно, что за эти несколько дней ничего задним числом не правили, старые элементы справочников не трогали, были просто продажи и поступления. А если сбой бы случился в какой-нибудь БП, то уже надо искать другой способ, например, как вы предложили в (5)?
А разве по номерам отправленных сообщений, которые можно увидеть вот здесь https://postimg.cc/nMGC30x9 , нельзя определить, какие данные были изменены? Может, можно как-то пометить, что "синхронизировать все данные, начиная с такого-то номера.."?

(5) - да, что-то такое припоминаю, спасибо!!

(6) синхронизировать все данные, начиная с такого-то номера - нет там такого. Если Сообщение синхронизировалось, после этого оно полностью исчезает, нет никаких следов.

(8) - большое спасибо! получается, те цифры, которые вижу на скрине напротив документов - это номера сообщений, которые еще не были переданы? а все, что было передано когда-то, и не изменено с тех пор, оно уже без номеров, для него "нет изменений"? эх... это ж действительно только сравнением данных баз "выковыривать" все изменения...

последнее сообщение (8) - ответ на (7)

Технически данный конкретный обмен считается полным или там какие-то доработки сделаны, которые блокируют полную передачу данных?

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

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

(11) - именно в ноль? интервал никак не отловить каким-нибудь отбором по дате?
       документов в базе за пару лет с момента обрезки, розничная бойкая торговля. с другой стороны - это машинное время, запустил и забыл...

(12) если рассуждать цинично, то задайтесь вопросом, а какой вообще смысл в наличии центральной базы?

Я бы забрал копии всех узлов на центральный сервер и в рабочем порядке синхронизировал их с центром. Ну не быстро и но и не страшно - ведь два дня без обмена выжили.

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

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

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

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

PS: в интернете куча бесплатных обработок сравнения объектов выложено, которые легко адаптировать под решение своей проблемы.

(13) - по сути, центральный узел - это "домашний офис". Через него забивается приход товара, смотрится какая-то аналитика, магазины в это время продолжают работать, очередь из людей не копится, пока товар заносится.. На будущее запомню, что можно сделать еще один узел ("главный"), который будет просто для передачи сообщений обмена. Чтобы лицензию не докупать, можно просто как вторую базу подключить на том же компе. Хотя сейчас не до конца понимаю смысл еще одного узла...
Благодарю за идею забрать копии узлов и синхронизировать в то время, как магазины будут спокойно работать! Не додумалась...

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

А вариант 2 - это отбираю все-все виды документов, справочников, регистров, константы и тд в окне обработке (скрин тот же https://postimg.cc/nMGC30x9) с даты-времени сбоя, каждый документ, регистр и тп прощелкиваю в "зарегистрировать для обмена", после этого номера сообщений могу не менять, просто синхронизировать? и так, понятно, в каждом узле.

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

центральный узел по любому ставьте на SQL, есть лицензия минисервера, сам SQL для небольших баз бесплатный... Ну и УПС нужен, что-бы держал "сервер" гарантировано 15 минут, а лучше 30

(15) не надо сравнивать сами объекты, достаточно сравнить только 1 поле "версия"

(19), (20) - благодарю! А можете посоветовать УПС из недорогих, чтобы держал столько? Сейчас в одном из магазинов стоит бюджетный УПС, не держит совсем.

Не используйте файловую версию информационной базы для центрального узла (ЦУ). А если используете - настройте регулярное создание копий, например, хотя бы каждый час. Для архивации можно использовать внешние архиваторы или типовой функционал актуальных версий конфигурации. ВАш кэп.

[off] или, например, как у меня было: создайте ещё один узел (копированием базы ЦУ), который будет обмениваться с ЦУ по плану обмена, в состав которого включены все без исключения объекты данных. Этот узел не предназначен для работы юзверей - он используется в качестве псевдо "зеркала" ЦУ. Дешёво и сердито.

(22) // он используется в качестве псевдо "зеркала" ЦУ. Дешёво и сердито.

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

(22) - благодарю! мотаю на ус, буду пробовать.
      с копией центрального узла идея очень нравится ((22) - и правда, не пришла в голову такая мысль, и не сразу дошел смысл, зачем еще один узел) теперь восхищаюсь лаконичностью и простотой предложенного решения :-) благодарю!).
      Получается, что этот "зеркальный узел" должен быть всегда запущен? (Если запускать его, к примеру, только вечером, а выгрузку из центра настроить автоматическую, то, теоретически, может случиться так, что центральный узел выгрузил сообщение, затем произошел сбой, центральный узел его пережил с какими-то потерями и продолжил работать (не всегда сообщают, что произошел сбой, могут продолжить работать после этого в базе, если она запустилась). Тогда след сообщение для обмена с "зеркалом" будет уже из поврежденной базы и затрет предыдущее).
Т.е. "зеркальный узел" должен быть всегда запущен и располагаться на др компе? Так... а если он всегда запущен, то в случае, описанном в предложениях выше, он ведь и загрузит то, что пришло после повреждений... Какой-нибудь бы скрипт написать, что если "предыдущее завершение работы было неожиданным", то не позволять запустить базу 1С... И распространить его на все компы, т.к. в магазинах, конечно, тоже могут запустить после сбоя...

блин... вторая пометка (22) в предыдущем сообщении должна быть (23)..

// Какой-нибудь бы скрипт написать

без написания скрипта корректно настроить работу зеркала для ЦБ вряд ли получится. На первое время получится, но как запустишь, то сразу появятся идеи, что там лучше усовершенствовать.

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

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

(24) Да,"зеркало" всегда должно регулярно обмениваться информацией с центральным узлом. Чем чаще - тем лучше. Так, как в "зеркале" никто не работает, то обмен информацией фактически будет "односторонним" - от центрально узла к "зеркалу". Второй "плюс" отсутствия юзверей на "зеркале" - журнал регистрации действий работы пользователей будет состоять только из записей обмена данными. Легко найти  записи какой объект когда изменялся/мигрировал.