Спасибо!👍👍

Благодарю

Через https://github.com/vmihailenco/msgpack ?

Да. Спасибо, уже разобрался)

привет. есть ли какие-то плагины для jetbrains ide-шек со стабами под тарантул?

Народ  подскажите как конвертнуть бинарные данные в string

а в чём отличие бинарных данных от string?

а ведь точно, тип у них один

тупанул

привет, а какая ошибка и где будет если указал максимально memory 2 гб и место кончилось (что если на сервере еще 14 гб свободно?)

будет какой то fatal или что?

ексепшны при попытках записи

@rybakit рассказывает про расширенные возможности MessagePack

"В этой статье я не буду рассказывать, как устроен MessagePack или сравнивать его с аналогами: материалов на эту тему в Интернете предостаточно. Чего действительно не хватает, так это информации о расширенной системе типов MessagePack.

Я постараюсь объяснить и показать на примерах, что это такое и как с помощью дополнительных типов сделать сериализацию еще более эффективной."

https://habr.com/ru/company/mailru/blog/555748/

Решение было простое.

Дело в том, что сервер 2 и сервер 3 - это клонированный сервер 1. Полностью клон виртуальной машины, в которой разве что поменяли хостнейм и айпи руками. Настройки тарантула не поменяли.

Что это означает? что каждый из этих трёх тарантулов имел ОДИН И ТОТ ЖЕ box.info.server.uuid, и box.info.server.id. Неважно, что в реплику добавлялись разные ip — когда один инстанс тарантула коннектился  к другому по реплике, у него ехала крыша — он видел себя на том конце, и выдавал Incorrect value for option 'replication_source': duplicate connection to the same replica

Я это видел, но не понимал что делать - ip же разные.
В какой-то момент, после прочтения Server startup with replication, догадался сравнить box.info.server.uuid, и начал понимать, в чём дело. Ещё через некоторое время встал вопрос, как сбросить server.uuid и server.id. Помогло  удаление .snap, .xlog файлов. После этого server.uuid и server.id обновились на новые, и воспроизвелась ситуация #3 в статье, дупликация перестала существовать, репликация прошла успешно.

правда, перед этим было промежуточное решение с удалением .snap, .xlog файлов и сбросом replication_source в пустое значение (сервер сбросился, server.id везде стал =1).
После этого, возврат replication_source  в правильное значение, и отлуп - ид реплики и ид кластера, на которые смотрим, не совпадает с ид реплики и кластера, прописанные локально после сброса ид сервера.
Только после этого сделал удаление .snap, .xlog файлов, но при этом replication_source прописал, в отличие от самого первого раза.

тут ссылка на тест контейнеры неправильная

https://github.com/tarantool/cartridge-java/issues/98
Поправим

Коллеги, подскажите, тарантул ребутится постоянно и в логах такое:

May 11 14:26:27 server_ tarantoolctl[2137438]: double free or corruption (!prev)
May 11 14:26:27 server_ systemd[1]: Started Process Core Dump (PID 2138519/UID 0).
May 11 14:26:27 server_ systemd-coredump[2138520]: Removed old coredump core.tarantoolctl.989.f9d62641118e40a2aa9b3bd65c905688.2116759.1620737315000000.lz4.
May 11 14:26:29 server_ systemd-coredump[2138520]: Core file was truncated to 2147483648 bytes.
May 11 14:26:29 server_ systemd-coredump[2138520]: Process 2137438 (tarantoolctl) of user 989 dumped core.#012#012Stack trace of thread 2137438:#012#0  0x00007fb9695707ff n/a (n/a)
May 11 14:26:30 server_ systemd[1]: tarantool@instance.service: Main process exited, code=dumped, status=6/ABRT
May 11 14:26:30 server_ systemd[1]: tarantool@instance.service: Failed with result 'core-dump'.
May 11 14:26:30 server_ systemd[1]: systemd-coredump@591-2138519-0.service: Succeeded.

lua кончилась или другое?

ох нет