Администрирование · 11 мин
РИБ 1С: как правильно обновлять распределённую информационную базу
Пошаговая инструкция по обновлению РИБ 1С: подготовка, обновление центрального и периферийных узлов, обмен данными, типичные ошибки и проверка результата.
Распределённая информационная база (РИБ) в 1С обновляется иначе, чем обычная: нельзя просто поставить новый релиз конфигурации в каждом узле по отдельности. Обновление всегда начинается с центрального узла, а периферийные базы получают изменения конфигурации только через механизм обмена — файлом сообщения обмена. Если нарушить порядок, узел перестанет принимать и отправлять пакеты, а в худшем случае потребуется пересоздание периферийной базы из образа центральной.
Ключевое правило: версия конфигурации периферийного узла не может быть новее версии центрального узла, а обмен между узлами с разными версиями конфигурации в типовых планах обмена запрещён. Поэтому вся процедура строится вокруг одного сценария: обновили центр → выполнили обмен → обновились периферийные узлы → снова выполнили обмен.
Ниже разобран полный цикл обновления РИБ: подготовка, последовательность действий в центральном и периферийных узлах, обновление через конфигуратор и через поддержку, проверка результата и типичные ошибки администраторов.
Как устроено обновление РИБ и почему порядок критичен
В распределённой базе конфигурация периферийного узла находится «на замке»: она жёстко связана с главным узлом и не может обновляться самостоятельно. Попытка загрузить в периферийную базу файл конфигурации (.cf) или обновить её через поддержку завершится ошибкой — платформа не даст это сделать, пока узел подчинён центральному.
Изменения конфигурации передаются в периферийный узел внутри файла сообщения обмена. Когда в центральном узле конфигурация изменена, при очередной выгрузке в сообщение включается не только пакет данных, но и образ обновлённой конфигурации. Периферийный узел при загрузке такого сообщения обнаруживает изменения и предлагает выполнить обновление конфигурации базы данных.
Отсюда следуют два практических вывода. Первый: обмен должен работать исправно до начала обновления — если узлы «разъехались» по номерам сообщений или обмен падает с ошибками, сначала чинится обмен. Второй: между обновлением центра и обновлением периферии пользователи периферийных узлов продолжают работать на старой версии, поэтому окно обновления нужно планировать с учётом всех узлов сети.
Подготовка: что сделать до обновления центрального узла
Первый шаг — полная резервная копия всех узлов, которые участвуют в обновлении, или как минимум центрального узла и самых критичных периферийных. Для файловых баз достаточно копии каталога с файлом 1Cv8.1CD, для клиент-серверных — выгрузка средствами СУБД или выгрузка в .dt через конфигуратор. Копия нужна именно до обновления, а не «у нас есть вчерашняя».
Второй шаг — проверить состояние обмена. Откройте в центральном узле настройку синхронизации и убедитесь, что последние обмены по всем узлам прошли без ошибок, нет незагруженных сообщений и предупреждений о коллизиях. Если какой-то узел давно не обменивался, выполните с ним обмен принудительно, чтобы выровнять номера отправленных и принятых сообщений.
Третий шаг — сверить версию платформы. Новый релиз конфигурации может требовать более свежую версию платформы 1С:Предприятие. Проверьте требования в описании релиза и, если нужно, сначала обновите платформу на сервере и на всех рабочих местах, включая периферийные узлы. Платформа обновляется независимо от РИБ, ограничений по узлам здесь нет.
- 1Сделать резервную копию центрального и периферийных узлов
- 2Выполнить обмен со всеми узлами и убедиться в отсутствии ошибок
- 3Проверить требования нового релиза к версии платформы
- 4Завершить сеансы пользователей в центральном узле
- 5Проверить наличие монопольного доступа для обновления конфигурации базы данных
Обновление центрального узла
Центральный узел обновляется так же, как обычная база: через конфигуратор пунктом «Конфигурация → Поддержка → Обновить конфигурацию» или через автоматическое обновление из сервиса, если база на поддержке без изменений. На время обновления конфигурации базы данных потребуется монопольный режим — все пользователи и фоновые задания должны быть завершены.
После загрузки обновления выполните «Обновление конфигурации базы данных» (F7) и примите изменения. Если релиз требует обновления через несколько промежуточных версий, пройдите их последовательно — пропуск обязательных релизов приводит к ошибкам обработчиков обновления. Затем запустите базу в режиме предприятия под правами администратора, чтобы отработали обработчики обновления данных: перенос данных в новые структуры, пересчёт служебных регистров.
Дождитесь полного завершения отложенных обработчиков обновления. В типовых конфигурациях их ход виден в разделе «Администрирование → Обслуживание → Результаты обновления». Пока отложенные обработчики не завершены, выполнять обмен и выпускать пользователей нежелательно: часть данных будет в промежуточном состоянии.
Доставка обновления в периферийные узлы
Когда центральный узел обновлён и стабильно работает, выполните выгрузку сообщения обмена для каждого периферийного узла штатной обработкой синхронизации данных. В это сообщение автоматически попадут изменения конфигурации. Способ доставки зависит от вашей схемы: прямое подключение через сеть, обмен через каталог, FTP, электронную почту или веб-сервис.
На периферийном узле загрузите полученное сообщение. Если в нём есть изменения конфигурации, система сообщит об этом и предложит обновить конфигурацию базы данных. Подтвердите обновление — пользователям периферийной базы на это время нужно выйти, так как требуется монопольный доступ. После завершения обновления запустите базу в режиме предприятия, чтобы отработали обработчики обновления данных, как и в центральном узле.
После успешного обновления периферийного узла выполните обмен в обе стороны: периферия отправляет данные в центр, центр — подтверждение приёма. Это выравнивает номера сообщений и переводит обмен в штатный режим на новой версии конфигурации.
Если периферийных узлов много, обновляйте их партиями, начиная с одного тестового узла. После успешного обновления первого узла и полноценного обмена с центром можно разворачивать процесс на остальные, не меняя порядок «центр → периферия».
Обновление периферийного узла через конфигуратор
Иногда изменения конфигурации уже загружены из сообщения обмена, но обновление конфигурации базы данных не выполнено — например, администратор отложил его. В этом случае откройте периферийную базу в конфигураторе: изменённая конфигурация будет видна как конфигурация поставщика, ожидающая применения. Выполните «Конфигурация → Обновить конфигурацию базы данных» — платформа применит изменения, полученные от главного узла.
Обратите внимание: в конфигураторе периферийного узла пункты загрузки конфигурации из файла и обновления через поддержку недоступны или опасны. Единственный легальный источник изменений — главный узел. Если по какой-то причине нужно срочно перенести доработку в периферию в обход обмена, это делается только через центральный узел: изменение вносится в центр и распространяется штатно.
Если узел отстал по версии и не принимает обмен
Ситуация: центр обновлён, а периферийный узел долго не обменивался и при загрузке сообщения выдаёт ошибку несоответствия конфигураций. Обычно помогает последовательная загрузка всех накопленных сообщений по порядку — старые сообщения содержат промежуточные версии конфигурации. Если промежуточных сообщений нет или они утеряны, надёжный путь один — создать новый образ периферийной базы из центрального узла и перенастроить узел заново.
Проверка результата обновления
После обновления всех узлов сверьте версии конфигураций: в центре и на каждой периферии номер релиза должен совпадать. Проверить можно через «О программе» в режиме предприятия или в конфигураторе. Расхождение версий — прямой признак того, что какой-то узел не получил или не применил обновление.
Затем выполните контрольный обмен по каждому узлу и убедитесь, что сообщения отправляются и принимаются без ошибок, номера принятых и отправленных сообщений увеличиваются согласованно. Полезно провести тестовый документ: создать его на периферии, выгрузить в центр и убедиться, что он появился там корректно, без потери реквизитов.
Как проверить результат
Номера релизов совпадают
Периферия на старом релизе — обновление не применено
Сообщения отправлены и приняты без ошибок
Ошибки загрузки, предупреждения о версии конфигурации
Документ переносится полностью и корректно
Документ не приходит или приходит с пустыми реквизитами
Все обработчики завершены успешно
Есть обработчики с ошибками или в очереди
Типичные ошибки и как их избежать
Самая частая ошибка — попытка обновить периферийный узел напрямую из файла поставки, минуя центральный. Даже если администратор снимет узел с подчинения, вернуть его в РИБ без пересоздания образа уже не получится, а данные, накопленные на узле, придётся переносить отдельно. Вторая типичная ошибка — обновление центра при неработающем обмене: изменения конфигурации не могут уйти в узлы, и сеть надолго зависает в рассинхронизированном состоянии.
Третья группа ошибок связана с обновлением «на живую»: пользователи продолжают работать во время обновления конфигурации базы данных, что приводит к блокировкам и незавершённым транзакциям. Также опасно игнорировать отложенные обработчики: обмен, запущенный до их завершения, может увезти в узлы данные в промежуточном формате.
Что важно запомнить
Обновляйте РИБ строго по цепочке: резервная копия и рабочий обмен → обновление центра с завершением обработчиков → выгрузка сообщений → обновление периферийных узлов через загрузку сообщений → контрольный обмен и сверка версий. Прямое обновление периферии из файла запрещено; при безвозвратной рассинхронизации узел пересоздаётся из образа центра.
Частые вопросы по обновлению РИБ
Можно ли обновить периферийный узел раньше центрального?
Нет. Периферийный узел получает изменения конфигурации только от главного узла через сообщение обмена, поэтому физически не может оказаться на более новой версии штатным способом. Сначала всегда обновляется центр.
Что делать, если периферийный узел выдаёт ошибку «конфигурация узла не соответствует ожидаемой»?
Проверьте, все ли накопленные сообщения обмена загружены по порядку — узел мог пропустить промежуточное обновление. Если сообщения утеряны, создайте новый образ периферийной базы из центрального узла и настройте узел заново, предварительно выгрузив из него неотправленные данные.
Нужно ли обновлять платформу 1С на всех узлах одновременно?
Одновременность не обязательна, но версия платформы на каждом узле должна удовлетворять требованиям релиза конфигурации. Платформа обновляется независимо от механизма РИБ, поэтому её можно ставить на узлы заранее, до обновления конфигурации.
Можно ли работать в периферийной базе, пока центр уже обновлён?
Да, периферийный узел продолжает работать на своей версии до получения сообщения с изменениями конфигурации. Ограничение одно: обмен между узлами с разными версиями конфигурации в типовых планах обмена блокируется, поэтому затягивать с обновлением периферии не стоит.
Как откатить обновление, если что-то пошло не так?
Штатного отката релиза в 1С нет — восстановление выполняется только из резервной копии, сделанной до обновления. Если обмен с обновлёнными данными уже прошёл в другие узлы, восстанавливать придётся всю цепочку затронутых узлов, поэтому копия обязательна на каждом этапе.
Чем обновление РИБ отличается от обмена через универсальный формат (EnterpriseData)?
В РИБ периферийная конфигурация подчинена центральной и обновляется только через сообщения обмена. При обмене через универсальный формат базы независимы по конфигурации и каждая обновляется отдельно — но там нужно следить за совместимостью правил обмена между версиями.