параметри load_balancing задает правило как выбирать реплику при select. Но это больше про другие шарды. Из-за параметра prefer_localhost_replica = true, в своем шарде distributed будет всегда читать локально на своей ноде.

А можно ли разделить инстансы, так чтобы было 3 шарда, по 2 реплики на каждый, а запись и чтение шли всегда на определённые 3 пока они не упадут?

да я как раз убрал его

и max_parallel_replica 3 сделал по кол-ву серверов

либо на все либо на одну реплику я так понял

я вот одного только не догоню, я сделал репликейтед таблицы, поверх сделал дистрибьютед, при этом интернал репликейшн фолс у меня стоял, я заинсертил данные в дистрибьютед таблицу на 60 гиг ... и они все засинкались нормально никаких конфликтов не было

Если у меня distributed над replicated и внутренняя репликации, то данные пишутся в 3 шарда, потом в фоне реплицируются в другие 3.
Мне бы хотелось иметь повторяемые результаты select до момента репликации

все у вас будет, как я понимаю

Так нет

Репликация асинхронная, а чтение идёт с реплики, которую кх сам выбирает

по умолчанию вроде prefer_local_replica

что то такое

Я так и не понял, как она работает на шардах не инициаторах. Может тонкости какие?

Всем привет. Могу ли я соединить два состояния аггрегированых функций? Что-то подобное к groupUniqArrayState(state1, state2)

Вопрос по разрешению запросов, в документации сказанно:

Доступ к БД не связан с настройкой readonly. Невозможно дать полный доступ к одной БД и readonly к другой.

Можно ли как то это обойти? Планируется ли расширить функционал раздела <allow_databases>?
Версия ClickHouse: 19.15.3.6

распаллеливание работает только на таблицах с sample by

да, конечно, настроить load_balancing = In order и прописать реплики в нужном порядке в описании кластера.

у меня два географически разнесенных dc. Я называю линукс хосты таким образом, чтобы ходить в реплики в своем dc при load_balancing= Nearest hostname

да. Нету. Из-за дедупликации последних 100 блоков.

distributed посылает в реплику1, реплику2 и реплику3 одно и тоже
реплика1 вставляет и пишет в зукипер контрольную сумму блока.
реплика2 проверяет что блок уже есть в зукипере (в ста последних) и не вставляет и скачивает новый парт с реплика1
реплику3 проверяет что блок уже есть в зукипере (в ста последних) и не вставляет и скачивает новый парт с реплика1

т.о. мы получили оверхед по сети и цпу.

Раз в полгода приходят люди и жалуются на дубликаты из-за этого. Почему?
реплика2 выключена или потеряла сеть.
distributed посылает в реплику1, реплику2 и реплику3 одно и тоже
реплика1 вставляет и пишет в зукипер контрольную сумму блока.
реплика3 проверяет что блок уже есть в зукипере (в ста последних) и не вставляет и скачивает новый парт с реплика1
через минуту сеть восстановилась
реплика2 проверяет что блока нет в зукипере (в ста последних)  вставляет и скачивает новый парт с реплика1
рассылает вставленное на реплику1 и реплику3 через репликацию -- insert умножился на два

insert quorum

сложить плюсом
state1+state2