вообщем так пока не победить
если делаю 1 докер без реплик, все норм

если делаю 2 докера с репликами мастер-реплика или мастер-мастер не важно на 2 серверах, сервера становятся read only и к ним не подключится

Replication_connect_quorum ?

Не подключиться в принципе, или только из Go клиента?

из го

это помоему для мастеров?

Т.е. тарантульная консоль и/или python клиент нормально подключаются, да?

йеп

Я хреново с докерами общаюсь. Можешь подготовить тест среду? Докерфайлы и башскрипт для запуска .
Я тогда на днях (скорее всего, в выходные) поковыряю.

если мастер-мастер и пытаюсь update  то вот такая тема

Can't modify data because this instance is in read-only mode. (0x7)

и вот не понимаю где копать)

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

Если "официальный" образ используется то я бы советовал отрубить entrypoint , чтобы то что там происходит не становилось неожиданностью

Добрый день. Подскажите пожалуйста, что может быть причиной постоянной (раз в 7 сек) ошибки «Incorrect value for option 'replication': duplicate connection with the same replica UUID», при том, что репликация не разрывается? Версия тарантула 2.6.2

https://github.com/tarantool/tarantool/issues/4668

поднимите у себя replication_connect_timeout и replication_timeout

временно

это воркэраунд этого тикета

через две минуты начинаем https://www.youtube.com/watch?v=nyWyIbSPKsQ

начали доклад про С++ коннектор

@a_lyapunov
а контейнер запроса в msgpack для iproto (заголовки , тело)   при каждом запросе строится целиком  как и  кодирование таплов ?  или шаблон какотой используется  в который вставляются данные

@a_lyapunov
мы просто в своем гошном используем еще хак     когда  в буферах для реквестов  уже лежат куски  которые закодированые,     остается только в начало такого буфера указать длину сообщения  предварительно в хвост буфера заэнкодить тело,   т.е.  происходит выигрыш в том что поля протокола iproto не кодируются на каждый запрос, а только на первый.   после этого такой буфер заливается в сеть и возвращается в пул  где его можно опять переиспользовать для следующего запроса

..

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

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