As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Sincronização de offset de grupos de consumidores
O MSK Replicator pode sincronizar deslocamentos de grupos de consumidores de um cluster de origem para um cluster de destino, permitindo que os consumidores troquem de cluster e retomem o processamento sem ignorar registros. Este tópico aborda como a sincronização offset funciona em configurações unidirecionais (antigas) e bidirecionais (aprimoradas) e destaca as armadilhas comuns.
Como funciona a sincronização offset
Como parte da replicação de dados, o Replicador do MSK consome mensagens do cluster de origem e as produz para o cluster de destino. Isso pode levar as mensagens a terem deslocamentos diferentes nos clusters de origem e de destino. Se você ativou a sincronização de offset do grupo de consumidores durante a criação do Replicator, o MSK Replicator traduz automaticamente as compensações enquanto copia os metadados para que, após o failover para o cluster de destino, seus consumidores possam retomar o processamento de perto de onde pararam.
O MSK Replicator é otimizado para consumidores no cluster de origem que estão lendo de uma posição mais próxima da ponta do fluxo (final da partição do tópico). Se seus grupos de consumidores estiverem atrasados no cluster de origem, você poderá observar um atraso maior para esses grupos de consumidores no destino em comparação com a origem, o que significa que os consumidores reprocessarão mais mensagens duplicadas após o failover. Para reduzir esse atraso, seus consumidores no cluster de origem precisam se atualizar e começar a consumir desde a ponta do stream. À medida que os consumidores se atualizarem, o Replicador do MSK reduzirá automaticamente o atraso.
A sincronização offset é um pipeline de três estágios:
Mapeamento de deslocamento — à medida que os registros são replicados da origem para o destino, o replicador registra mapeamentos periódicos entre os deslocamentos de origem e os deslocamentos de destino correspondentes. Como os deslocamentos de origem e destino divergem (pontos de partida diferentes, compactação etc.), esses mapeamentos são essenciais.
Tradução offset — Periodicamente, o replicador lê as compensações confirmadas para cada grupo de consumidores replicado no cluster de origem. Em seguida, ele usa os mapeamentos de deslocamento armazenados para traduzir esses deslocamentos de origem em deslocamentos de destino equivalentes.
Confirmação de compensação — As compensações traduzidas são comprometidas com o
__consumer_offsetstópico do cluster de destino, de forma que, quando um consumidor se conecta ao destino e se junta ao mesmo grupo, ele é retomado aproximadamente da posição correta.
Principais comportamentos:
A tradução offset é aproximada, não exata. As amostras do replicador compensam os mapeamentos em intervalos, portanto, o deslocamento traduzido pode estar um pouco atrás da posição equivalente real. Isso ocorre intencionalmente: ele erra no lado da at-least-once entrega, o que significa que os consumidores podem reler um pequeno número de mensagens após o failover.
As compensações só são comprometidas com um grupo de consumidores no alvo se nenhum consumidor estiver consumindo ativamente nesse grupo no alvo. Isso evita que o replicador interfira com os consumidores que já estão em execução no cluster de destino.
Os grupos de consumidores devem corresponder ao filtro de grupos de consumidores configurado (padrões de inclusão/exclusão) para serem sincronizados.
Replicação unidirecional com sincronização de offset herdada
Esse é o modo padrão para um replicador unidirecional padrão (Cluster A → Cluster B).
Nomeação de tópicos — A sincronização offset antiga oferece suporte à replicação de nomes de tópicos prefixados e idênticos.
Direção — As compensações do grupo de consumidores só são sincronizadas com o cluster de destino quando os produtores estão ativos na origem e os consumidores estão inativos no cluster de destino.
Failover — Os consumidores podem ser direcionados para o cluster de destino e retomarão a partir da posição de deslocamento traduzida.
Sem suporte a failback — a sincronização de offset antiga não converte os deslocamentos do destino de volta para a origem. Se você mover os consumidores para o destino e depois quiser movê-los de volta para a origem, não há tradução automática de offset para a viagem de volta. Se o failback for necessário, use uma configuração bidirecional com sincronização de offset aprimorada.
Configuração bidirecional com sincronização de offset aprimorada
Uma configuração bidirecional requer dois replicadores funcionando em direções opostas (Replicador A→B e Replicador B→A). Cada replicador ainda executa a replicação unidirecional de dados e a sincronização offset — ele replica os dados da origem para o destino e sincroniza os deslocamentos do grupo de consumidores na mesma direção. Com a sincronização offset aprimorada, cada replicador pode continuar sincronizando grupos de consumidores mesmo quando produtores e consumidores estão ativos em clusters diferentes.
Características principais:
Nomeação de tópicos — A sincronização aprimorada requer replicação idêntica de nomes de tópicos em ambos os replicadores.
Dois replicadores, cada um unidirecional — cada replicador replica os dados e sincroniza os deslocamentos em uma direção. O comportamento bidirecional vem do trabalho conjunto do par.
Lê os mapeamentos dos dois replicadores — Ao traduzir os deslocamentos, os replicadores trabalham juntos para determinar a tradução mais precisa disponível.
Failover e failback — os consumidores podem ser movidos de um cluster para o outro e retomá-los aproximadamente da posição correta.
Quando ativar a sincronização de deslocamento bidirecional:
Migração com capacidade de reversão — Ao migrar de um cluster para outro e você quiser a capacidade de reverter para o cluster original se surgirem problemas.
Arquiteturas ativas — quando os dois clusters estão fornecendo leituras e gravações ativamente, e você precisa que os consumidores possam alternar entre os clusters.
Recuperação de desastres — quando você precisa garantir que os consumidores possam retomar o processamento a partir da compensação correta em qualquer cluster após um evento de failover ou failback.
Monitorando a sincronização offset
Monitore as seguintes CloudWatch métricas da Amazon para verificar se a sincronização offset está funcionando corretamente:
ConsumerGroupCount— verifique se o número esperado de grupos de consumidores está sendo sincronizado nos dois replicadores.ConsumerGroupOffsetSyncFailure— Deve ser 0 em ambos os replicadores. Se esse valor for maior que 0, verifique se os grupos de consumidores estão ativos, verifique as permissões de leitura e descrição e garanta que os tópicos existam no cluster de destino.OffsetLag (MSK Cluster)eOffsetLag (Non-MSK Cluster)— Compare o atraso do consumidor em nível de partição em ambos os clusters para verificar se os deslocamentos estão sincronizados.
Armadilhas comuns
-
Os consumidores podem reler um pequeno número de mensagens após o failover
A tradução offset é aproximada. O deslocamento traduzido é intencionalmente conservador — pode estar um pouco atrás da posição equivalente real. Isso significa que os consumidores normalmente reprocessam um pequeno número de registros após a troca de clusters. Os aplicativos devem ser projetados para lidar com processamento duplicado (idempotência).
-
As compensações não são sincronizadas com grupos que estão consumindo ativamente o alvo
Se um grupo de consumidores já estiver ativo no cluster de destino, o replicador não substituirá seus deslocamentos. Esse é um mecanismo de segurança. No entanto, isso significa que, se os consumidores começarem a usar o alvo antes que o replicador tenha a chance de sincronizar as compensações, esses consumidores começarão com a política de redefinição de compensação padrão do alvo (normalmente
latestouearliest), não com a posição traduzida. -
A sincronização offset tem um atraso inerente
A tradução offset depende de dois processos assíncronos: replicação de dados e sincronização offset. Sempre há algum atraso entre o momento em que um consumidor comete um deslocamento na fonte e o momento em que o deslocamento traduzido aparece no destino. Durante o failover, esse atraso pode fazer com que os consumidores releiam mais mensagens do que o esperado se o consumidor de origem estivesse ativo recentemente.
-
Grupos de consumidores devem ser incluídos no filtro de replicação
Somente grupos de consumidores que correspondam ao padrão de inclusão configurado (e não correspondam ao padrão de exclusão) terão seus deslocamentos sincronizados. Se as compensações de um grupo de consumidores não estiverem aparecendo no destino, verifique se elas estão incluídas na configuração de replicação do grupo de consumidores.
-
Os replicadores unidirecionais não oferecem suporte a failback
Com a sincronização de offset legada (unidirecional), os offsets são traduzidos apenas da origem para o destino. Se você mover os consumidores para o destino e depois precisar movê-los de volta para a origem, precisará determinar manualmente as compensações corretas ou aceitar o reprocessamento. Se o failback for necessário, use uma configuração bidirecional com sincronização de offset aprimorada.
-
A exclusão e a recriação de tópicos podem invalidar mapeamentos de deslocamento
Se um tópico for excluído e recriado em qualquer cluster, os mapeamentos de deslocamento se tornarão obsoletos porque o novo tópico começa no deslocamento 0. Com a sincronização de offset herdada, isso pode resultar em traduções de offset incorretas. A sincronização de offset aprimorada detecta a recriação de tópicos e redefine os mapeamentos automaticamente.
