Обновление распределенных информационных баз (РИБ) в решениях на платформе «1С:Предприятие 8.3» — это всегда ответственная задача, требующая от системного администратора четкого планирования. Ситуация значительно усложняется, когда перед нами стоит задача обновить конфигурацию сразу на несколько релизов вперед, время ограничено одной ночью (технологическим окном), а интернет-канал на удаленных торговых точках оставляет желать лучшего. Типичный пример такого сценария — обновление популярной конфигурации «1С:Розница 2.2» в центральном офисе и на периферийных торговых точках.
В этой статье мы подробно разберем, как решить эту задачу с минимальными затратами времени, выясним, почему стандартные механизмы обмена могут давать сбои при слабом интернете, проанализируем влияние различных методов на настройки торгового оборудования и рассмотрим альтернативные профессиональные варианты обновления РИБ.
При стандартном подходе процесс обновления РИБ выглядит следующим образом: администратор обновляет центральный узел (ЦУ), после чего запускается сеанс синхронизации. В процессе обмена система формирует файл выгрузки, содержащий изменения конфигурации (файл обмена содержит так называемый «заголовок» с обновленной конфигурацией базы данных). Периферийный узел принимает этот файл, видит изменения метаданных, блокирует работу пользователей и требует от администратора запустить Конфигуратор для применения изменений базы данных (клавиша F7).
Если пропущенных релизов много, файлы обмена становятся огромными. При слабом или нестабильном интернете (например, при использовании 3G/4G-модемов на торговых точках) передача таких пакетов превращается в проблему. Файлы могут скачиваться с ошибками, сессия обмена может прерываться, а трафик — расходоваться впустую. Кроме того, при последовательном обновлении через РИБ на каждый релиз требуется провести как минимум два цикла обмена (прием изменений периферией и отправка подтверждения в центр), что в условиях лимита времени абсолютно нереализуемо.
Автор темы на форуме предложил радикальный способ: полностью обновить центральный узел на все необходимые релизы «в один запуск» на быстром компьютере в офисе, после чего сформировать для каждого удаленного магазина новый начальный образ и доставить его на точки (или скачать целиком по сети).
Рассмотрим подробнее этот вариант. Он действительно рабочий и позволяет обойти проблему постепенной «прокачки» каждого релиза по слабому интернету. Однако у этого метода есть существенные недостатки:
1Cv8.1CD) весит в сотни раз больше, чем файлы обновлений конфигурации. Передать такой объем по слабому интернету на удаленную точку физически невозможно — придется везти базу на флешке или жестком диске.Выясним причину, почему при создании нового начального образа гарантированно «слетают» настройки торгового оборудования (онлайн-касс, эквайринговых терминалов, сканеров штрихкодов, весов и т.д.).
В конфигурации «1С:Розница 2.2» (и других современных решениях 1С) подключение любого оборудования жестко привязано к справочнику Рабочие места. Каждое рабочее место в программе однозначно идентифицируется уникальным идентификатором (GUID), который генерируется на основе сетевого имени компьютера, операционной системы и пути к базе данных.
Когда мы создаем начальный образ заново и разворачиваем его на торговой точке:
В результате после запуска новой периферийной базы кассиры не смогут пробить чек или принять оплату картой. Администратору придется заново вручную перенастраивать все драйверы и оборудование на каждом рабочем месте, что сводит на нет всю экономию времени от быстрого обновления.
Существует профессиональный обходной путь, который идеально подходит для обновления баз при слабом интернете. Этот метод позволяет обновить конфигурацию подчиненного узла сразу на финальный релиз без пересоздания образа базы данных и без потери настроек торгового оборудования.
Разберем этот алгоритм по шагам:
Шаг 1. Финальная синхронизация. Перед началом работ проводим стандартный обмен со всеми торговыми точками, чтобы все накопленные документы и чеки гарантированно ушли в центральную базу.
Шаг 2. Обновление центрального узла. Обновляем центральную базу данных на все необходимые релизы до целевой версии.
Шаг 3. Подготовка файла конфигурации. В Конфигураторе обновленного центрального узла выгружаем файл конфигурации (меню «Конфигурация» — «Сохранить конфигурацию в файл...»). Полученный файл с расширением .cf будет весить в разы меньше, чем база целиком, и его можно относительно быстро передать на точки через интернет (или привезти на флешке).
Шаг 4. Временное отключение РИБ на торговой точке. Чтобы подчиненная база позволила обновить себя напрямую из файла без контроля главного узла, ее необходимо временно «отвязать» от РИБ. Для этого запускаем Конфигуратор периферийной базы на точке и открываем встроенную обработку или запускаем базу в режиме Предприятия и выполняем следующий программный код:
// Программное отключение связи с главным узлом
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Также отвязать базу можно через командную строку, запустив Конфигуратор со специальным ключом:
"C:\Program Files\1cv8\bin\1cv8.exe" CONFIG /F "Путь_К_Базе_На_Точке" /ResetMasterNode
После этой процедуры база становится полностью автономной, а в Конфигураторе разблокируются все объекты метаданных.
Шаг 5. Загрузка конфигурации. В Конфигураторе периферийной базы выбираем пункт меню «Конфигурация» — «Загрузить конфигурацию из файла...» и указываем наш подготовленный файл .cf от центрального узла. Выполняем обновление конфигурации базы данных (клавиша F5 или F7).
Шаг 6. Запуск и обработка данных. Запускаем периферийную базу в режиме «1С:Предприятие». Дожидаемся выполнения всех отложенных обработчиков обновления данных БСП (Библиотеки стандартных подсистем).
Шаг 7. Восстановление связи РИБ. Снова подключаем периферийную базу к главному узлу. Для этого в режиме «1С:Предприятие» выполняем код восстановления связи:
// Укажите ссылку на предопределенный узел вашей центральной базы
СсылкаНаЦентр = ПланыОбмена.ПолнотекстовыйПоиск.НайтиПоКоду("ЦУ");
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦентр);
Шаг 8. Выравнивание номеров сообщений. Чтобы при первом же обмене не возникло конфликта версий, заходим в настройки синхронизации и вручную устанавливаем номера принятых и отправленных сообщений в соответствии с номерами, зафиксированными в центральной базе.
Результат: база на точке обновлена до актуальной версии за один шаг. Настройки торгового оборудования, GUID рабочего места и все локальные данные пользователей полностью сохранены.
Для решения задачи автоматического применения пришедших обновлений на периферийных точках (вопрос из сообщения №15) мы можем использовать встроенные возможности конфигурации или внешние скрипты.
Рассмотрим подробнее встроенный механизм БСП. В «1С:Розница 2.2» предусмотрена штатная функция автоматического применения обновлений конфигурации при обмене данными. Чтобы настроить этот механизм, выполним следующие действия:
При получении файла обмена с новой конфигурацией система автоматически создаст исполняемый bat-файл, завершит работу текущих пользователей, запустит Конфигуратор в фоновом пакетном режиме обновления, применит изменения метаданных и снова запустит режим «1С:Предприятие» для выполнения обработчиков.
Если требуется полный контроль над процессом, администраторы часто используют сценарии командной строки (bat-файлы). Разберем пример скрипта автоматического обновления конфигурации базы данных:
@echo off
chcp 65001
set v8path="C:\Program Files\1cv8\bin\1cv8.exe"
set dbpath="C:\1C_Bases\Retail_Store"
set dbuser="Администратор"
set dbpass="ПарольАдмина"
echo Запуск обновления конфигурации базы данных на торговой точке...
%v8path% CONFIG /F %dbpath% /N %dbuser% /P %dbpass% /UpdateDBCfg /UC "КодБлокировки"
if %errorlevel% neq 0 (
echo Произошла ошибка при обновлении!
) else (
echo Обновление успешно применено.
)
pause
Также высокую популярность в сообществе 1С имеет специализированный софт, такой как «Обновлятор-1С». Он позволяет централизованно автоматизировать резервное копирование, последовательное обновление и запуск обработчиков на множестве распределенных баз по расписанию.
Проанализируем ситуацию, описанную в сообщении №11. Часто на удаленных торговых точках установлены слабые компьютеры (например, ноутбуки или неттопы с процессорами класса Intel Celeron, 2 ГБ оперативной памяти и медленными жесткими дисками HDD). На таких машинах процесс реструктуризации базы данных при масштабном обновлении может занимать долгие часы или вовсе аварийно завершаться из-за нехватки оперативной памяти.
Если вы столкнулись с такой аппаратной проблемой, настоятельно рекомендуем использовать описанный выше метод обновления через файл .cf, но выполнять его физически на своем рабочем мощном компьютере. Вы можете скопировать локальный файл периферийной базы 1Cv8.1CD на свой рабочий ПК (где установлен быстрый SSD и минимум 16 ГБ RAM), запустить процесс обновления на нем (он займет считанные минуты вместо часов), а затем вернуть обновленный файл базы данных обратно на торговую точку.
При переходе на новые релизы платформы 8.3 и конфигурации «1С:Розница» часто возникает критическая проблема несовместимости установленных расширений и автоматически скачиваемых патчей (исправлений от фирмы 1С).
Если в центральной базе были установлены патчи, они регистрируются к обмену и передаются в подчиненные узлы. Во время обновления структуры метаданных эти патчи могут вызвать конфликт совместимости, из-за чего база на точке откажется запускаться.
Рекомендация: перед началом процесса глобального обновления в центральной базе обязательно удалите все установленные патчи (раздел «Администрирование» — «Обслуживание» — «Обновление программы» — «Установленные исправления (патчи)»). После завершения обновления всей цепочки РИБ и успешного запуска всех узлов вы сможете заново скачать актуальные патчи, выпущенные уже специально для нового релиза конфигурации.