andsmРуководство теперь хочет чтобы система работала 24/7, для этого есть причины. В обычные выходные это несложно обеспечить, но при переходе на новую версию так не получится.
Простой все равно будет, но его время надо как-то уменьшать.
Идеи как это сделать имеются, но интересен опыт других.Если было требование 24х7, то обновления мы писали так, что бы не прерывать работу системы.
Сделать это не просто, а очень просто, так что это вопрос административный, а не технологический.

andsmWarAntandsm,

не изменять апгрейдом кучу данных не предлагать?
Разумеется. Если бы настолько очевидное решение подходило бы, то и вопроса бы не было.Вообще трудно представить обновление, для которого нельзя придумать способ сделать его так, что бы это не затронуло пользователей.
Хотелось бы пример, тем более чсто вы говорите про это, как о чём то очевидном.

МуМуВ контексте того что у вас используется репликация, тем более вы должны понимать концепт того каким образом это решать и сколько это будет стоить. Еще момент, если архитектурно в самом начале разработки системы не было принято стратегическое о ее дальнейшей работе в 24*7 то это может быть и нерешаемой задачей(то есть без окон не обойтись никак).Да, увидел дополнение про репликации...
Согласен, тогда придётся что то либо менять в архитектуре, либо отказаться от идеи.

andsmalexeyvgпропущено...
Вообще трудно представить обновление, для которого нельзя придумать способ сделать его так, что бы это не затронуло пользователей.
Хотелось бы пример, тем более чсто вы говорите про это, как о чём то очевидном.
Мелкие обновления у нас и так выходят без остановки системы. Речь то идет о выходе новой версии системы.Так надо изменения версии делать по той же схеме, что и мелкие обновления.

Знаете, из вашего описания ведь неявно следует, что новые версии клиентского софта не работают со старой версией базы, и наоборот.
А это важный признак противоречия архитектуры и 24х7
Какая разница, можно ли останавливать базу, или нельзя, если клиент превращается ровно в пполночь превращается в тыкву?
Впрочем, может, у вас клиент один, то есть сайт?

Вот, значит, пора менять архитектуру на 24х7, раз бизнес захотел.
То есть отойти от принципа "программисты ваяли-ваяли, работали-работали, и вот, у них готова новая версия. Она накатывается на сервер, и на клиент, и пока накатывают, ничего не работает."
Значит, старый клиент (или Веб-сервер) должен работать с новой базой, все изменения в базе должны делаться без остановки, клиент тоже должен обновляться быстро (мы, правда, сессии всё таки теряли, не получалось без этого)

andsmWarAntя про то же, странная система которая требует переделки кучи данных при простом обновлении версии системы, на лицо кривая архитектура, явно не подразумевающая работу без остановки, и для такой архитектуры есть тольок два варианта, либо переписать либо открыть чулан с костылями.
"Простое" обновления версии системы?
Ну вот пример. Новая версия системы, выходит через несколько недель. 100+ скриптов по внесению изменению в данные и в схему. Чуть менее 1000 измененных хранимых процедур. Это можно назвать простым обновлением?А что такого? Каждое изменение, каждый скрипт, делается так, что бы система как работала, так и продолжала работать.

Даже серьёзное изменение модели (типа, было несколько таблиц, стало несколько совсем других таблиц, связанных по другому, и с другими данными) можно делать так, что бы всё продолжало работать.

Конечно, общий деплой сначала обкатывается на копии продакшен-системы, и проверяется тестерами; ну, это уже в принципе банальная органицация изменений, это само собой.

andsmalexeyvgВпрочем, может, у вас клиент один, то есть сайт?

Клиентский софт вообще не имеет прямого доступа к БД. Он соединяется к серверам приложений, и только серверные компоненты работают с БД. Работа с клиентскими приложениями идет по определенному протоколу, который при выходе версии не меняется, Вот для серверных компонентов версия БД важна.А, ну ок, это даже лучше, удобнее контролировать.
Под "сайт" я имел в виду некую единую, контролируемую вами, систему.