D
Сорри я думал вопрос про то как это делать в кх. Про flyway - кто нибудь другой поможет.
Size: a a a
2020 September 27
G
Сами можем создать, отдельно скрипт который будет копировать данные на все узлы
D
Gleb
Сами можем создать, отдельно скрипт который будет копировать данные на все узлы
Ну лучше создавать через on cluster. Но можно как у вас то же
G
Сорри я думал вопрос про то как это делать в кх. Про flyway - кто нибудь другой поможет.
Те
если я руками создам таблицу одноимённую, on cluster, то она будет содержать все копии данных на каждом узле кластера?
И путём подмены объекта решу задачу
если я руками создам таблицу одноимённую, on cluster, то она будет содержать все копии данных на каждом узле кластера?
И путём подмены объекта решу задачу
D
А стоп
D
Данные сами копируются
D
Надо использовать replicatedmergetree
D
Gleb
Те
если я руками создам таблицу одноимённую, on cluster, то она будет содержать все копии данных на каждом узле кластера?
И путём подмены объекта решу задачу
если я руками создам таблицу одноимённую, on cluster, то она будет содержать все копии данных на каждом узле кластера?
И путём подмены объекта решу задачу
Руками создаете таблицу типа replicatedmergetree on cluster.
После вставки в любую реплику, данные будут на всех автоматически
После вставки в любую реплику, данные будут на всех автоматически
G
С какими опциями, что бы данные на всех узлах копировались?
И как заставить по умолчанию использовать этот тип таблиц а не tinylog
И как заставить по умолчанию использовать этот тип таблиц а не tinylog
G
Если это можно
G
Руками создаете таблицу типа replicatedmergetree on cluster.
После вставки в любую реплику, данные будут на всех автоматически
После вставки в любую реплику, данные будут на всех автоматически
Спасибо, видимо только руками решается
G
И как заставить по умолчанию использовать этот тип таблиц а не tinylog?
D
Gleb
И как заставить по умолчанию использовать этот тип таблиц а не tinylog?
Ковыряйте flyway
pk
наверно можно попробовать завести кластер в котором все нужные машины будут репликами друг друга, но это может неожиданно как-то работать.
может завести distributed табличку, а данные хранить в одном месте? зачем вообще эту историю в кликхаусе хранить?
может завести distributed табличку, а данные хранить в одном месте? зачем вообще эту историю в кликхаусе хранить?
G
Задача именно в использовании этой flyaway. История нужна самой утилите.
G
наверно можно попробовать завести кластер в котором все нужные машины будут репликами друг друга, но это может неожиданно как-то работать.
может завести distributed табличку, а данные хранить в одном месте? зачем вообще эту историю в кликхаусе хранить?
может завести distributed табличку, а данные хранить в одном месте? зачем вообще эту историю в кликхаусе хранить?
У клика есть возможность использовать по умолчанию мерджетрии а не tinylog?
G
Вариант с дистрибьютед тоже хороший.
Думал такой использовать, но это все отдельными скриптами надо делать.
Думал такой использовать, но это все отдельными скриптами надо делать.
G
Вот если бы можно в конфиг клика поменять шаблон по умолчанию использовать replicatedmergetree то это решило бы многие вопросы не только с flyaway
s
Господа, борюсь с
Запрос при перезапуске выдаёт разные результаты
Я предполагаю что это из-за
Наверняка это известная проблема, подскажите решение плиз
left outer join в версии 19.9.4Запрос при перезапуске выдаёт разные результаты
Я предполагаю что это из-за
left outer join, но .. в теории может конечно и ещё из-за чего-то другогоНаверняка это известная проблема, подскажите решение плиз
AL
Всем привет
Кликхаус постоянно увеличивает потребление памяти, уже 16 gb мало.
Данных накопилось за несколько лет.
Какие есть варианты замедлить рост потребления?
Вижу такие:
1. Ограничить. Как?
2. Удалить партиции старше года. Старые данные влияют на потребление?
3. Смириться, дать столько памяти сколько просит, но попытаться уменьшить объем входящих данных.
Везде replicated merge tree.
Кликхаус постоянно увеличивает потребление памяти, уже 16 gb мало.
Данных накопилось за несколько лет.
Какие есть варианты замедлить рост потребления?
Вижу такие:
1. Ограничить. Как?
2. Удалить партиции старше года. Старые данные влияют на потребление?
3. Смириться, дать столько памяти сколько просит, но попытаться уменьшить объем входящих данных.
Везде replicated merge tree.