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

Ты в реальной жизни такое видел?
Ну и, конечно, а чем это мешает ситуации с монолитом?

Так мгновенно в мире ничего не случается. Обычно ведь как делается:

1. Бд просят сделать флаш на диск и приостановить запись
2. Снимают снапшот
3. Снапшот отгоняют на целевую машину
4. То же самое что в п1.
5. Снимают инкрементальный снапшот между текущим состоянием и снапшотом из п.2
6. То же самое что в п3.

Фактически, мы тут ограничены полосой между машинами

Ну, тут я вижу проблемы:
1) приостановить запись. Это довольно сложно, это нужно дождаться всех транзакций (или какие-то принудительно прервать)
2) снять снэпшот. На современных fs это довольно быстро
3) а вот тут для терабайтной БД он уже совсем не быстро.
5) инкрементный снэпшот может оказаться не тривиальной задачей, вообще говоря. И не маленьким

По сути это ничем не отличается от асинхронной репликации между БД (даже хуже по скорости).
Но делать переключение active-standby на каждую выкладку для БД - довольно грустная операция.
Потому обычно так при выкладке без простоя и не делают

Видел. В prepaid платформе от comverse. Каждая стойка - независимый юнит и обслуживает свой диапазон номеров. В стойке пара p-series в кластере под oracle и пачка нод для процессинга.

Если все внутри одного СХД, то шаг 3, конечно, гораздо проще.
Но все равно нужно остановить БД и поднять новую (и это не про стандартный active-standby), это дорогая штука.

Ну, тут тоже не одна нода на один шард, тут у тебя два узла БД и пачка нод сверху. Это - другое решение, не про "один шард на один инстанс"

(И нафига столько железа только на prepaid-ы, ну да ладно....)

со скоростью снятия снепшотов у zfs проблем нет
"A snapshot is a read-only copy of a file system or volume. Snapshots can be created almost instantly, and they initially consume no additional disk space within the pool. "
Правда скорость восстановления из снепшота вроде точно такая же как и везде. Тем не менее единственное применение фич zfs для БД читал только у ситимобила, но они ее юзают, чтобы данные с прода для автотестов забирать
https://habr.com/ru/company/citymobil/blog/492172/

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

хм. Пишут, что "полное создание снапшота с остановкой и запуском реплики занимает до 40 секунд, развёртывание из снапшота нового экземпляра MySQL занимает до 20 секунд."

Ну я и говорю, что медленно для blue-green

Так а почему для терабайтной бд уже совсем не быстро?

И почему инкрементальный снапшот может быть нетривиален? Фактически, нам надо сравнить 2 дерера Меркла. А благодаря этому двигаясь вниз по дереву и найдя 2 одинаковых хеша вглубь можно не идти.

Ну, тебе надо перегнать 1TB между двумя СХД. Это не мгновенно совсем. Если один общий СХД - то попроще, да.

Так это полное. Я ж говорил, что в 2 этапа.

в смысле через инкрементальное через zfs send?

Ты делаешь инкрементальный бэкап на уровне хранилища, а не БД. Нужно удостоверится, что для БД подобные операции не опасны.
По идее, при интеграции БД и FS, можно было бы делать гораздо проще и быстрее, но увы.

3 минуты паре 40г

Угу. Сначала полный(и он может быть долгим, а потом инкрементальный)

А тут нужно смотреть, сколько займет сумма изменений.
Ну и я все равно не вижу, а чем это лучше просто реплики и копирования реплики as is
(ну, разве что встроенные средства реплик в opensource баз данных плохо поддерживают возврат с stanby на active)