Обновление распределенных информационных баз (РИБ) в экосистеме «1С:Предприятие» — это всегда ответственный процесс, требующий от системного администратора повышенного внимания. Ситуация многократно усложняется, если конфигурация «1С:Розница 2» на предприятии не обновлялась долгое время (пропущено 15 и более обязательных релизов), а на торговых точках установлены слабые компьютеры или ноутбуки, которые физически не способны быстро переварить огромные массивы изменений метаданных.
В этой статье мы подробно рассмотрим, как правильно организовать процесс масштабного обновления «1С:Розница 2» в топологии РИБ, проанализируем основные риски, выявим подводные камни и разберем три проверенные практические стратегии перехода на актуальный релиз.
В чем главная сложность долгого отсутствия обновлений в РИБ?
Когда распределенная база данных работает в штатном режиме, конфигурация периферийного узла (ПУ) обновляется автоматически через стандартный файл обмена (содержит образ новой конфигурации .cf). Однако при «прыжке» через 15-20 релизов (особенно при переходе с ветки 2.2 на ветку 2.3) стандартный механизм обмена гарантированно даст сбой. Выделим основные причины проблем:
Огромный объем файла обмена. При масштабном изменении структуры таблиц первый файл обмена после обновления центральной базы (ЦБ) будет весить сотни мегабайт или даже гигабайты. Передача такого пакета по медленным каналам связи (FTP, электронная почта) практически всегда прерывается по таймауту.
Аппаратные ограничения на точках. Слабые ноутбуки и кассовые компьютеры в магазинах не справятся с реструктуризацией тяжелых таблиц базы данных в режиме «1С:Предприятие». Процесс может зависнуть на десятки часов, парализовав работу торговой точки.
Сбой обработчиков БСП (Библиотеки стандартных подсистем). При обновлении запускаются фоновые процедуры конвертации данных. Если запустить обмен между базами до того, как эти процедуры полностью завершились на каждом узле, данные в РИБ будут безнадежно испорчены.
Потеря настроек торгового оборудования. При полной перезаливке (пересоздании) периферийных баз с нуля «слетают» локальные настройки касс, эквайринговых терминалов и сканеров штрихкодов, так как они привязаны к конкретному рабочему месту и локальной базе.
Разберем детально три основные стратегии решения этой задачи, их плюсы, минусы и пошаговые алгоритмы реализации.
Этот метод считается самым надежным с точки зрения сохранения целостности данных без радикального вмешательства в архитектуру РИБ. Вместо того чтобы обновлять центральную базу сразу до финального релиза, мы разбиваем путь на небольшие этапы — по 2-4 релиза за один шаг.
Пошаговый алгоритм действий выглядит следующим образом:
Создаем полные резервные копии всех узлов информационной системы (центрального и всех периферийных). Это критически важное правило, пренебрегать им нельзя ни в коем случае.
В центральной базе накатываем цепочку из 2-3 релизов через конфигуратор с помощью файлов обновлений .cfu.
Запускаем центральную базу в режиме «1С:Предприятие» под правами администратора. Ждем полного завершения всех процедур отложенного обновления данных (БСП). Статус выполнения можно отслеживать в форме «Результаты обновления программы».
Выполняем выгрузку данных из центральной базы для всех периферийных узлов.
На каждом периферийном узле запускаем сеанс обмена, принимаем изменения конфигурации, заходим в конфигуратор, обновляем базу данных (клавиша F7), а затем запускаем режим «1С:Предприятие» для выполнения обработчиков БСП.
Убедившись, что обмен прошел успешно на всех точках и базы работают стабильно, снова делаем промежуточные резервные копии всей сети и переходим к следующему пакету из 2-3 релизов.
Преимущества метода: Высокая надежность, минимальный риск безвозвратной порчи данных, сохранение всех локальных настроек торгового оборудования на точках.
Недостатки: Колоссальные затраты времени администратора. Если у вас 5 периферийных узлов и 15 обязательных обновлений, этот процесс может растянуться на недели.
---
Стратегия №2: Полное обновление копии и пересоздание узлов
Этот вариант часто выбирают, когда хотят выполнить обновление «в один заход» и полностью избавиться от накопленных за годы работы ошибок в периферийных базах.
Разберем этот сценарий по шагам:
Берем резервную копию центральной базы и разворачиваем ее на мощном компьютере администратора (например, на процессоре класса Core i5 / i7 с быстрым NVMe SSD).
Последовательно обновляем эту базу до финального требуемого релиза. Поскольку мы работаем на мощном железе локально, процесс пойдет в разы быстрее, чем на реальных серверах и ноутбуках клиентов.
Дожидаемся завершения работы всех обработчиков обновления БСП в режиме «1С:Предприятие».
На время проведения финальных работ полностью останавливаем работу всех торговых точек (обычно это делается в ночное время или в праздничные дни). Проводим последний «грязный» обмен со старыми базами, чтобы собрать в центр все документы, оформленные кассирами за последнее время.
Переносим накопленные данные в нашу обновленную базу.
В обновленной центральной базе генерируем новые начальные образы для всех периферийных узлов (создаем новые ПУ).
Доставляем новые базы на торговые точки (через облачные хранилища или физически на флешках) и заменяем ими старые базы.
Важное предупреждение: При таком подходе на кассовых компьютерах полностью «слетят» настройки подключаемого оборудования. Вам придется заново прописывать сетевые адреса терминалов, COM-порты фискальных регистраторов, настраивать шаблоны чеков и подключать сканеры. Настоятельно рекомендуем перед заменой баз вручную зафиксировать или сфотографировать все параметры торгового оборудования в старых базах.
---
Стратегия №3: Временный разрыв связи РИБ (Профессиональный метод)
Если вам необходимо перейти с редакции 2.2 на 2.3, то стандартное обновление через каналы РИБ практически неосуществимо из-за глобального изменения структуры метаданных. В этом случае наиболее эффективным и безопасным методом является временное отключение связи с главным узлом, автономное обновление баз на местах и последующее восстановление связи.
Рассмотрим подробнее данный алгоритм:
Подготовка. Полностью останавливаем автоматический обмен данными между базами.
Программная отвязка периферийных узлов. На каждой торговой точке нам необходимо сделать базу автономной (основной). Для этого запускаем конфигуратор периферийной базы с параметром командной строки:
/ResetMasterNode
Альтернативный вариант — использовать специализированную обработку (например, «ГлавныйУзел.epf») и выполнить в режиме «1С:Предприятие» следующий код:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После этого база на точке перестает считать себя подчиненным узлом и позволяет вносить изменения в конфигурацию напрямую.
Параллельное обновление баз. Обновляем центральную базу на сервере до целевого релиза. Одновременно с этим (или последовательно) обновляем базы на точках. Если ноутбуки на точках слишком слабые, можно скопировать файлы локальных баз 1Cv8.1CD на мощный компьютер администратора, обновить их там до нужного релиза, дать отработать всем обработчикам обновления, а затем вернуть файлы обратно на точки.
Восстановление связи РИБ. Когда и центральная база, и все ПУ обновлены строго до одного и того же релиза, нам нужно вернуть настройки распределенной базы назад. На каждой периферийной точке запускаем обработку восстановления связи главного узла:
СсылкаНаЦентр = ПланыОбмена.Розница.НайтиПоКоду("ЦБ"); // Код центрального узла
Если ЗначениеЗаполнено(СсылкаНаЦентр) Тогда
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦентр);
КонецЕсли;
Сброс номеров сообщений. Чтобы восстановить корректный обмен и избежать конфликтов конфигурации, сбрасываем номера принятых и отправленных сообщений в планах обмена в ноль как в центре (для данного узла), так и на самом периферийном узле.
При использовании этого метода вы полностью сохраняете все локальные данные, документы, справочники и, самое главное, настройки торгового оборудования на точках.
---
Важные технические лайфхаки при масштабных обновлениях
Чтобы минимизировать риски сбоев во время выполнения описанных процедур, настоятельно рекомендуем придерживаться следующих правил:
Предварительно удаляйте патчи и расширения. Перед началом обновления (как в центре, так и на узлах) полностью удалите все установленные патчи (исправления) от фирмы «1С» и отключите кастомные расширения конфигурации. Старые патчи, рассчитанные на прошлые релизы, гарантированно заблокируют запуск базы данных после обновления метаданных.
Контролируйте отложенные обработчики БСП. Если процесс обновления «завис» на каком-то фоновом задании (например, система пытается часами пересчитывать неактуальные регистры маркировки пятилетней давности), вы можете открыть регистр сведений ОбработчикиОбновления через меню «Функции для технического специалиста». Найдите проблемный обработчик и вручную измените его статус на «Выполнен». Это позволит завершить обновление системы.
Используйте утилиту «Обновлятор-1С». Чтобы не тратить время на скачивание вручную 15 промежуточных дистрибутивов и рутинный запуск конфигуратора, воспользуйтесь сторонним специализированным софтом для автоматизации обслуживания баз «1С». Это сэкономит вам до 90% времени.
Ручной перенос тяжелых файлов обмена. Если объем первого файла обмена превышает разумные пределы, не пытайтесь передать его через встроенные почтовые клиенты или медленный FTP-протокол. Запишите файл обмена на флеш-накопитель, физически привезите его на точку (или передайте через скоростные файлообменники) и загрузите вручную через стандартную обработку «Выгрузка загрузка данных XML» или стандартный интерфейс синхронизации.
Мы проанализировали три основных пути решения проблемы долгого отсутствия обновлений в РИБ на базе «1С:Розница 2». Выбор конкретного метода зависит от технических характеристик компьютеров на точках, количества свободного времени у администратора и необходимости сохранения настроек торгового оборудования. Наиболее профессиональным и безопасным при переходе с редакции 2.2 на 2.3 признан метод с временным программным отключением главного узла (Стратегия №3).