Ситуация, когда физический сервер или база данных главного узла в распределенной системе (РИБ) оказывается безвозвратно утерянной, является критической для любого бизнеса. Однако архитектура платформы «1С:Предприятие 8.3» позволяет восстановить работоспособность сети, используя один из подчиненных узлов в качестве нового «центра». В этой статье мы подробно разберем, как превратить периферийную базу в главную и восстановить обмен данными.
Перед началом активных действий нам необходимо проанализировать структуру оставшихся узлов. В распределенных базах часто встречается не только «звездная» топология (все подчинены одному центру), но и иерархическая (каскадная). Рассмотрим ситуацию, когда у нас остались две базы:
Если главный узел (ГЛ) утерян, наша задача — сделать Узел №1 полностью независимым (главным), чтобы он мог продолжать полноценно обмениваться данными с Узлом №2 и, при необходимости, с новыми периферийными базами. Важно помнить: простое копирование базы не сделает её «главной» автоматически, так как в системных таблицах сохраняется признак подчиненности.
Для того чтобы периферийный узел перестал считать себя подчиненным, необходимо разорвать связь на уровне платформы. Это можно сделать двумя способами. Выбор зависит от того, имеем ли мы возможность запустить базу в режиме «Предприятие».
Способ А: Программный метод (через встроенный язык)
Если мы можем зайти в базу под пользователем с полными правами, запустим внешнюю обработку или воспользуемся консолью кода. Нам понадобится метод ПланыОбмена.УстановитьГлавныйУзел(). Рассмотрим следующий пример кода:
// Процедура снимает признак подчиненности текущей базы
Процедура ОтключитьОтГлавногоУзла()
Попытка
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Сообщить("База успешно отключена от главного узла и теперь является независимой.");
Исключение
Сообщить("Ошибка при попытке отключения: " + ОписаниеОшибки());
КонецПопытки;
КонецПроцедуры
После выполнения этой команды база Узла №1 станет считать себя «главной». У нее разблокируется возможность изменения конфигурации, которая ранее была доступна только через обновление из центра.
Способ Б: Параметр командной строки
Бывают случаи, когда база блокирует вход из-за несоответствия конфигураций или ожидаемого сообщения обмена. В такой ситуации используем запуск 1С с ключом в командной строке (через CMD или настройки ярлыка):
1cv8.exe /ResetMasterNode
Этот параметр принудительно очищает ссылку на основной узел в системных параметрах информационной базы при старте.
Теперь, когда Узел №1 стал независимым, проанализируем список узлов в меню Операции - Планы обмена (или через интерфейс администрирования синхронизации данных). Проверим следующие моменты:
Разберем критически важный нюанс, о котором часто забывают. РИБ строго следит за номерами сообщений. Каждое сообщение имеет номер: «Принятое» и «Отправленное». Если новый главный узел отправит сообщение №10, а подчиненный узел ожидает сообщение №500 (которое он когда-то получил от старого центра), обмен будет заблокирован.
Выясним, как сбросить или скорректировать номера. Для этого в форме узла плана обмена вручную или программно установим значения:
Проделаем это в обеих базах (в новом центре и во всех периферийных). Это заставит систему начать нумерацию пакетов данных заново.
Если мы работаем с современными конфигурациями (Розница, УТ 11, БП 3.0), недостаточно просто изменить план обмена. В таких программах активно используется «Библиотека стандартных подсистем» (БСП), которая хранит дополнительные идентификаторы.
Проанализируем константу ИдентификаторИнформационнойБазы. При создании копии узла этот GUID остается прежним. Если мы планируем подключать новые узлы, нам может потребоваться обновить идентификатор базы, чтобы механизмы синхронизации не путали новую «центральную» базу со старой «периферийной». Для этого используйте типовые обработки из состава БСП для изменения настроек синхронизации данных.
За долгое время автономной работы (как в нашем примере — полгода) в базах накопилось огромное количество изменений. Посмотрим на таблицы регистрации: каждый измененный документ, справочник или запись регистра «ждет» своей очереди на отправку.
Рекомендация: Перед первым запуском обмена после восстановления структуры крайне желательно очистить регистрацию изменений, если данные в базах уже актуализированы вручную или иными способами. Если этого не сделать, первая выгрузка может занять десятки гигабайт и привести к переполнению памяти или диска.
Используйте программный метод для очистки регистрации по конкретному узлу:
УзелОбъекта = ПланыОбмена.ПоМагазинам.НайтиПоКоду("КодУзла2");
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбъекта);
Выясним причину возможных «сюрпризов» после слияния. Если в период отсутствия связи в обоих магазинах (Узел 1 и Узел 2) создавали, например, новые карточки номенклатуры, то при возобновлении РИБ возникнут дубли. Платформа 1С в РИБ сопоставляет объекты по их уникальному идентификатору (UUID).
Даже если наименование и артикул совпадают, UUID у созданных вручную объектов будут разными. В итоге в справочнике появится две записи «Молоко 1л». Рассмотрим шаги по минимизации вреда:
Восстановление РИБ через «повышение в звании» подчиненного узла — это рабочий и эффективный метод, который избавляет от необходимости создавать начальный образ с нуля и заново разворачивать базы на точках. Главное — четко следовать последовательности: отключение от мастера -> сброс счетчиков -> очистка старой регистрации -> контроль дублей. Таким образом, мы сохраняем накопленные данные и восстанавливаем автоматизированный оборот информации в системе.