Доброго дня, коллеги!
Видится, что непростая практическая задача стоит перед нашим слушателем. Сколько времени он убьет на “это вот все” – неизвестно. Но очевидно, что стоит принять рекомендацию тренера и посмотреть в сторону расширений. Это позволит значительно упростить процесс обновления РИБ в будущем.
Курс: Разработка расширений и технологии доработки конфигураций 1С без снятия с поддержки
Вопрос
Здравствуйте! Подскажите, пожалуйста, по обновлению РИБ на несколько ключевых релизов. Есть центральная и 10 периферийных баз, в которых пользователи работают с утра до ночи. Есть возможность обновлять ночью, но на копиях баз, так как компьютеры с основными базами ночью выключены (файловые базы). Вопросы следующие:
- Можно ли в РИБ обновлять итерационно только центральный узел, не передавая данные в периферийные? А затем в периферийных накатить итоговую конфигурацию? Можно ли так делать? Могут ли испортиться от этого данные?
- Если по п. 1 сделать нельзя, то можно ли отвязать копии от РИБ и обновлять все 11 баз, как обычные независимые, а затем соединить обратно в РИБ, назначив главный узел? Долго ли происходит восстановление РИБ, если размер базы ~2Гб?
- Используете ли при таких задачах подход с обновлением главного узла, а периферийные базы пересоздаются заново с обновленного релиза? В каких случаях такой подход оправдан?
- Есть ли какие-нибудь инструменты для массового обновления баз? Пользуетесь ли вы такими в работе?
Ответ
Добрый день!
- Да, можно обновить центральный узел на несколько релизов, затем выгрузить изменения в периферийные узлы. Главное, чтобы конфигурация поддерживала такой переход через несколько релизов, в периферийной базе при запуске в пользовательском режиме отработали обработчики обновления данных (если они необходимы). Это можно проверить на копии центральной и 1 периферийной базе. В моей практике на 1С:Розница такой вариант прошел нормально.
- При таких попытках возникала ошибка, что конфигурация узла распределенной базы не соответствует ожидаемой, обмен в РИБ не работал. Приходилось пересоздавать узлы или загружать конфигурацию из центральной базы в периферийную.
Назначение главного узла происходит быстро, а вот загрузка конфигурации может занять достаточно много времени. - Да, используется, особенно когда параллельно планируем уменьшить размер периферийной базы, например, оставить в ней только справочники. Или когда создание заново периферийной базы быстрее, чем загрузка обновленной конфигурации и данных из центральной базы.
- Могу порекомендовать использовать расширения, удобно для внесения мелких изменений и доработок, чтобы не выгружать измененную конфигурацию в файле обмена. А так использую программы для удаленного доступа. Какого-то особого инструмента именно для обновления баз не применяю.
Это пример разобранного вопроса из Мастер-группы курса
Разработка расширений и технологии доработки конфигураций 1С без снятия с поддержки.
Разработка расширений и технологии доработки конфигураций 1С без снятия с поддержки.
Описание курса и примеры видео
Я бы не рекомендовал, обовлять на несколько релизов крупные базы. Релизы, где происходят изменения с ЕГАИС, ИС МП и другими интеграциями, если вы их испльзуете в работе.
Обновляйте по одному релизу последовательно. Автоматизируйте работу через сторонние утилиты. Обновлятор1с. Скрипты автозапуска. (Можно запускать 1с с определёнными параметрами, и тогда узел РИБ примет и установить обновление)
Добрый день!
Спасибо за рекомендацию.
В п. 1 вопроса центральная база именно так и обновлялась – последовательно на каждый релиз, с запуском в пользовательском режиме, чтобы выполнились обработчики. Затем изменения передавались в периферийные базы. Всё прошло успешно.
В любом случае рекомендуется сделать тестовый контур, выполнить действия на нем, протестировать полученные результаты, затем повторить на рабочих базах.