что такое "Выставляем" ?

+ во первых нахрена все это, чем insert_deduplicate=0 не угодил?

+ во вторых это обложено тестами, поэтому я как-то не вижу как это могло сломаться незаметно для санитаров

1) выставляем = либо указываем в общем серверном конфиге
<merge_tree>
       <replicated_deduplication_window_seconds>600</replicated_deduplication_window_seconds>
   </merge_tree>
либо непосредственно при создании таблицы передаем SETTINGS replicated_deduplication_window_seconds=60
2) тем, что дедупликация может быть полезна, например чтобы быстрый ретрай при обрыве соединения с одной из реплик действительно не сделал двойную вставку
3) простите, какая разница обложено это тестами или нет, вот есть наблюдаемое явление - блоки дедуплицируются даже через десятки периодов чистки. Есть версии, как это может происходить и какие настройки еще можно проверить?

ну выставите в replicated_deduplication_window_seconds=1
и протестируйте. сломаться может всЁ

Как правильно пользоваться remoteSecure? Усли я делаю нечто вроде SELECT * FROM remoteSecure(...), то возвращает 0 строчек и Ok., хотя на самом сервер данные эти есть. Каким образом туда сертификат передать?

Там в сообщении написано, что мы выставляли небольшие значения до 60 секунд, не пропадают блоки из ZK. И дедупликация продолжает работать.

проверил при replicated_deduplication_window_seconds=1 переданном прямо при создании таблицы в SETTINGS. Эффект тот же, дедупликация продолжает работать

да, действительно странно работает, какой-то баг неочевидный

cleanup_delay_period  какой?

Т.е. вы это воспроизвели?

system.merge_tree_settings прямо сейчас говорит cleanup_delay_period                                       │ 30

я так понимаю пол-минуты

причем непонятно как это не ловится

integration/test_extreme_deduplication

там вообще

   <merge_tree>
       <replicated_deduplication_window>999999999</replicated_deduplication_window>
       <replicated_deduplication_window_seconds>1</replicated_deduplication_window_seconds>
       <cleanup_delay_period>1</cleanup_delay_period>
       <cleanup_delay_period_random_add>0</cleanup_delay_period_random_add>
       <old_parts_lifetime>1</old_parts_lifetime>
   </merge_tree>

может в приоритете количество сохраненных блоков а не время?

не, в доке это очень явно прописано

доку-то я писал, уже не помню почему там так написано

:)

у меня случайно вставляется =) иногда да, иногда нет...

replicated_deduplication_window_seconds
Similar to "replicated_deduplication_window", but determines old blocks by their lifetime. Hash of an inserted block will be deleted (and the block will not be deduplicated after) if it outside of one "window". You can set very big replicated_deduplication_window to avoid duplicating INSERTs during that period of time.

очистка раз в 30 сек. это понятно

cleanup_delay_period │ 30    │       0 │ Period to clean old queue logs, blocks hashes and parts. │ UInt64