Engagement en deux phases

En deux phases

La validation en deux phases ne garantit pas qu’une transaction dissortingbuée ne peut pas échouer, mais elle garantit qu’elle ne peut pas échouer en silence sans que le MT en soit conscient.

Pour que B puisse déclarer la transaction comme étant prête à être validée, B doit avoir la transaction dans un stockage persistant (c.-à-d. Que B doit pouvoir garantir que la transaction peut être validée en toutes circonstances). Dans cette situation, B a persisté dans la transaction mais le gestionnaire de transactions n’a pas encore reçu de message de B confirmant que B a terminé la validation.

Le gestionnaire de transactions interrogera à nouveau B lorsque B reviendra en ligne et lui demandera de valider la transaction. Si B a déjà validé la transaction, la transaction sera déclarée comme validée. Si B n’a pas encore engagé la transaction, celle-ci sera validée car elle l’a déjà persistée et est donc toujours en mesure de valider la transaction.

Pour que B tombe en panne dans cette situation, il devrait subir une défaillance catastrophique ayant perdu des données ou des entrées de journal. Le gestionnaire de transactions serait toujours conscient du fait que B n’avait pas signalé de validation réussie. ¹

En pratique, si B ne peut plus commettre la transaction, cela impliquerait que le sinistre qui a entraîné la sortie de B ait causé une perte de données et B signalait une erreur lorsque le TM lui demandait de commettre un TxID dont il ne connaissait pas ou ne pensait pas être dans un état commitable.

Ainsi, la validation en deux phases n’empêche pas une défaillance catastrophique, mais évite que la panne ne passe inaperçue. Dans ce scénario, le gestionnaire de transactions signalera une erreur à l’application si B ne peut pas valider.

L’application doit encore pouvoir récupérer de l’erreur, mais la transaction ne peut pas échouer en mode silencieux sans que l’application soit mise au courant de l’état incohérent.

Sémantique

• Si un gestionnaire de ressources ou un réseau tombe en panne en phase 1, le gestionnaire de transactions détectera une erreur fatale (impossible de se connecter au gestionnaire de ressources) et marquera la sous-transaction comme ayant échoué. Au retour du réseau, la transaction sera annulée sur tous les gestionnaires de ressources participants.

• Si un gestionnaire de ressources ou un réseau tombe en panne lors de la phase 2, le gestionnaire de transactions continue à interroger le gestionnaire de ressources jusqu’à ce qu’il soit restauré. Lorsqu’il se reconnectera au gestionnaire de ressources, il indiquera au gestionnaire de ressources de valider la transaction. Si le gestionnaire de gestion renvoie une erreur du type “Unknown TxID”, le TM sera au courant du problème de perte de données dans le gestionnaire de ressources.

• Si le TM tombe en panne en phase 1, le client se bloquera jusqu’à ce que le TM revienne, à moins qu’il n’arrive à expiration ou qu’il reçoive une erreur due à une connexion réseau endommagée. Dans ce cas, le client est informé de l’erreur et peut réessayer ou initier l’abandon lui-même.

• Si le TM tombe en phase 2, il bloquera le client jusqu’à ce que le TM revienne. Il a déjà signalé que la transaction était engageable et aucune erreur fatale ne devrait être présentée au client, bien que cela puisse bloquer jusqu’à ce que le TM soit réactivé. La MT aura toujours la transaction dans un état non validé et interrogera les gestionnaires de ressources à valider lors de sa remontée.

Les événements de perte de données post-validation dans les gestionnaires de ressources ne sont pas traités par le gestionnaire de transactions et dépendent de la résilience des gestionnaires de ressources.

La validation en deux phases ne garantit pas la tolérance aux pannes – voir Paxos pour un exemple de protocole traitant de la tolérance aux pannes – mais elle garantit que la défaillance partielle d’une transaction dissortingbuée ne peut pas être ignorée.

1. Notez que ce type d’échec peut également entraîner la perte de données provenant de transactions précédemment validées. La validation en deux phases ne garantit pas que les gestionnaires de ressources ne peuvent pas perdre ou corrompre des données ou que les procédures de reprise après incident ne gâchent pas.

Votre scénario n’est pas le seul où les choses peuvent finalement mal tourner malgré tous les efforts. Supposons que A et B ont tous deux signalé “prêt à s’engager” pour TM, puis que quelqu’un détwig la ligne entre TM et, disons, B. B attend le feu vert (ou non) de TM, mais cela a certainement gagné Ne pas attendre pour toujours que TM se reconnecte (ses propres ressources impliquées dans la transaction doivent restr bloquées / inaccessibles tout au long du temps d’attente pour des raisons évidentes). Donc, quand B attend trop longtemps pour son propre goût, il faudra ce qu’on appelle des “décisions heuristiques”. Autrement dit, il décidera de valider ou d’annuler indépendamment de TM, sur la base de, eh bien, je ne sais pas vraiment quoi, mais cela n’a pas vraiment d’importance. Il devrait être évident que de telles décisions heuristiques peuvent s’écarter de la décision de validation réelle prise par TM.

Je crois que l’engagement en trois phases est une approche bien meilleure. Malheureusement, je n’ai trouvé personne implémentant une telle technologie.

http://the-paper-trail.org/blog/consensus-protocols-three-phase-commit/

Voici les parties essentielles de l’article ci-dessus:

La difficulté fondamentale de 2PC est que, une fois la décision de validation prise par le coordinateur et communiquée à certaines répliques, les répliques vont de l’avant et agissent sur la déclaration de validation sans vérifier si toutes les autres répliques ont reçu le message. Ensuite, si une réplique qui a commis un crash avec le coordinateur, le système n’a aucun moyen de dire quel était le résultat de la transaction (puisque seul le coordinateur et la réplique qui a reçu le message le savent). Comme la transaction a peut-être déjà été validée sur la réplique en panne, le protocole ne peut pas être interrompu de manière pessimiste – car la transaction peut avoir des effets secondaires impossibles à annuler. De même, le protocole ne peut forcer la transaction à s’engager de manière optimiste, car le vote initial aurait pu s’abandonner.

Ce problème est – principalement – contourné par l’ajout d’une phase supplémentaire à 2PC, ce qui nous donne sans surprise un protocole de validation en trois phases. L’idée est très simple. Nous interrompons la deuxième phase de 2PC – «commit» – en deux sous-phases. Le premier est la phase de préparation à l’engagement. Le coordinateur envoie ce message à toutes les répliques lorsqu’il a reçu à l’unanimité des “oui” lors de la première phase. À la réception de ces messages, les répliques entrent dans un état où elles sont capables de commettre la transaction – en prenant les verrous nécessaires, etc. – mais surtout, ne faites aucun travail qu’elles ne pourront plus annuler par la suite. Ils répondent ensuite au coordinateur en leur disant que le message “prépare à commettre” a été reçu.

Le but de cette phase est de communiquer le résultat du vote à chaque réplique afin que l’état du protocole puisse être récupéré, quelle que soit la réplique meurt.

La dernière phase du protocole fait presque exactement la même chose que la phase originale «commit ou abort» dans 2PC. Si le coordinateur reçoit la confirmation de la livraison du message ‘prepare to commit’ de toutes les répliques, il est alors prudent de continuer à valider la transaction. Toutefois, si la livraison n’est pas confirmée, le coordinateur ne peut pas garantir que l’état du protocole sera récupéré en cas de panne (si vous tolérez un nombre fixe d’échecs, le coordinateur peut continuer après avoir reçu f + 1). confirmations). Dans ce cas, le coordinateur annulera la transaction.

Si le coordinateur devait tomber en panne à un moment donné, un nœud de récupération peut reprendre la transaction et interroger l’état à partir des répliques restantes. Si un réplica qui a commis la transaction est tombé en panne, nous soaps que tous les autres réplicas ont reçu un message “prepare to commit” (sinon le coordinateur ne serait pas passé à la phase de validation) et le noeud de récupération sera donc capable de déterminer que la transaction a pu être engagée et de guider le protocole jusqu’à sa conclusion. Si une réplique signale au noeud de récupération qu’elle n’a pas reçu de préparation, le noeud de récupération sait que la transaction n’a pas été validée sur une réplique et pourra donc abandonner ou réexécuter le protocole de manière pessimiste. Depuis le début.

3PC résout-il tous nos problèmes? Pas tout à fait, mais ça se rapproche. Dans le cas d’une partition réseau, les roues se détachent plutôt – imaginez que toutes les répliques reçues «se préparent à commettre» se trouvent d’un côté de la partition et celles qui ne le sont pas de l’autre. Ensuite, les deux partitions continueront avec les nœuds de récupération qui valident ou abandonnent respectivement la transaction, et lorsque le réseau fusionne, le système aura un état incohérent. 3PC a donc des performances potentiellement dangereuses, tout comme 2PC, mais il fera toujours des progrès et satisfera donc ses propriétés de vivacité. Le fait que 3PC ne bloque pas les pannes à un seul nœud le rend beaucoup plus attrayant pour les services où la haute disponibilité est plus importante que les faibles latences.