Comment les validations en deux phases empêchent-elles les pannes de dernière seconde?

Question

Je suis en train d'étudier comment de validation à deux phases de travaux à travers une transaction distribuée. C'est ma compréhension que dans la dernière partie de la phase de la transaction coordinator demande à chaque nœud s'il est prêt à s'engager. Si tout le monde d'accord, il leur dit d'aller de l'avant et de s'engager.

Qu'est ce qui empêche la suite de l'échec?

1. Tous les nœuds de répondre qu'ils sont prêt à s'engager
2. La transaction coordonnateur raconte à "aller de l'avant et de s'engager", mais l'un des nœuds se bloque avant de recevoir cette message
3. Tous les autres nœuds de s'engager avec succès, mais maintenant, la transaction distribuée est corrompu
4. C'est ma compréhension que s'est écrasé lorsque le nœud est de retour, sa transaction ont été annulées (puisqu'il n'a jamais eu le message de commit)

Je suis en supposant que chaque nœud est en cours d'exécution normale de la base de données qui ne sait rien au sujet des transactions distribuées. Qu'ai-je manqué?

Answer 1

Non, ils ne sont pas invités à annuler, car dans le scénario de l'affiche d'origine, certains des nœuds ont déjà été validés. Ce qui se passe, c'est lorsque le noeud écrasé devient disponible, le coordinateur de transaction lui dit de valider à nouveau.

Étant donné que le nœud a répondu positivement à la phase de "préparation", il est nécessaire de pouvoir "commettre", même après un crash.

Answer 2

Résumer les réponses de chacun:

1. On ne peut pas utiliser des bases de données normales avec des transactions distribuées. La base de données doit explicitement prendre en charge un coordinateur de transaction.

2. Les nœuds ne sont pas invités à revenir en arrière, car certains des nœuds ont déjà été validés. En réalité, lorsque le noeud écrasé revient, le coordinateur de transaction lui dit de valider à nouveau.

Answer 3

Pas de. Le Point 4 est incorrect. Chaque nœud dossiers de stockage stable qu'il a été en mesure de valider ou d'annuler la transaction, de sorte qu'elle sera en mesure de le faire, comme c'est commandé, même à travers les accidents. Quand s'est écrasé le nœud est en haut, il doit réaliser qu'il a une transaction en pre-commit état, rétablir toute les serrures ou d'autres commandes, et ensuite tenter de communiquer avec le coordonnateur de site pour recueillir le statut de la transaction.

Les problèmes se produisent uniquement si s'est écrasé le nœud ne vient jamais de revenir en arrière (puis tout le reste pense que l'opération a été OK, ou seront, s'est écrasé lorsque le nœud est de retour).

Answer 4

Une validation en deux phases n'est pas infaillible, elle est simplement conçue pour fonctionner dans 99% des cas.

"Le protocole suppose qu'il existe un stockage stable sur chaque nœud avec un journal à écriture anticipée, qu'aucun nœud ne se bloque pour toujours, que les données du journal de réécriture à l'avance ne sont jamais perdues ou corrompues lors d'une panne, et que deux nœuds peuvent communiquer avec l'un l'autre."

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

Answer 5

Il existe de nombreuses façons d'attaquer les problèmes avec la validation en deux phases. Presque tous d'entre eux le vent comme une variante de la Paxos trois phases de validation de l'algorithme. Mike Burrows, qui a conçu le Joufflu serrure service de Google qui est basé sur Paxos, a dit qu'il y a deux types de distribués à commettre des algorithmes - "Paxos, et de mauvaises réponses" - dans une conférence que j'ai vu.

Une chose s'est écrasé le nœud peut faire, quand il reawakes, c'est dire "je n'ai jamais entendu parler de cette transaction, qui devrait-il été commis?" à la coordonnatrice, qui permettra de dire que le vote a été.

Gardez à l'esprit que ce est un exemple d'un problème plus général: le déroutement de nœud pourrait manquer de nombreuses opérations avant qu'il récupère. Par conséquent, il est très important que lors de la récupération, il faudrait en parler soit à la coordonnatrice ou d'une autre réplique avant de faire lui-même disponible. Si le nœud lui-même ne peut pas dire si oui ou non il est tombé en panne, alors les choses deviennent plus impliqués, mais encore souple.

Si vous utilisez un système de quorum pour les lectures de base de données, l'incohérence sera masqué (et fait connaître à la base de données elle-même).