Обновление распределенной информационной базы (РИБ) — это всегда ответственный процесс, требующий от администратора повышенной концентрации. Ситуация существенно усложняется, когда конфигурацию необходимо обновить не на один шаг вперед, а сразу через несколько ключевых релизов. Перед специалистом встает дилемма: пойти по быстрому пути (обновить центральную базу до финального релиза и сделать одну выгрузку конфигурации в периферийные узлы) или действовать по классической схеме (последовательно обновлять центральный и периферийные узлы на каждый промежуточный ключевой релиз).
В этой статье мы подробно проанализируем техническую сторону обоих подходов, рассмотрим скрытые угрозы «быстрого» метода, разберем влияние механизмов БСП (Библиотеки стандартных подсистем) и предложим альтернативный профессиональный метод обновления с временным отключением главного узла.
На первый взгляд идея обновить центральную базу (ЦБ) сразу до конечного релиза и отправить одну тяжелую выгрузку конфигурации в периферийные базы (ПБ) выглядит очень заманчиво. Это экономит массу времени и избавляет от необходимости многократно запускать сеансы обмена. Однако технически базы в РИБ идентичны по конфигурации, но не по данным. Именно здесь кроется главная опасность.
Ключевые релизы выпускаются разработчиками 1С не просто так. На этих этапах в структуре метаданных происходят глобальные изменения, которые требуют обязательного запуска обработчиков обновления данных. Рассмотрим классический пример изменения метаданных, который наглядно демонстрирует риск потери информации:
ПеречислениеСсылка.ПеречислениеСсылка и СправочникСсылка. При запуске предприятия отрабатывает специальная обработка обновления: она создает элементы в новом справочнике на основании значений перечисления и перезаписывает документы, подставляя новые ссылки.СправочникСсылка. Код старого обработчика обновления из релиза Б в конфигурации релиза В уже отсутствует за ненадобностью.Проанализируем, что произойдет, если мы обновим ЦБ сразу до версии В и отправим файл обмена в периферийный узел. Периферийная база примет конфигурацию релиза В, где реквизит документа имеет жесткий тип СправочникСсылка. Однако локальные данные документов в ПБ все еще хранятся в формате ПеречислениеСсылка, так как база пропустила релиз Б и соответствующий обработчик конвертации данных на ней никогда не запускался! В результате при первой же реструктуризации на периферийном узле эти данные будут безвозвратно утеряны (очищены), а пользователи увидят пустые поля в документах.
В современных конфигурациях (таких как ERP, КА 2, УТ 11, БП 3.0, ЗУП 3.1) большинство обработчиков обновления переведены в разряд отложенных. Они выполняются в фоновом режиме регламентными заданиями уже после того, как база запущена в режиме предприятия и пользователи начали работу.
Каждый последующий ключевой релиз БСП строго рассчитывает на то, что данные информационной базы уже приведены к структуре предыдущего релиза. Если запустить финальную конфигурацию на «сырых» данных старого релиза, отложенные обработчики могут отработать некорректно, заблокироваться или вызвать критические ошибки («битые» ссылки, пустые регистры сведений и т.д.).
Если вы все же решили обновлять базу последовательно, крайне важно на каждом промежуточном ключевом релизе принудительно завершать выполнение всех отложенных обработчиков обновления. Для этого в клиент-серверных вариантах работы можно запустить базу в монопольном режиме через командную строку со специальным параметром:
1cv8.exe ENTERPRISE /F "C:\Base1C\CentralDB" /N "Администратор" /P "Пароль" /C ВыполнитьОтложенноеОбновлениеСейчас
Этот параметр заставит систему выполнить все фоновые обработчики в несколько потоков до того, как начнется синхронизация с периферийными узлами.
Для гарантированного сохранения целостности данных рекомендуется использовать классический пошаговый алгоритм обновления. Разберем его по этапам:
РезультатыОбновленияИнформационнойБазы.Если периферийных баз много, они имеют внушительный объем, а каналы связи оставляют желать лучшего, последовательная передача тяжелых файлов конфигурации (.cf) через файлы обмена РИБ может затянуться на недели и сопровождаться постоянными сбоями сетевых таймаутов.
В таких сценариях опытные системные администраторы используют профессиональный метод временного отключения главного узла. Рассмотрим его по шагам:
Шаг 1. Полная синхронизация. Выполните полный двусторонний обмен между центральной и периферийной базами, чтобы добиться абсолютной идентичности данных.
Шаг 2. Отключение главного узла в ПБ. В периферийном узле необходимо программно снять признак подчиненности главному узлу. База временно станет полностью автономной. Это можно сделать с помощью конфигуратора, запустив команду:
1cv8.exe config /F "C:\Base1C\Node1" /ResetMasterNode /N "Администратор" /P "Пароль"
Или запустив в режиме предприятия обработку с простым кодом:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Шаг 3. Параллельное локальное обновление. Теперь вы можете обновлять центральную базу и отключенную периферийную базу параллельно как две независимые базы. Вы последовательно накатываете cf-файлы нужных релизов на каждую базу локально, запускаете их в режиме предприятия и ждете выполнения всех процедур обновления. Локальное обновление на SSD-дисках выполняется в разы быстрее, чем пересылка изменений по сети.
Шаг 4. Восстановление связи РИБ. После того как обе базы обновлены до финального и абсолютно идентичного релиза, в периферийной базе необходимо заново прописать связь с главным узлом. Для этого выполните следующий код:
СсылкаНаЦБ = ПланыОбмена.НайтиПоКоду("ЦБ"); // "ЦБ" - код центрального узла в плане обмена
Если ЗначениеЗаполнено(СсылкаНаЦБ) Тогда
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦБ);
КонецЕсли;
Шаг 5. Возобновление обмена. Поскольку конфигурации баз на момент восстановления связи стали абсолютно идентичными, система не будет пытаться передавать тяжелые файлы метаданных. Обмен возобновится в штатном режиме, а все данные будут гарантированно сконвертированы без потерь.
При планировании масштабного обновления распределенной сети обязательно учитывайте следующие важные факторы:
ВерсииОбъектов также может быть включен в состав плана обмена. Убедитесь, что изменения номеров версий передаются корректно, чтобы избежать конфликтов синхронизации истории изменений.Проанализировав все риски, мы настоятельно рекомендуем отказаться от идеи "быстрого" обновления через один файл обмена при перепрыгивании ключевых релизов. Потратьте время на последовательное обновление или воспользуйтесь методом с отключением главного узла — это убережет вашу компанию от критической потери данных и сэкономит массу сил на последующее восстановление базы.