--- title: "Kafka Simulator v1.5 + v1.6 — clusters esticados, armazenamento e operação" date: 2026-09-02T00:00:00.000Z author: "michal" excerpt: "Dois pacotes de uma vez. O modo livre completa a sua escada de topologias com os clusters esticados de 3-DC e de 2,5-DC com testemunha, e 19 novos cenários cobrem o ciclo de vida do log — retenção, compactação, armazenamento em camadas — mais o plano de controlo KRaft e as operações num cluster vivo." --- Dois pacotes saem juntos: **v1.5 — Armazenamento e ciclo de vida** e **v1.6 — Operação, controlador e quotas**. Juntos trazem ao [Kafka Simulator](/kafka-simulator/) **19 novos cenários**, o currículo chega a **74 de 122**, e o modo livre termina a escada de formas de cluster começada na v1.3. Desta vez começamos pelo modo livre, porque são estes dois desbloqueios os mais pedidos. ## Modo livre: a escada de topologias está completa Desde a v1.3 o sandbox crescia uma forma de cluster por pacote: primeiro ativo/passivo, depois ativo/ativo. Ambos são **dois clusters** ligados por um mirror assíncrono. As duas formas que chegam agora são de outro tipo: **um só cluster esticado entre datacenters**, onde a replicação é síncrona e o próprio ISR atravessa a WAN. A diferença aparece assim que algo falha: - Num par **espelhado**, perder uma região é um *failover*: promoves o outro lado e aceitas o que o mirror ainda não tinha copiado. - Num cluster **esticado**, perder um DC é um *evento de replicação*: o ISR encolhe, e se ainda podes escrever depende apenas de `min.insync.replicas`. ### 3-DC esticado (novo na v1.5) Três datacenters, um cluster. O sandbox por omissão dá-te um broker e um controlador em cada um de `dc-a`, `dc-b` e `dc-c`, com os brokers intercalados para que a colocação round-robin espalhe as réplicas de cada partição pelos três sítios. Três partições, por isso cada DC abre com um líder natural, por isso a disposição mostra liderança equilibrada entre DCs em vez de uma partição solitária. Há **um quórum KRaft distribuído pelos três sítios**, não um por região. Mata um DC e perdes um votante em três; os dois restantes continuam a formar maioria e o cluster continua a decidir. ### 2,5-DC esticado (novo na v1.6) O último degrau: dois datacenters *de dados* mais um terceiro sítio **testemunha** que detém um voto de controlador e nenhuns dados. É a forma MRC da Confluent. Cada DC de dados recebe **2 réplicas síncronas e 1 observador** — RF 4 no conjunto síncrono, com `min.insync.replicas` a 3. Duas coisas sobre os observadores: - **Não contam para o ISR**, por isso não seguram uma escrita `acks=all`. Uma réplica através da WAN que condicionasse cada commit seria um desastre de latência; um observador é como manténs uma cópia remota sem a pagar no caminho de escrita. - Quando o ISR cai abaixo de `min.insync.replicas`, um observador pode ser **promovido automaticamente** para restaurar a durabilidade. Por omissão o sandbox promove na queda do ISR e despromove de novo quando o DC recupera; também pode ficar promovido, ou desligas o automatismo e fazes à mão. A testemunha encaixa diretamente nos cenários de controlador desta entrega. Um quórum quer um número ímpar de votantes, e comprar um terceiro datacenter completo para o obter é caro — por isso compras meio. O cenário 06.0.2 («quórum KRaft») termina exatamente na falha que a testemunha existe para evitar; agora podes montar as duas configurações no sandbox e compará-las. Com isto, **as cinco formas de cluster estão disponíveis**: DC único, ativo/passivo, ativo/ativo, 3-DC esticado e 2,5-DC esticado. Cada desbloqueio restante do modo livre — o laboratório de falhas na v1.7, o terminal CLI do Kafka na v1.8, a governança na v1.9 — é uma capacidade nova, não uma forma nova. A mesma ressalva da v1.3: o **currículo de DR** que narra estas topologias continua a chegar na v1.8. As formas aterram primeiro de propósito, para que haja onde experimentar as ideias antes de os cenários as explicarem. Se entretanto quiseres ler mais sobre arquiteturas multirregião, o [guia da SoftwareMill sobre recuperação de desastres e arquiteturas multirregião no Apache Kafka](https://softwaremill.com/guide-to-apache-kafka-disaster-recovery-and-multi-region-architectures/) é um tratamento aprofundado dos compromissos que estas formas codificam. Vale a pena tê-lo aberto noutro separador enquanto brincas com o sandbox. ## Os cenários ### v1.5 — Armazenamento e ciclo de vida (9 cenários) Um log do Kafka não é uma fita infinita. Este módulo cobre em três grupos o que acontece aos registos depois de escritos. **Retenção** — `retention.ms` e `retention.bytes` a avançar o log start offset, e o que recebe um consumidor que pede um offset já apagado pela retenção (`OFFSET_OUT_OF_RANGE`, e o reset que se segue). **Compactação** — `cleanup.policy=compact` a guardar o último valor por chave preservando offsets e deixando buracos; tombstones a apagar uma chave, com `delete.retention.ms` como janela de graça para um consumidor observar a eliminação antes de ser purgada; e `compact,delete` a correr ambas as políticas juntas. **Armazenamento em camadas** — descarregar um prefixo envelhecido do log para a camada remota, lê-lo de volta, e a diferença entre retenção *local* e *total*. É o grupo que mais muda o dimensionamento de um cluster: a retenção local deixa de ser o que limita até onde atrás um consumidor pode ler. ### v1.6 — o plano de controlo (`kraft`, 4 cenários) O que o controlador faz, e o que para quando ele não está: - **O trabalho do controlador** e o **quórum KRaft** — o controlador mantém consistentes os metadados, não os dados. Perde a maioria do quórum e não há controlador: os líderes ficam onde estão e nada de novo é decidido até que um votante volte. - **Failover do controlador e recuperação de metadados** — um novo controlador ativo tem de alcançar o offset de metadados confirmado antes de poder servir, e é por isso que as eleições congelam por um momento após um failover. - **ZooKeeper contra KRaft** — o mesmo cluster sob dois planos de controlo, lado a lado. ### v1.6 — operação (`operations`, 6 cenários) O que um operador muda num cluster em produção, e o que cada mudança custa: - **Escalar para fora** e o rebalanceamento que se segue; **escalar para dentro**, drenando um broker antes de o remover. - **Reatribuição manual de partições**, e a mesma reatribuição **limitada sob carga** — onde vês uma réplica nova entrar tarde no ISR porque puseste um teto ao seu ritmo de recuperação para proteger o tráfego vivo. - **Alterações de configuração a quente** e **quotas de cliente** que estrangulam um produtor atrasando as respostas em vez de descartar dados. ## O que vem a seguir 74 de 122 cenários, sete pacotes entregues e um sandbox de modo livre que já consegue modelar todas as formas de cluster a que o resto do currículo se vai referir. A seguir vem a v1.7 e o laboratório de falhas: injetar mortes de brokers e partições de rede em qualquer uma dessas cinco formas, a pedido. Abre o [simulador](/kafka-simulator/), arranca um sandbox de 2,5-DC e mata um DC de dados, e depois vê um observador ser promovido para te manter acima de `min.insync.replicas`.