N
а с распределенными таблицами не будет проблем в таком случае?
Size: a a a
2020 August 19
OM
Добрый день, я пытаюсь сбилдить Clickhouse для PowerPC, единственный "гайд", который я нашел, тут https://github.com/ClickHouse/ClickHouse/pull/4132 (комментарий dmkoltsov) . Есть что-то более официальное/актуальное?
N
Добрый день, я пытаюсь сбилдить Clickhouse для PowerPC, единственный "гайд", который я нашел, тут https://github.com/ClickHouse/ClickHouse/pull/4132 (комментарий dmkoltsov) . Есть что-то более официальное/актуальное?
а в докере нельзя запустить?
YV
Ну или может есть какие нибудь способы переезда в новый кластер всех данных?
Ну самый простой способ - INSERT INTO ... SELECT * FROM remote()...
A
все привет! подскажите плиз, получаю DB::Exception: Too many parts (393) ключ партиционирования
PARTITION BY user_id % 100. Данные вставляются с интервалом 5 минут по 400-600 user_id. Интересует, какой лимит на парты в течении часа? подозреваю что лимит может быть привышен за 10 инсертовПривет.
PARTITION BY должен быть таким, чтобы за все время жизни проекта, скажем, 10 лет, партишнов создалось не более нескольких сотен, максимум — тысяч штук. Иначе будет деградация скорости в тысячи раз. По умолчанию предлагается использовать что-то вроде PARTITION BY toYYYYMM(date_time_field). То есть на каждый месяц новый партишн. Если партов будет больше тысячи, то будет все тормозить.OM
а в докере нельзя запустить?
Это запасной вариант 🙂 , мы пытаемся понять насколько СH нам подходит, один из nice-haves это рабочий билд для PowerPC
N
Ну самый простой способ - INSERT INTO ... SELECT * FROM remote()...
тоже ничего 🙂 ведь цель мигрировать, а какими методами это другой вопрос) Спасибо
КТ
а потом переключить на новые зк?
нет
если нужны и новые ЗК тоже, то надо в существущий ЗК кластер добавить новых ЗК
а потом их оторвать когда запись уже будет переключена в новый кластер
если нужны и новые ЗК тоже, то надо в существущий ЗК кластер добавить новых ЗК
а потом их оторвать когда запись уже будет переключена в новый кластер
КТ
когда их оторвешь, они будут новые, но уже с данными старых ЗК
КТ
а с распределенными таблицами не будет проблем в таком случае?
нет
distributed таблицы читают список хостов из конфига из remote_servers секций
distributed таблицы читают список хостов из конфига из remote_servers секций
КТ
поэтому я и предложил новые сервера сразу туда не добавлять
N
нет
distributed таблицы читают список хостов из конфига из remote_servers секций
distributed таблицы читают список хостов из конфига из remote_servers секций
Спасибо за уточнение
КТ
можно ещё парты из shadow-копий потаскать, если как и с INSERT SELECT устраивает, что потом придется дотаскивать то что в кластер записали пока INSERT SELECT работал
КТ
говорим "alter table таблица freeze"
находим папочку shadow, в ней свежую папочку таблицы
находим папочку shadow, в ней свежую папочку таблицы
N
ENGINE = MergeTree в copier тоже не работает, жизнь боль
КТ
и потом "tar|nc"/rsync/другое, по вкусу
N
можно ещё парты из shadow-копий потаскать, если как и с INSERT SELECT устраивает, что потом придется дотаскивать то что в кластер записали пока INSERT SELECT работал
да я уже думаю о том, чтобы даунтайм сделать и просто синкануть файлы один в один в новый кластер
КТ
попробуй для начала одну таблицу через репликацию, звучит сложновато но раз сделаешь, потом легко
сам щас только так и делаю когда надо сервер например заменить целиком, или на хосты пожирнее целиком утащить шард
сам щас только так и делаю когда надо сервер например заменить целиком, или на хосты пожирнее целиком утащить шард
N
попробуй для начала одну таблицу через репликацию, звучит сложновато но раз сделаешь, потом легко
сам щас только так и делаю когда надо сервер например заменить целиком, или на хосты пожирнее целиком утащить шард
сам щас только так и делаю когда надо сервер например заменить целиком, или на хосты пожирнее целиком утащить шард
репликацию методом: новые ЗК тоже, то надо в существущий ЗК кластер добавить новых ЗК
а потом их оторвать когда запись уже будет переключена в новый кластер
а потом их оторвать когда запись уже будет переключена в новый кластер
КТ
ну если ЗК тоже будет новый отдельный то да
смотри вот есть у тебя... пускай будет для пример один зукипер сервер и один кх сервер. и ещё один новый сервер под зк и новый под кх
берешь в конфиге старого зк расширяешь его до 2-х серверов, новый зк с таким же конфигом, он встанет и данные со старого высосет
берешь новый кх сервер натравливаешь на новый зк уже
создаешь на новом все Replicated таблички (у тебя же они все Replicated, верно?)
ждешь пока по репликации доедут данные
удаляешь все таблички на старом сервере (предварительно подменив старый на новый в remote_servers если надо)
в конфиге нового зк убираешь старый зк
сжигаешь старые зк и кх
смотри вот есть у тебя... пускай будет для пример один зукипер сервер и один кх сервер. и ещё один новый сервер под зк и новый под кх
берешь в конфиге старого зк расширяешь его до 2-х серверов, новый зк с таким же конфигом, он встанет и данные со старого высосет
берешь новый кх сервер натравливаешь на новый зк уже
создаешь на новом все Replicated таблички (у тебя же они все Replicated, верно?)
ждешь пока по репликации доедут данные
удаляешь все таблички на старом сервере (предварительно подменив старый на новый в remote_servers если надо)
в конфиге нового зк убираешь старый зк
сжигаешь старые зк и кх