зачем тогда картридж, круд и тому подобное, просто напишите в доке что все идите в шард

А можно пояснить что вы хотели этой картинкой сказать?

То, что бакеты - это лишь отображение на какое-то физическое хранилище. И получилось так, что данные по 2м разным bucket_id лежат на одном сторадже.

не, вы видимо кейс не поняли. есть проблемы что иногда круд глючит и ищет/запиывает данные не там где нужно. это описано в issue. для того что бы попробовать исключить эту проблему не прибегая к jit.off я изучил доку и там написано что в opts для всех операций можно указать bucket_id. Я как обычный человек понимаю, что если у меня есть функция которая не глючит и считает бакет правильно, я могу его сам вычислять и сразу круду говорить куда идти, а не полагаться на него.  

Исключительно для проверки гипотезы я и попробовал сделать get и select с заранее не верным bucket. На мой взгляд в этой ситуации как раз таки данные и не должны были найтись, потому что в указанном бакете их нет.

по факту получается что он игнориуется и его роль вообще не понятна😏

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

т е вам должно помочь все равно

Бакет в vshard используется для того, чтобы верифицировать шард-получатель запроса

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

too long wal write от 0,5 до 3 секунд — это оч много. В норме их почти не должно быть. Обычно это не проблема долгой записи на диск, а того, что какой-то fiber на долго захватил тх (или эвентлуп тх долго “проворачивался”).

В наших кейсах прибивание носит спорный характер: в 90-й персентиль улучшается, но 99-й ухудшается, потому что шедуллер может на ядро, где исполняется тарантул, направить какой-нибудь другой процесс, и тарантул будет деградировать.

Если до прибивания процесса к ядрам таких too long wal не было, а после они появились, то есть вероятность, что вы столкнулись с этим эффектом.

В задачах low latency мы не прибивали процессы к ядрам, а выкручивали nice и ограничивали кол-во процессов тарантула на сервере, чтобы они не конкурировали друг с другом и ядром линукса.

При этом бакеты в разных стораджах

Если в сторадж придёт запрос с бакетом, который он не обслуживает, то запрос должен быть отмаршрутизирован заново, а роутер перевычислить маршрут

о как, то есть если круд глючит, то ему пофигу что ты ему заранее хочешь подсказать.... как-то не логично, от слова совсем

пойдет в тот сторадж где лежит бакет который ВЫ указали

не, там не про то вопрос

Так, а теперь начинаем с начала. В самом начале я показал что это не работает.

Насколько я помню, круд вообще не проверяет, есть ли бакет на сторадже. Он тупо на роутере зовет route, и на сторадже уже ничего не проверяет. Но я не знаю, чинили это или нет

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

Поиск идёт не в бакете а в сторадже где бакет находится

это неинтуитивно, но это так, да