Как устранить рассинхронизацию номеров сообщений в узлах РИБ 1С

Работа с распределенными информационными базами (РИБ) — это всегда ответственность за целостность данных и непрерывность обмена. Одной из наиболее распространенных технических проблем является ситуация, когда номера отправленных и принятых сообщений в главном и подчиненном узлах перестают соответствовать логике системы. Проанализируем ситуацию: в главном узле номер отправленного сообщения — 4753, а принятого — 2792. В подчиненном узле при этом отправлено 2960, а принято 4571. Такой разрыв блокирует обмен, так как система ожидает пакеты со строго определенными номерами.

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

Разберем механику процесса: почему номера «разлетаются»?

Перед тем как приступать к правке, выясним причину. В нормальном состоянии обмен работает по принципу квитирования (подтверждения). Когда Главный узел отправляет сообщение №100, Подчиненный узел должен его принять и в своем ответном сообщении прислать подтверждение: «Я принял твое сообщение №100». Только после этого Главный узел удаляет регистрацию изменений для объектов, вошедших в это сообщение.

Основные причины сбоя:

1. Восстановление базы из резервной копии. Если одну из баз «откатили» назад, её счетчики вернулись в прошлое, а вторая база об этом «не знает» и ждет продолжения нумерации.
2. Сбои при загрузке тяжелых пакетов. Файл был прочитан, но транзакция записи не завершилась или не отправилось подтверждение из-за разрыва связи.
3. Программные ошибки. Ошибки в коде обработчиков обмена или критические ошибки платформы при реструктуризации базы.

Способ 1: Метод полного обнуления счетчиков

Проанализируем самый простой и быстрый способ, который часто советуют на технических форумах. Он заключается в установке нулевых значений во всех четырех полях (отправленные и принятые в обоих узлах).

Алгоритм действий:

1. В главном узле заходим в настройки синхронизации данных.
2. Находим нужный узел и устанавливаем Номер отправленного = 0 и Номер принятого = 0.
3. Переходим в подчиненный узел и выполняем аналогичную операцию: Номер отправленного = 0 и Номер принятого = 0.
4. Запускаем обмен сначала из главного в подчиненный, затем обратно.

Важное предостережение: Посмотрим на риски. При обнулении номеров система может повторно отправить все зарегистрированные изменения. Если в базах накопилось много изменений, первый обмен после обнуления может быть очень долгим и породить конфликты версий объектов. Мы рекомендуем использовать этот метод только в крайнем случае, когда логическая последовательность полностью утеряна.

Способ 2: Метод выравнивания (подгонки) номеров

Этот метод более изящный и безопасный. Мы не сбрасываем историю в ноль, а «подсказываем» базам, какие сообщения на самом деле являются актуальными. Проанализируем ситуацию из примера автора:

• Главный узел: Отправлено 4753, Принято 2792.
• Подчиненный узел: Отправлено 2960, Принято 4571.

Разберем по шагам, как выровнять эти значения:

1. В Главном узле: Устанавливаем номер принятого сообщения равным номеру последнего успешно отправленного из подчиненного узла. В нашем случае ставим Номер принятого = 2960 (или 2959, чтобы наверняка подхватить последние данные).
2. В Подчиненном узле: Устанавливаем номер принятого сообщения равным номеру последнего успешно отправленного из главного. Ставим Номер принятого = 4753 (или 4752).

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

Способ 3: Использование обработки «Регистрация изменений для обмена»

В современных конфигурациях на базе БСП (Библиотеки стандартных подсистем) нет необходимости писать код для смены номеров. Рассмотрим, как это сделать штатными средствами:

1. Откроем обработку Регистрация изменений для обмена (её можно найти через «Все функции» или в разделе «Администрирование — Синхронизация данных»).
2. Выберем нужный узел обмена.
3. Нажмем кнопку Изменить номера сообщений (или иконку «карандаш» рядом с номерами).
4. В появившемся окне вручную отредактируем Номер отправленного и Номер принятого.

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

Программная корректировка номеров

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

// Пример для программного изменения номеров сообщений
УзелОбъекта = ПланыОбмена.ПоОрганизации.НайтиПоКоду("П01").ПолучитьОбъект();
УзелОбъекта.НомерОтправленного = 0;
УзелОбъекта.НомерПринятого = 0;
УзелОбъекта.Записать();

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

Работа с XML-пакетом: «экстренная помощь»

Иногда бывает так, что файл обмена уже сформирован, он огромный, и мы не хотим переформировывать его заново. Разберем ситуацию: подчиненный узел не принимает файл, так как ожидает номер 4572, а пришел файл с номером 4500.

Мы можем открыть XML-файл обмена в текстовом редакторе (например, Notepad++) и найти в самом начале теги MessageNo и ReceivedNo. Если вручную изменить значение MessageNo на ожидаемое базой-приемником, система может «проглотить» файл и успешно его загрузить. Однако будьте осторожны: это нарушает целостность цепочки подтверждений и должно использоваться только опытными администраторами.

Резюме и рекомендации

Подведем итог нашему анализу. Рассинхронизация номеров в РИБ — это не приговор для базы, а штатная проблема, требующая внимания к деталям.

1. Не спешите обнулять. Сначала попробуйте метод выравнивания (подгонки) номеров под актуальные значения.
2. Проверьте журнал регистрации. Перед любыми манипуляциями выясните причину сбоя: возможно, база не загружает сообщения из-за ошибки в данных (например, дубли предопределенных элементов или нарушение уникальности кодов), а номера — это лишь следствие.
3. Следите за конфигурацией. Если номера перестали расти, проверьте, совпадает ли версия метаданных в узлах. Иногда «зависшее» обновление конфигурации блокирует инкремент счетчиков сообщений.
4. Делайте бэкапы. Любое вмешательство в структуру планов обмена лучше проводить после создания резервной копии базы данных.

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