11016
Обсуждаем ClickHouse
если реплика была долго оффлайн то она помечается как is_lost
и тогда тупо с остальных реплик данные тащит...
если не долго, то тащит только новое (там длинна очереди репликации 1000 по умолчанию)...
не очень понятно что вы имеется ввиду под "нельзя посмотреть на реплике"
там при старте просто идет загрузка primary.idx в память для текущих данных...
таблица будет в readonly пока не синкнется...
Всем привет, вопрос вот такой. Когда реплика находится в режиме восстановления( выключали на тех работы ) то в этот момент посмотреть что либо на реплике не удается, так же в момент "проигрывания" утерянных записей за время, начинает копиться новый лаг - текущий. То есть реплика восстанавливает данные за время выключения, и так же лаг появляется на текущие данные - это нормальное поведение репликации или диск не вывозит ?
Читать полностью…
Я правильно понимаю, что в момент запуска команды BACKUP DATABASE ClickHouse фиксирует состав данных которые будет бэкапировать и любые изменения этих данных в процессе выполнения не войдут в бэкап?
Читать полностью…
жесть какая... зачем вам это нужно?
зачем вам "реплиуируемые таблицы" которые не реплицируются?
я бы вообще uuid макрос отменил
его придмали и вставили в репликацию в полной уверенности что так можно всякие Rename и Excahgne быстро делать атомарно в Replicated таблицах для Atomic
так мне это и нужно, вопрос не в этом
вот я задаю путь /clickhouse/tables/{uuid}/{shard} on cluster '{cluster}'
я ожидаю что uuid при выполнении запроса будет разным на каждом шарде, а фиг, одинаковый, а вот шард разный
Ну так это, по факту, вопрос настройки шарда)
Обычно таки таблицы создаются соответственно макросу shard
Но при желании да, можно или кластер создать с одним шардом , или ручками шард проставить в пути зк. Но это скорее исключение же
вопрос, может кто знает
почему макрос {shard} при создании таблицы разолвится на каждом шарде, а uuid резолвится на инициаторе?
не могу найти это в документации
ReplicatedMergeTree вполне себе способен реплицировать данные между шардами и делает это, очень удобно когда нужно делать global join. таким образом можно маленькие таблицы копировать на каждый сервер и делать локальный джоин вместо глобального
Читать полностью…
/ме смеется на мобильном интернете (4G на два деления)
Читать полностью…
35 терабайтов ещё понятно, но 35 гигов это же вообще ни о чем
Читать полностью…
Вообще , кстати в бэкапе лежат не голые парты?
Я попытался выкачать из бэкапа папки с партами, закинуть в detached и приаттачить к таблице .
Там во многих папках не хватает файлов, кликхаус ругается
Это формат кликхаус бэкапа немного другой или таки битый бэкап у меня?
ЗЫ, не похоже, что битый, ведь RESTORE без ON CLUSTER нормально отрабатывает
Ну, кстати , нет, конкретно этот не пробовал и не проверял
Читать полностью…
ПО моему опыту - нормальное. Сначала реплика разгребает старый лаг, и в это время копится новый. Потом разгребет и его
Читать полностью…
{uuid} это не автогенерация, это ид таблицы, ясно почему оно одинаковое
Читать полностью…
{uuid} резолвится по другому... и нигде не определен
{shard} вообще в <macros> потому что определен... и там опять нет никаких шардов
потому что тупо на каждом сервере читается и резолвится в рантайме...
uuid макрос помогает при восстановлении из бекапа
но опять же вопрос не в этом, меня просто интересует как найти в документации почему макросы работают по-разному, один выполняется на инициаторе, второй на шарде
т.е макрос, как конструкция, работает по-разному, хотя по сути это должен быть string.replace для любой строки
вот я ищу в документации почему это не так
потому что иначе у вас таблицы с одним именем будут смотреть в разные пути в ZK
и никакой репликации не будет
тут должна быть эмоция палец вверх, мне недоступна
Читать полностью…
я бы перефразировал, ReplicatedMergeTree НИЧЕГО не знает про шарды, единственное место где используются шарды это когда {shard} макрос задан внутри replication_path в параметрах таблицы и тогда получается что реплики из разных шардов смотрят в разные пути ZK поэтому данные из разных шадров не реплицируются между собой
Читать полностью…
Может человек на медленном коннекте. Всякое бывает.
Читать полностью…
В общем мой совет - создать полную копию старого кластера и туда восстановить бекап чтобы исключить любые догадки о работе бекапа в целом
Читать полностью…
Кстати вы этот бекап ранее пробовали восстанавливать ? Там с бекапом все ок ? Данные в нем полные с двух шардов ?
Читать полностью…
мне - да, вполне
есть еще резервный кластер с таким же конфигом
само собой шард и его реплика в разных дц, межнконтинетальный сценарий не предусмотрен
терраформ скрипт сам переподнимает ноды и сетапит новые