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

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

Два способа доставить обновление на периферию — по сети (веб-сервис, общий каталог, FTP) или файлом сообщения, если узел офлайн. Первый быстрее и почти не требует участия людей на местах. Второй нужен для удалённых складов и магазинов без постоянного канала: администратор передаёт файл обмена, и сотрудник загружает его сам.

1. Подготовка: схема узлов и синхронизация «до нуля»

Начните не с файла обновления, а со схемы. Нарисуйте дерево: какой узел главный, какие подчинены ему напрямую, есть ли многоуровневая РИБ (подчинённый узел сам является главным для своих филиалов).

Для каждого узла выпишите:

• 🖥️ режим работы — файловый или клиент-серверный;
• 🔢 версию платформы на сервере и на рабочих местах;
• 🔁 транспорт обмена — веб-сервис, каталог, FTP, электронная почта;
• 👤 кто на месте может запустить программу под администратором;
• 🧩 подключённые расширения и внешние обработки.

Что сделать перед обновлением

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

Когда обновлять

Лучшее время — вечер пятницы или утро выходного дня, когда в узлах никто не работает . Так у вас будет запас на повторный цикл обмена, если какой-то узел не примет обновление с первого раза.

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

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

2. Обновление главного узла РИБ

Главный узел обновляется так же, как обычная база. Подчинённость в РИБ на него не влияет.

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

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

Через встроенный сервис

В конфигурациях на БСП (БП 3.0, ЗУП 3.1, УТ 11, КА, ERP) главный узел можно обновить из режима предприятия: Администрирование → Обслуживание → Обновление версии программы. Программа сама скачает релизы по цепочке, сделает копию и обновит базу.

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

3. Отправка новой конфигурации на периферию

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

Что происходит при этом:

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

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

Если узел работает через файлы

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

Расширения конфигурации

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

4. Как обновить подчинённый узел РИБ

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

Конфигурации на БСП

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

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

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

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

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

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

5. Обмен после обновления и проверка данных

После того как все узлы обновлены, РИБ должна вернуться к обычному ритму. Проверьте три вещи.

Версии совпадают. Откройте в каждом узле О программе и сравните номер релиза. Расхождение даже в последней цифре означает, что узел не принял изменения.

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

Данные не потерялись. Сравните контрольные цифры главного и подчинённого узла за период «тихого окна»:

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

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

Когда узел проще пересоздать

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

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

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

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