Clickhouse. Оптимизация таблицы в кластере не работает должным образом

У меня кластер 2x2 v19.15.2.2 с реплицированной многораздельной таблицей.

select * from system.parts 

=> some_part_0_0_1, some_part_0_0_2 and etc.

показывает мне отдельные части.

Док сообщает, что во время вызова optimize все части будут объединены , но после вызова такого запроса

// current settings on each node 
optimize_throw_if_noop = 1 
replication_alter_partitions_sync = 2 

optimize table my_table on cluster my_cluster partition my_partition final

Он просто генерирует еще одну часть, а старые части не объединяются.

Что я делаю не так? Спасибо


sql database replication clickhouse ddl
person Mikhail Kutuzov    schedule 26.11.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

выберите * из system.parts ГДЕ активен

процесс слияния (инициированный optimize) объединяет несколько старых (активных) частей в новую активную часть. Старые части (объединенные) стали неактивными и будут удалены через 8 минут (защита 8 минут, потому что CH не использует fsync по причинам производительности).

person Denny Crane    schedule 26.11.2019
comment
Что делать, если одна из четырех реплик не работает? В нем говорится, что There are 2 unfinished hosts (1 of them are currently active), they are going to execute the query in background. Получит ли он текущий запрос, когда он будет запущен? Как я могу быть уверен? Спасибо. - person Mikhail Kutuzov; 27.11.2019
comment
Об этом сообщает распределенный DDL. Собственно запрос Optimize имеет смысл только у лидера таблицы. Вы кластер 2x2. Итак, у вас есть два лидера (по одному на каждый шард). Этот единственный живой лидер запланировал слияние в ZK, выполнил его сам и поместил метаинфо о недавно слитой части в ZK. Когда другая реплика в этом сегменте станет активной, она прочитает ZK и выполнит слияние или загрузит новую часть (это зависит от нескольких факторов, алгоритм довольно велик, чтобы объяснить это здесь). - person Denny Crane; 27.11.2019