← На главную

Рассмотрим ситуацию, с которой часто сталкиваются крупные предприятия при переходе на новые масштабные редакции конфигураций (например, с 1С:ERP 2.4 на 2.5 или 1С:Управление торговлей 11.4 на 11.5). Процесс реструктуризации таблиц и выполнения отложенных обработчиков обновления может занимать десятки часов. Остановка работы сотен пользователей на такой длительный срок критична для бизнеса. Чтобы решить эту проблему, фирма «1С» предлагает типовой функционал: обновление информационной базы без остановки работы пользователей через копию базы. Разберем по шагам, как устроен этот механизм и какие подводные камни нас ожидают.

Проанализируем архитектуру и алгоритм работы механизма

Данная технология жестко ограничена архитектурой хранения данных — она ориентирована исключительно на клиент-серверные информационные базы. Для файловых баз данных этот функционал не поддерживается. Интерфейс управления процессом обычно выведен в раздел Администрирование — Обслуживание — Результаты обновления и дополнительная обработка данных.

Посмотрим на классический алгоритм выполнения такого обновления:

1. Создается полная копия рабочей информационной базы на сервере СУБД.
2. Копия обновляется до новой версии. В ней в фоновом режиме запускаются и выполняются все необходимые (даже самые длительные) процедуры обработки данных.
3. В это же время пользователи продолжают работать в штатном режиме в оригинальной старой базе, не замечая процесса обновления.
4. Все новые документы и изменения справочников, которые пользователи создают в старой базе, фиксируются и накапливаются с помощью механизма планов обмена.
5. Накопленная разница данных (дельта) регулярно отправляется из рабочей (старой) базы в обновленную копию.
6. После завершения всех обработчиков и финальной синхронизации данных, старая рабочая база выводится из эксплуатации. Обновленная копия становится основной, и пользователи переключаются на нее (момент перехода происходит в момент перелогина пользователя).

Выясним нюансы настройки правил конвертации

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

Почему это необходимо? Рассмотрим подробнее:

1. Изменение структуры метаданных: При переходе на новую редакцию (например, ERP 2.5) структура регистров и документов существенно меняется.
2. Кастомные доработки: Если в вашей базе есть нетиповые объекты, типовой шаблон обмена о них ничего не знает.
3. Обработчики обновления: Это самая сложная часть. Если в обновленной «копии» обязательные обработки обновления преобразуют старые данные в новые, то «дельта» данных, приходящая из старой базы, содержит информацию в старом формате. Правила конвертации должны учесть изменения и «на лету» преобразовать старые данные объектов в новые при их загрузке в обновленную базу.

Как отмечают специалисты, за полноценность принимаемых данных всегда отвечает отправляющая сторона. Это означает, что в правила конвертации иногда приходится вшивать логику алгоритмов обновления, чтобы новые документы, созданные пользователями во время переходного периода, корректно легли в новые регистры (например, если был добавлен новый учетный регистр, которого нет в базе-источнике).

Разберем альтернативы и сравнение с другими методами

Посмотрим на альтернативные варианты, которые обсуждаются в профессиональном сообществе:

1. Динамическое обновление. Почему бы не использовать его? Как мы знаем, при динамическом обновлении функционал может стать частично недоступным, формы могут падать, а запросы выдавать ошибки прямо во время работы пользователей. Обновление через копию исключает эти риски, так как пользователи работают в стабильной старой версии до момента полного переключения.

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

3. Обмен через шину данных. Вместо прямого обмена по правилам конвертации (который может быть излишне ресурсоемким), некоторые архитекторы предпочитают настраивать нормальный обмен на очередях сообщений через корпоративную шину данных. Это позволяет более гибко контролировать маршрутизацию и трансформацию объектов.

Подведем итоги

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