Обновление конфигурации в РИБ: от главного узла до филиалов

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

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

Подготовка главного узла к обновлению РИБ

Главный узел — это база, в которой создавались начальные образы остальных. Узнать его просто: в периферийном узле конфигурация закрыта для изменения, в главном — нет. Если сомневаетесь, откройте Администрирование → Синхронизация данных: в подчинённом узле там видно, с каким главным узлом он связан.

Перед обновлением выполните пять шагов:

1. 🔄 Полная синхронизация со всеми узлами. Сначала примите данные из каждого филиала, потом отправьте им ответ. Задача — чтобы в пути не осталось сообщений, сформированных по старой структуре.
2. 🚪 Договоритесь о паузе. На время установки пользователи главного узла выходят из программы. Филиалы могут работать, пока к ним не придёт обновление.
3. 💾 Резервные копии. Выгрузите главный узел в .dt или сделайте копию средствами СУБД. Копия главного узла обязательна: без неё откат обновления сломает нумерацию сообщений обмена со всеми филиалами.
4. 🧩 Версия платформы. Посмотрите, какую минимальную версию платформы требует новый релиз. Если номер выше установленного, сначала поставьте новую платформу на все компьютеры всех узлов, затем обновляйте конфигурацию.
5. 🔍 Доработки и расширения. Если конфигурация снята с поддержки или в ней есть свои изменения, обновление пойдёт через сравнение и объединение. Расширения проверьте отдельно: после нового релиза они могут не подключиться.

Что уходит на узлы: план обмена и правила выгрузки

Распределенная база работает на плане обмена с флагом «Распределенная информационная база». Именно этот флаг заставляет платформу передавать вместе с данными изменения конфигурации. В типовых конфигурациях такие планы уже созданы, настраивать их в конфигураторе не нужно.

Что важно знать про правила выгрузки:

• 📦 Конфигурация передаётся целиком по изменениям, без фильтров. Отборы, заданные в настройках синхронизации, действуют только на данные: организации, склады, период.
• 📅 Отборы данных лучше не трогать во время обновления. Если поменять условия выгрузки в тот же день, в первом сообщении после обновления окажется и новая конфигурация, и большой объём перерегистрированных данных. Ошибку в такой каше искать сложнее.
• 🌐 Транспорт обмена остаётся прежним: общий каталог, FTP, электронная почта или прямое подключение через интернет . Для обновления ничего переключать не надо, но учтите размер сообщения. С изменениями конфигурации архив весит десятки мегабайт, и почтовый сервер может его не пропустить.

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

Обновление главного узла и выгрузка изменений

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

Через пользовательский режим

В БП 3.0, ЗУП 3.1, УТ 11 это Администрирование → Интернет-поддержка и сервисы → Обновление версии программы. Программа скачает релиз, создаст резервную копию (для файловой базы), обновит конфигурацию и перезапустится. Нужны права администратора и подключённая интернет-поддержка.

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

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

Выгрузка изменений для филиалов

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

Сообщение формируется в каталоге или на FTP, указанном в настройках транспорта. Обычно это архив, имя которого начинается с Message_ и содержит коды узла-отправителя и узла-получателя.

Доставка сообщения и установка обновления на периферийном узле

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

Дальше порядок такой:

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

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

Как узлы обмениваются данными после обновления

Самый частый вопрос после обновления РИБ: «Почему в филиале какие-то документы пересчитались, хотя там никто ничего не делал?» Ответ — в обработчиках обновления.

В типовых конфигурациях на Библиотеке стандартных подсистем обработчики делятся на две группы:

• 🏢 Выполняемые в главном узле. Они меняют данные: перезаполняют реквизиты, пересчитывают регистры. Результат регистрируется к обмену и приходит в филиалы обычными сообщениями. В периферийном узле такие обработчики не запускаются, иначе одни и те же данные изменились бы дважды.
• 💻 Выполняемые в каждом узле. Это обработчики, которые затрагивают только локальные настройки: служебные константы, параметры работы программы.

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

Что проверить после обновления:

Ошибки при обновлении распределенной базы

Большинство проблем при обновлении РИБ сводятся к нарушенному порядку действий или к восстановлению одного из узлов из копии. Выберите симптом:

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

Отдельно о попытке «обойти» главный узел. Загрузить .cf в периферийный узел через конфигуратор нельзя: конфигурация подчинённого узла защищена от изменений. Если очень нужно, узел отключают от РИБ и создают заново, но это уже пересоздание узла, а не обновление.

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

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

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

В настройках каждой синхронизации задайте расписание: например, каждый час в рабочее время и в 23:00. Тогда новое обновление само уйдёт в филиал при ближайшем обмене. Устанавливать его всё равно будет администратор — автоматического перезапуска пользователей типовые конфигурации без согласия не делают.

Пакетный запуск главного узла

Для серверной или файловой базы обновление можно выполнить скриптом, например ночью из Планировщика заданий Windows:

@echo off
set V8BIN="C:\Program Files\1cv8\8.3.25.1374\bin\1cv8.exe"
set IB=/S "srv1c\buh_main"
set USR=/N "Админ" /P "пароль"

rem 1. Резервная выгрузка
%V8BIN% DESIGNER %IB% %USR% /DumpIB "D:\backup\buh_main.dt" /Out "D:\log\dump.log"

rem 2. Обновление конфигурации и конфигурации БД
%V8BIN% DESIGNER %IB% %USR% /UpdateCfg "D:\upd\1cv8.cfu" /UpdateDBCfg /Out "D:\log\upd.log"

rem 3. Обработчики обновления в режиме предприятия
%V8BIN% ENTERPRISE %IB% %USR% /C "ЗапуститьОбновлениеИнформационнойБазы" /DisableStartupDialogs

Номер платформы в пути замените на свой. Ключ /UpdateCfg работает только для конфигурации на поддержке без доработок; для изменённой обновление нужно разбирать вручную.

Пакетное применение в филиале

Если в узле обмен уже загрузил изменения конфигурации, применить их можно тем же способом: запустить DESIGNER с ключом /UpdateDBCfg, а затем ENTERPRISE с /C "ЗапуститьОбновлениеИнформационнойБазы". Такой скрипт удобно держать в каждом филиале и запускать ночью после планового обмена.

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