Cluster Mestre-Escravo - Como ter certeza de que o mestre está realmente morto para o escravo assumir?

Question

Cluster Mestre-Escravo - Como ter certeza de que o mestre está realmente morto para o escravo assumir?

#1 resposta do (3 votos)
#2 resposta do (0 votos)

5

Eu tenho um sistema interno de mensagens, semelhante a um agente de mensagens. Temos um intermediário de mensagem principal e um intermediário de mensagem de escravo. Um intermediário de mensagem apenas recebe mensagens e as envia para todos os nós. O escravo está agindo como um nó, recebendo mensagens do mestre e do estado de construção para poder assumir o controle em caso de falha do mestre.

Agora meu problema é: como posso detectar, se possível e sem intervenção humana, que o mestre está morto? O mestre pode parecer morto, e o escravo pode ser tentado a assumir, mas você pode acabar na situação de dois mestres em seu sistema.

Estou tentando entender como os sistemas de cluster implementam a detecção de dead-dead. Até agora parece que um humano tem que matar manualmente o mestre e ligar um escravo, mas seria muito mais preferível que este processo fosse automático.

message-queue cluster messaging

por Pika Sucar 28.05.2016 / 18:46

fonte

2 respostas

0

Veja o Teorema da PAC . Se você quiser que a Tolerância à Partição (isto é, o mestre pareça morto, mas não realmente), você deve sacrificar Consistência (ou seja, consenso principal) ou Disponibilidade (ou seja, manuseio automático do servidor inativo sem tempo de inatividade). Você não pode ter todos os três.

Além disso, como disse CodeInChaos no comentário, com apenas um mestre e um escravo, você não consegue distinguir um mestre morto de uma rede particionada. Para poder detectar e recuperar do particionamento de rede sem problemas de consistência maciça, você precisa de pelo menos três réplicas.

Se você está disposto a sacrificar Consistência, então com duas réplicas, você pode fazer o escravo assumir e declarar que é um novo mestre depois de incrementar um número de versão de troca. Tudo o que o antigo mestre faz será feito com o antigo número de versão de comutação, e quando o mestre e o escravo se reconectarem, qualquer coisa que o escravo não tenha reconhecido antes da partição de rede precisará ser descartada.

por 29.05.2016 / 03:14

fonte

Tags message-queue cluster messaging

Modelo “Clones” Adicionando complexidade ao projeto N-Tier MVC? MVVM Persistence from view model

score 3 · Accepted Answer

Eu sugeriria definir critérios do que significa "morto", então periodicamente pesquisar a condição de "morto" e realizar o balanço. Talvez "morto" seja definido como "não enviou nenhuma mensagem para nenhum dos nós em X segundos". Qualquer que seja a árvore de decisão que um ser humano siga atualmente para verificar se deve ou não virar o serviço. Pode ser 1 condição, 10 ou dezenas. Quão bem a lógica é definida irá controlar com que precisão detecta "morto" e falha.

Além disso, o processo de "swing over" deve incluir informar ao mestre "morto" que ele foi declarado como morto e não deve executar nenhum tipo de operação "mestre". Com uma exceção - você pode querer repetir todas as mensagens que foram passadas enquanto era master, mas não foram enviadas.

Ou, se o código do cliente estiver sob seu controle, faça com que os clientes gerenciem as mensagens que falharam na tentativa. Você precisa de algo para evitar que as mensagens caiam nas rachaduras.

Seria uma boa idéia ter também o mestre morto, se ele voltar online, para entrar online como um secundário ... e ter o detector de "deadness" agora pesquisando o novo mestre e pronto para falhar de volta o mestre original se esse mestre morrer e o mestre original estiver ativo.