и еще там версия пакета metrics 0.7 а в гите уже 0.9 (а в rpm spec указано вообще 1.0)

Подскажите, как снести полностью картридж приложение с серверов(разворачивалось через ansible)?

я так делаю: стопаю все сервисы (systemctl stop myapp@*), сношу пакет (rpm —erase), удаляю файлы тарантула (/var/lib/tarantool/myapp* и /var/log/tarantool/myapp*). У вас пути могут быть другие, но идея такая

Добрый верчер, можно ли инстансам, создаваемым через cartridge_helpers.Cluster задать настройку сохранения логов?

можно в энв им просунуть TARANTOOL_LOG

Спасибо,  попробую

1.10 это LTS?

да

почему? т.е. в чем смысл использовать 1.10 вместо 2.x+?

Как и у любого другого LTSа

какие ключевые отличия 1.10 от 2.x?

В 2.х периодически выходят новые миноры, новые фичи. В 1.10 фич нет, только багофиксы

Добрый день, коллеги, после прочтения информации на сайте и части документации возникло несколько вопросов:
1. тарантул умеет в стрим данных из других sql баз, для mysql и postgresql коннекторы доступны в комьюнити эдишин, для оракла - только в иетрепрайз, верно?
2. Тарантул имеет реализацию коннектора к кафке, доступную в комьюнити эдишн?
3. В комьюнити эдишн доступны все инструменты для построения datagrid?

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

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

Почему-то для аналитики рекомендуют колоночные БД. Впрочем, похоже, что Альфа-Банк заменил свою аналитическую торговую систему с SQL на Тарантул.

ну, если аналитика олапная, то да, итоговое хранилище лучше из колоночных. а если оперативная - то ТДГ или аналог хорошо ложится

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

@dsharonov уточни пожалуйста, кроме каких именно деталей всё правильно?

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

ну например исходящий odbc коннектор в гриде есть, а в опенсорсе его нет (нужен для mssql, hive, vertica и т д)

про ссылку в доке не понял - если речь про опенсорс, то все доки - это ридми соответствующих коннекторов (мускуль и пг). но это именно коннекторы, cdc придется кодить самостоятельно.

А вот интересно, кто-то уже налабал коннектор для кликхауса под тарантул?

там же основной протокол для запросов - http, а в тарантуле есть http клиент