APRENDER. PRATICAR. EVOLUIR.Parar um follower e observar o serviço restante
Depois de confirmar o líder, o laboratório para um follower que pertence ao cluster. Os outros dois membros confirmam uma escrita com after-one-stop. A paragem não remove o membro da composição: continuam a existir três votantes configurados e dois disponíveis. Esta distinção interessa em manutenção. Um inventário de processos vivos não substitui a composição e a comunicação entre votantes. O ensaio demonstra progresso com a maioria neste caso local; não promete ausência de impacto para qualquer cliente. Um consumidor que só conhece o endpoint parado pode continuar indisponível enquanto uma operação direta contra um membro saudável funciona. O diagnóstico deve conservar as duas observações.
Reintegrar o mesmo membro com os seus dados
O follower é reiniciado com o diretório original, sem criar outro cluster nem alterar a composição. O laboratório aguarda até conseguir ler nesse membro o valor confirmado durante a sua ausência. Esta é evidência mais útil do que apenas ver o processo arrancado. O procedimento aplica-se ao membro temporariamente parado que não foi removido; um membro removido permanentemente tem regras diferentes e não deve ser reintegrado por analogia. Num runbook, distingue reinício, substituição e recuperação de desastre. Antes de fechar a manutenção, confirma identidade, estado, operações e a margem que ficou disponível para a próxima falha. Um arranque com o nome certo não prova tudo isto.
Eleição do líder e recuperação do cliente
Noutro grupo, o laboratório termina abruptamente apenas o processo que identificou como líder. Os dois membros sobreviventes convergem num líder diferente e confirmam after-leader-stop. O antigo líder regressa e acompanha esse estado. O ensaio não mede um limite contratual de recuperação. Tem um prazo para falhar se a condição não for observada, mas esse prazo não é um SLA. A aplicação real pode precisar de reconectar, renovar sessões, descobrir endpoints e tratar operações sem resposta. Por isso, eleição concluída e batch recuperado são marcos distintos. Num comité, conserva o tempo e o âmbito de cada observação e evita extrapolar o portátil para uma arquitetura distribuída sob carga.
Recuperar quorum e reconciliar operações incertas
Quando dois votantes estão parados, o ensaio envia um put ao processo restante e não recebe confirmação dentro do prazo. Depois reinicia um dos membros parados, observa nova maioria funcional e lê a chave dessa tentativa. Na execução registada, o resultado foi ausência. O código admite presença ou ausência porque o timeout do cliente, sozinho, não determina o resultado final. A lição é reconciliar, não memorizar a saída desta execução. O ensaio confirma depois uma nova escrita e o regresso dos três membros, sem forçar mudanças de composição. Num serviço com efeitos externos, define como resolver a identidade e o resultado da operação antes de uma repetição que possa duplicar trabalho.
Learners e pré-condições de manutenção
Os exemplos de learners são análise documental, sem alterações de composição executadas neste laboratório. Um learner não promovido recebe estado, mas ainda não conta como votante. Assim, três votantes e um learner continuam a precisar de dois votos. A promoção exige condições verificadas pelo servidor, incluindo sincronização adequada. Não retires outro votante apenas porque o processo learner aparece num dashboard. A documentação recomenda mudanças controladas e verificadas uma de cada vez. Perder quorum também não se resolve com um member add normal enviado ao único sobrevivente, pois a mudança precisa do acordo do cluster. Distingue recuperar membros, substituir um membro e seguir um procedimento de recuperação quando a maioria não regressa.
Aceitação por capacidade, dependências e função
Num exemplo de planeamento, três zonas oferecem 400 pedidos/s cada e a carga é 750. Perder uma deixa 800 e uma margem nominal de 50, assumindo que tráfego e dependências permitem usar essa capacidade. O cálculo não demonstra o funcionamento da identidade ou configuração se esses serviços estiverem na zona perdida. A aceitação deve ligar a falha definida à função do consumidor, capacidade, erros e reconciliação. O laboratório local fornece observações sobre processos e consenso; não executou perda de zona, partição de rede real, fencing físico ou promoção PostgreSQL. A evidência registada inclui versão e hash do script, com ensaios de ambiente e revisão especializada ainda necessários para conclusões mais amplas.
configured voters = 3
1 stopped -> 2 live voters, majority possible
2 stopped -> 1 live voter, majority unavailable
learner before promotion -> no additional vote
# Process count alone is not quorum or service acceptance.Parar um follower permite continuar com dois votantes; parar dois deixa um processo acessível sem quorum. Repor um membro permite recuperar operações, mas o resultado do put que teve timeout é reconciliado separadamente.
Armadilhas comuns
Contar learners como votos; recriar cluster num reinício; tomar timeout por ausência; medir só eleição; usar três processos no mesmo host como prova de isolamento entre zonas.
Tópicos relacionados: Quorum, leituras e autoridade · Capacidade residual e domínios de falha · Fencing e recuperação de serviço
A operação segura exige saber que membros votam, que estado regressou e se o consumidor consegue concluir a função acordada.
Referência: etcd failure modes · DR HA 2026-09; Pacemaker 3.0, etcd 3.6, PostgreSQL 18 and selected Kubernetes/AWS behavior