что такое зукипер аутентификация? zk ACL ?

Всем привет!
Кто-нибудь работал с тз имеющими переход на зимнее\летнее время?
Сегодня в полночь был переход с 03:30 на 04:30, а кх считает по-прежнему.

DB_01 :) select toTimeZone(now(), 'Asia/Tehran')

┌─toTimeZone(now(), 'Asia/Tehran')─┐
│              2021-03-22 19:27:05 │
└──────────────────────────────────┘

DB_01 :) Bye.
[root@DB_01 preprocessed_configs]# date
Mon Mar 22 20:31:13 +0430 2021

Нет, это когда identity задается в конфиге Clickhouse в секции <zookeeper>. Ну и в самом зукипере настраивается как-то так - https://log-it.tech/2020/07/08/exclusive-sasl-on-zookeeper-connections/

DB_01 :) select toTimeZone(now(), 'Asia/Tehran')

┌─toTimeZone(now(), 'Asia/Tehran')─┐
│              2021-03-22 19:27:05 │
└──────────────────────────────────┘

DB_01 :) Bye.
[root@DB_01 preprocessed_configs]# date
Mon Mar 22 20:31:13 +0430 2021

это баг

Храните в интах с точностью до копеек либо до десятых целых копеек
Только придётся юниты отдельно хранить для валют
В целом децимал или инт решает все эти проблемы

identity в <zookeeper> это auth для проверки ACL

Видимо, все мои проблемы в неправильной настройке зукипера. Может у кого-то есть примеры настроек кластера zookeeper с аутентификацией, чтобы clickhouse работал?

Кого тут тегать, чтобы банили за спам?

ну можно и самому для начала репортнуть

никого, мы сами удалим спам, eventually == maybenever

О, спасибо! Почитаю.

Похоже, что в общем случае серия форсированных (с некоторой периодичностью) OPTIMIZE FINAL не гарантируют обнуления значений для column TTL столбцов ReplicatedMergeTree таблицы, у которых этот column TTL просрочен.
Выражение для column TTL: toDate(end_datetime) + toIntervalDay(1) , где end_datetime - DateTime событий.
Таблица партиционирована как toYYYYMMDD(end_datetime).
Версия 20.10.7.4

Я у себя сейчас на партишне 20210320 этот эффект воспроизвёл.
В этом партишне у всех событий toDate(end_datetime)='2021-03-20', поэтому предполагалось, что для всех событий столбцы с column TTL "toDate(end_datetime) + toIntervalDay(1) " должны были обнулиться.

OPTIMIZE FINAL все 18 партов этого партишна сейчас объединяет в один, и уже видно, что .bin файлы для  column TTL столбцов вполне себе не нулевые.
Я внутри партов полазил - и вижу, что во многих из этих партов есть записи, где значение column TTL столбцов не сброшены, но на диске в файле ttl.txt  для этих столбцов стоят нули.
Видимо при слияниях с помощью OPTIMIZE кликхаус отталкивается от содержимого данного файла, и поэтому в новый парт попадают не обнулившиеся значения.

В чём особенность записей, у которых column TTL в ходе предыдущих мерджей не сбросился?
Все эти записи пришли с опозданием.
end_datetime у них 20е число, а в другом поле, wdt, (которое инициализируется как DEFAULT now() при загрузке в ClickHouse) везде сегодняшний или вчерашний день

На рисунке выше - результаты запроса в разрезе партов партишна 20210322.
SELECT _part, min(toDate(end_datetime)+toIntervalDay(1)) AS ttl_expression, count() as total_events, countIf(edt_ms!=0) as nonzero_edt_ms, round(100*nonzero_edt_ms/total_events, 1) as percents_nonzero_edt_ms, minIf(wdt, toYear(wdt)=2021 AND now()-wdt>3600) AS min_wdt, maxIf(wdt, toYear(wdt)=2021 AND now()-wdt>3600) AS max_wdt FROM lbsdb2_r1.all_events_v01d WHERE toYYYYMMDD(end_datetime)=20210320 GROUP BY _part ORDER BY _part;

Поля таблицы:
   end_datetime DateTime DEFAULT 0 CODEC(Delta(4), ZSTD(1)),
...
  edt_ms Int16 DEFAULT 0 TTL toDate(end_datetime) + toIntervalDay(1),
  wdt DateTime DEFAULT now() CODEC(Delta(4), ZSTD(1)) TTL toDate(end_datetime) + toIntervalDay(1),
...
PARTITION BY toYYYYMMDD(end_datetime)
ORDER BY (msisdn, end_datetime)
TTL (toDate(end_datetime) + toIntervalMonth(4)) + toIntervalDay(1)
SETTINGS min_rows_for_wide_part = 4194304, ttl_only_drop_parts = 1, index_granularity = 8192 │

И если я не запутался, то мораль сей басни в том, что для инициирования принудительного сбрасывания значений просроченных column TTL столбцов, надо использовать прямо предназначающийся для этого MATERIALIZE TTL (IN PARTITION ...)  а не идти обходными путями через OPTIMIZE FINAL (PARTITION ...)

запускайте c optimize_throw_if_noop=1 -- увидите ошибку

Так она же успешно запустилась - сейчас не было ошибки, в PROCESSLIST  передо мной висит

она?