D
Да вот я к этому это и написал. Попробую просто грохнуть wal пока
это во что выставлено в таблице? min_bytes_for_compact_part
Size: a a a
2021 March 20
A
это во что выставлено в таблице? min_bytes_for_compact_part
да глобально где-то мегабайт в 5
A
у нас много мелких частых вставок и куча таблиц, поэтому и решил их задействовать
A
Бинго
A
Дело было именно в этом
A
Грохнул wal и упало уже на другой таблице
A
Всем спасибо за подсказки
D
заведите тикет, это ненормально
A
Это уж точно
D
инмем парт всего лишь парт и он пишется в ЗК, на старте КХ должен прочесть из ВАЛа и пересоздать парты в памяти... то что у вас явно баг
A
Ну он походу их пересоздает, игнорит при наличии force_restore_data, а на следующий запуск WAL снова проигрывается и по новой
D
не, я так понял он делает сравнение с ЗК ещё перед тем как создает их из ВАЛа... хотя это все гадание, сделайте тикет, там наверняка чтото простое
DC
Подскажите, как лучше поступить при оптимизации запроса.
Имеется запрос который на уровне событий собирает данные о пользователе, такие как: изначальные идентификаторы и текущий идентификатор.
Запрос сильно упирается в оперативу.
Первые idшники берутся как anyIf()с проверкой на пустые id
Текущий как anyLastIf() c проверкой на дефолтный id
Имеется запрос который на уровне событий собирает данные о пользователе, такие как: изначальные идентификаторы и текущий идентификатор.
Запрос сильно упирается в оперативу.
Первые idшники берутся как anyIf()с проверкой на пустые id
Текущий как anyLastIf() c проверкой на дефолтный id
чудес не бывает, надо же все session_id "помнить" и копить их стейт
если индекс подходит то optimize aggregate in order = 1
если индекс подходит то optimize aggregate in order = 1
DC
Ну да, я терминейтнул под для воспроизведения ошибки. Связанных с ZK ошибок в логах не вижу. При этом, перед перезапуском записи в таблицу не было, в каждой партиции по парту и сейчас с force_restore_data они же и остались. Откуда КХ может взять инфу о партах?
вообще это все выглядит как нормальное поведение, из-за выключенного fsync
КХ не ожидает что кеш линукса потеряется (по дефолту).
вам надо все fsync включить по одному
КХ не ожидает что кеш линукса потеряется (по дефолту).
вам надо все fsync включить по одному
A
вообще это все выглядит как нормальное поведение, из-за выключенного fsync
КХ не ожидает что кеш линукса потеряется (по дефолту).
вам надо все fsync включить по одному
КХ не ожидает что кеш линукса потеряется (по дефолту).
вам надо все fsync включить по одному
Даже при штатном завершении кх?
DC
Даже при штатном завершении кх?
если при штатном то наверное баг, кто-то забыл может fsync сделать
A
если при штатном то наверное баг, кто-то забыл может fsync сделать
Ну вот, значит заброшу тикет
DC
ну и я бы проверял все параметры по одному
min_rows_to_fsync_after_merge
min_compressed_bytes_to_fsync_after_merge
min_compressed_bytes_to_fsync_after_fetch
fsync_after_insert
fsync_part_directory
write_ahead_log_bytes_to_fsync
write_ahead_log_interval_ms_to_fsync
in_memory_parts_insert_sync
min_rows_to_fsync_after_merge
min_compressed_bytes_to_fsync_after_merge
min_compressed_bytes_to_fsync_after_fetch
fsync_after_insert
fsync_part_directory
write_ahead_log_bytes_to_fsync
write_ahead_log_interval_ms_to_fsync
in_memory_parts_insert_sync
А
Здравствуйте! Подскажите пожалуйста, как правильно посмотреть - используется ли индекс при запросе? Я делаю explain ast select ...
DC
Здравствуйте! Подскажите пожалуйста, как правильно посмотреть - используется ли индекс при запросе? Я делаю explain ast select ...
set force_primary_key=1;
запрос кинет ошибку если индекс не используется
запрос кинет ошибку если индекс не используется