Представим себе апдейт ПО атомной станции или другого ПО 24/7 которое нельзя останавливать.
Как там делаеют апдейт если надо обновлять к примеру ПО + базу.
С ПО я еще могу понять, что по очереди обновляем ноды, компы.
А вот с базой непонятно. Если структура меняется так, что старая версия приложения не может работать с новой, то как делают?
вариант у меня, но всё равно какойто сложный
1. Делаем кластер из баз и репликацию между базами.
2. Отрубаем несколько нод из кластера, накатываем на них все изменения
3. Включаем новую версию базы, отрубаем старые версии и дальше накатываем
4. Накатываем на новые версии базы скрипт по переносу данных которые произошли на старой версии базы, пока делали пункт 2
Здравствуйте, Rikomer, Вы писали:
R>Кто с таким сталкивался?
Можно просто иметь несколько систем которые сперва обновляются полностью, а потом идёт переключение работы на них (hotswap). Таким образом, у тебя будет полная версия старой системы на которую можно откатиться и полностью обновлённая версия.
Здравствуйте, Rikomer, Вы писали:
R>Представим себе апдейт ПО атомной станции или другого ПО 24/7 которое нельзя останавливать.
Если атомная станция, то там критичное ПО такое, что его или можно патчить на ходу, или вообще не надо обновлять между циклами работы. А плановая остановка раз в пару лет вполне допустима.
А некритичное пусть себе хоть каждую ночь апдейтится.
R>Как там делаеют апдейт если надо обновлять к примеру ПО + базу. R>С ПО я еще могу понять, что по очереди обновляем ноды, компы.
Или сам софт позволяет обновляться на ходу.
Это позволяют, например: Erlang (есть полный набор штатных механизмов такого обновления), Python (функции и объявления классов обновляются сразу, для объектов на этих классах есть несколько решений разной степени велосипедности), Java (перегрузка классов с восстановлением из сериализованного), многие другие...
R>А вот с базой непонятно. Если структура меняется так, что старая версия приложения не может работать с новой, то как делают?
То просто так не делают должна быть совместимость по дороге, даже если план перехода потребует нескольких хитрых промежуточных этапов и удорожания работы при переходе (как обновлять несколько версий колонок одновременно).
R>вариант у меня, но всё равно какойто сложный R>1. Делаем кластер из баз и репликацию между базами. R>2. Отрубаем несколько нод из кластера, накатываем на них все изменения R>3. Включаем новую версию базы, отрубаем старые версии и дальше накатываем R>4. Накатываем на новые версии базы скрипт по переносу данных которые произошли на старой версии базы, пока делали пункт 2
Всё равно будут неконсистентные промежуточные состояния.
Надо обходиться без таких отрубаний.
Здравствуйте, Rikomer, Вы писали:
R>Представим себе апдейт ПО атомной станции или другого ПО 24/7 которое нельзя останавливать. R>Как там делаеют апдейт если надо обновлять к примеру ПО + базу. R>С ПО я еще могу понять, что по очереди обновляем ноды, компы. R>А вот с базой непонятно. Если структура меняется так, что старая версия приложения не может работать с новой, то как делают?
R>вариант у меня, но всё равно какойто сложный R>1. Делаем кластер из баз и репликацию между базами. R>2. Отрубаем несколько нод из кластера, накатываем на них все изменения R>3. Включаем новую версию базы, отрубаем старые версии и дальше накатываем R>4. Накатываем на новые версии базы скрипт по переносу данных которые произошли на старой версии базы, пока делали пункт 2
R>Кто с таким сталкивался?
Если реактор после отказа автоматики мгновенно взлетает на воздух — то это явно плохой реактор, а отказать может любая автоматика, даже самая надёжная. Вывод — реактор нужно проектировать так, что бы он какое-то время мог работать "на автопилоте", пока например управляющий компьютер перезагрузится. Если оно так спроектировано, то обновлять можно прямо во время работы, соблюдая только временные сроки.
P.S. Если используется например система тройного резервирования(т.е. используется протокол голосования), то тогда вообще проблем нет: поочерёдно обновляем по на компьютерах и всё.
Здравствуйте, Rikomer, Вы писали:
R>Представим себе апдейт ПО атомной станции или другого ПО 24/7 которое нельзя останавливать. R>Как там делаеют апдейт если надо обновлять к примеру ПО + базу.
А зачем на атомной станции база? От ответа на этот вопрос зависит, как там ее обновляют...
Здравствуйте, Qulac, Вы писали:
Q>Если реактор после отказа автоматики мгновенно взлетает на воздух — то это явно плохой реактор, а отказать может любая автоматика, даже самая надёжная. Вывод — реактор нужно проектировать так, что бы он какое-то время мог работать "на автопилоте", пока например управляющий компьютер перезагрузится. Если оно так спроектировано, то обновлять можно прямо во время работы, соблюдая только временные сроки.
На автопилоте он может вполне планово и безопасно уйти в такое состояние, из которого в рабочий режим его надо неделю переводить.
Здравствуйте, Rikomer, Вы писали:
R>Представим себе апдейт ПО атомной станции или другого ПО 24/7 которое нельзя останавливать. R>Как там делаеют апдейт если надо обновлять к примеру ПО + базу. R>С ПО я еще могу понять, что по очереди обновляем ноды, компы. R>А вот с базой непонятно. Если структура меняется так, что старая версия приложения не может работать с новой, то как делают?
R>вариант у меня, но всё равно какойто сложный R>1. Делаем кластер из баз и репликацию между базами. R>2. Отрубаем несколько нод из кластера, накатываем на них все изменения R>3. Включаем новую версию базы, отрубаем старые версии и дальше накатываем R>4. Накатываем на новые версии базы скрипт по переносу данных которые произошли на старой версии базы, пока делали пункт 2
R>Кто с таким сталкивался?
Обычно в работе основной комплект и есть резервный комплект. Если надо обновить — то основной комплект выводят из работы, включают резервный комплект в работу.
Основной комплект обновляют и переключают обратно. Так делают в энергетике, думаю на атомной станции также.
Про атомные станции не знаю, но вообще делается примерно так:
1. Обновляется софт, чтобы работал и со старой и с новой версией базы.
2. Обновляется база, добавляются новые поля и тд, старые не удаляются.
3. Мигрируются данные.
4. Обновляется софт, чтобы работал только с новой версией базы.
5. Обновляется база, удаляются старые поля.
В зависимости от характера изменений какие-то шаги можно пропускать.
Здравствуйте, Rikomer, Вы писали:
R> А вот с базой непонятно. Если структура меняется так, что старая версия приложения не может работать с новой, то как делают?
А зачем так делать? Расширяем структуру ДБ так, чтобы расширение не мешало старой версии. Обновляем. При необходимости онлайн удаляем старые поля, которые новая версия не трогает. И не забываем перенести/сконвертировать данные из удаляемых полей...
Как понимаешь, надо не просто понять как релизить, но и "готовить" софт+хард под этот процесс.
R>Кто с таким сталкивался?
Давал похожий вопрос при собесе релизеров.
R>Как там делаеют апдейт если надо обновлять к примеру ПО + базу. R>А вот с базой непонятно. Если структура меняется так, что старая версия приложения не может работать с новой, то как делают?
Коллективное бессознательное склонялось в основном к содержанию двух копий БД/приложений через балансер, против чего я особо не протестовал
Здравствуйте, Rikomer, Вы писали:
R>А вот с базой непонятно. Если структура меняется так, что старая версия приложения не может работать с новой, то как делают? R>Кто с таким сталкивался?
Два варианта:
1) Инкапсуляция на уровне БД. Структура базы делается новая, но сохраняется "старый интерфейс" путем создания вьюх и триггеров. Сначала обновляется база, потом софт. Проблема только если миграция в новую структуру занимает много времени.
2) "Читаем из старой, пишем в новую". Сначала обновляется структура базы. Код приложения изменяется так, чтобы операции чтения работали как со старой, так и с новой структурой, а запись шла только в новую. Обычно проще, чем первый вариант, но есть тенденция что такие "знания" в программе навсегда остаются и ведут к багам.
должна быть совместимость по дороге, даже если план перехода потребует нескольких хитрых промежуточных этапов и удорожания работы при переходе (как обновлять несколько версий колонок одновременно).
