Ситуация, когда при создании копии центральной базы забывают отключить регламентные задания, является одной из самых частых причин «развала» распределенной информационной базы (РИБ). В результате копия базы начинает обмениваться данными с периферийными узлами, подменяя собой основной узел. Разберем подробно, почему это происходит и как восстановить работоспособность системы, не прибегая к полному пересозданию образов.
Для понимания процесса восстановления нам необходимо проанализировать техническую суть механизма обмена. В РИБ каждый узел имеет уникальный идентификатор. Периферийная база (узел-приемник) идентифицирует «свой» центр по коду и внутреннему идентификатору (GUID). Когда создается полная копия центра, она наследует все эти признаки. Если копия базы выполняет обмен, периферия принимает этот пакет данных как легитимный.
Основная проблема заключается в номерах сообщений. В каждом сообщении обмена передаются два ключевых числа: «Номер отправленного» и «Номер принятого». Периферийный узел жестко контролирует эти номера: он примет сообщение от центра только в том случае, если номер входящего сообщения строго больше номера последнего успешно принятого сообщения. Если копия базы отправила пакет с номером «105», а оригинальная база «застряла» на номере «100», то при попытке синхронизации оригинала периферия выдаст ошибку, так как ожидает номер 106 или выше.
Первым делом нам необходимо привести в соответствие счетчики сообщений в обеих базах. Рассмотрим два способа решения этой задачи.
Способ А: Ручное сопоставление номеров
Проанализируем текущее состояние номеров. В центральной базе (оригинале) откроем форму настроек узла обмена (Планы обмена — РИБ). Посмотрим, какой номер сообщения был отправлен последним. Затем перейдем в периферийную базу и посмотрим «Номер принятого сообщения» от главного узла. Если в периферии номер больше, чем в центре, нам нужно вручную в центральной базе установить «Номер отправленного» на единицу больше, чем зафиксировано в периферии как «Принятое».
Способ Б: Обнуление счетчиков (наиболее надежный метод)
Часто проще «начать жизнь с чистого листа», обнулив счетчики в обеих базах. Рассмотрим, как это сделать. Нам потребуется программно или через стандартную обработку Регистрация изменений для обмена данными установить значения «Номер отправленного» и «Номер принятого» в 0. После того как в обоих узлах (и в центре, и в подчиненном) номера будут сброшены, первый же обмен пройдет успешно, так как любой номер сообщения будет воспринят системой как новый.
Для программного сброса в консоли кода можно использовать следующий алгоритм:
УзелОбъекта = ПланыОбмена.ПоискПоКоду("КодВашегоУзла").ПолучитьОбъект();
УзелОбъекта.НомерОтправленного = 0;
УзелОбъекта.НомерПринятого = 0;
УзелОбъекта.Записать();
После того как мы «протолкнули» техническую возможность обмена, мы столкнемся с проблемой потери данных. Пока работала база-копия, в ней могли регистрироваться изменения, которые не попали в оригинал, а в оригинале — изменения, которые не ушли в периферию. Проанализируем ситуацию: нам нужно гарантировать, что все актуальные данные из центра попадут во все узлы.
Разберем по шагам работу с обработкой Регистрация изменений для обмена:
Контрагенты и документы ПоступлениеТоваровУслуг).Посмотрим на ситуацию с другой стороны: если в периферийной базе за это время были созданы новые документы, их также нужно принудительно зарегистрировать для отправки в центр, чтобы восстановить целостность данных во всей сети.
При рассинхронизации часто возникают коллизии. Например, в копии базы был изменен документ, и эти изменения ушли в периферию. В оригинале этот документ остался прежним. При восстановлении обмена система должна решить, какая версия документа главная. По умолчанию в 1С:Розница приоритет имеет Центральный узел.
Проанализируем возможные последствия:
Для минимизации проблем рекомендуем после успешного обмена запустить стандартную обработку Поиск и удаление дублей, чтобы проверить справочники Номенклатура, Контрагенты и Дисконтные карты.
Если вам все же необходимо продолжать использовать копию базы (например, для тестов), крайне важно предотвратить повторение ситуации. Разберем, что нужно сделать в копии:
/AllowExecuteScheduledJobs -Off.Регистрация изменений для обмена, выбрав команду «Удалить регистрацию для всех объектов».Если рассинхронизация затронула огромные массивы данных или привела к повреждению структуры (например, разошлись конфигурации), ручное «выравнивание» может занять слишком много времени и не гарантировать результат. В таком случае рассмотрим вариант создания нового начального образа.
Этот метод гарантирует 100% идентичность данных. Вы создаете новый файл базы для подчиненного узла из центральной базы (через меню Создать начальный образ). Однако помните, что это потребует передачи большого файла на удаленную точку и полной замены базы на периферии, что приведет к потере тех данных, которые были созданы в периферийном узле и не успели уйти в центр до сбоя.
Важный совет: Перед любыми манипуляциями с номерами сообщений и регистрацией изменений обязательно сделайте резервные копии всех баз, участвующих в обмене. Это застрахует вас от окончательной потери данных в случае ошибки при ручной корректировке планов обмена.