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

andsmWarAntandsm,

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

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

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

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

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

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

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

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

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

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

andsmalexeyvgА что такого? Каждое изменение, каждый скрипт, делается так, что бы система как работала, так и продолжала работать.

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

Я думаю, это практически нереально.
При таком подходе слишком высокий риск появления багов в коде. И если для какого-нибудь сайта это может быть допустимо, то для финансовой системы это не допустимо. Качество должно быть на первом месте.Я не вижу разницы в смысле "качества".

Но это в принципе неважно.
Если вы говорите, что система должна прекращать функционирование на период обновления, что любые средства уменьшения времени простоя недопустимо, потому что "Качество должно быть на первом месте", то непонятен вопрос топика.
Получается, исходный вопрос ставится так: "Как уменьшить время простоя, при условии, что его уменьшать недопустимо?"

КритикПопробуйте перейти на недельные релизы, тогда объем изменений будет невелик, соответственно и периоды обновления будут меньше по длительности. Доведете их, скажем, до 15 минут в неделю - большинство пользователей это должно устроить.Сомневаюсь, что это уменьшит время простоя.
Конечно, надо анализировать процесс, но наверняка основное время уходит на включение и повторную инициализацию репликаций
КритикОбновления с учетом изменений делать можно, но это довольно сложно, по сути трудоемкость разработки будет существенно выше (в разы). И все равно тогда 100% кому-то придется оправдываться в духе "я забыл, я это не учел", а кому-то придется это слушать.Конечно, трудоёмкость увеличится, скрипты деплоя будут сложнее, даже не скрипты как таковые, а усложняется процесс плавного бесшовного изменения при некоторых модификациях модели.

А ошибки будут и при варианте с остановкой системы на период обновления. Какая разница то?
Тут какой то особой зависимости нет, кроме очевидного "количество багов пропорционально количеству кода". Бизнес заказал дополнительную функциональность, добавились ошибки по этой функциональности, как и должно быть. Что бы их не добавлять, единственный вариант - ничего не делать.

andsmЯ как-то переводил БД с одной схемы данных на совсем другую, тоже для 24/7 системы и с активно пишущими пользователями. Некоторые таблицы превращались в несколько других таблиц, некоторые таблицы наоборот объединялись. Содержимое многих полей менялось при обновлении, и т.п. Размер БД был примерно 1.5 Тб. Так вот, время простоя составило 15 секунд. Да-да, секунд. Другое дело, что разработка такого перехода заняла несколько месяцев. Хочется поискать менее трудоемкие варианты.Да-да, вот, возможно же.

Но придётся заплатить трудоёмкостью.
Как иначе решить такую задачу? Кнопки волшебной нет.
Именно так все и делают.

Владислав Колосов24/7 - это Enterprise edition + Always on. Придется раскошелиться.У автора вопрос в другом.
Есть достаточно сложная система, состоящая из множества серверов СУБД, серверов приложений, клиентского софта и т.д.

Нету такого "Enterprise edition + Always on", который бы включал все эти компонеты.
Что бы половинку можно было бы обновить, а потом оно бы само синхронизировалось (например, при изменении модели данных).
И без потери траназкций.
И что бы ничего не писать, и что бы гарантированно рисков/багов не добавилось.

МуМу,

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

Сложные схемы приходится придумывать для более сложных изменений, да ещё связанных с большими объёмами данных (например, большую таблицу, занимающую весь рейд, превратить в секционированную, без остановки).

МуМуАлгоритм с полем приведен как пример когда в логике приложения это поле учавствует, то есть раньше считалась какая то сумма из чего то а вот теперь решили сделать агрегацию. Получилось две ветки алгоритма, старый и новый. При учете непрерывности работы системы должны на сервере приложения работать два алгоритма до тех пор пока изменения не будут применены и останется только новый.Это в системах 24*7 делается проще.

На первом этапе добавляем новое поле, обеспечиваем его начальное заполнение и поддержку актуальности.
Когда этот этап завершён, и на продакшене всё работает, обновляется сервер приложений (клиент), на использование нового поля. И в этот же деплой удаляется старое (если, к примеру, новое вместо старого).
Такой подход, конечно, замедляет изменения, но зато в 2 раза дешевле, и менее багоёмкий.

Конечно, если фича нужна срочно, то можно и забашлять "за 2 алгоритма".
МуМуА в жизни чего только не бывает, попытайтесь например 1С сделать с ее регламентами сделать 24*7, боюсь практически это будет сделать без окон невозможно при текущей архитектуре.Ну понятно, что мы говорим о случае, когда есть контроль над всей системой.
Если нет, то тут 50% - либо получится, либо не получится :-)