В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

pro.kafka

1586 membersпожаловаться на группу
2020 January 15

VB

Vladimir Bukhtoyarov in pro.kafka
Max Underwood
0.10.0.0 и 1.0.0 но compact я и менял на delete
вопрос был не про то что обычные топики не чистятся, а про то что в __consumer_offsets старые сегменты не удаляются. Для топика __consumer_offsets менять retention.policy на delete мягко говоря опасно
источник
21:16пожаловаться#1

HK

Huan Karlos in pro.kafka
Vik Gamov
Confluent-server?
да. это по сути та же кафка?
источник
21:16пожаловаться#2

MU

Max Underwood in pro.kafka
Alex
с учётом что без доп манипуляций не можешь сказать какие топики на какие брокеры-диски уйдут, то странно звучат заявления
“так можно контролировать сколько будет использовать выделенного диска и никогда не получить проблему с его нехваткой”
Мы используем все брокеры и кол реплик равное количеству брокеров. Это Ваше утверждение звучит странно. Я конечно не исключаю варианта где кол репликацией меньше количества брокеров но зачем это делать? Если кластер большой разве что. Тут да. Мой подход неоднозначный
источник
21:17пожаловаться#3

A

Alex in pro.kafka
У вас кластер на топик?
источник
21:18пожаловаться#4

A

Alex in pro.kafka
Если на кластере пару десятков топиков, то тут все становится веселее
источник
21:18пожаловаться#5

MU

Max Underwood in pro.kafka
Нет. Все топики кроме офсетов на трёх брокерам. Для офсетов отдельные три штуки
источник
21:19пожаловаться#6

MU

Max Underwood in pro.kafka
Ничего не веселей. У нас более десяти точно
источник
21:19пожаловаться#7

A

Alex in pro.kafka
Ну и да, 3-4 реплики достаточно, а кластера далеко не по 3-4 машинки
источник
21:19пожаловаться#8

MU

Max Underwood in pro.kafka
Не хочу обсуждать особенности этого выбора, но Ваш комментарий про мое "странное" заявление был неуметным
источник
21:21пожаловаться#9

A

Alex in pro.kafka
Кластер на 10 машинок,
Топик 3 реплики, 5 партиций
10 топиков

Без ручных манипуляций я не берусь ставить как партиции разъедутся по брокерам
источник
21:21пожаловаться#10

A

Alex in pro.kafka
А если у разных топиков ещё и ретеншен разный, то и объём диска сьеденого на каждом из брокеров тем более
источник
21:22пожаловаться#11

MU

Max Underwood in pro.kafka
А вот без ручной манипуляции лидеры будут распределенны неравномерно. Нагрузка не будет распределённая по кластеру ровно
источник
21:23пожаловаться#12

MU

Max Underwood in pro.kafka
Зачем тогда сколько нужно?
источник
21:24пожаловаться#13

MU

Max Underwood in pro.kafka
Брокеров. Если лидеры будут на паре нод
источник
21:24пожаловаться#14

MU

Max Underwood in pro.kafka
Распределение лидеров рассчитывает наш скрипт во время создания топика
источник
21:25пожаловаться#15

MU

Max Underwood in pro.kafka
Что бы не лезть к брокерам офсетов
источник
21:25пожаловаться#16

A

Alex in pro.kafka
Я говорю не про лидеров а про расположение всех реплик
источник
21:25пожаловаться#17

MU

Max Underwood in pro.kafka
Работают на чтение и запись только лидеры
источник
21:26пожаловаться#18

MU

Max Underwood in pro.kafka
Остальное standby
источник
21:26пожаловаться#19

A

Alex in pro.kafka
Реплики точно так же пишут на диск, в моем примере задача как разместить

3*5*10=50 партиции по 10 машинкам

Гарантий что они разместятся без перекосов никто не даст

Причём разные партиции разный объем имеют
источник
21:27пожаловаться#20