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

· 9 мин

Содержание

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

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

Подготовка к обновлению распределённой базы

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

Что сделать заранее:

  1. 📋 Составьте список всех узлов: какой главный, какие подчинённые, есть ли многоуровневая схема (узел, у которого свои подчинённые).
  2. 🔄 Проведите полную синхронизацию во всех узлах: сначала каждый подчинённый отправляет данные, затем главный их принимает и отвечает. Добейтесь, чтобы в каждом узле обмен завершился без ошибок.
  3. 🕒 Договоритесь с пользователями о «тихом окне». Для обновления структуры базы в каждом узле нужен монопольный доступ, поэтому в момент обновления узла в нём никто не работает .
  4. 💾 Сделайте резервные копии. Копия главного узла обязательна, копии крупных периферийных узлов желательны.
  5. 📄 Проверьте версию платформы: новый релиз конфигурации требует платформу с номером не ниже указанного в описании релиза. Её нужно поставить и на сервер главного узла, и на все компьютеры и серверы периферийных узлов.

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

Резервную копию файловой базы удобно делать выгрузкой в .dt через Конфигуратор (Администрирование → Выгрузить информационную базу). Для клиент-серверной базы надёжнее штатный бэкап СУБД: он быстрее и не требует монопольного режима.

Как быстро увидеть схему узлов

Если РИБ досталась вам от предшественника, схему проще всего посмотреть в самой базе. В типовой конфигурации список настроенных обменов виден в Администрирование → Синхронизация данных → Настройки синхронизации данных: там каждая строка — отдельный узел, с датой последнего обмена.

На уровне платформы список узлов виден в Конфигураторе: Администрирование → Распределённая ИБ → Управление распределённой ИБ. Узел, у которого в этом окне нет родителя, и есть главный.

Запишите для каждого узла: где лежит база, какая там платформа, кто отвечает за обновление на месте. В филиале без своего администратора договоритесь заранее, кто запустит синхронизацию и подтвердит установку обновления.

Не восстанавливайте узел РИБ из старой копии «на всякий случай», если обновление прошло нормально. Узел, откатанный назад, расходится с другими по номерам сообщений, и обмен с ним придётся чинить отдельно.

Шаг 1. Обновляем центральный узел РИБ

Главный узел обновляется так же, как обычная база на поддержке. Есть два пути.

Через Конфигуратор:

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

Из режима 1С:Предприятие (типовые конфигурации на БСП): в БП 3.0, ЗУП 3.1 и УТ 11 обновление запускается из раздела Администрирование → Интернет-поддержка и сервисы, группа «Обновление версии программы». Программа сама скачает релиз, сделает обновление и перезапустится.

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

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

Изменённая вручную конфигурация главного узла уйдёт в периферию целиком, со всеми доработками. Так что доработки тестируйте на копии до того, как они попадут в рабочую РИБ.

Шаг 2. Выгружаем сообщение обмена с изменениями конфигурации

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

Что делать в главном узле:

  1. Откройте Администрирование → Синхронизация данных → Настройки синхронизации данных.
  2. Выберите настройку обмена с нужным узлом и нажмите «Синхронизировать».
  3. Повторите для каждого подчинённого узла (или дождитесь автоматической синхронизации по расписанию).

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

А что с правилами обмена

В РИБ правила обмена в виде файла (как в обменах через «Конвертацию данных» между разными конфигурациями) не загружают. Узлы распределённой базы имеют одну конфигурацию, объекты переносятся как есть. После обновления ничего перезагружать в настройках обмена не нужно.

Исключение — РИБ с отбором (например, узел филиала получает только свою организацию или склад). Правила, по которым объекты регистрируются к отправке, зашиты в саму конфигурацию и обновляются вместе с ней. Если вы меняли отборы, проверьте их в настройке синхронизации после обновления.

Если у вас одновременно есть РИБ и обмен с другой программой по правилам (например, БП с ЗУП), правила того обмена после обновления проверьте отдельно: там они загружаются из файла или берутся из макета конфигурации.

Шаг 3. Применяем обновление в периферийных узлах

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

Обмен через БСП (типовые конфигурации)

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

Ручной обмен через Конфигуратор

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

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

Многоуровневая РИБ

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

СхемаКто обновляется вручнуюКак получают конфигурацию остальные
Один главный + филиалыТолько главный узелЧерез обмен, каждый филиал применяет сам
МногоуровневаяТолько корневой узелУровень за уровнем, после применения у родителя
Филиал с отбором данныхТолько главный узелТак же через обмен, после — проверка отборов

Контроль синхронизации после обновления

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

1. Версия конфигурации. В каждом узле откройте Справка → О программе и сравните номер релиза. Он должен совпадать с главным узлом.

2. Номера сообщений. В настройке синхронизации видно, когда был последний успешный обмен и есть ли ошибки. После обновления проведите хотя бы два полных цикла: «узел → главный» и «главный → узел».

3. Журнал регистрации. Посмотрите Администрирование → Обслуживание → Журнал регистрации с отбором по событиям обмена данными. Предупреждения о том, что какие-то объекты не удалось записать, тут видны лучше, чем в окне синхронизации.

Обновление РИБ завершено, если
Выполнено: 0 / 5

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

Ошибки при обновлении РИБ и что с ними делать

Ниже — ситуации, которые встречаются на практике. Тексты сообщений зависят от версии платформы и БСП, поэтому ориентируйтесь на смысл.

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

Чего делать нельзя

  • ❌ Обновлять подчинённый узел файлом .cfu, снимать его с поддержки или пытаться «отвязать» от главного. Платформа такого не даст, а попытки обходов ломают обмен.
  • ❌ Обновлять главный узел на релиз «через один» без промежуточных, если описание обновления требует цепочку.
  • ❌ Держать филиал без обмена неделями после обновления. Конфигурация ждёт в очереди, а пользователи продолжают работать на старой версии, и разрыв растёт.
  • ❌ Пересоздавать узел из начального образа как первое средство. Это крайний вариант, когда остальное не помогло.

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

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