Различия

Показаны различия между двумя версиями страницы.

--- linux:kafka [2024/04/15 03:27]
admin
+++ linux:kafka [2024/05/10 05:57] (текущий)
admin
@@ Строка 225: / Строка 225: @@
 bin/kafka-topics.sh --bootstrap-server localhost:9092 --command-config config/credentials.conf --list
 bin/kafka-topics.sh --bootstrap-server localhost:9092 --command-config config/credentials.conf --describe --topic "myTopic"
+</code>
-	# Перебалансировка
-bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --command-config config/credentials.conf --reassignment-json-file rebalance.json --execute
-	# Сам файл для перебалансировки
-{"version":1,
- "partitions":[
-     {"topic":"__consumer_offsets","partition":4,"replicas":[2,0,1]}
-]}
-</code>
@@ Строка 285: / Строка 276: @@
  --alter --topic "myFirstTopic" --delete-config retention.ms
 </code>
+</details>
+<details>
+<summary>:!: Ручная балансировка</summary>
+Файл для перебалансировки
+<code json>
+{"version":1,
+ "partitions":[
+     {"topic":"__consumer_offsets","partition":4,"replicas":[2,0,1]},
+     {"topic":"__consumer_offsets","partition":5,"replicas":[2,0,1]},
+     {"topic":"__consumer_offsets","partition":6,"replicas":[2,0,1]}
+]}
+</code>
+<code bash>
+    # Применение изменений
+bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --command-config config/credentials.conf --reassignment-json-file rebalance.json --execute
+   # Еще требуется тригернуть непосредственно миграцию лидеров в соответствии с приоритетами
+bin/kafka-leader-election.sh --bootstrap-server localhost:9092 --admin.config config/auth_ssl.properties --election-type preferred --all-topic-partitions
+# Либо это произойдет автоматом при включенном параметре "auto.leader.rebalance.enable=false"
+</code>
+Есть еще вроде как перебалансировка в утилите kafkactl\\
+но тут что то непонятно, фактически это работа с фактором репликации, который побочно влияет на распределение\\
+нормально распределить удалось только снизив кол-во до единицы и снова подняв до 3х\\
+<code bash>
+kafkactl alter topic brain-finres-events-test --replication-factor 3
+</code>
 </details>
@@ Строка 356: / Строка 380: @@
 current-context: default
 </code>
+Еще пример
+<code bash>
+contexts:
+  default:
+    brokers:
+      - bootstrap-kafka1:9092
+      - bootstrap-kafka2:9092
+    sasl:
+      enabled: true
+      mechanism: scram-sha512
+      password:
+      username: admin
+    tls:
+      enabled: true
+      insecure: true
+current-context: default
+</code>
 Некоторые команды
@@ Строка 381: / Строка 426: @@
 	# Describe group
 kafkactl describe consumer-group test_app
+  # Смена контекста из конфига
+kafkactl config use-context my_other_contx
 </code>
 </details>
@@ Строка 483: / Строка 532: @@
 </code>
 </details>
+==== Epoch ====
+==== Overs ====
+В Кафке по умолчанию вычитывание сообщений из партиции останавливается, когда получатель доходит до битого сообщения, и до тех пор, пока оно не будет пропущено и закинуто в “карантинную” очередь (также именуемой “dead letter queue”) для последующей обработки, чтение партиции продолжить не получится.
+ZooKeeper при подключении нового читателя производит перераспределение участников в Consumer Group таким образом, чтобы каждая партиция имела одного и только одного читателя
+==== Параметры ====
+=== ? Параметры потребителей ? ===
+**max.poll.records**\\
+По умолчанию 500, максимальное кол-во записей, возвращаемых одним вызовом **poll()**\\
+Изменение вроде не сильно влияет, потребитель кэширует записи и постепенно возвращает оттуда\\
+**max.poll.interval.ms**\\
+По умолчанию 5мин, макс задержка между вызовами **poll()**. т.е. время в течении которого потребитель может бездействовать, если метод **poll()** не вызывался в течении этого времени то клиент считается отвалилшимся и консьюмер группа начинает перебалансировку\\
+<details>
+<summary>:!: Быстродействие потребителя</summary>
+Два выше рассмотренных свойства задают требования к приложению клиента, оно должно потреблять "max.poll.records" за "max.poll.interval.ms"\\
+Увеличение "max.poll.records" может снижить пропускную способность изза роста накладных расходов\\
+Увеличение "max.poll.interval.ms" может замедлить скорость отклика при перебалансировке потребителей\\
+</details>
+**fetch.max.bytes**\\
+Дефолт 50мб, макс размер пакета запрашиваемого консьюмером во время чтения. Концептуально связан с "request.timeout.ms"\\
+**request.timeout.ms**\\
+Таймаут, за который консьюмер ожидает запрошенные данные от брокера\\
+**group.instance.id**\\
+Что то связано со статическими потребителями, и отвал статического будет по истечении **session.timeout.ms**\\
+==== CLI ====
+=== Topics ===
+<details>
+<summary>:!: Расширенный вывод (desribe)</summary>
+По мимо всего прочего, показано 3 столбца:\\
+**Leader**\\
+Указан брокер где находится лидер-партиция. Кафка равномерно распределяет лидеров между досутпными брокерами\\
+Вроде вручную это не регулируется\\
+**Replicas**\\
+Указаны брокеры которые реплицируют данные партиции, вне зависимости от лидерства\\
+Первый идентификатор представляет предпочтительного лидера, поэтому кафка попытается сделать его лидером партиции\\
+:!: В случае отвала брокера, резервный лидер партиции выбирается именно из этого столбца, проверено практикой, надежно\\
+**Isr**\\
+Означает синхронизированную реплику.\\
+Сообщения шлются в лидера, затем если есть репли-фактор то фоловеры копируют новые сообщения себе, вычитывают.\\
+Брокер считает засинхронизирован если не сильно отстает (Replica.lag.time.max.ms)\\
+Здесь что то тоже упоминается про приоритет выбора, может это про контроллер ? (пока один раз сошлось, хотя нет)\\
+</details>
+====  ====
+====  ====
+====  ====
+====  ====
+<details>
+<summary>:!: </summary>
+</details>

zxcx

Инструменты пользователя

Инструменты сайта

Различия

Инструменты страницы