Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Failover offline del broker e client
Kafka consente di utilizzare un broker offline; un singolo broker offline in un cluster sano ed equilibrato che segue le migliori pratiche non avrà alcun impatto né causerà il fallimento della produzione o del consumo. Questo perché un altro broker assumerà la leadership della partizione e perché la libreria client di Kafka eseguirà automaticamente il failover e inizierà a inviare richieste ai nuovi broker leader.
Contratto client-server
Ciò si traduce in un contratto condiviso tra la libreria client e il comportamento lato server; il server deve assegnare con successo uno o più nuovi leader e il cliente deve cambiare broker per inviare richieste ai nuovi leader in modo tempestivo.
Kafka utilizza delle eccezioni per controllare questo flusso:
Un esempio di procedura
-
Il broker A entra in uno stato offline.
-
Il client Kafka riceve un'eccezione (in genere una disconnessione dalla rete o not_leader_for_partition).
-
Queste eccezioni fanno sì che il client Kafka aggiorni i propri metadati in modo da conoscere i leader più recenti.
-
Il cliente Kafka riprende a inviare richieste ai nuovi responsabili delle partizioni su altri broker.
Questo processo richiede in genere meno di 2 secondi con il client Java fornito e le configurazioni predefinite. Gli errori sul lato client sono prolissi e ripetitivi ma non sono motivo di preoccupazione, come indicato dal livello «WARN».
Esempio: Eccezione 1
10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender -
[Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left).
Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2
Esempio: Eccezione 2
10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"
I client Kafka risolvono automaticamente questi errori in genere entro 1 secondo e al massimo 3 secondi. Ciò si presenta come una produce/consume latenza di p99 nelle metriche lato client (in genere elevata in millisecondi negli anni 100). Un valore superiore a questo valore indica in genere un problema di configurazione del client o del carico del controller sul lato server. Consulta la sezione sulla risoluzione dei problemi.
Un failover riuscito può essere verificato controllando l'aumento delle metriche BytesInPerSec e delle LeaderCount metriche su altri broker, il che dimostra che il traffico e la leadership si sono mossi come previsto. Osserverai anche un aumento della UnderReplicatedPartitions metrica, previsto quando le repliche sono offline con il broker di shutdown.
Risoluzione dei problemi
Il flusso di cui sopra può essere interrotto rompendo il contratto client-server. I motivi più comuni del problema includono:
Configurazione errata o utilizzo non corretto delle librerie client di Kafka.
Comportamenti e bug predefiniti imprevisti nelle librerie client di terze parti.
Controller sovraccarico con conseguente rallentamento dell'assegnazione del leader della partizione.
Viene eletto un nuovo controller, con conseguente rallentamento dell'assegnazione del leader di partizione.
Per garantire un comportamento corretto per gestire il fallimento della leadership, consigliamo di:
È necessario seguire le migliori pratiche sul lato server per garantire che il controller broker sia dimensionato in modo appropriato per evitare una lenta assegnazione della leadership.
Le librerie client devono avere i tentativi abilitati per garantire che il client gestisca il failover.
Le librerie client devono avere retry.backoff.ms configurato (impostazione predefinita 100) per evitare tempeste. connection/request
Le librerie client devono impostare request.timeout.ms e delivery.timeout.ms su valori in linea con lo SLA delle applicazioni. Valori più alti comporteranno un failover più lento per determinati tipi di errore.
Le librerie client devono garantire che bootstrap.servers contenga almeno 3 broker casuali per evitare un impatto sulla disponibilità sulla scoperta iniziale.
Alcune librerie client sono di livello inferiore rispetto ad altre e si aspettano che lo sviluppatore dell'applicazione implementi autonomamente la logica dei tentativi e la gestione delle eccezioni. Fai riferimento alla documentazione specifica della libreria client, ad esempio l'utilizzo, e assicurati di seguire la reconnect/retry logica corretta.
Consigliamo di monitorare la latenza sul lato client per le produzioni, il conteggio delle richieste riuscite e il conteggio degli errori per gli errori non ripetibili.
Abbiamo osservato che le vecchie librerie golang e ruby di terze parti rimangono dettagliate durante un intero periodo di tempo offline del broker, nonostante le richieste di produzione e consumo non siano influenzate. Ti consigliamo di monitorare sempre le metriche a livello aziendale, oltre a quelle relative alle richieste relative al successo e agli errori, per determinare se nei log c'è un impatto reale rispetto al rumore.
I clienti non dovrebbero allarmarsi in caso di eccezioni transitorie, network/not_leader poiché sono normali, prive di impatto e previste come parte del protocollo Kafka.
I clienti non devono allarmarsi perché sono normali, UnderReplicatedPartitions privi di impatto e attesi da un unico broker offline.
