Здравствуйте, Rikomer, Вы писали:

R>Представим себе апдейт ПО атомной станции или другого ПО 24/7 которое нельзя останавливать.
R>Как там делаеют апдейт если надо обновлять к примеру ПО + базу.
R>С ПО я еще могу понять, что по очереди обновляем ноды, компы.
R>А вот с базой непонятно. Если структура меняется так, что старая версия приложения не может работать с новой, то как делают?

R>вариант у меня, но всё равно какойто сложный
R>1. Делаем кластер из баз и репликацию между базами.
R>2. Отрубаем несколько нод из кластера, накатываем на них все изменения
R>3. Включаем новую версию базы, отрубаем старые версии и дальше накатываем
R>4. Накатываем на новые версии базы скрипт по переносу данных которые произошли на старой версии базы, пока делали пункт 2

R>Кто с таким сталкивался?

Если реактор после отказа автоматики мгновенно взлетает на воздух — то это явно плохой реактор, а отказать может любая автоматика, даже самая надёжная. Вывод — реактор нужно проектировать так, что бы он какое-то время мог работать "на автопилоте", пока например управляющий компьютер перезагрузится. Если оно так спроектировано, то обновлять можно прямо во время работы, соблюдая только временные сроки.

Здравствуйте, Rikomer, Вы писали:

R>Представим себе апдейт ПО атомной станции или другого ПО 24/7 которое нельзя останавливать.
R>Как там делаеют апдейт если надо обновлять к примеру ПО + базу.
R>С ПО я еще могу понять, что по очереди обновляем ноды, компы.
R>А вот с базой непонятно. Если структура меняется так, что старая версия приложения не может работать с новой, то как делают?

R>вариант у меня, но всё равно какойто сложный
R>1. Делаем кластер из баз и репликацию между базами.
R>2. Отрубаем несколько нод из кластера, накатываем на них все изменения
R>3. Включаем новую версию базы, отрубаем старые версии и дальше накатываем
R>4. Накатываем на новые версии базы скрипт по переносу данных которые произошли на старой версии базы, пока делали пункт 2

R>Кто с таким сталкивался?

Если реактор после отказа автоматики мгновенно взлетает на воздух — то это явно плохой реактор, а отказать может любая автоматика, даже самая надёжная. Вывод — реактор нужно проектировать так, что бы он какое-то время мог работать "на автопилоте", пока например управляющий компьютер перезагрузится. Если оно так спроектировано, то обновлять можно прямо во время работы, соблюдая только временные сроки.

P.S. Если используется например система тройного резервирования(т.е. используется протокол голосования), то тогда вообще проблем нет: поочерёдно обновляем по на компьютерах и всё.