AS
Офтоп конечно, а че кворум инсерт там никак не придумают?... Какая-то странная бага, очевидно же что нельзя комитить офсет в кафке если движок мерджтри не подтвердил запись
это не бага, особенность реализации)
Size: a a a
2020 December 23
R
это не бага, особенность реализации)
Выглядит как архитектурная бага, а может ты врёшь и там все нормально с этим )
AS
там этот плагин вообще до недавнего времени был не очень работоспособен, поэтому хорошо хоть так
хотите больших гарантий - пилите свое решение (как все и поступают)
хотите больших гарантий - пилите свое решение (как все и поступают)
DS
ну только если цель такую ставить
DS
тогда лучше сразу в ексель целиться
AS
Выглядит как архитектурная бага, а может ты врёшь и там все нормально с этим )
https://github.com/ClickHouse/ClickHouse/issues/5208 вот относительно недавний issue, в нём есть цитата из старой доки, что перед рестартом ноды нужны открепить вьюху и закончить потребление из кафки, чтобы не продолбать сообщения в буфере
в актуальной доке этого уже нет https://clickhouse.tech/docs/en/engines/table-engines/integrations/kafka/ но я бы всё равно потестил, прежде чем что то пилить
в актуальной доке этого уже нет https://clickhouse.tech/docs/en/engines/table-engines/integrations/kafka/ но я бы всё равно потестил, прежде чем что то пилить
ВК
Можете описать порядки величин?
- Сколько времени отсутствует репликация?
- Какая нагрузка? (RPS?) Какой средний размер транзакции (тапла)
- Какая загрузка CPU каждого из узлов (т.е. какой резерв на "догон" репликации)?
- "Повышенное" потребление — насколько? Сколько норма, сколько арена, сколько превышение?
- Сколько времени отсутствует репликация?
- Какая нагрузка? (RPS?) Какой средний размер транзакции (тапла)
- Какая загрузка CPU каждого из узлов (т.е. какой резерв на "догон" репликации)?
- "Повышенное" потребление — насколько? Сколько норма, сколько арена, сколько превышение?
сделал минимальный стенд на котором видно проблему.
1) пишем на одну ноду миллион записей
2) подключем к кластеру вторую
3) в процессе переливки wal вторая нода выжирает память
1) пишем на одну ноду миллион записей
2) подключем к кластеру вторую
3) в процессе переливки wal вторая нода выжирает память
ВК
Можете описать порядки величин?
- Сколько времени отсутствует репликация?
- Какая нагрузка? (RPS?) Какой средний размер транзакции (тапла)
- Какая загрузка CPU каждого из узлов (т.е. какой резерв на "догон" репликации)?
- "Повышенное" потребление — насколько? Сколько норма, сколько арена, сколько превышение?
- Сколько времени отсутствует репликация?
- Какая нагрузка? (RPS?) Какой средний размер транзакции (тапла)
- Какая загрузка CPU каждого из узлов (т.е. какой резерв на "догон" репликации)?
- "Повышенное" потребление — насколько? Сколько норма, сколько арена, сколько превышение?
ВК
Можете описать порядки величин?
- Сколько времени отсутствует репликация?
- Какая нагрузка? (RPS?) Какой средний размер транзакции (тапла)
- Какая загрузка CPU каждого из узлов (т.е. какой резерв на "догон" репликации)?
- "Повышенное" потребление — насколько? Сколько норма, сколько арена, сколько превышение?
- Сколько времени отсутствует репликация?
- Какая нагрузка? (RPS?) Какой средний размер транзакции (тапла)
- Какая загрузка CPU каждого из узлов (т.е. какой резерв на "догон" репликации)?
- "Повышенное" потребление — насколько? Сколько норма, сколько арена, сколько превышение?
R
Кажется тут не хватает самого главного,... собственно тайминг того что там "выжирается", на мастере и слейве
ВК
Кажется тут не хватает самого главного,... собственно тайминг того что там "выжирается", на мастере и слейве
добавил сюда вывод box.runtime.info().used
ВК
реально какая то дичь
похоже на это
https://github.com/tarantool/tarantool/issues/5536
https://github.com/tarantool/tarantool/issues/5536
R
ВК
да, в 2.1 нормально работает. Проблемы начинаются с v2.2 и до текущей v2.7