Обновление распределенной информационной базы (РИБ) — это всегда ответственный процесс, требующий стабильности системы. Однако в реальных условиях мы часто сталкиваемся с проблемами: постоянные отключения электроэнергии на удаленных точках, «тонкие» каналы связи и огромные файлы обмена, которые не успевают передаться за время «окна» доступности сети. Проанализируем, как можно минимизировать риски и провести обновление максимально безопасно.
Стандартный механизм РИБ предполагает, что конфигурация передается внутри файла обмена (Message_XXX_YYY.xml). Если файл весит сотни мегабайт, а интернет постоянно обрывается, узел может неделями не получать обновление. Разберем пошагово альтернативные варианты решения этой задачи.
Если передать жирный файл обмена не удается, мы можем обновить конфигурацию периферийного узла напрямую через Конфигуратор, используя файл конфигурации .cf. По умолчанию в РИБ Конфигуратор на подчиненном узле заблокирован для изменений, но это ограничение можно обойти.
Рассмотрим алгоритм действий:
.cf из центральной базы (Конфигуратор — Конфигурация — Сохранить конфигурацию в файл). Этот файл можно передать на точку любым способом (на флешке, через облако с докачкой).
// Снимаем привязку к главному узлу
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
После выполнения этого кода база становится автономной. Теперь мы можем зайти в Конфигуратор периферийного узла, и функции изменения конфигурации станут доступны. Выполним следующие шаги в Конфигураторе:
.cf файл).Важно: После обновления крайне важно вернуть привязку к главному узлу, иначе обмен данными не возобновится. В режиме «Предприятие» выполняем код:
// УзелСсылка — это ссылка на главный узел (Центральная база) в плане обмена
СсылкаНаЦентр = ПланыОбмена.Розница.НайтиПоКоду("ЦБ"); // Замените "ЦБ" на ваш код
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦентр);
Проанализируем ситуацию: теперь версии конфигураций в центре и на периферии совпадают. При следующем обмене система увидит, что метаданные идентичны, и передаст только данные, что значительно уменьшит размер сообщения.
Если проблема только в интернете (обрывы связи), а не в самом процессе обновления, рассмотрим способ оптимизации доставки файлов. Стандартный FTP или почта плохо справляются с обрывами на больших файлах.
Рекомендуется использовать специализированное ПО, например Syncthing. Оно работает по принципу P2P (как торренты).
Разберем преимущества этого подхода:
Syncthing докачает оставшиеся 10%, а не будет начинать заново.Администратору остается только дождаться появления файла в локальной папке на точке и запустить типовой обмен 1С, который подхватит уже скачанный файл мгновенно.
Выгрузки часто становятся «жирными» из-за того, что в них попадает много накопленных изменений данных вместе с конфигурацией. Выясним причину раздувания файлов и устраним её.
Перед обновлением конфигурации можно временно очистить регистрацию изменений для справочников и документов, если они не критичны для немедленной передачи. Для этого используем типовую обработку «Регистрация изменений для обмена данными». Если в сообщении останется только структура конфигурации, файл станет легче. После успешного обновления конфигурации данные можно перерегистрировать или дослать позже.
Самый опасный момент при отключении электричества — это реструктуризация таблиц базы данных (нажатие F7). Если в этот момент питание пропадет, база может перейти в состояние «Database is suspect» или просто повредиться.
Начиная с платформы 8.3, проанализируем возможность использования фонового обновления конфигурации базы данных. Этот механизм позволяет выполнять основную часть реструктуризации в то время, когда пользователи продолжают работать в системе. Разберем по шагам:
Это значительно снижает риск попадания на момент отключения электричества, так как критическое «окно», когда база заблокирована и уязвима, сокращается в десятки раз.
Если ваши обновления Розницы 2.2 связаны не с переходом на новый релиз от вендора, а с вашими собственными доработками (печатные формы, логика проведения), посмотрим на пример использования расширений.
Объекты, вынесенные в расширения (Extensions), передаются через РИБ значительно быстрее. Обновление расширения не требует глубокой реструктуризации основных таблиц базы данных. Это позволяет проводить «тяжелые» обновления основной конфигурации крайне редко (например, раз в квартал), а текущие правки вносить через легкие механизмы, которые не боятся слабого интернета.
Для системного администратора будет полезным настроить пакетный файл (.bat), который будет проверять наличие файла обновления и запускать процесс в автоматическом режиме ночью. Чтобы избежать проблем с питанием, в скрипт можно добавить проверку состояния ИБП (через WMI). Если заряд батареи ниже 50%, скрипт просто не начнет обновление конфигурации.
Пример команды для автоматического обновления базы из командной строки:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F "D:\1C_Base" /UpdateDBCfg /Out "C:\log.txt" /Visible
Подводя итог, выделим основные стратегии для работы в сложных условиях:
Syncthing, Cloud Drives) для гарантированной доставки файлов.ПланыОбмена.УстановитьГлавныйУзел(Неопределено) для локальной загрузки .cf.Совместное применение этих методов позволит вам успешно обслуживать распределенную сеть даже в самых неблагоприятных инфраструктурных условиях.