Как обновить конфигурацию в распределённой базе 1С (РИБ)

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

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

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

Что нужно знать о механизме РИБ перед обновлением

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

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

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

Подготовка: что сделать до обновления центрального узла

Первый шаг — резервные копии всех узлов, которые будут участвовать в обновлении. Минимум — центральная база и те периферийные, куда пойдёт обмен в ближайший цикл. Для файловых баз достаточно копии каталога, для клиент-серверных — выгрузка через СУБД или файл .dt.

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

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

Обновление конфигурации в центральном узле

Обновление центрального узла выполняется стандартно: через «Конфигурация → Поддержка → Обновить конфигурацию» в конфигураторе или через «Администрирование → Обновление версии программы» в режиме предприятия, если конфигурация на полной поддержке и обновление типовое. Для нетиповых конфигураций используется сравнение и объединение с файлом поставки (.cf) с ручной разборкой изменённых объектов.

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

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

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

Передача обновления в периферийные базы

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

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

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

Принятие обновления на периферийном узле

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

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

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

Типичные проблемы и способы их решения

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

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

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

Проверка результата после обновления всех узлов

Итоговая проверка сводится к трём пунктам: версии конфигурации во всех узлах совпадают, обмен между узлами выполняется без ошибок, обработчики обновления (в том числе отложенные) завершены везде. Версию смотрят в сведениях о программе, состояние обработчиков — в разделе «Обновление версии программы» или через журнал регистрации.

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

Контрольные точки

Как проверить результат

Версия конфигурации на узлах

Норма

Версии в центре и на всех периферийных узлах совпадают

Тревожный признак

На узле старая версия или ошибка о несоответствии при обмене

Сеанс обмена

Норма

Выгрузка и загрузка завершаются без ошибок

Тревожный признак

Сообщение не загружается, в журнале ошибки конфигурации

Отложенные обработчики

Норма

Все обработчики обновления завершены

Тревожный признак

Обработчики в статусе ошибки или выполняются бесконечно

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

Можно ли обновить периферийную базу РИБ напрямую через конфигуратор?

Нет. Платформа запрещает изменять конфигурацию подчинённого узла иначе как через сообщение обмена от главного узла. Попытка загрузить .cf или выполнить объединение завершится ошибкой. Единственный легальный путь — обновить центр и передать изменения обменом.

Что делать, если периферийный узел долго не обменивался и отстал на несколько релизов?

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

Обязательно ли обновлять все периферийные узлы сразу?

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

Как отличить РИБ от обычного обмена между базами?

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

Что делать, если обновление на периферии прервалось из-за отключения питания?

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

Нужно ли обновлять платформу 1С на всех узлах одновременно?

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