Обновление узла РИБ: что сделать в центре, а что на точке

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

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

1. Подготовка центральной базы перед обновлением

Главный принцип РИБ: конфигурацию меняют только в главном узле. В подчинённом узле она закрыта для правки, и загрузить туда .cfu через Конфигуратор не получится. Поэтому вся подготовка идёт в центре.

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

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

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

2. Каналы связи: через что обновление доходит до точки

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

Настройки транспорта открываются из формы синхронизации: в Администрирование → Синхронизация данных выберите настройку обмена с узлом и откройте параметры подключения.

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

3. Порядок выгрузки и загрузки при обновлении узла

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

В центральном узле

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

В периферийном узле

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

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

Если окна с предложением обновиться нет

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

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

Чтобы не держать нить шагов в голове, отмечайте их по ходу:

4. Предопределённые элементы и конфликты после обновления

Самая частая «странная» ошибка в РИБ после обновления связана с предопределёнными элементами: счетами плана счетов, видами расчёта, элементами справочников, отмеченными в конфигурации как предопределённые.

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

Признаки проблемы:

• ❗ ошибка при обращении к предопределённому элементу с указанием, что найдено несколько элементов;
• ❗ ошибка Предопределенный элемент не существует — элемент не дошёл до узла или был удалён;
• ❗ в плане счетов на точке два одинаковых счёта, у одного из них пиктограмма предопределённого.

Как разбирать:

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

Коллизии данных

Второй вид конфликта — один и тот же объект изменён и в центре, и на точке между обменами. В РИБ приоритет у главного узла: при коллизии побеждает его версия. Изменения на точке молча перезапишутся. Поэтому и нужна пауза в работе филиала на время обновления.

Если периферия связана правилами КД 2, а не РИБ

Иногда «периферийной» называют базу другой конфигурации, связанную обменом по правилам Конвертации данных 2.0: например, магазин на отдельной конфигурации и центральную торговую базу. Это не РИБ. Конфигурация по обмену не передаётся, каждую базу обновляют отдельно своим релизом.

Порядок здесь другой:

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

5. Автоматическое обновление по расписанию

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

Где настроить. В форме синхронизации с узлом включите автоматическую синхронизацию и задайте расписание: например, каждые 15 минут в рабочее время. Расписание задаётся в обеих базах — каждая запускает свою половину обмена.

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

Клиент-серверный вариант. Регламентные задания выполняет сервер 1С, сеанс пользователя не нужен. Проверьте, что блокировка регламентных заданий в параметрах базы снята.

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

• 🌙 вечером центр обновлён, обмен по расписанию разносит сообщения;
• ☀️ утром первый пользователь точки видит предложение установить обновление и подтверждает его;
• ✅ после перезапуска обмен по расписанию продолжается как обычно.

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

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

@echo off
set V8="C:\Program Files\1cv8\8.3.25.1374\bin\1cv8.exe"
%V8% DESIGNER /F"D:\Bases\Sklad" /N"Администратор" /P"пароль" /UpdateDBCfg /Out"D:\Logs\update_sklad.txt" /DisableStartupDialogs

Номер платформы в пути подставьте свой: он совпадает с папкой в C:\Program Files\1cv8\. Ключ /Out пишет результат в текстовый файл — по нему видно, прошло ли обновление. После этого запустите базу в режиме предприятия и повторите обмен, чтобы дочитать данные.

6. Диагностика: журнал регистрации и протокол обмена

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

Форма синхронизации. В Администрирование → Синхронизация данных у каждой настройки показаны дата последней успешной синхронизации и предупреждения. Если дата старая — обмен с этим узлом не проходит.

Журнал регистрации. Откройте Администрирование → Обслуживание → Журнал регистрации и отберите события, в названии которых есть «Обмен данными». Смотрите уровень «Ошибка» за период обновления. В тексте события обычно видно, на каком этапе оборвалось: подключение, выгрузка, загрузка, обновление конфигурации.

Каталог обмена. Для транспорта через каталог или FTP сравните дату файла сообщения с временем запуска обмена. Если файл старый, центр не выгрузил новое сообщение. Если файла нет вовсе — проблема в правах или пути.

Частые сбои и что с ними делать:

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

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

7. Частые вопросы об обновлении периферийной базы