Обороткабаза знаний по 1С 8.3

Обновление распределённой базы 1С: от главного узла до последнего филиала

· 9 мин

Содержание

Конфигурацию в распределённой информационной базе (РИБ) обновляют только в главном узле. Подчинённые узлы получают изменения сами, вместе с очередным сообщением обмена, и устанавливают их через Обновить конфигурацию базы данных. Файл .cfu в подчинённый узел не загружают: его конфигурация защищена от изменений.

Сбои в РИБ после обновления почти всегда идут от нарушенного порядка: обновили центр, пока филиал не выгрузил свои данные, или подняли платформу только в одном узле. Ниже порядок, при котором обновить конфигурацию 1С в режиме РИБ можно без потери документов и без пересоздания узлов.

Как устроено обновление в РИБ и что нужно до начала

В РИБ у всех узлов одна и та же конфигурация. Платформа следит за этим сама. Когда в главном узле меняется конфигурация базы данных, изменения автоматически регистрируются для всех подчинённых узлов первого уровня. При следующем обмене они уходят в сообщении вместе с данными.

Подчинённый узел, получив такое сообщение, записывает новую конфигурацию в основную конфигурацию узла. Применить её к базе данных — отдельное действие, и для него нужен монопольный доступ к этой базе.

Что из этого следует на практике:

  • 🔒 В подчинённом узле нельзя обновиться «вперёд» центра или поставить другой релиз.
  • 📦 Сообщение обмена с изменениями конфигурации весит заметно больше обычного: десятки мегабайт для типовых конфигураций.
  • 🧭 В многоуровневой РИБ изменения спускаются по уровням: узел второго уровня получит их только после того, как обновится его «родитель».
  • 🧩 Расширения конфигурации живут отдельно. В подчинённые узлы попадают только те, у которых в свойствах включено использование в распределённой информационной базе.

Что проверить заранее

ЧтоЗачем
Версия платформы во всех узлахНовый релиз может требовать платформу с номером не ниже указанного в описании обновления. Её ставят во всех узлах до обновления конфигурации.
Последний успешный обмен с каждым узломВ узле не должно остаться невыгруженных документов.
Канал обменаКаталог, FTP или почта должны пропускать сообщения большого размера.
Права в подчинённых узлахОбновление базы там запускает пользователь с административными правами.
Окно для работВремя, когда пользователи центра и филиалов не работают в базе.

Если узел уже несколько дней не выходил на связь, сначала добейтесь от него обмена. Обновлять центр, пока филиал «молчит», — самый частый источник расхождений.

Шаг 1. Готовим главный узел

Порядок работ в центральной базе:

  1. Проведите полный цикл синхронизации со всеми подчинёнными узлами: центр выгружает, узел загружает и выгружает свои данные, центр их загружает. Раздел Администрирование → Синхронизация данных.
  2. Попросите филиалы не вводить документы до окончания обновления. Если работы в выходной, достаточно предупредить.
  3. Завершите сеансы пользователей главного узла. В конфигурациях на БСП это делают через блокировку работы пользователей в разделе Администрирование → Обслуживание.
  4. Сделайте резервную копию главного узла: выгрузку .dt в Конфигураторе или резервное копирование средствами СУБД для клиент-серверной базы.

Копию главного узла делайте обязательно и именно перед обновлением. Об откате ниже есть отдельный разговор: восстанавливать центр из копии в РИБ сложнее, чем обычную базу.

Блокировка и завершение сеансов обрывают работу пользователей. Несохранённые документы пропадут, поэтому сеансы завершают по договорённости, а не посреди рабочего дня.

Главный узел готов к обновлению
Выполнено: 0 / 5

Шаг 2. Обновляем конфигурацию центра и формируем изменения для узлов

Само обновление в главном узле не отличается от обычной базы:

  1. Откройте базу в режиме Конфигуратора.
  2. Выберите Конфигурация → Поддержка → Обновить конфигурацию и укажите файл .cfu нужного релиза.
  3. Дождитесь сравнения и объединения, затем примите изменения.
  4. Выполните Конфигурация → Обновить конфигурацию базы данных (клавиша F7) и подтвердите реорганизацию.
  5. Запустите базу в режиме 1С:Предприятие. Отработают обработчики обновления, программа покажет описание изменений.

На четвёртом шаге платформа регистрирует изменения конфигурации для подчинённых узлов. Отдельной команды «выгрузить конфигурацию» нет: изменения уйдут при ближайшей выгрузке данных в узел.

Дальше выполните синхронизацию с каждым узлом из Администрирование → Синхронизация данных. Если обмен идёт по расписанию, можно дождаться его, но надёжнее запустить вручную и убедиться, что сообщение ушло без ошибок.

Если между текущим и целевым релизом есть обязательные промежуточные, проходите всю цепочку в главном узле. Узлы при этом можно не синхронизировать после каждого шага: в сообщение попадёт итоговая конфигурация.

После обновления центра в разделе Администрирование → Обслуживание откройте результаты обновления. Если там висят незавершённые отложенные обработчики, дайте им закончиться до активной работы. Часть обработчиков в подчинённых узлах не выполняется: их результат приходит из главного узла с данными.

Шаг 3. Устанавливаем обновление в подчинённом узле

В узле всё начинается с обычной загрузки данных. Типовые конфигурации на БСП, получив изменения конфигурации, приостанавливают загрузку данных и сообщают, что из главного узла пришло обновление программы. Остальные данные из этого сообщения загрузятся уже после установки.

Порядок в узле:

  1. Пользователь с административными правами запускает синхронизацию и видит сообщение о полученном обновлении.
  2. Все остальные пользователи узла выходят из программы.
  3. Обновление устанавливают по предложению программы или вручную: открыть узел в Конфигураторе и выполнить Конфигурация → Обновить конфигурацию базы данных. Конфигуратор покажет, что основная конфигурация отличается от конфигурации базы данных.
  4. Узел запускают в режиме 1С:Предприятие. Отрабатывает обновление информационной базы.
  5. Синхронизацию запускают ещё раз: теперь загружаются данные, которые ждали установки обновления.

Не отменяйте установку и не продолжайте работать в узле на старой версии, когда программа уже сообщила о полученном обновлении. Обмен в таком узле встанет, пока конфигурация базы данных не будет обновлена.

Для Обновить конфигурацию базы данных нужен монопольный доступ к базе узла. Если в узле кто-то остался, обновление не начнётся. Завершение чужих сеансов обрывает их работу: договаривайтесь заранее.

Если у узла есть свои подчинённые

Узел первого уровня после обновления сам регистрирует изменения для своих подчинённых. Порядок тот же: обновили узел, выполнили обмен с узлом второго уровня, установили обновление там.

Шаг 4. Сверяем данные после обновления

Обновление считается законченным не тогда, когда узел запустился на новом релизе, а когда прошёл полный обмен в обе стороны.

Что сделать по каждому узлу:

  1. Выполнить синхронизацию из узла: узел выгружает документы, накопленные с момента последнего обмена.
  2. Загрузить их в главном узле и отправить ответ.
  3. Открыть в узле Администрирование → Синхронизация данных и проверить, что в журнале последнего обмена нет предупреждений.
  4. Сверить пару контрольных показателей: остатки на одном складе, оборот за день, количество документов за дату обновления.
ПризнакЧто значит
Обмен завершился, предупреждений нетУзел обновлён, данные сходятся
Узел снова сообщает о полученном обновленииЦентр обновили ещё раз, нужно повторить шаг 3
Есть предупреждения о непроведённых документахОбработчики обновления изменили данные; документы перепроводят после проверки
Обмен не идёт, ошибка загрузки сообщенияСм. раздел про сбои ниже

Ведите простую таблицу: узел, дата получения обновления, дата установки, дата первого полного обмена. На пяти и более узлах без неё легко пропустить филиал, который «вроде обновился».

Сбои при обновлении РИБ и как из них выходить

Диагностика: выберите симптом

Если обновить узел не получается

Когда узел не удаётся вернуть в обмен, у него есть радикальный, но чистый путь — начальный образ.

  1. Выгрузите из проблемного узла всё, что можно: синхронизация в сторону центра, если работает. Если нет — выпишите документы, которые были введены после последнего успешного обмена.
  2. В главном узле создайте новый начальный образ для этого узла. Команда есть в настройке синхронизации с узлом.
  3. Разверните образ на месте старой базы филиала, сохранив копию старой.
  4. Повторно введите документы, которые не успели попасть в центр.

Старую базу узла не удаляйте сразу: из неё ещё может понадобиться что-то достать. Просто отключите её от обмена и уберите из списка баз у пользователей.

Автоматизация обновления РИБ

Ручное обновление нормально работает на двух-трёх узлах. При десятке филиалов процесс стоит автоматизировать хотя бы частично.

Синхронизация по расписанию

В Администрирование → Синхронизация данных для каждого узла настраивается расписание обмена. Узлы будут сами получать изменения конфигурации вскоре после обновления центра.

В файловой базе регламентные задания выполняются, только пока в ней открыт хотя бы один сеанс. Для файлового узла без постоянно открытого клиента расписание не сработает.

Обновление центра из командной строки

Пакетный режим Конфигуратора позволяет обновить главный узел ночью без участия администратора:

"C:\Program Files\1cv8\8.3.25.1374\bin\1cv8.exe" DESIGNER /S "srv1c\base_center" /N "Администратор" /P "пароль" /UpdateCfg "D:\update\1Cv8.cfu" /UpdateDBCfg /DisableStartupDialogs /Out "D:\update\center.log"

Номер версии в пути замените на свою. Ключ /UpdateCfg применяет файл обновления, /UpdateDBCfg обновляет конфигурацию базы данных, /Out пишет протокол. Для файловой базы вместо /S указывают /F "путь к каталогу базы".

Установка в узле из командной строки

В подчинённом узле после загрузки сообщения с изменениями достаточно одного ключа:

"C:\Program Files\1cv8\8.3.25.1374\bin\1cv8.exe" DESIGNER /F "D:\Bases\Filial_1" /N "Администратор" /P "пароль" /UpdateDBCfg /DisableStartupDialogs /Out "D:\update\filial_1.log"

После этого узел нужно один раз запустить в режиме 1С:Предприятие, чтобы отработало обновление информационной базы. Затем снова выполнить обмен.

Чтобы пакетный запуск не упёрся в открытые сеансы, в конфигурациях на БСП используют блокировку с кодом разрешения: режим 1С:Предприятия с параметром /C ЗавершитьРаботуПользователей, а последующие запуски — с ключом /UC <код>.

Пароль администратора в bat-файле — уязвимое место. Храните скрипт в каталоге, доступном только учётной записи, от которой он запускается.

Что автоматизировать не стоит

  • 🚫 Обновление центра без свежей копии. В скрипт сначала ставят выгрузку или резервное копирование СУБД.
  • 🚫 Установку в узле без проверки протокола. Если /Out содержит ошибки, обмен с этим узлом лучше остановить.
  • 🚫 Обновление на несколько релизов за ночь без проверки после каждого. Достаточно одного сбоя обработчика, чтобы разбирать последствия во всех филиалах.

Частые вопросы

Можно ли обновить подчинённый узел раньше главного?
Нет. Конфигурация подчинённого узла защищена от изменений и меняется только сообщением из главного узла.
Нужно ли ставить одинаковую платформу во всех узлах?
Желательно. Обязательное условие — номер версии не ниже того, что требует релиз конфигурации. Одинаковая версия снимает лишние вопросы при обмене.
Сколько ждать, пока изменения дойдут до узла?
До ближайшего обмена после обновления конфигурации базы данных в центре. При ручном запуске — несколько минут, при обмене по расписанию — до следующего срабатывания.
Что будет с документами, введёнными в узле во время обновления центра?
Они не пропадут: узел выгрузит их при следующем обмене. Но если они введены в старой структуре и затронуты обработчиками обновления, их стоит проверить и перепровести.
Можно ли откатить обновление только в одном узле?
Нет. Узел обязан иметь ту же конфигурацию, что и главный. Откат возможен только для всей РИБ — через восстановление центра и пересоздание узлов.