Como os compromissos em duas fases impedem a falha do último segundo?

Question

Estou estudando como o commit bifásico funciona em uma transação distribuída. Entendo que, na última parte da fase, o coordenador de transações pergunta a cada nó se está pronto para se comprometer. Se todos concordaram, ele diz para eles seguirem em frente e se comprometerem.

O que impede a seguinte falha?

1. Todos os nós respondem que estão prontos para se comprometer
2. O coordenador de transações diz para eles "vá em frente e cometer", mas um dos nós trava antes de receber esta mensagem
3. Todos os outros nós se comprometem com sucesso, mas agora a transação distribuída é corrupta
4. Entendo que quando o nó quebrado voltar, sua transação será revertida (já que nunca recebeu a mensagem de confirmação)

Estou assumindo que cada nó está executando um banco de dados normal que não sabe nada sobre transações distribuídas. O que eu perdi?

Answer 1

Resumindo as respostas de todos:

1. Não se pode usar bancos de dados normais com transações distribuídas. O banco de dados deve suportar explicitamente um coordenador de transações.

2. Os nós não são instruídos a reverter porque alguns dos nós já se comprometeram. O que acontece é que, quando o nó travado volta, o coordenador de transações diz para terminar o compromisso.

Answer 2

Não, eles não são instruídos a reverter porque, no cenário do pôster original, alguns dos nós já se comprometeram. O que acontece é que, quando o nó travado fica disponível, o coordenador de transações diz para se comprometer novamente.

Como o nó respondeu positivamente na fase "preparar", é necessário poder "comprometer", mesmo quando voltar de um acidente.

Answer 3

Não. O ponto 4 está incorreto. Cada nó registra em armazenamento estável que foi capaz de comprometer ou reverter a transação, para que ele possa fazer o que comandou mesmo em falhas. Quando o nó travado voltar, ele deve perceber que possui uma transação no estado pré-comprometimento, restabeleça quaisquer bloqueios relevantes ou outros controles e, em seguida, tente entrar em contato com o site do coordenador para coletar o status da transação.

Os problemas só ocorrem se o nó travado nunca voltar (então todo o resto pensa que a transação foi boa ou será quando o nó quebrado voltar).

Answer 4

O comprometimento de duas fases não é infalível e foi projetado apenas para funcionar nos 99% dos casos de tempo.

"O protocolo pressupõe que haja armazenamento estável em cada nó com um tronco de escrita, que nenhum nó trava para sempre, que os dados no tronco de escrita nunca são perdidos ou corrompidos em um acidente e que quaisquer dois nós podem se comunicar um com o outro."

http://en.wikipedia.org/wiki/two-phase_commit_protocol

Answer 5

Existem muitas maneiras de atacar os problemas com o compromisso bifásico. Quase todos eles acabam como uma variante do algoritmo de comprometimento trifásico do Paxos. Mike Burrows, que projetou o serviço de bloqueio gordinho no Google, baseado em Paxos, disse que existem dois tipos de algoritmos de confirmação distribuídos - "paxos e os incorretos" - em uma palestra que vi.

Uma coisa que o nó acidentado poderia fazer, quando se reproduza, é dizer: "Eu nunca ouvi falar dessa transação, deveria ter sido cometido?" Para o coordenador, que dirá qual foi a votação.

Lembre -se de que este é um exemplo de um problema mais geral: o nó quebrado pode perder muitas transações antes de se recuperar. Portanto, é terrivelmente importante que, após a recuperação, converse com o coordenador ou outra réplica antes de se disponibilizar. Se o nó em si não sabe dizer se ele travou ou não, as coisas se envolvem mais, mas ainda são tratáveis.

Se você usar um sistema quorum para leituras de banco de dados, a inconsistência será mascarada (e divulgada pelo próprio banco de dados).