IE
@Mjolkhare будем опенсорсить "суперконнектор" для гошки?
он ужасен, надо его сначала переписать :))
Size: a a a
2020 October 08
KN
@Mjolkhare будем опенсорсить "суперконнектор" для гошки?
давайте сделаем кластерный суперконнектор
KN
Да, я читал их код. МНе не нравится, что информация о кластере будет храниться в двух местах — на роутерах кластера и в клиентах-коннекторах
она хранится в одном месте. на клиент она передается во время подключения, и там не страшно если она разъедется
IE
мы делали в го сначала коннектор под 1.5, потом уже под 1.10, для простоты они были сделаны одинаковыми, без использования возможностей клиента 1.10
AK
она хранится в одном месте. на клиент она передается во время подключения, и там не страшно если она разъедется
Не только в этом проблема, что разъедется, а в том что логика по распределению запросов будет дублироваться
KN
Не только в этом проблема, что разъедется, а в том что логика по распределению запросов будет дублироваться
только небольшая часть
KN
расчет хэша и направление на нужный узел
AK
Ну это пока у нас умной балансировки нет на роутерах например
AK
Мне кажется там больше кусок
KN
что такое умная балансировка?
AK
использование статистики для распределения запросов на чтение между репликами в разных физических серверах
KN
этого мы делать не будем
KN
в обозримом будущем так точно
KN
ну и на клиентах тебя это никто не заставляет делать
AT
Раньше так делал net.box. До версии 1.10. Это приводило к тому, что когда по сети выполнялся package.reload, это приводило к ddl, изменению версии схемы и тихому ретраю запроса. В итоге инстанс мог релоадиться по 5-10 раз подряд. (Спасибо ещё, что прекращалось).
Вообще на любую политику ретраев, даже на селекты, можно придумать пользовательский сценарий, где это стрельнёт. Поэтому неуправляемые ретраи это зло и подводные мины.
Правильный подход — указывать политику с самим запросом. Причём стоит учитывать тот факт, что если от вас запрос вылетел, то он мог быть исполнен на базе, а ошибка вам могла дойти в искажённом виде.
Вообще на любую политику ретраев, даже на селекты, можно придумать пользовательский сценарий, где это стрельнёт. Поэтому неуправляемые ретраи это зло и подводные мины.
Правильный подход — указывать политику с самим запросом. Причём стоит учитывать тот факт, что если от вас запрос вылетел, то он мог быть исполнен на базе, а ошибка вам могла дойти в искажённом виде.
Проверка schema id идет до выполнения запроса (по крайней мере, сейчас). Надо бы найти, что именно менялось.
v
давайте сделаем кластерный суперконнектор
Если будет консул или etcd, у меня уже есть поддержка
KN
Если будет консул или etcd, у меня уже есть поддержка
будет
A
Инженер после 10 лет на Erlang перешел на Tarantool https://t.me/bit_10/14
v
Инженер после 10 лет на Erlang перешел на Tarantool https://t.me/bit_10/14
странноватое сравнение конечно. но имеет право на жизнь.
MF
а что странно?