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

Question

J'étudie le fonctionnement de la validation en deux phases dans une transaction distribuée. Je crois comprendre que dans la dernière partie de la phase, le coordinateur de transaction demande à chaque nœud s’il est prêt à s’engager. Si tout le monde est d’accord, alors il leur dit de s’engager.

Qu'est-ce qui empêche l'échec suivant?

1. Tous les nœuds répondent qu'ils sont prêt à s'engager
2. La transaction le coordinateur leur dit de "continuer" et commettre " mais l'un des nœuds se bloque avant de recevoir cette message
3. Tous les autres noeuds ont été validés, mais la transaction distribuée est maintenant corrompue
4. Je crois comprendre que lorsque le noeud bloqué reviendra, sa transaction aura été annulée (car il n'a jamais reçu le message de validation)

Je suppose que chaque nœud exécute une base de données normale qui ne connaît rien des transactions distribuées. Qu'est-ce qui m'a manqué?

Answer 1

Résumant les réponses de chacun:

1. Il est impossible d'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. Il n'est pas demandé aux noeuds de revenir en arrière, car certains d'entre eux ont déjà été validés. Ce qui se passe, c'est que lorsque le noeud écrasé revient, le coordinateur de transaction lui dit de terminer la validation.

Answer 2

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 que lorsque le noeud écrasé devient disponible, le coordinateur de transaction lui dit de s’engager à nouveau.

Parce que le nœud a répondu positivement dans le message "preparer" phase, il est nécessaire de pouvoir "commettre", même après un crash.

Answer 3

Non. Le point 4 est incorrect. Chaque nœud enregistre dans le stockage stable qu'il a été en mesure de valider ou d'annuler la transaction, de sorte qu'il puisse exécuter les commandes même après des plantages. Lorsque le noeud écrasé réapparaît, il doit se rendre compte qu'il a une transaction en état de pré-validation, rétablir les verrous ou autres contrôles pertinents, puis tenter de contacter le site coordinateur pour collecter le statut de la transaction.

Les problèmes ne surviennent que si le nœud en panne ne réapparaît jamais (alors tout le reste pense que la transaction était OK ou le sera quand le nœud en panne reviendra).

Answer 4

La 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 de ce journal ne sont jamais perdues ou corrompues, et deux nœuds peuvent communiquer l'un avec l'autre. "

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

Answer 5

Il existe de nombreuses façons d’attaquer les problèmes liés à la validation en deux phases. Presque tous finissent par être une variante de l’algorithme de validation triphasé de Paxos. Mike Burrows, qui a conçu le service de verrouillage Chubby de Google basé sur Paxos, a déclaré qu'il existe deux types d'algorithmes de validation distribués: "Paxos et les algorithmes incorrects". - dans une conférence que j'ai vue.

Une des choses que le noeud en panne pourrait faire, quand il se réveille, est en disant: "Je n'ai jamais entendu parler de cette transaction, aurait-elle dû être validée?" au coordinateur, qui lui dira quel était le vote.

N'oubliez pas qu'il s'agit d'un exemple de problème plus général: le nœud en panne pourrait manquer de nombreuses transactions avant d'être récupéré. Par conséquent, il est extrêmement important que, lors de la récupération, il communique avec le coordonnateur ou une autre réplique avant de se rendre disponible. Si le nœud lui-même ne peut pas dire s'il s'est écrasé ou non, les choses deviennent plus compliquées, mais toujours traitables.

Si vous utilisez un système de quorum pour les lectures de base de données, les incohérences seront masquées (et portées à la connaissance de la base de données).