То есть replicas_status 200 на самом деле не гарантирует актуальность реплики? А есть что-то, что гарантирует?)

реплики всегда отстают, т.е. скорость света конечна, поэтому в любой момент времени есть вероятность что в другую реплику уже вставили, а мы еще не знаем

подскажите, а есть ли какой-то способ конвертировать результат SELECT в словарь, без source(executable(command 'clickhouse-client...')))?

create view aa as select

source aa

А как тогда можно защититься от случайных альтеров в отстающие реплики? В плане, именно на отстающую таблицу.

Добрый день! Есть ли аналог функции quantile, где можно указать «разрешение» (чтобы уменьшить размер стейта)?

Опять же надо понимать что мы говорим не об отстающем сервере, а об отстающей таблице на сервере, 1 таблица может отставать и статус будет не 200, а в остальные таблицы будут вполне рабочими. Так что надо понять сколько секунд можно отставать для конкретной таблицы

то есть можно прямо view использовать в качестве source?

ну так отставание задайте например 30 сек.

да

спасибо, попробую

quantileTDigest ?

Вот если остальные таблицы рабочие - как можно это понять? Выяснять допустимый лаг для каждой выглядит не очень эффективным выходом.
Для контекста: выполняю последовательность операций (создание-заливка-проверка-свап-удаление) над одной replcated таблицей, размазанной по куче шардов, реплик по две штуки на шард. Нужно, чтобы если одна реплика легла/мигнула/долго лежала и восстала в середине процесса я не поломала репликацию внезапным альтером на восстанавливающуюся таблицу и не поломала свой процесс, делая запросы к отстающим репликам.
Была информация, что replicas_status мне это обеспечивает, но, видимо, это не так? Есть ли надежный способ обезопасить себя от сюрпризов в условиях отсутвия транзакций?

ну absolute_delay в replicas показывает насколько отстает текущая реплика. Но если сервер лежит то это не узнать.

вместо свапа таблиц, может делать свап/replace партиций ?

https://gist.github.com/den-crane/521975b5333c5dc7059bed4030f62f94

Проверку живости делаю, на мертвый хост запросы кидать не буду. Но актуальность проверять хочется тоже.
Для партиционированных таблиц как раз replace partition, да. Для непартиционированных двойной rename через дополнительную tmp таблицу. Не стала расписывать потому что вроде не очень релевантно к теме)

Все равно нарваться на отстающую можно почти на каждом этапе

на синтаксис в виде create dictionary ... source aa.. он ругается expected source, из документации пока не понял какой тип для view  чтобы задать source(...)

А absolute_delay показывает только релевантное отставание (идет репликация, ждет выполнения ON CLUSTER и всякое такое) или там еще что-то внутреннее может быть, что не нужно ждать?
В плане, могу ли я ориентировать на супер-низкий absolute_delay для таблицы или я никогда не дождусь момента для записи при таком подходе?

>>Для партиционированных таблиц как раз replace partition, да.
>> Для непартиционированных двойной rename через дополнительную tmp таблицу.

почему ?  что такое непартиционированные таблицы? таких не бывает. У них партиция одна и называется tuple()

ну aa это имя таблицы

SOURCE(CLICKHOUSE(HOST 'localhost' PORT 9000 TABLE aaaa DB 'default' USER 'default'))