я когда то руками написал шардинг на мастер мастере ,   и ребалансировщик автоматический и  rw   без остановки вообще...  но там принципиально другая схема шардирования ,   там данные сразу отпартиционированы

что значит сразу отпартицированы? Т.е. данные распределяются согласно некой функции?

примерно как в эластике

не знаю как в эластике)))

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

для  упрощения операций - каждая партиция - отдельный спейс ,   по сути  спейсы целиком переезжают с одного хоста на другой ... все хосты с точки зрения  tnt всегда rw

рядом стоит etcd  и рулит куда кому ходить и куда кому переезжать

маппинг партиция => хост в нем же хранится?

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

etcd посути только для того чтобы все договорились о том что хост либо есть, либо  его нет ... а самое распределеине статическое ... чтототипа как guava работает  только гораздо лучше

Все на lua. Есть некоторая функция, согласно которой мы раскидываем данные на хосты - шарды. Допустим их 3 штуки. Они реплицируют данные на 3 штуки слейвов, которые работают согласно своей настройке. Клиент вызывая шард функцию, знает куда надо писать/читать делает r/w только в мастер (для чего это отдельная история).
Дальше
Нужно добавить с схему новый сервер, меняется настройка слейва и применяется. Что происходит?
1. 3 Мастера начали сливать данные на новые сервера (допустим их уже 4) согласно конфигу слейвов
2. Слейв становится неадекватный, потому что один и тот же пользователь оказывается на разных хостах
3. Зачищаем полностью слейвы (стираем данные) далее, запускаем функцию синхронизации, одновременно идет репликация. Эти процессы идут одновременно и разруливаются приоритетом, чтобы устаревшие данные не затерли новые.
4. Слейвы работаю по новой схеме и полностью адекватны
5. Меняем роли. Слейв становится мастеров, а мастер слейвом
все. Ни секунды остановки

Нет одного роутера, их много, все разруливается конфигами на lua. Достаточно просто рестартануть все проекты на инстансах

На самом деле все сложнее, но если по простому, идея такая

Но вы не можете прицепить одну реплику к трем разным мастерам по репликации.

Также вам на всех роутерах нужно понять, что мастеров стало 4 вместо 3, и не сроутить случайно запрос в старый мастер.

Либо у вас есть логика в приложении/роутере, которая делает ретраи в новые мастера, когда видит, что схема изменилась

На всех роутерах в момент смены роли применяется новые настройки, просто этот процесс занимает доли секунды.

Соотв отпадает необходимость ставить инстансы в состояние read

не бывает никакой одновременности ...

Ну, тогда кажется, что при нагрузке 1к рпс на роутер вы можете словить неожиданный запрос в старую схему

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

тот кто то этого был мастером должен явно всех отваживать к нему ходить

тут скорость применения конфига даже не сильно важна, могут быть грязные чтения, но нет грязных записей