SGBD distribué - Protocoles de validation

Dans un système de base de données local, pour valider une transaction, le gestionnaire de transactions doit uniquement transmettre la décision de s'engager au gestionnaire de reprise. Cependant, dans un système distribué, le gestionnaire de transactions doit transmettre la décision de s'engager à tous les serveurs des différents sites où la transaction est exécutée et appliquer uniformément la décision. Lorsque le traitement est terminé sur chaque site, il atteint l'état de transaction partiellement validée et attend que toutes les autres transactions atteignent leur état partiellement engagé. Lorsqu'il reçoit le message que tous les sites sont prêts à s'engager, il commence à s'engager. Dans un système distribué, tous les sites s'engagent ou aucun d'entre eux ne le fait.

Les différents protocoles de validation distribués sont -

  • Engagement en une phase
  • Engagement en deux phases
  • Engagement en trois phases

Validation distribuée en une phase

La validation distribuée en une phase est le protocole de validation le plus simple. Considérons qu'il existe un site de contrôle et un certain nombre de sites esclaves où la transaction est en cours d'exécution. Les étapes de la validation distribuée sont -

  • Une fois que chaque esclave a terminé localement sa transaction, il envoie un message «DONE» au site de contrôle.

  • Les esclaves attendent le message «Commit» ou «Abort» du site de contrôle. Ce temps d'attente s'appellewindow of vulnerability.

  • Lorsque le site de contrôle reçoit le message «DONE» de chaque esclave, il prend une décision de validation ou d'abandon. C'est ce qu'on appelle le point de validation. Ensuite, il envoie ce message à tous les esclaves.

  • A la réception de ce message, un esclave valide ou abandonne puis envoie un message d'acquittement au site de contrôle.

Validation distribuée en deux phases

La validation distribuée en deux phases réduit la vulnérabilité des protocoles de validation en une phase. Les étapes effectuées dans les deux phases sont les suivantes -

Phase 1: Prepare Phase

  • Une fois que chaque esclave a terminé localement sa transaction, il envoie un message «DONE» au site de contrôle. Lorsque le site de contrôle a reçu le message «DONE» de tous les esclaves, il envoie un message «Prepare» aux esclaves.

  • Les esclaves votent pour savoir s'ils veulent toujours s'engager ou non. Si un esclave veut s'engager, il envoie un message «Prêt».

  • Un esclave qui ne souhaite pas s'engager envoie un message «Not Ready». Cela peut se produire lorsque l'esclave a des transactions simultanées conflictuelles ou qu'il y a un délai d'attente.

Phase 2: Commit/Abort Phase

  • Une fois que le site de contrôle a reçu le message «Prêt» de tous les esclaves -

    • Le site de contrôle envoie un message «Global Commit» aux esclaves.

    • Les esclaves appliquent la transaction et envoient un message «Commit ACK» au site de contrôle.

    • Lorsque le site de contrôle reçoit le message «Commit ACK» de tous les esclaves, il considère la transaction comme validée.

  • Une fois que le site de contrôle a reçu le premier message «Not Ready» d'un esclave -

    • Le site de contrôle envoie un message «Global Abort» aux esclaves.

    • Les esclaves abandonnent la transaction et envoient un message «Abort ACK» au site de contrôle.

    • Lorsque le site de contrôle reçoit le message «Abort ACK» de tous les esclaves, il considère la transaction comme abandonnée.

Commit triphasé distribué

Les étapes de la validation distribuée en trois phases sont les suivantes -

Phase 1: Prepare Phase

Les étapes sont identiques à celles de la validation en deux phases distribuée.

Phase 2: Prepare to Commit Phase

  • Le site de contrôle émet un message de diffusion «Enter Prepared State».
  • Les sites esclaves votent «OK» en réponse.

Phase 3: Commit / Abort Phase

Les étapes sont identiques à la validation en deux phases, sauf que le message «Valider ACK» / «Abort ACK» n'est pas requis.