Как правильно обновлять типовую конфигурацию (1С 8.3, серверные базы)
Давно задаюсь вопросом: а как, собственно, правильно обновлять типовые конфигурации 1С 8.3 (Бух., ЗиК) ; серверные базы, чтобы было минимум ошибок в базах. Особенно если обновляешься сразу на несколько релизов, например, за квартал.
Понятно, что сначала сделать бэкап (я делаю и бэкап базы SQL и бэкап базы DT).
А потом возможны такие варианты:
а) делать обновление обычным образом через конфигуратор; после каждого обновления запускать базу (т.е. "в режиме 1СПредприятие"), ждать, когда выполнятся "дополнительные процедуры обработки данных при обновлении" (а это иногда и день может занять);
б) делать обновление обычным образом через конфигуратор, но базу не запускать, а сразу можно делать следующее обновление через конфигуратор (т.е. на следующий релиз конфигурации, который разрешит конфигуратор), а уже потом, в конце, запустить базу;
в) вообще делать обновление не в режиме Конфигуратор, а в режиме 1СПредприятие, с правами администратора, в автоматическом режиме.
Вопрос может показаться тривиальным, но я опросил знакомых (администраторов мелких серверов 1С) - и у всех разные мнения -) Поэтому решил вынести на обсуждение.
Понятно, что сначала сделать бэкап (я делаю и бэкап базы SQL и бэкап базы DT).
А потом возможны такие варианты:
а) делать обновление обычным образом через конфигуратор; после каждого обновления запускать базу (т.е. "в режиме 1СПредприятие"), ждать, когда выполнятся "дополнительные процедуры обработки данных при обновлении" (а это иногда и день может занять);
б) делать обновление обычным образом через конфигуратор, но базу не запускать, а сразу можно делать следующее обновление через конфигуратор (т.е. на следующий релиз конфигурации, который разрешит конфигуратор), а уже потом, в конце, запустить базу;
в) вообще делать обновление не в режиме Конфигуратор, а в режиме 1СПредприятие, с правами администратора, в автоматическом режиме.
Вопрос может показаться тривиальным, но я опросил знакомых (администраторов мелких серверов 1С) - и у всех разные мнения -) Поэтому решил вынести на обсуждение.
По теме из базы знаний
- Синхронизация хранилища 1С и git-репозитория с применением OneScript и Gitsync. Методика и пошаговая инструкция для создания скрипта и его регулярного запуска
- Некоторые моменты обновления типовых конфигураций (доработанных типовых конфигураций)
- Многопоточный CI-контур для 1С c Packer, Vagrant и Jenkins. Часть 1. Описание системы и обзор инструментария
- Как читать чужой код? Часть 1. Общие вопросы. Доработка чужого кода. Code review
- Как читать чужой код? Часть 2. Доработка типовой конфигурации. Обновление доработанной типовой конфигурации
Найденные решения
Спасибо всем за ответы. В общем, в итоге, все сошлись на том, что, хотя для этого нет внятного обоснования, но все обновляют по варианту (а) (я, кстати, тоже делаю именно так, но это занимает кучу времени, поэтому я втайне надеялся, что мне скажут, что можно обновлять без промежуточных запусков в режиме 1СПредприятие -)) )
(4) а насчет dt - я делаю (и советую) бэкап и как бэкап базы SQL, и как dt. Т.к. бэкап нужен для ЧП, а при ЧП иногда бывает так, что и базу SQL не восстановишь (или, например, слетит программная лицензия на сервер; сайт 1С висит, а работать нужно) - тогда приходится выгружать dt в файловую базу, работать в ней и потом снова выгружать в базу SQL.
Часто читал, что dt плохой вариант для бэкапов; признаться, не понял почему, но, тем не менее, тоже стараюсь всуе не использовать.
(4) а насчет dt - я делаю (и советую) бэкап и как бэкап базы SQL, и как dt. Т.к. бэкап нужен для ЧП, а при ЧП иногда бывает так, что и базу SQL не восстановишь (или, например, слетит программная лицензия на сервер; сайт 1С висит, а работать нужно) - тогда приходится выгружать dt в файловую базу, работать в ней и потом снова выгружать в базу SQL.
Часто читал, что dt плохой вариант для бэкапов; признаться, не понял почему, но, тем не менее, тоже стараюсь всуе не использовать.
Надо всегда запускать после обновления в обычный режим. При этом ИНОГДА проходят важные обработки. Например при разбиении счета на несколько субсчетов, значения переносятся на промежуточный субсчет, создаются новые нижнего уровня и значения возвращаются. Не выполнится обработка данные на новом субсчете не появятся, а со старого (основного) исчезнут. Угадать, когда что происходит невозможно. Лучше не рисковать. Сам налетел разок, больше не хочется
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Во-первых, никогда не используй DT в качестве бэкапа, потому что успешная выгрузка в него совершенно не гарантирует последующую успешную загрузку. Единственное предназначение выгрузки в DT - перенос базы между различными видами СУБД. Пруф на ИТС.
Во-вторых, однажды я решил обновить типовую базу сразу на много релизов при помощи автообновления из под режима предприятия и с удивлением обнаружил, что оно накатывает cfu один за другим без промежуточных запусков в режиме предприятия для запуска обработчиков обновления данных. Техподдержка на мой логичный вопрос ответила, что автообновление работает правильно, а вот делать то же самое руками через конфигуратор - неправильно. Теоретически, если после обновления сразу на несколько релизов обработчики обновления в режиме предприятия завершились без ошибок, значит всё прошло хорошо. Но с судьбой лучше не играть, мало ли что вылезет при последующих обновлениях. Поэтому мой выбор - ручное обновление через конфигуратор на один ключевой релиз за раз с запуском предприятия и контроля выполнения обработчиков обновления данных.
Во-вторых, однажды я решил обновить типовую базу сразу на много релизов при помощи автообновления из под режима предприятия и с удивлением обнаружил, что оно накатывает cfu один за другим без промежуточных запусков в режиме предприятия для запуска обработчиков обновления данных. Техподдержка на мой логичный вопрос ответила, что автообновление работает правильно, а вот делать то же самое руками через конфигуратор - неправильно. Теоретически, если после обновления сразу на несколько релизов обработчики обновления в режиме предприятия завершились без ошибок, значит всё прошло хорошо. Но с судьбой лучше не играть, мало ли что вылезет при последующих обновлениях. Поэтому мой выбор - ручное обновление через конфигуратор на один ключевой релиз за раз с запуском предприятия и контроля выполнения обработчиков обновления данных.
(4)
(4)
Смешно, т.е. выгрузка не гарантирует загрузку, а при переносе между разными СУБД, гарантирует?
(4)
Во-первых, никогда не используй DT в качестве бэкапа, потому что успешная выгрузка в него совершенно не гарантирует последующую успешную загрузку. Единственное предназначение выгрузки в DT - перенос базы между различными видами СУБД. Пруф на ИТС.
Смешно, т.е. выгрузка не гарантирует загрузку, а при переносе между разными СУБД, гарантирует?
(4)
что оно накатывает cfu один за другим без промежуточных запусков в режиме предприятия для запуска обработчиков обновления данных.
Так база уже в режиме предприятия и после накатки обновления и запускаются обработчики. ;) Минус такого обновления - очень долго и не факт что завершиться успешно... Я после пары раз таких обновлений отказался на всегда от такого способа.
Спасибо всем за ответы. В общем, в итоге, все сошлись на том, что, хотя для этого нет внятного обоснования, но все обновляют по варианту (а) (я, кстати, тоже делаю именно так, но это занимает кучу времени, поэтому я втайне надеялся, что мне скажут, что можно обновлять без промежуточных запусков в режиме 1СПредприятие -)) )
(4) а насчет dt - я делаю (и советую) бэкап и как бэкап базы SQL, и как dt. Т.к. бэкап нужен для ЧП, а при ЧП иногда бывает так, что и базу SQL не восстановишь (или, например, слетит программная лицензия на сервер; сайт 1С висит, а работать нужно) - тогда приходится выгружать dt в файловую базу, работать в ней и потом снова выгружать в базу SQL.
Часто читал, что dt плохой вариант для бэкапов; признаться, не понял почему, но, тем не менее, тоже стараюсь всуе не использовать.
(4) а насчет dt - я делаю (и советую) бэкап и как бэкап базы SQL, и как dt. Т.к. бэкап нужен для ЧП, а при ЧП иногда бывает так, что и базу SQL не восстановишь (или, например, слетит программная лицензия на сервер; сайт 1С висит, а работать нужно) - тогда приходится выгружать dt в файловую базу, работать в ней и потом снова выгружать в базу SQL.
Часто читал, что dt плохой вариант для бэкапов; признаться, не понял почему, но, тем не менее, тоже стараюсь всуе не использовать.
Надо всегда запускать после обновления в обычный режим. При этом ИНОГДА проходят важные обработки. Например при разбиении счета на несколько субсчетов, значения переносятся на промежуточный субсчет, создаются новые нижнего уровня и значения возвращаются. Не выполнится обработка данные на новом субсчете не появятся, а со старого (основного) исчезнут. Угадать, когда что происходит невозможно. Лучше не рисковать. Сам налетел разок, больше не хочется
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот