+1

но писать в этом случае нужно в конечную реплику а не в дистрибьютед (как собственно и нужно делать)?

Можно в дистрибьютед, можно сразу в любую из реплик. Прочтите доку

До можете и в дистрибьютед, которая будет смотреть на определенные реплики шардов.

всё, я понял, надо дистрибьютед направить туда, куда мне надо и делать их столько сколько мне надо
и можно перед ними ставить что угодно для приёма запросов либо ничего не ставить вовсе

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

но вот например одна реплика умерла, именно та, куда я смотрю по вашей схеме, как читать тогда? а если указать шард то таблица поймёт откуда брать. Или я что-то не понимаю

подскажите как понять почему ClickHouse падает? Раз в час может перезагружаться.

Из запрещенного MV с join с огромной таблицей и тысячи вставок в нее в секунду.

Версия 20.4.4.18
В error.log ничего очевидного

спасибо, я читал, интересует именно вопрос распределения запросов по нашим требованиям, чтобы никто не пострадал от падения из-за непродуманных селектов, например

С шардами ещё хуже будет, шард это набор уникальной информации. Когда вы обращаетесь к кластеру с двумя шардами, то запрашивается информация из каждого шарда и складывается. Если вы имеете ввиду независимых кластера два, то другой момент, но тогда как уже сказали, вы придумали свою репликацию. В той схеме что я предпложил, вы можете сделать дистрибьютед, которая смотрит на все реплики. Если одна из них не доступна, то она на время будет исключаться из запросов. Для тех аналитиков что вынесены отдельно - не страшно возможно и подождать поднятия или повторить запрос к другой дистрибьютед.

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

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

Так звучит лучше.

больше спасибо за помощь и наведение на путь истинный

осталось решить как это за фейловерить

У меня x3 реплики на каждый шард, пишем в две реплики каждого шарда. Сапорт и тяжелые запросы к 3ей реплики. А сервисная статистика для клиентов уже со всех читать может.

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

а шардов несколько и там разные данные ?

да, у нас средний объем данных, всё в один жирно будет.

Если у вас, к примеру 100 Тб данных, то с одним шардом каждый должен будет у себять иметь эти 100 Тб. А потом ещё вдруг рейд умер и переливать их всех)