Спасибо, Вы мне очень помогли.
Одно с другим не может быть связанно (Сарказм).

Есть продукт, у продукта выходят патчи/обновления.
Иммутабельность и IAC предполагает, что никто своими кривыми руками не лезет обновлять систему, а выполняется проход по сценариям, полностью повторяющему каждый ранее выполненный шаг.
И вот ягодка кроется в том, как обеспечить работоспособность продукта, когда вся эта котовасия происходит.

И перестаньте людям хамить, пожалуйста

Никак. Большинство обновлений баз предполагают обновление каталога и бинарников самой СУБД, поэтому процесс придётся остановить.

Единственный вариант - это делать полное зеркало и балансером трафик уводить на ДРУГОЙ кластер, совершенно независимый. После этого мучительно переносить бэкапы обратно.

Я знаю где так сделано 🙂 В принципе работает, но схема сложная

Спасибо, Мить 😉
Тут всё ещё хуже, выходит, когда тоже самое нужно придумать и для етл))
Вот так, просто, из нежелания работать и доверять коллегам, девопс готов спустить 50к$ ещё на сервера. Молчу, сколько стоит работа...)

Ну это утопия. 50к$ вы не отделаетесь, это будет гораздо дороже, в выхлопа от этого ноль.

Учитывая время обновления вертики той же, проще просто временно останавливать потоки. При достаточной мощности и кафка, и найфай, и всё что угодно другое может временно аккумулировать в себе больше данных, которые потом влетят в СУБД

У нас процесс обновления занимает сейчас не больше часа, при том что он ручной

Если его автоматизировать через ансибл - то ваще будет минут 15-20.

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

Я не совсем понял, речь идет об обновлении версии своего решения или об обновлении мажорных версий самой СУБД?
В первом случае обычно нет проблем реализовать обновление без простоя вообще.
Во втором - зависит от конкретной СУБД, конечно.

Вы же выше писали, что первый кейс только на груви решается или я не правильно вас понял?

Оба кейса много на чем решаются. Ансибл - не удачный инструмент для сколь-нибудь сложных сценариев обновления.

Да, я уже понял вашу позицию

Любой случай обновления бинарей базы требует остановки процесса субд.

В некоторых архитектурах и при небольших объемах можно выкрутиться, но в основном - нет. Даже если storage и compute разделены, потребуется почти полное дублирование compute и все равно разрывы в работе на переключение или переход в RO режим

Хм, мы, опять-таки, о чем говорим, о смене мажорной версии СУБД?
Или о своем коде? Для своих решений нет необходимости обновлять ядро СУБД, там обновление без простоя делается достаточно просто (и в любом приличном финтехе это делают).
Если о ядре СУБД, то там тоже есть варианты, например один из основных причин использовать Oracle RAC в настоящее время - это именно плавное обновление версии СУБД.
Но можно и через Active-standby, там переключение без потери можно сделать, при нормальной реализации клиентских приложений.
Все останавливать - нет необходимости.
Впрочем, это все принципиально для OLTP, для OLAP простой в несколько часов часто считается несущественным, там проще все остановить, конечно.

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

Интересно, расскажете где не получилось?

Нормальное обновление без останова сложной системы - это итеративный многостадийны процесс с кучей сценариев вида:
"развернуть сервис версии n+1, настроить меш по переводу на него тестовых пользователей, прогнать тесты на тестовых пользователях, проверить логи, запросить у админа разрешение продолжить, настроить меш на перевод 1% пользователей, подождать час, проверить логи, запросить у админа разрешения продолжить, перевести 10% пользователей, подождать день" и т.п.
Плюс еще параллельные миграции (в том числе долгосрочные), совместимость разных сервисов, переключения фичафлагов по факту окончания выкладки и так далее.
Рулить этим из ансибла (который сделан в идеологии "привести целевые сервера в соответствие с описанным декларативно идеалом") очень неудобно (хотя, конечно, реально  - но очень не выгодно).
Впрочем, удобных инструментов для сложной выкладки на рынке нет. Что-то можно сделать на грэдле, что-то можно сделать груви-сценариями в Jenkins (с кучей плагинов), но удобной платформы - нет.
Основные проблемы - это "долгосрочные операции" (подождать час, а потом анализировать статистику), событийные модули (а если сработал алерт на прометеусе - откатить выкладку), взаимодействие с оператором (после 10% пользователей такая-то статистика - продолжать или нет).