все равно не становится понятнее.
кластер из 3х шардов с 2 репликами на каждом
Раскатываются скрипты liqubase с драйвером Клика. В урле профиля добавили socker_timeout=5m ( по умолчанию 30с , когда впервые ловили ошибку)
pзапрос висит 5 минут и валится с ошибкой
Падают запросы с code 159 Read timeout
В логах за указанное время падения ошибко и ерроров нет.
по метрикам никаких аномалий не видно.
Подскажите, куда копать. может кто сталкивался?
вы бы запрос хотя бы показали на котором зависает, но например у вас база не Atomic и крутится OPTIMIZE ON CLUSTER запрос, в это время вы пытаетесь делать в миграции другие ON CLUSTER операции, они будут ждать OPTIMIZE
да, закономерности от запросов не отслеживали. всегда ловили или на операциях ALTER или на INSERT/DELETE row/table на селектах не ловили. к примеру есть таблица, очень маленькая, в которой пара десятков строк. При попытке ее удалить ловили ошибку. delete table name on cluster name. ON CLUSER все запросы.
если, это так, как с этим бороться? или может есть бестпрактисы, чтоб такое не ловить?
так а какой тип базы данных у вас? может у вас другая проблема мы например раньше делали клиента который сам умеет ходить по шардам и все запросы параллельно выполнять на каждом, без использования ON CLUSTER. Сейчас с Atomic движком поидее такой проблемы не должно быть Ну и такой подход позволяет сильно ускорят ETL, когда на каждом шарде можно параллельно запускать insert select без использования distributed таблиц
если я правильно понял то восновном это MergeTree и Destributed таблицы
тип базы данных, а не таблиц select name, engine from system.databases
Atomic по умолчанию
Обсуждают сегодня