Problema cu ZooKeeper

De aproape zece ani, fiecare cluster Apache Kafka a necesitat un ansamblu Apache ZooKeeper separat pentru a gestiona metadatele: ce brokeri au fost activi, care broker a fost lider pentru ce partiție, subiect și metadate ACL. ZooKeeper este un sistem de coordonare distribuit robust și fiabil, dar a introdus o serie de probleme operaționale semnificative:

  • Complexitate operațională dublă: Fiecare echipă care gestionează Kafka a trebuit să gestioneze, de asemenea, un cluster ZooKeeper separat (de obicei 3 sau 5 noduri), cu propria sa monitorizare, ciclu de upgrade și configurație distinctă.
  • Scalabilitate limitată a metadatelor: ZooKeeper a arătat o degradare a performanței peste ~200.000 de partiții pe cluster, deoarece metadatele fiecărei partiții au fost scrise ca noduri ZooKeeper separate.
  • Alegerea lentă a controlorului: Când controlerul brokerului Kafka a căzut, noul controler a trebuit să citească întregul starea clusterului de la ZooKeeper înainte de a putea funcționa, un proces care ar putea dura zeci de secunde pentru clusterele mari.
  • Dificultate în recuperarea în caz de dezastru: recuperarea unui cluster Kafka în caz de pierdere a datelor pe ZooKeeper a fost un proces manual complex și riscant.

Cronologie KRaft

  • KIP-500 (2020): Propunere originală de a elimina ZooKeeper din Kafka
  • Kafka 2.8 (aprilie 2021): prima versiune cu KRaft în acces anticipat (doar pentru testare)
  • Kafka 3.3 (octombrie 2022): KRaft a fost declarat gata de producție pentru noi clustere
  • Kafka 3.5 (iunie 2023): instrument de migrare ZooKeeper la KRaft disponibil
  • Kafka 3.7 (martie 2024): modul ZooKeeper este depreciat
  • Kafka 4.0 (martie 2025): modul ZooKeeper a fost eliminat definitiv

Cum funcționează KRaft: Jurnalul de consens Raft

Conceptul jurnalului de metadate

Soluția adoptată în KRaft (Kafka Raft) este elegantă: în loc să depindă de un sistem extern pentru metadate, Kafka își gestionează metadatele ca a Subiect intern Kafka numit @metadata. Acest subiect este replicat printr-un protocol Raft între nodurile controlerului.

În KRaft, brokerii de cluster își asumă unul dintre cele două roluri (sau ambele, în grupuri mici):

  • Controlorii: Gestionează metadatele clusterului. Într-un cluster de producție, se recomandă un cvorum de 3 controlere. Controlorul activ (leaderul Raft) procesează toate modificările metadatelor și le reproduce altor controlori.
  • Broker: gestionează jurnalele de partiții, deservește producătorii și consumatorii. Brokerii păstrează o copie memoria cache a metadatelor primite de la controler, actualizată în flux.

Protocolul plutei de la Kafka

Raft este un algoritm de consens distribuit conceput pentru a fi de înțeles (spre deosebire de Paxos). Pe scurt: dintre toate nodurile de cvorum, unul este ales lider. Conducătorul primește toate scripturile, le propagă adepților, iar când majoritatea nodurilor au confirmat scrierea, o consideră săvârșită.

În KRaft, acest lucru se traduce astfel:

  1. O operație de metadate (crearea unui subiect, atribuirea liderului partiției etc.) ajunge la controlerul lider
  2. Controlerul lider scrie operația în jurnalul de metadate ca un eveniment serializat
  3. Evenimentul este replicat la adepții controlerului prin intermediul protocolului FETCH (folosind codul Kafka existent)
  4. Când majoritatea controlorilor au confirmat (cvorum), operațiunea este comisă
  5. Brokerii primesc actualizări de metadate transmise de controlerul activ prin MetadataUpdate
# Struttura di una directory dati KRaft (broker+controller combinato)
# /var/lib/kafka/data/

/var/lib/kafka/data/
  meta.properties          # cluster.id, node.id, version
  __cluster_metadata-0/    # il metadata log (partizione 0)
    00000000000000000000.log
    00000000000000000000.index
    00000000000000000000.timeindex
    leader-epoch-checkpoint
  ordini-effettuati-0/     # log di una partizione normale
  ordini-effettuati-1/
  ...

# meta.properties esempio:
node.id=1
version=1
cluster.id=MkU3OEVBNTcwNTJENDM2Qk

Controller de cvorum: Dimensiune

Controlorul de cvorum urmează regulile de consens: a tolera f eșec, sunt necesare 2f+1 noduri.

  • 3 controlere: tolerează 1 defecțiune (configurație minimă pentru producție)
  • 5 controlere: tolerează 2 defecțiuni simultane (recomandat pentru clustere critice)
  • 1 controler: Numai pentru dezvoltare/testare locală, fără toleranță la erori

Controlorii pot fi dedicat (numai rolul de controler, nu gestionați partițiile utilizator) sau combinate (aceleași mașini care acționează și ca brokeri). Pentru grupuri mici (< 10 brokeri) controlorii combinate sunt bine. Pentru clusterele mari sau cu debit mare, controlerele dedicate izolează sarcina de gestionare metadate din încărcarea I/O a partițiilor.

Configurarea unui cluster KRaft de la zero

# server.properties per un nodo controller+broker combinato (cluster single-node per dev)

# ─── Identity ─────────────────────────────────────────────────────────────────
# In KRaft ogni nodo ha un node.id unico nel cluster (sostituisce broker.id)
node.id=1

# Ruoli: "broker" | "controller" | "broker,controller"
process.roles=broker,controller

# Indirizzo del quorum controller: formato node.id@host:port
controller.quorum.voters=1@localhost:9093

# ─── Listeners ────────────────────────────────────────────────────────────────
# KAFKA: listener per producer/consumer
# CONTROLLER: listener per comunicazione KRaft interna
listeners=KAFKA://localhost:9092,CONTROLLER://localhost:9093
advertised.listeners=KAFKA://localhost:9092

listener.security.protocol.map=KAFKA:PLAINTEXT,CONTROLLER:PLAINTEXT
inter.broker.listener.name=KAFKA
controller.listener.names=CONTROLLER

# ─── Storage ──────────────────────────────────────────────────────────────────
log.dirs=/var/lib/kafka/data

# ─── Replication defaults ─────────────────────────────────────────────────────
default.replication.factor=1        # 1 per dev, 3 per produzione
min.insync.replicas=1               # 1 per dev, 2 per produzione
offsets.topic.replication.factor=1

# ─── Retention ────────────────────────────────────────────────────────────────
log.retention.hours=168             # 7 giorni
log.segment.bytes=1073741824        # 1GB per segmento
# Inizializzare il cluster KRaft (una tantum)
# Step 1: generare un cluster UUID univoco
KAFKA_CLUSTER_ID=$(kafka-storage.sh random-uuid)
echo "Cluster ID: $KAFKA_CLUSTER_ID"

# Step 2: formattare la directory storage con il cluster ID
kafka-storage.sh format \
  --config /etc/kafka/server.properties \
  --cluster-id "$KAFKA_CLUSTER_ID"

# Output:
# Formatting /var/lib/kafka/data with metadata.version 4.0-IV3.

# Step 3: avviare il broker
kafka-server-start.sh /etc/kafka/server.properties

Important: ID-ul clusterului este imuabil

Il cluster.id generat atunci când formatul este scris în fișier meta.properties a fiecărui nod și în jurnalul de metadate. Nu poate fi schimbat după inițializare. Dacă pierdeți acest fișier și doriți să adăugați un nod la clusterul existent, trebuie să utilizați procedura de bootstrap corespunzătoare. Stocați ID-ul clusterului într-un sistem de gestionare a secretelor.

Docker Compose: KRaft Cluster for Local Development

# docker-compose.yml per cluster Kafka 4.0 KRaft (3 broker)
# Immagine: apache/kafka:4.0.0 (immagine ufficiale Apache, non Confluent)

version: "3.9"

services:
  kafka1:
    image: apache/kafka:4.0.0
    container_name: kafka1
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: "broker,controller"
      KAFKA_LISTENERS: "PLAINTEXT://kafka1:9092,CONTROLLER://kafka1:9093"
      KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT://kafka1:9092"
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT"
      KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER"
      KAFKA_CONTROLLER_QUORUM_VOTERS: "1@kafka1:9093,2@kafka2:9093,3@kafka3:9093"
      KAFKA_INTER_BROKER_LISTENER_NAME: "PLAINTEXT"
      KAFKA_DEFAULT_REPLICATION_FACTOR: 3
      KAFKA_MIN_INSYNC_REPLICAS: 2
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 3
      CLUSTER_ID: "MkU3OEVBNTcwNTJENDM2Qk"
    volumes:
      - kafka1-data:/var/lib/kafka/data

  kafka2:
    image: apache/kafka:4.0.0
    container_name: kafka2
    environment:
      KAFKA_NODE_ID: 2
      KAFKA_PROCESS_ROLES: "broker,controller"
      KAFKA_LISTENERS: "PLAINTEXT://kafka2:9092,CONTROLLER://kafka2:9093"
      KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT://kafka2:9092"
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT"
      KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER"
      KAFKA_CONTROLLER_QUORUM_VOTERS: "1@kafka1:9093,2@kafka2:9093,3@kafka3:9093"
      KAFKA_INTER_BROKER_LISTENER_NAME: "PLAINTEXT"
      KAFKA_DEFAULT_REPLICATION_FACTOR: 3
      KAFKA_MIN_INSYNC_REPLICAS: 2
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 3
      CLUSTER_ID: "MkU3OEVBNTcwNTJENDM2Qk"
    volumes:
      - kafka2-data:/var/lib/kafka/data

  kafka3:
    image: apache/kafka:4.0.0
    container_name: kafka3
    environment:
      KAFKA_NODE_ID: 3
      KAFKA_PROCESS_ROLES: "broker,controller"
      KAFKA_LISTENERS: "PLAINTEXT://kafka3:9092,CONTROLLER://kafka3:9093"
      KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT://kafka3:9092"
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT"
      KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER"
      KAFKA_CONTROLLER_QUORUM_VOTERS: "1@kafka1:9093,2@kafka2:9093,3@kafka3:9093"
      KAFKA_INTER_BROKER_LISTENER_NAME: "PLAINTEXT"
      KAFKA_DEFAULT_REPLICATION_FACTOR: 3
      KAFKA_MIN_INSYNC_REPLICAS: 2
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 3
      CLUSTER_ID: "MkU3OEVBNTcwNTJENDM2Qk"
    volumes:
      - kafka3-data:/var/lib/kafka/data

volumes:
  kafka1-data:
  kafka2-data:
  kafka3-data:

Migrarea de la Kafka 3.x cu ZooKeeper la KRaft

Dacă gestionați un cluster Kafka 3.x în modul ZooKeeper și trebuie să migrați la KRaft (necesar pentru a utiliza Kafka 4.0), procesul se numește Migrare KRaft și este acceptat oficial începând cu versiunea 3.5. Vestea bună: Migrația are loc fără timp de nefuncţionare pentru producători și consumatori.

Fazele migrației

Procesul oficial este împărțit în 6 etape:

  1. Verificați cerințele preliminare: upgrade la Kafka 3.7 (cea mai recentă versiune cu suport pentru scriere dublă ZooKeeper+KRaft), verificați dacă toți brokerii au metadata.version aliniat.
  2. Implementarea controlerului KRaft: Porniți nodurile de control KRaft (3 noduri noi sau brokeri existenți cu rol suplimentar). Controlorii obțin metadatele inițiale de la ZooKeeper prin instrumentul de migrare.
  3. Mod de scriere dublă: Brokerii scriu metadate atât în ​​ZooKeeper, cât și în jurnalul de metadate KRaft. În această fază, sistemul este pe deplin operațional.
  4. Migrația s-a încheiat: toți brokerii migrează, ZooKeeper devine doar pentru citire pentru Kafka. Producătorii și consumatorii nu percep nicio întrerupere.
  5. Finalizator ZooKeeper: rulați finalizatorul care curăță metadatele Kafka din ZooKeeper.
  6. Închideți ZooKeeper: Dezafectați ansamblul ZooKeeper. Cluster complet KRaft. 
# Step 1: Verifica metadata.version attuale del cluster
# (da eseguire con Kafka 3.7)
kafka-features.sh --bootstrap-server kafka1:9092 describe

# Output:
# Feature: metadata.version
#   SupportedMinVersion: 3.0-IV1
#   SupportedMaxVersion: 3.7-IV4
#   FinalizedVersion: 3.7-IV4

# Step 2: Avvia i controller KRaft con la migration config speciale
# In server.properties dei controller KRaft:
process.roles=controller
zookeeper.connect=zk1:2181,zk2:2181,zk3:2181   # ancora necessario in fase di migrazione
controller.quorum.voters=10@kc1:9093,11@kc2:9093,12@kc3:9093

# Step 3: Avvia la migration (da eseguire una volta soli i controller KRaft sono up)
# Modifica server.properties di OGNI broker Kafka esistente:
# Aggiunge il parametro:
zookeeper.metadata.migration.enable=true
controller.quorum.voters=10@kc1:9093,11@kc2:9093,12@kc3:9093

# Riavvia i broker uno alla volta (rolling restart, zero downtime)
# I broker entrano in migration mode automaticamente

# Step 4: Monitora lo stato della migrazione
kafka-metadata-shell.sh \
  --snapshot /var/lib/kafka/data/__cluster_metadata-0/00000000000000000000.snapshot

# Step 5: Finalizza (dopo che tutti i broker sono migrati)
kafka-features.sh --bootstrap-server kafka1:9092 upgrade \
  --metadata 3.7-IV4  # o la versione target

# Step 6: Rimuovi zookeeper.connect dai server.properties e riavvia i broker

Notificări importante pentru migrare

  • Nu te întoarce ușor: Odată ce migrarea KRaft este completă și ZooKeeper este eliminat, rollback-ul este foarte complex. Migrați mai întâi într-un mediu de procesare identic cu cel de producție.
  • ACL-uri și configurații: ACL-urile și configurațiile dinamice gestionate prin ZooKeeper sunt migrate automat în jurnalul de metadate, dar verificați dacă acestea sunt prezente după migrare.
  • Conector Kafka Connect: conectori care folosesc clusterul Kafka ca backend pentru stare (group.id, offsets) continuă să funcționeze neschimbat.
  • MirrorMaker 2: Dacă utilizați MM2 pentru replicare geografică, actualizați clusterele la distanță în același fereastra de întreținere pentru a evita incompatibilitățile versiunilor.

KRaft cu configurație avansată: controlere dedicate

Pentru clustere cu debit mare sau care gestionează un număr mare de partiții (>50.000), se recomanda separarea controlorilor de brokeri (controlere dedicate). Ca asta operațiunile de metadate (crearea subiectului, alegerea liderului, schimbarea configurației) nu concurează cu jurnalul de partiție I/O pe aceleași discuri. 

# server.properties per un CONTROLLER DEDICATO (non gestisce partizioni utente)
node.id=10
process.roles=controller
controller.quorum.voters=10@kc1:9093,11@kc2:9093,12@kc3:9093
listeners=CONTROLLER://kc1:9093
listener.security.protocol.map=CONTROLLER:PLAINTEXT
controller.listener.names=CONTROLLER
log.dirs=/var/lib/kafka/metadata

# server.properties per un BROKER PURO (non è controller)
node.id=1
process.roles=broker
controller.quorum.voters=10@kc1:9093,11@kc2:9093,12@kc3:9093
listeners=KAFKA://kafka1:9092
advertised.listeners=KAFKA://kafka1:9092
listener.security.protocol.map=KAFKA:PLAINTEXT
inter.broker.listener.name=KAFKA
controller.listener.names=CONTROLLER
log.dirs=/var/lib/kafka/data

# Con questa configurazione:
# - 3 macchine controller dedicati (leggeri, poca RAM, poca CPU)
# - N broker puri (ottimizzati per I/O disco)
# - Nessuna competizione di risorse tra metadata ops e I/O partizioni

În Confluent Cloud și în medii gestionate, cum ar fi Amazon MSK (care a adoptat KRaft începând cu versiunea 3.6), separarea controlor/broker are loc automat și este transparentă pentru utilizator.

Beneficiile operaționale ale KRaft

Pornire și recuperare mai rapidă

Cu ZooKeeper, când controlerul brokerului Kafka a repornit, a trebuit să citească întreaga stare a clusterului de la ZooKeeper înainte de a putea opera. Pentru clustere cu peste 100.000 de partiții, acest lucru ar putea dura 30-90 de secunde indisponibilitatea controlerului.

Cu KRaft, controlerul lider păstrează jurnalul de metadate deja în memorie și pe discul local. Un failover de controler necesită de obicei mai puțin de 5 secunde, chiar și pentru grupuri mari. Un studiu de caz a unei companii fintech (Confluent Engineering Blog, 2025) documentează o reducere cu 40% a timpului de configurare după migrarea la KRaft.

Scalabilitate metadate

ZooKeeper avea o limită practică de aproximativ 200.000 de partiții per cluster (indiferent de performanță a operațiunilor cu metadate degradate semnificativ). KRaft gestionează jurnalul de metadate ca de obicei Bușteni Kafka cu compactare și a fost testat cu milioane de partiții pe cluster.

Simplitate operațională

Eliminarea ZooKeeper înseamnă:

  • Un sistem de monitorizat în loc de două
  • Un ciclu de upgrade în loc de două (de multe ori ZooKeeper și Kafka aveau constrângeri complexe de versiune)
  • Implementare mai ușoară pe Kubernetes (mai puțin StatefulSet, mai puțin PVC)
  • Recuperare în caz de dezastru mai ușoară (starea clusterului este în jurnalul de metadate, nu este distribuită între Kafka și ZooKeeper)

KRaft pe Kubernetes cu Strimzi

Strimzi este cel mai popular operator Kubernetes pentru gestionarea Kafka. Din versiunea 0.38, Strimzi acceptă nativ KRaft: 

# Kafka cluster KRaft con Strimzi Operator (Kubernetes)
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  namespace: kafka
  annotations:
    # Abilita KRaft mode (richiede Strimzi 0.38+)
    strimzi.io/kraft: enabled
spec:
  kafka:
    version: 4.0.0
    replicas: 3
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
    config:
      # KRaft-specific
      default.replication.factor: 3
      min.insync.replicas: 2
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 2
      # Retention
      log.retention.hours: 168
      log.segment.bytes: 1073741824
    storage:
      type: persistent-claim
      size: 100Gi
      class: fast-ssd
    # Controller separato (produzione: controller dedicati)
    # Ometti questa sezione per controller combinati (default)
  # entityOperator gestisce topic e utenti tramite CRD
  entityOperator:
    topicOperator: {}
    userOperator: {}
# Creare un topic con Strimzi CRD (invece di kafka-topics.sh)
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: ordini-effettuati
  namespace: kafka
  labels:
    strimzi.io/cluster: my-cluster
spec:
  partitions: 6
  replicas: 3
  config:
    retention.ms: "604800000"
    min.insync.replicas: "2"
    compression.type: snappy

Verificarea stării Clusterului KRaft

# Verificare chi è il controller leader attuale
kafka-metadata-quorum.sh \
  --bootstrap-server kafka1:9092 \
  describe --status

# Output:
# ClusterId:              MkU3OEVBNTcwNTJENDM2Qk
# LeaderId:               1
# LeaderEpoch:            42
# HighWatermark:          156789
# MaxFollowerLag:         0
# MaxFollowerLagTimeMs:   12
# CurrentVoters:          [{"nodeId":1,"logEndOffset":156789,"lag":0},
#                          {"nodeId":2,"logEndOffset":156789,"lag":0},
#                          {"nodeId":3,"logEndOffset":156789,"lag":0}]
# CurrentObservers:       []

# Verificare i dettagli del quorum
kafka-metadata-quorum.sh \
  --bootstrap-server kafka1:9092 \
  describe --replication

# Leggere il metadata log (per debugging)
kafka-dump-log.sh \
  --files /var/lib/kafka/data/__cluster_metadata-0/00000000000000000000.log \
  --cluster-metadata

Diferențe de configurare: ZooKeeper vs KRaft

Pentru cei care provin dintr-un cluster ZooKeeper, iată principalele diferențe de configurare de știut:

Configurare ZooKeeperMode KRaftMode
Conexiune la cluster zookeeper.connect controller.quorum.voters
ID-ul nodului broker.id node.id
Roluri Întotdeauna broker process.roles
Controloare pentru ascultători N / A controller.listener.names
Inițializare Mașină (mânere ZK) kafka-storage.sh format
Stocare ACL ZooKeeper znodes Jurnal de metadate

Versiunea metadatelor și steaguri de caracteristică în KRaft

Cu KRaft, Kafka introduce conceptul de metadate.versiune: O versiune a formatului de metadate în cluster. Acest lucru permite actualizarea continuă a unui cluster fără timp de nefuncționare, câte un nod la un moment dat. Versiunea metadatelor este actualizată numai atunci când toți brokerii din cluster acceptă noua versiune. 

# Verificare la metadata.version corrente e le versioni supportate
kafka-features.sh \
  --bootstrap-server kafka1:9092 \
  describe

# Output tipico con Kafka 4.0:
# Feature: metadata.version
#   SupportedMinVersion: 3.0-IV1
#   SupportedMaxVersion: 4.0-IV3
#   FinalizedVersion: 4.0-IV3

# Verificare tutti i feature flags disponibili
kafka-features.sh \
  --bootstrap-server kafka1:9092 \
  describe --all

# Aggiornare la metadata.version dopo un upgrade di cluster
# (eseguire DOPO che tutti i broker sono stati aggiornati alla nuova versione)
kafka-features.sh \
  --bootstrap-server kafka1:9092 \
  upgrade --metadata 4.0-IV3

Versiunea 4.0-IV3 (Kafka 4.0 Incremental Version 3) este cea mai recentă versiune disponibilă Kafka 4.0 martie 2025. Fiecare creștere a versiunii permite noi funcții și optimizări ale protocolului.

Depanarea KRaft: probleme comune

Clusterul nu pornește: „Nu s-au găsit alegători în cvorum”

Această eroare indică faptul că nodurile de control nu pot găsi alți alegători de cvorum. Cauze comune:

  • controler configurat greșit.cvorum.voters: Verificați dacă formatul este corect (nodeId@hostname:port) și că numele de gazdă pot fi rezolvate de către toate nodurile.
  • Ascultător CONTROLLER inaccesibil: Verificați dacă firewall-ul permite comunicare pe portul de ascultare al controlerului (implicit: 9093) între nodurile controlerului.
  • Nepotrivire cu ID-ul clusterului: dacă ai repornit cu kafka-storage.sh format pe unul dintre noduri fără a utiliza ID-ul de cluster corect, nodurile nu se vor alătura clusterului. 
# Verificare il cluster ID su ogni nodo
cat /var/lib/kafka/data/meta.properties
# node.id=1
# version=1
# cluster.id=MkU3OEVBNTcwNTJENDM2Qk  <-- deve essere identico su tutti i nodi

# Verificare che il controller leader sia eletto
kafka-metadata-quorum.sh \
  --bootstrap-server kafka1:9092 \
  describe --status | grep LeaderId

# Se LeaderId=-1, nessun leader è stato eletto (quorum non raggiunto)

# Controllare i log del broker per errori KRaft
grep -E "WARN|ERROR" /var/log/kafka/kafka.log | grep -i "kraft\|quorum\|controller"

Broker nu a fost adăugat la cluster

Când adăugați un nou broker la un cluster KRaft existent, brokerul trebuie să fie formatat cu același ID de cluster ca și clusterul existent: 

# Recupera il cluster ID dal cluster esistente
CLUSTER_ID=$(kafka-metadata-quorum.sh \
  --bootstrap-server kafka1:9092 \
  describe --status | grep ClusterId | awk '{print $2}')

echo "Cluster ID: $CLUSTER_ID"

# Formatta il nuovo broker con lo stesso cluster ID
kafka-storage.sh format \
  --config /etc/kafka/server.properties \
  --cluster-id "$CLUSTER_ID"

# Avvia il nuovo broker
kafka-server-start.sh /etc/kafka/server.properties

# Verifica che il nuovo broker sia visibile nel cluster
kafka-broker-api-versions.sh \
  --bootstrap-server kafka1:9092 | grep "id:"

Următorii pași din serie

Cu KRaft inclus, sunteți gata să abordați aspecte mai avansate ale configurației Kafka:

  • Articolul 3 – Producător și Consumator avansat: configurația detaliată a acks, idempotent producerși reîncercați strategiile pentru a asigura durabilitatea fără duplicate.
  • Articolul 4 – Semantica Exact O dată: Tranzacții Kafka pentru scrieri atomice pe mai multe subiecte, cu noul coordonator de tranzacții implementat în jurnalul de metadate KRaft.
  • Articolul 11 ​​– Kafka în producție: Dimensiunea clusterului KRaft, configurația a replicilor controlerului, recuperare în caz de dezastru și backup pentru jurnalul de metadate.

Legătură cu alte serii

  • Kubernetes avansat: implementarea lui Kafka pe Kubernetes cu operatorul Strimzi, gestionarea persistentă a stocării și scalarea automată a grupului de consumatori.
  • Observabilitate: Monitorizarea cvorumului KRaft cu JMX Exporter, valori critice cum kafka.controller:type=KafkaController,name=ActiveControllerCount și alertă la alegerea liderului.