При администрировании распределенных информационных баз (РИБ) часто возникает соблазн сэкономить время на обновлениях, особенно если их накопилось много. Появляется идея обновить центральный узел сразу до последней версии, перепрыгнув через несколько промежуточных релизов, а затем позволить подчиненным узлам обновиться одним махом. Рассмотрим, почему такой подход, несмотря на кажущуюся простоту, является крайне рискованным, и разберем правильную, безопасную методику обновления РИБ.
Проанализируем ситуацию, с которой столкнулся автор вопроса. Он отключил синхронизацию, обновил центральный узел с версии 2.3.17 до 2.3.20 (пропустив 2 релиза), а затем включил синхронизацию обратно. На первый взгляд, все прошло успешно: подчиненные узлы получили и установили финальное обновление. Но что на самом деле происходит "под капотом" и какие риски это несет?
1. Пропуск обработчиков обновления.
Это самая главная и самая опасная проблема. При переходе с одного релиза на другой разработчики конфигурации часто включают в обновление специальные обработчики обновления информационной базы. Их задача — привести данные в соответствие с новой структурой метаданных. Они могут:
Когда вы обновляетесь "прыжком" с версии А до версии Г, пропуская Б и В, есть огромный риск, что будут выполнены только обработчики обновления для перехода на версию Г, а критически важные обработчики из версий Б и В будут пропущены. Это бомба замедленного действия. Проблема может проявиться не сразу, а спустя недели или месяцы, когда программа попытается обратиться к некорректно преобразованным данным, что приведет к ошибкам, неверным отчетам или полной потере данных.
Пример из практики: при обновлении конфигурации "Розница" с пропуском релизов в справочнике ПодключаемоеОборудование не заполнился новый реквизит. Выяснилось, что обработчик, который должен был это сделать, находился в одном из пропущенных релизов. В результате часть оборудования перестала работать корректно.
2. Нарушение логики обмена в РИБ.
Отключение синхронизации перед обновлением центрального узла — это грубая ошибка. Механизмы платформы 1С, отвечающие за обновление, должны "знать", что информационная база работает в режиме РИБ. Это необходимо для того, чтобы система корректно регистрировала изменения объектов для обмена. Когда вы отключаете обмен, обработчики обновления могут отработать некорректно, не зарегистрировав для отправки в подчиненные узлы все необходимые изменения данных, которые они произвели. Это также приводит к рассинхронизации данных между узлами.
Чтобы избежать проблем и гарантировать целостность данных, придерживайтесь строгой последовательности действий. Этот процесс дольше, но он единственно верный и безопасный.
Важно: выполнять два сеанса синхронизации (туда и обратно) после каждого релиза — это не избыточность, а обязательное условие для поддержания консистентности данных в РИБ.
В жизненном цикле некоторых конфигураций (например, "Управление торговлей", "Комплексная автоматизация") фирма "1С" сама выделяет так называемые ключевые релизы. Это версии, которые содержат значительные архитектурные изменения, и перепрыгивать через них категорически нельзя. Иногда разработчики допускают обновление с пропуском нескольких неключевых релизов.
Как узнать, можно ли пропустить релиз?
update.txt или на странице релиза на портале 1С обычно указывается, с каких версий можно обновляться на текущую.ОбновлениеИнформационнойБазыКлиентПереопределяемый в УНФ), и найти там процедуру ПриОпределенииВозможностиОбновления. В ней программно зашита логика проверки минимально допустимой версии для обновления.Даже если пропуск релиза допустим, общая рекомендация для РИБ остается прежней: обновляйтесь последовательно. Это минимизирует риски.
Иногда при обновлении очень больших баз (например, 1С:ERP) пакет обновления получается настолько объемным, что не "пролезает" через каналы связи РИБ. В таких исключительных случаях допускается следующая процедура:
.cf)..cf файл загружается в бывший подчиненный узел вручную.Этот метод требует высокой квалификации администратора и должен применяться только в крайнем случае.
Чтобы упростить рутинную процедуру последовательных обновлений, можно использовать специализированные инструменты. Например, настроить автоматическое обновление конфигурации (регламентное задание), которое возьмет на себя последовательную передачу изменений в узлы РИБ.
автоматизацию обновления конфигурации с помощью PowerShell. Такие программы и скрипты позволяют настроить сценарий, который будет автоматически выполнять все шаги в правильном порядке: обновить, запустить, выполнить обмен, дождаться завершения и перейти к следующему релизу.
Пример скрипта для такой программы, который выполняет обмен после обновления:
@jobs_run(
only_using:False,
descriptions:"Выполнение обмена по сценарию: Сценарий синхронизации для Филиал ООО Рога",
names:"",
wait_for_completion: True,
timeout_minutes: 30
)
В заключение, отвечая на исходный вопрос "А что, так можно было?": нет, так делать нельзя. Экономия нескольких часов на последовательных обновлениях может обернуться днями или неделями восстановления данных и поиска скрытых ошибок. Правильная, методичная и последовательная процедура обновления РИБ — залог стабильной работы вашей системы.