Приветствую. Вопрос такой: имеется кластер с круговой репликацией. Как правильно отправить запрос на drop partition в этом случае, учитывая что каждый шард имеет свой db_name?

не вижу ошибок в логе про это..

вопрос в чем?
DDDL раньше не работали, и надо было делать все вручную, сейчас работает и базу вычисляет сам (берет из defaultdatabbase).

а что тогда висит? Что за сообщения вы видите в логах про drop table ?

Не вижу в логе ошибок про дроп этой таблицы

Понятно. Похоже я упустил элемент default database при сетапе круговой репликации. Это должно быть имя базы первичной реплики для данного хоста?

>Таблицы такой нет, но походив по хостам вижу DROP TABLE ... , который висит 2 часа уже

это про что было? что вы видите?

эм. Как у вас вообще тогда хоть что-то работает?

Это я вижу в SHOW PROCESSLIST -
elapsed:              7568.768223177

грепайте лог по id (uuid) запроса / по имени таблицы

скорее всего только рестарт

короче, круговая репликация -- говнище нерабочее. Бегите от нее как от огня.

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

Если речь о default database в настройках шардинга, то с ними всё в порядке. Они имеются ввиду?

любой где elapsed:              7568.768223177

короче, круговая репликация -- говнище нерабочее. Бегите от нее как от огня.

вопрос в чем?
DDDL раньше не работал, и надо было делать все вручную, сейчас работает и базу вычисляет сам (берет из defaultdatabbase).

Добрый день,
после обновления КХ с 20.1 до 20.12.
Кластер 4 шарда по 2 реплики.
При большом количестве инсертов по 5к строк начинают накапливаться parts на реплика_1 шард_1 и на реплика_1 шард_2, будто не происходит merge или медленно.
на остальных репликах parts не накапливаются, конфигурации везде одинаковые.

<merge_tree>
<parts_to_throw_insert>6000</parts_to_throw_insert>
<parts_to_delay_insert>3000</parts_to_delay_insert>
<max_delay_to_insert>2</max_delay_to_insert>
</merge_tree>

До обновления проблем не было
Не могу понять куда смотреть((

запрос есть на всех серверах, везде под разным query_id
но про свой запрос нету ничего в логах ни одного хоста (

<merge_tree>
<parts_to_throw_insert>6000</parts_to_throw_insert>
<parts_to_delay_insert>3000</parts_to_delay_insert>
<max_delay_to_insert>2</max_delay_to_insert>
</merge_tree>

>реплика_1 шард_1

такое ощущение что вы говорите про Distributed таблицу -- т.е. проблема вообще не связана с MergeTree , с партами, с мержами, с parts_to_throw_insert

что вы имели в виду под "начинают накапливаться parts на реплика_1 шард_1" ? про .bin файлы?

вообще запрос начинается с коммента /* ddl_entry=query-0002931769 */ DROP TABLE ...
если погрепать по этому номеру, то на одном хосте есть ошибка

Mar  3 15:55:31 {тут host} 2021.03.03 15:55:31.151640 [ 2238 ] {75c3daed-5e1a-41ae-9409-55aba903a3fd} <Error> TCPHandler: Code: 159, e.displayText() = DB::Exception: Watching task {тут path}/query-0002931769 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 24 unfinished hosts (0 of them are currently active), they are going to execute the query in background, Stack trace:

SELECT database, table, count() AS cnt FROM system.parts GROUP BY database, table
┌─database─┬─table────────────┬──cnt─┐
│ gru      │ kposes_sh        │ 2413 │
│ gru      │ kadposes_sh      │ 1424 │

cnt - стремится к 6000, далее все инсерты отваливаются с ошибкой Too many patrs