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

DI>Так и я про члены кластера. Твоя архитектура не учитывает, что в кластере из чудесных высоконадежных компонентов, может пропадать связь между компонентами.
Мы всё ещё про failover cluster? В нём как раз всё учтено.
Если речь про failover clusters, из которых построена sharded — система, то ей наплевать на пропадание связи между компонентами. Как мы вроде бы выяснили.

DI>Но ты так и продемонстрировал архитектуры. Я тебе вполне конкретно возразил, ты отправил меня в книгу (что выглядит как слив), в книге причем я не помню подтверждения твоих слов
Ну ок, давайте по пунктам.
2. Что делать, когда нагрузка превышает пропускную способность ноды.
Это тот же самый п.1 — перевозим часть шардов на соседние / новые ноды, вплоть до выравнивания нагрузки.
3. Что делать, если популярность Джастина выросла — переселяем его на отдельную ноду.
3.1. Что делать, если популярность Джастина упала — подселяем его обратно на ноду с низкой нагрузкой. Переселяем нового кумира. Называется это dynamic sharding.

Вопрос со звёздочкой: Как организовать переезд без даунтайма.
Шаг 1: Начинаем репликацию данных с ноды X на ноду Y
Шаг 2: Переключаем Master для нашего шарда с ноды X на ноду Y, указывая ноду X в качестве fallback при чтении данных. То есть нода Y знает, что если что-то не найдено, надо форварднуть реквест на ноду X.
Шаг 3: Дожидаемся окончания репликации
Шаг 4: Отключаем fallback, удаляем шард с ноды X.

На шагах 2 и 3 может потребоваться ожидание консенсуса. Алгоритмы для этого есть.

DI>>>Я правда недоумеваю, зачем бороться с ветряными мельницами, ну устроен мир вот так — везде компромисы. Обратного так никто из борящихся так и не показал
S>>Мир — да, именно так и устроен. А в CAP никаких компромиссов нет. За это мы её и не любим.

DI>Это демагогия — выражение "все в мире компромисы" не верно, так как бескомпромисно.
Ну так это же ваше утверждение. Вы уже определитесь, за вы или против.