Front
Back
Exemplo: tópico com LOG-END-OFFSET=1000. Grupo novo com auto.offset.reset=latest. De onde começa?
Começa em 1000 (fim do log). Vai consumir só mensagens novas (offset >=1000).
Exemplo: tópico com LOG-END-OFFSET=1000. Grupo novo com auto.offset.reset=earliest. De onde começa?
Começa no início disponível (ex: offset 0 ou earliest disponível) e consome backlog até 999.
Exemplo: grupo existente com CURRENT-OFFSET=700 e LOG-END-OFFSET=1000. latest afeta?
Não. Ele começa do 700 porque há offset commitado válido.
Como calcular LAG no describe do consumer group?
LAG = LOG-END-OFFSET - CURRENT-OFFSET (por partição).
Exemplo: CURRENT-OFFSET=700 e LOG-END-OFFSET=1000. Qual LAG?
LAG=300 (faltam 300 mensagens para alcançar o fim).
Exemplo: você roda reset –to-latest e o resultado mostra NEW-OFFSET=1000. O que aconteceu?
O grupo passou a começar no fim (1000) e “pulou” backlog.
Exemplo: após reset –to-latest, CURRENT-OFFSET fica igual ao LOG-END-OFFSET. O que significa?
LAG=0. O grupo está “em dia”, aguardando novas mensagens.
Exemplo: você roda reset –to-earliest e NEW-OFFSET=0. O que acontece ao subir a app?
Ela reprocessa tudo desde o começo (0..).
Exemplo: CURRENT-OFFSET=50 e LOG-END-OFFSET=1000. Você reseta para to-offset 900. O que muda?
O grupo passa a começar em 900 e só processa 900..999 (mais novas).
Exemplo: offset commitado aponta para 1200, mas LOG-END-OFFSET=1000. O que ocorre?
O offset é inválido (fora do range). Aí aplica auto.offset.reset (earliest ou latest).
Exemplo: commit inválido e auto.offset.reset=latest. De onde começa?
Começa no fim atual (LOG-END-OFFSET). Não reprocessa backlog.
Exemplo: commit inválido e auto.offset.reset=earliest. De onde começa?
Começa no earliest disponível (início ainda retido) e reprocessa o que existir.
Por que um offset commitado pode virar inválido?
Porque mensagens antigas expiraram (retention) ou houve truncamento/alteração do log.
Exemplo: você resetou para latest, mas a app continua falhando no offset antigo. Qual causa mais provável?
Você resetou o consumer group errado ou o grupo estava ativo e não aceitou o reset.
Exemplo: o comando reset mostra NEW-OFFSET atualizado, mas depois volta. Por quê?
Alguma instância ainda estava consumindo e commitou offsets antigos/concorrentes (grupo não estava realmente inativo).
Qual condição ideal antes de resetar offsets?
Consumer group inativo (sem membros). Assim o reset não “briga” com commits.
Em termos práticos, quando latest é útil?
Quando você quer ignorar backlog (grupo novo) ou pular mensagens antigas após reset.
Em termos práticos, quando earliest é útil?
Quando você quer reprocessar histórico (replay) ou reconstruir estado.
Regra final: latest/earliest importam quando?
Só quando NÃO há offset válido (grupo novo/sem commit ou commit inválido). Caso contrário, vale o offset commitado.
