APRENDER. PRATICAR. EVOLUIR.Um ensaio com premissas explícitas
Esta oficina continua o cluster saudável do laboratório: três votantes originais e um candidato já promovido. A sequência foi escolhida para observar quatro votos, uma paragem e a remoção posterior da identidade antiga. Não é um procedimento universal de substituição. A documentação de reconfiguração apresenta também substituição por remoção seguida de adição; a escolha depende do estado, da versão e do procedimento aplicável. Sob perda de maioria, não podes presumir que a sequência saudável aceita novas alterações. Distingue recuperação de membros, substituição planeada e recuperação de desastre antes de preparar comandos ou compromissos de prazo com o negócio.
Parar e remover são transições diferentes
O laboratório escolhe um membro original que não é o líder e para apenas o seu processo. Permanecem quatro votos configurados e três processos ativos, suficientes para a maioria de três. Uma escrita sintética confirma progresso nesse estado. Depois, a remoção da identidade antiga é submetida ao cluster. O inventário passa a três votantes e a maioria necessária regressa a dois. A evidência confirma a identidade antiga ausente, o substituto presente e o valor sintético nos membros ativos. Uma linha do tempo com estas observações é mais útil do que reportar apenas servidor retirado, pois permite reconstruir a margem em cada fase.
O regresso de uma identidade removida
O exercício volta a arrancar o processo antigo com o seu próprio diretório descartável. O processo reconhece que a identidade foi removida e termina; a composição mantém o substituto. Isto demonstra por que motivo rollback não pode significar apenas voltar a executar o binário anterior. A remoção é estado do cluster. Uma recuperação real precisa de procedimento compatível com esse estado e de proteção dos dados que possam ser necessários à investigação. O laboratório não aceita diretórios externos e elimina apenas os dados temporários que criou. Não uses este exercício como autorização para apagar ou reutilizar diretórios de uma instalação existente.
Reconciliar antes de repetir
Após a substituição, o laboratório tenta promover novamente o membro já votante. O comando é rejeitado, embora o estado pretendido já exista. Esta observação separa objetivo, estado e código de saída. Um executor que só aceita sucesso do comando pode tentar desfazer trabalho correto para satisfazer o script. Num timeout anterior, o problema é diferente: o estado ainda não é conhecido. Em ambos os casos, consulta a composição e preserva a identidade alvo antes de escolher a ação seguinte. Regista quem fez a observação, a hora e o que continua incerto, para evitar que uma mudança de turno reinicie a sequência por suposição.
Aceitar o consumidor e a margem restante
No cluster final de três votantes, o laboratório para um follower, confirma outra escrita e volta a integrar esse processo com os seus dados. Isto demonstra a observação local de uma paragem, não a perda de uma zona ou a recuperação de um job bancário. Um consumidor configurado apenas para o endpoint retirado pode continuar a falhar quando o cluster já funciona. Define operações funcionais, origem de rede, latência aceitável, janela de observação e responsável pela aceitação. Regista separadamente recuperação do cluster, recuperação do consumidor e redundância reposta. O ensaio no portátil não qualifica Linux de produção, segurança, capacidade nem domínios físicos independentes.
Handover e decisão de fechar
Prepara um exercício de quarenta e cinco minutos em inglês. Durante quinze minutos, a equipa constrói a cronologia de uma substituição fictícia e calcula a maioria em cada fase. Aos quinze minutos, recebe um inject: o cluster funciona, mas o job de reconciliação aponta ao endpoint antigo. Usa mais quinze minutos para atribuir diagnóstico, comunicar impacto no cut-off e definir a próxima atualização. Nos quinze minutos finais, apresenta um handover com composição, identidade removida, evidência, consumidor pendente, responsável e limite para novas mudanças. Só fecha os critérios demonstrados; uma aprovação administrativa não transforma uma operação ainda falhada em recuperação funcional.
3 voters + 1 learner -> majority 2
4 voters after promotion -> majority 3
1 voter process stopped -> still 4 configured, 3 live
old identity removed -> 3 configured, majority 2
# Observed local sequence; assess prerequisites for any real change.Parar o membro antigo deixa quatro votos configurados e três processos ativos. Remover a identidade deixa três votos. Arrancar os dados antigos não desfaz essa remoção.
Armadilhas comuns
Chamar rollback a um simples restart; repetir operações após timeout; medir apenas saúde do cluster; aceitar testes no mesmo host como prova de perda de zona.
Tópicos relacionados: Domínios de falha e capacidade residual · Quorum e isolamento de escritores · Eleição, regresso e manutenção
Fecha a mudança com identidade, composição e resultado funcional reconciliados. Mantém visíveis as limitações e os critérios de aceitação ainda pendentes.
Referência: etcd runtime reconfiguration · DR HA 2026-09; Pacemaker 3.0, etcd 3.6, PostgreSQL 18 and selected Kubernetes/AWS behavior