При развертывании крупных распределенных информационных систем на платформе 1С:Предприятие администраторы и разработчики часто сталкиваются с серьезной технической проблемой: стандартный механизм создания начального образа подчиненного узла РИБ (через конфигуратор или функцию ПланыОбмена.СоздатьНачальныйОбраз()) работает крайне медленно. На «тяжелых» базах генерация одного образа может занимать от полутора часов до половины суток. Если вам необходимо запустить в работу десятки филиалов или торговых точек (например, 60 магазинов), стандартный путь потребует колоссальных временных затрат.
В этой статье мы подробно рассмотрим альтернативный, «быстрый» метод создания периферийных узлов РИБ. Он заключается в прямом копировании базы данных и последующей программной перенастройке узлов обмена. Этот способ позволяет сократить время развертывания одного филиала с часов до нескольких минут. Мы разберем весь процесс по шагам, проанализируем неочевидные подводные камни, а также ответим на сопутствующие вопросы администрирования РИБ.
Суть быстрого метода состоит в том, что вместо генерации нового файла базы данных мы берем готовую копию центральной информационной базы (файловый вариант 1Cv8.1CD или бэкап СУБД) и превращаем ее в периферийный узел. Рассмотрим этот процесс по шагам.
Шаг 1. Подготовка в центральной базе
Прежде всего, нам необходимо зафиксировать появление нового узла в главной базе. Откроем центральную базу и перейдем к нашему плану обмена. Создадим в нем новый элемент — будущий периферийный узел. Зададим ему понятное наименование и уникальный код (например, М60 для магазина №60). Запишем узел. На этом этапе в центральной базе больше ничего делать не нужно.
Шаг 2. Создание физической копии базы
Сделаем полную копию центральной базы данных. Для файловой базы это обычное копирование файла 1Cv8.1CD в новую директорию. Для клиент-серверной базы — создание бэкапа средствами СУБД (например, SQL-копия .bak) и его последующее разворачивание на сервере под новым именем. Важно, чтобы перед копированием конфигуратор базы был полностью закрыт, а сама база отвязана от хранилища конфигурации (если оно используется), чтобы избежать конфликтов блокировок.
Шаг 3. Запуск копии в автономном режиме
Теперь запустим созданную копию базы данных. База «думает», что она по-прежнему является центральной. Нам нужно разорвать эту логику. Если копия снималась с уже подчиненного узла, необходимо предварительно сбросить признак подчиненности. Для этого запустим конфигуратор скопированной базы из командной строки с параметром /ResetMasterNode:
1cv8.exe DESIGNER /F"ПутьККопииБазы" /ResetMasterNode
После этой процедуры база очистит ссылку на своего родителя и станет полностью самостоятельной.
Шаг 4. Программная рокировка узлов в копии
Откроем нашу скопированную базу в режиме «1С:Предприятие». Нам необходимо выполнить переназначение ролей узлов. В копии узел ЭтотУзел до сих пор указывает на центральную базу. Нам же нужно сделать так, чтобы ЭтотУзел стал периферийным, а центральная база превратилась во внешнего родителя. Напишем и запустим обработку со следующим программным кодом:
// Шаг 4.1. Изменяем код и наименование текущего предопределенного узла "ЭтотУзел"
ЭтотУзелОбъект = ПланыОбмена.НашПланОбмена.ЭтотУзел().ПолучитьОбъект();
ЭтотУзелОбъект.Код = "М60"; // Код нового периферийного узла, созданного на Шаге 1
ЭтотУзелОбъект.Наименование = "Магазин №60 (Этот узел)";
ЭтотУзелОбъект.Записать();
// Шаг 4.2. Создаем узел для центральной базы данных
// В копии базы узел центра должен существовать как обычный элемент плана обмена
НовыйЦентрОбъект = ПланыОбмена.НашПланОбмена.СоздатьУзел();
НовыйЦентрОбъект.Код = "ЦБ"; // Код центрального узла
НовыйЦентрОбъект.Наименование = "Центральная информационная база";
НовыйЦентрОбъект.Записать();
// Шаг 4.3. Устанавливаем связь подчиненности
СсылкаНаЦентр = НовыйЦентрОбъект.Ссылка;
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦентр);
Проанализируем этот код. Мы изменили код предопределенного узла ЭтотУзел скопированной базы на код нового магазина. Затем создали обычный узел с кодом центральной базы и методом ПланыОбмена.УстановитьГлавныйУзел() объявили его главным родителем. Теперь база официально считается подчиненным периферийным узлом РИБ.
Шаг 5. Очистка неактуальных узлов в копии
Поскольку копия создавалась из центральной базы, в ее планах обмена физически остались записи обо всех других ранее созданных периферийных узлах (например, магазинах от 1 до 59). Если их оставить, база начнет тратить ресурсы на обслуживание этих узлов. Нам необходимо программно обойти все узлы плана обмена и удалить те, которые не являются ЭтотУзел или главным узлом:
ВыборкаУзлов = ПланыОбмена.НашПланОбмена.Выбрать();
Пока ВыборкаУзлов.Следующий() Цикл
СсылкаНаУзел = ВыборкаУзлов.Ссылка;
// Не трогаем предопределенный узел и главный узел
Если СсылкаНаУзел <> ПланыОбмена.НашПланОбмена.ЭтотУзел()
И СсылкаНаУзел <> ПланыОбмена.ПолучитьГлавныйУзел() Тогда
УзелОбъект = СсылкаНаУзел.ПолучитьОбъект();
Попытка
УзелОбъект.Удалить();
Исключение
ЗаписьЖурналаРегистрации("УдалениеУзлов", УровеньЖурналаРегистрации.Предупреждение, , ,
"Не удалось удалить узел " + СсылкаНаУзел + ": " + ОписаниеОшибки());
КонецПопытки;
КонецЕсли;
КонецЦикла;
Рассмотрим самую опасную ловушку описываемого метода. При прямом копировании базы данных в ней сохраняется вся история зарегистрированных изменений для обмена (таблицы регистрации изменений). Новая база считает, что она должна отправить в центральный узел миллионы записей, измененных за всю историю существования компании.
Если сразу запустить обмен, начнется так называемый «шторм обменов». Центральная база захлебнется входящим потоком дублирующей информации, транзакции заблокируют СУБД, файлы обмена разрастутся до гигабайтных размеров, а дисковая подсистема выйдет из строя.
Выясним решение этой проблемы. Перед первым сеансом синхронизации в новой периферийной базе необходимо полностью стереть всю регистрацию изменений для главного узла. Сделать это можно следующей командой:
ГлавныйУзел = ПланыОбмена.ПолучитьГлавныйУзел();
Если ЗначениеЗаполнено(ГлавныйУзел) Тогда
ПланыОбмена.УдалитьРегистрациюИзменений(ГлавныйУзел);
КонецЕсли;
Этот простой вызов очистит регистрационные таблицы СУБД (в SQL-версии это таблицы с префиксом _ChngRec), и первый обмен пройдет мгновенно, передав лишь актуальные системные квитанции.
Разберем важные вопросы, касающиеся внутренней структуры РИБ, конфигурации баз на SQL и управления составом данных.
Метод копирования абсолютно универсален. Разница кроется лишь в способе получения копии данных:
1Cv8.1CD.Если поместить две созданные базы в SQL-сервер и попытаться найти разницу в структурах таблиц, мы увидим, что сами схемы данных, таблицы документов и справочников абсолютно идентичны. Единственное различие будет зафиксировано на уровне записей в таблицах планов обмена (в SQL они именуются как _Node<n>) и в таблице констант, где хранится ссылка на главный узел.
Да, платформа предоставляет такую возможность. При вызове метода ПланыОбмена.СоздатьНачальныйОбраз() или при интерактивном создании в конфигураторе вы можете указать тип расположения базы «На сервере 1С:Предприятия», задать имя сервера СУБД, имя новой базы и параметры авторизации администратора СУБД. Платформа самостоятельно создаст пустую базу данных на сервере СУБД, перенесет туда конфигурацию и выгрузит необходимый срез данных. Однако для терабайтных баз данный процесс часто прерывается из-за нехватки оперативной памяти на сервере приложений 1С, поэтому метод создания из копии остается незаменимым решением.
Управление миграцией данных настраивается на двух уровнях:
Разрешить или Запретить).ПриОтправкеДанныхПодчиненному(). Внутри нее разработчик может написать алгоритм фильтрации (например, отсекать передачу документов по конкретным складам или организациям, неактуальным для данного филиала).Да, это одна из главных целей создания РИБ с фильтрами. При стандартном создании образа платформа автоматически отфильтрует данные, и периферийная база сразу получится «легкой» (в ней окажутся только те документы, которые разрешены правилами миграции).
Однако при быстром создании базы из копии мы получаем на периферии полную копию всех данных предприятия (со всеми чужими магазинами и историческими данными). Чтобы сделать ее «облегченной», необходимо после настройки связи с главным узлом запустить специальную обработку свертки и удаления неактуальных данных. Мы должны программно удалить документы других филиалов, очистить регистры сведений и провести тестирование и исправление базы сжатием таблиц.
Да, но при соблюдении важного архитектурного условия. Функциональные опции в 1С привязаны к значениям констант или ресурсам регистров сведений. Если константа, отвечающая за функциональную опцию, включена в «Состав» плана обмена РИБ, то при изменении настройки в центре значение автоматически перезапишет настройку на периферийном узле при первом же сеансе связи.
Чтобы функциональные опции работали независимо (например, в Магазине №1 включена ордерная схема, а в Магазине №2 — отключена), хранящие их константы или регистры должны быть исключены из состава плана обмена. В таком случае настройки на каждом узле будут автономными и никогда не затрутся при синхронизации.
Метод развертывания РИБ из копии базы данных — мощный инструмент в арсенале администратора 1С. Он позволяет миновать долгий процесс генерации начального образа платформой. Главное — помнить о необходимости удаления лишних узлов в копии, программной привязке главного узла и, самое важное, полной очистке регистрации изменений во избежание лавинообразных перегрузок системы.