@floxard  неа

:) alter table __migration attach all;

Syntax error: failed at position 32 ('all'):

alter table __migration attach all;

Expected one of: PARTITION, PART

:) alter table __migration attach PART all;

Syntax error: failed at position 37 ('all'):

не

partition

не part

alter table __migration attach PARTITION all;

и в скобки

alter table __migration attach PARTITION 'all';

и ещё ID

alter table __migration attach PARTITION ID 'all';

Получилось! Огромное спасибо!

Есть ли опыт использования этого скрипта со старой mysql, например 5.6? При попытке запустить producer-а ошибка:
ImportError: cannot import name 'charset_to_encoding' from 'pymysql.charset'.

Пробовал разные версии pymysql, для версии 0.9.3 эта ошибка исчезает, но возникает:
pymysql.err.InternalError: (1236, "Client requested master to start replication from position > file size; the first event 'log-bin.000001' at 6601356, the last event read from './log-bin.000001' at 4, the last byte read from './log-bin.000001' at 4.")

Моя гипотеза - скрипт не тестировали со старыми версиями mysql.

Огромный + в карму @floxard  за помощь =)

добрый день. Подскажите, дата саентисты хотят доставать данные из кликхауса без условий почти select * from table с ограничением по датам, но это все равно сотни тысяч событий (хотят делать так раз в сутки). Насколько я понимаю - так делать, как минимум плохо, как подобные запросы будут влиять на производительность?

добавьте +реплику и пускай они ходят туда, а нормальный прод на остальные реплики
и пускай её хоть изнасилуют ;)

ну и как минимум попартиционироваться тогда по датам

что вероятно вы уже

елси сотни тысяч строк раз в сутки, то это реально мало
никак это не повлияет

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

+1 партицирование по toYYYYMMDD или по toYYYYMM как минимум должно быть в таблице