A
А есть ли безопасный метод пересоздания большой таблицы с изменением типа order by
Size: a a a
2021 March 18
DC
А есть ли безопасный метод пересоздания большой таблицы с изменением типа order by
нету
а безопасный в каком смысле? Без остановки инсертов?
а безопасный в каком смысле? Без остановки инсертов?
A
Возможно плохо искал.
К примеру создать новую таблицу и переместить данные из одной в другую, чтобы не резервировать место для перехода
К примеру создать новую таблицу и переместить данные из одной в другую, чтобы не резервировать место для перехода
КТ
Можете создать новую таблицу такую же как старую но с нужным order by
Потом таблицу с движком Merge которая будет смотреть в обе
Потом таблицу с движком Merge которая будет смотреть в обе
КТ
Потом таскать из старой в новую
DT
Возможно плохо искал.
К примеру создать новую таблицу и переместить данные из одной в другую, чтобы не резервировать место для перехода
К примеру создать новую таблицу и переместить данные из одной в другую, чтобы не резервировать место для перехода
Можно по партициям перекидывать, а что бы селекты видели все данные обернуть эти обе таблицы под Merge
A
Подскажите что делать если неожиданно, /var/lib/clickhouse/data/system/query_thread_log_2 эта таблица почти в террабайт размером стала?
A
файл*
A
безопасно ли будет его удалить?
DT
безопасно ли будет его удалить?
Да, TRUNCATE TABLE
DT
На самом деле стоит настроить retention
A
На самом деле стоит настроить retention
можете подсказать как лучше это сделать?
DT
можете подсказать как лучше это сделать?
Example for query_log. It drops partitions with data older than 14 days:
After that you need to restart ClickHouse and drop or rename the existing table system.query_log, then CH creates a new table with these settings.
rename table system.query_log to system.query_log__1;
Important part here is a daily partitioning PARTITION BY (event_date) and ttl_only_drop_parts=1. In this case ClickHouse drops whole partitions. Dropping of partitions is very easy operation for CPU / Disk I/O.
Usual TTL (without ttl_only_drop_parts=1) is heavy CPU / Disk I/O consuming operation which re-writes data parts without expired rows.
$ cat /etc/clickhouse-server/config.d/query_log_ttl.xml
<?xml version="1.0"?>
<yandex>
<query_log>
<database>system</database>
<table>query_log</table>
<engine>ENGINE = MergeTree PARTITION BY (event_date)
ORDER BY (event_time)
TTL event_date + 14 day DELETE
SETTINGS ttl_only_drop_parts=1
</engine>
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
</query_log>
</yandex>
After that you need to restart ClickHouse and drop or rename the existing table system.query_log, then CH creates a new table with these settings.
rename table system.query_log to system.query_log__1;
Important part here is a daily partitioning PARTITION BY (event_date) and ttl_only_drop_parts=1. In this case ClickHouse drops whole partitions. Dropping of partitions is very easy operation for CPU / Disk I/O.
Usual TTL (without ttl_only_drop_parts=1) is heavy CPU / Disk I/O consuming operation which re-writes data parts without expired rows.
DT
Это пример для обычной query_log
DT
но ее можно переделать на query_thread_log
A
Спасибо!
K
Example for query_log. It drops partitions with data older than 14 days:
After that you need to restart ClickHouse and drop or rename the existing table system.query_log, then CH creates a new table with these settings.
rename table system.query_log to system.query_log__1;
Important part here is a daily partitioning PARTITION BY (event_date) and ttl_only_drop_parts=1. In this case ClickHouse drops whole partitions. Dropping of partitions is very easy operation for CPU / Disk I/O.
Usual TTL (without ttl_only_drop_parts=1) is heavy CPU / Disk I/O consuming operation which re-writes data parts without expired rows.
$ cat /etc/clickhouse-server/config.d/query_log_ttl.xml
<?xml version="1.0"?>
<yandex>
<query_log>
<database>system</database>
<table>query_log</table>
<engine>ENGINE = MergeTree PARTITION BY (event_date)
ORDER BY (event_time)
TTL event_date + 14 day DELETE
SETTINGS ttl_only_drop_parts=1
</engine>
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
</query_log>
</yandex>
After that you need to restart ClickHouse and drop or rename the existing table system.query_log, then CH creates a new table with these settings.
rename table system.query_log to system.query_log__1;
Important part here is a daily partitioning PARTITION BY (event_date) and ttl_only_drop_parts=1. In this case ClickHouse drops whole partitions. Dropping of partitions is very easy operation for CPU / Disk I/O.
Usual TTL (without ttl_only_drop_parts=1) is heavy CPU / Disk I/O consuming operation which re-writes data parts without expired rows.
Подскажите, а ttl_only_prop_parts применимо для переноса между дисками?
D
Перенос между дисками и так на уровне партов вроде... Но это не точно
DT
Подскажите, а ttl_only_prop_parts применимо для переноса между дисками?
Интересный вопрос, но я думаю кх между дисками перемещает только целые парты.
K
Просто пробовали диск с3, отжирает много внешнего канала перманентно, как будто маленькими частями гоняет