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