Так это дофига.
Обычно нужно успеть за 3-5 секунд все переключение при выкладке, иначе пользователь видит сбой.

А реально в OLTP только погасить входящий поток - будет требовать больше времени.

Это только полный снапшот.

Ок, но на погашение все равно дофига времени уйдет...

Вон, для не сильно нагруженного ситимобила - 40 секунд...

ну у zfs довольно продвинутая схема работы со снепшотами и их инкрементами из коробки, так что она в этом плане действительно хороша, но базу действительно еще запустить же надо
С другой стороны, я недавно апдейтRDS инстансов делал и чтобы апгрейднуть мастер надо было фейловер сделать, который занимает секунд 10-30. В принципе на мониторинге даже не отразилось особо. Но у меня далеко не финтех. Юзеры могут просто страничку обновить, если запрос не пройдет :)

Базу сначала остановить надо, это еще хуже

Ну, если юзеры могут "страничку обновить" - то это уже не выкладка без простоя, это вообще другие сценарии нужны

нуу при всей некритичности тем не менее 20-30 секунд это примерно предел в который хотелось бы уложиться, потому что юзеров очень много

благо аврора у амазона довольно стабильно работает и переключается тожебодро

Зачем?

А если не сделаешь, то у тебя снэпшот чего будет? Транзакций в середине? При подъеме БД они откатятся, это не то, что ты хочешь )

Именно. Фактически, всё что СУБД должна уметь - это ручку pause/unpause.

Снапшот снимается миллисекунды.

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

Потому связь логики снэпшота с БД была бы гораздо лучше, но увы (

Добрый день. Что думаете об этом курсе?
https://skillbox.ru/course/software-architect/?utm_source=telegram&utm_medium=groups&utm_campaign=475_software-architect_telegram_groups_post_course_all_remoteit_ardens&utm_content=2021-07-09

Просмотрел оглавление, знаком со всеми пунктами.

почитал я эту живую дискуссию - для себя прихожу к выводу, что микросервисы (если их создавать с адекватной гранулярностью, не дробить по каждому чиху) в современных реалиях (когда может внезапно понадобиться отмасштабировать продукт) выглядят хорошим решением. Хотя и есть определенный оверхед для разработки, это да.

Ну, для сеньор-дева нормальный курс (по плану, ничего не знаю про состав лекций). Для архитектора - покрыто где-то процентов 30 от основных задач.
Страдает (как и все) поверхностью и однобокостью.

Это какую дискуссию?