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