При работе с распределенными информационными базами (РИБ) иногда возникает необходимость изменить их топологию. Типичный сценарий: в сети из трех баз (один главный узел и два периферийных) требуется полностью исключить старый главный узел. При этом одну из периферийных баз необходимо назначить новой Главной, а вторую существующую базу подключить к ней в качестве подчиненного (периферийного) узла.
Стандартный механизм платформы 1С предлагает для создания нового периферийного узла использовать выгрузку начального образа. Однако если базы имеют внушительный объем (сотни гигабайт), этот процесс может затянуться на десятки часов или прерваться по техническим причинам. Если вторая база уже существует и физически «выросла» из той же самой конфигурации, мы можем связать их напрямую. В профессиональной среде этот подход называют «альтернативным созданием начального образа».
В этой статье мы подробно разберем по шагам, как правильно связать две существующие базы в новую структуру РИБ, избежать конфликтов метаданных и настроить обмен в современных конфигурациях на базе БСП (Библиотеки стандартных подсистем), таких как Бухгалтерия предприятия 3.0, Управление торговлей 11 или ERP Управление предприятием.
Перед началом любых манипуляций необходимо убедиться, что подключаемая база изначально была создана из той же резервной копии или того же главного узла, что и будущая главная база. Если базы создавались независимо и имеют разные внутренние идентификаторы объектов метаданных (GUID документов, справочников и т. д.), связать их напрямую через РИБ невозможно. В таком случае поможет только перенос данных через конвертацию или XML-выгрузку.
Прежде чем приступать к перенастройке, обе периферийные базы необходимо сделать полностью независимыми, то есть снять с них признак подчиненности старому главному узлу.
Для этого выполним следующие действия:
/ResetMasterNode.
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После выполнения этой команды базы перестанут быть подчиненными. В них разблокируется возможность изменения конфигурации и настроек, а также пропадут все ограничения на редактирование данных, которые ранее накладывал статус периферийного узла.
Теперь выберем базу, которая станет новой Главной (в нашем примере это бывшая Периферийная 1). В ней необходимо создать инфраструктуру для подключения второй базы.
Выполним подготовку узла:
Код и понятное Наименование.ИдентификаторУзла, представляющий собой GUID в виде строки). При создании нового узла этот GUID сгенерируется автоматически. Зафиксируем это значение (его можно считать программно или посмотреть через консоль запросов/обработку), так как оно потребуется нам на следующем шаге.Чтобы вторая база успешно подключилась к новой Главной, и платформа не выдавала ошибок вроде «Несоответствие идентификатора узла» или «Ошибка формата представления изменений», нам необходимо вручную синхронизировать их внутренние идентификаторы.
Проанализируем алгоритм настройки во второй базе:
ЭтотУзел. Ему необходимо присвоить точно такой же Код, какой был задан для него в созданной записи новой Главной базы на предыдущем шаге.ИдентификаторУзла у узла ЭтотУзел во второй базе. Запишем туда точное строковое значение GUID, которое мы получили из Главной базы. Для этого можно применить следующий код:
УзелОбъект = ПланыОбмена.[ИмяВашегоПланаОбмена].ЭтотУзел().ПолучитьОбъект();
УзелОбъект.ИдентификаторУзла = "СЮДА_ВСТАВЛЯЕМ_GUID_ИЗ_ГЛАВНОЙ_БАЗЫ";
УзелОбъект.Записать();
ЭтотУзел в Главной базе.
СсылкаНаНовыйГлавный = ПланыОбмена.[ИмяВашегоПланаОбмена].НайтиПоКоду("КОД_НОВОЙ_ГЛАВНОЙ");
Если Не СсылкаНаНовыйГлавный.Пустая() Тогда
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаНовыйГлавный);
КонецЕсли;
Поскольку обе базы ранее активно участвовали в обменах с прежним главным узлом, в них накоплен огромный массив зарегистрированных изменений и служебных данных. Их необходимо полностью зачистить, иначе новые связи «зависнут», а старые транзакции могут затереть или зациклить данные.
Выполним очистку по шагам:
ВыборкаУзлов = ПланыОбмена.[ИмяВашегоПланаОбмена].Выбрать();
Пока ВыборкаУзлов.Следующий() Цикл
Если ВыборкаУзлов.Ссылка <> ПланыОбмена.[ИмяВашегоПланаОбмена].ЭтотУзел() Тогда
ПланыОбмена.УдалитьРегистрациюИзменений(ВыборкаУзлов.Ссылка);
КонецЕсли;
КонецЦикла;
РегистрСведений.ИсторияОбменаДаннымиРегистрСведений.ПараметрыОбменаДаннымиРегистрСведений.ОбъектыИнформационныхБазНомера принятых и отправленных сообщений для новой пары узлов в обеих базах необходимо принудительно сбросить. По умолчанию платформа ожидает начать обмен с чистого листа. Если номера сообщений в первой отправке окажутся некорректными относительно ожидаемых базой-приемником, платформа заблокирует чтение файла обмена.
Установим номера отправленных и принятых сообщений в значение 0 (или 1 в зависимости от версии платформы) для созданных узлов в обеих базах. Для этого используем стандартную обработку «Регистрация изменений для обмена» либо программный код:
УзелОбъект = СсылкаНаУзел.ПолучитьОбъект();
УзелОбъект.НомерОтправленного = 0;
УзелОбъект.НомерПринятого = 0;
УзелОбъект.Записать();
Рассмотрим еще один критически важный организационный момент. При смене ролей баз обязательно проверьте настройки префиксов кодов и номеров документов в обеих базах. У новой Главной базы и ее подчиненного узла префиксы должны различаться. Если префиксы пересекаются или совпадают, то при создании новых документов в филиалах и последующей синхронизации неизбежно возникнут конфликты уникальности номеров документов и кодов справочников.
Изменить префикс в современных базах на БСП можно в разделе Администрирование — Синхронизация данных (поле «Префикс этой информационной базы»).
Мы подробно разобрали альтернативный способ связывания баз в распределенной структуре. Данный подход экономит колоссальное количество времени администратора и разработчика 1С, избавляя от необходимости генерировать многогигабайтные начальные образы. Соблюдение правильной последовательности действий по очистке служебных регистров БСП, синхронизации GUID узлов и сбросу номеров сообщений гарантирует стабильный и бесперебойный запуск нового обмена данными.