1 CNAM Vendredi 29 Novembre 2002 Bases de Données Avancées UV C 19722 Responsable : Mr Scholl PROTOCOLE A DEUX PHASES Meryem Guerrouani.

Présentation au sujet: "1 CNAM Vendredi 29 Novembre 2002 Bases de Données Avancées UV C 19722 Responsable : Mr Scholl PROTOCOLE A DEUX PHASES Meryem Guerrouani."— Transcription de la présentation:

1 1 CNAM Vendredi 29 Novembre 2002 Bases de Données Avancées UV C 19722 Responsable : Mr Scholl PROTOCOLE A DEUX PHASES Meryem Guerrouani

2 2 PLAN Définition et outils généraux - la mémoire stable - Le coordinateur - Le journal dinscription Protocole de validation à deux phases - Phase 1 - Phase 2 Problèmes liés aux pannes Solution pour lever lincertitude dun exécutant Traitement de reprise après une panne Programmation de la validation à deux phases Conclusion

3 3 Définition et outils généraux Mémoire stable: Afin de résister aux pannes, Le stockage se fait sur deux disques ordinaires. Chaque bloc du disque 2 est une copie du bloc correspondant Dans le disque 1. Lors dun mise à jour dun bloc, on commence la mise à jour du bloc du disque 1, puis celui du disque 2.

4 4 s o t b w f h a s o t b w f h as o t b w f h a s o t b w f h a s o t b w f h a s o t b w f h a s (a):Stockage stable (b):Plantage après la m.à.j du disque 1 ©:m.à.j. du disque 2 Exemple de Stockage Stable Disque1 Disque2 Exemple de Stockage Stable

5 5 Définition et outils généraux Le coordinateur: C (« coordinator » dirige de façon centralisée les transactions Demande File vide P2 C P3 P1 Coordinateur OK C P3 P2 P1 P3 P2 C P3 P1 Coordinateur Relâchement

6 6 Définition et outils généraux(suite) Le journal de transactions distribuées (« distributed transaction log ») – Contient les informations suivantes: »Identifiant de la transaction. »Les fichiers et blocs impliqués. »Les anciennes valeur avant (lopération). »Les nouvelles valeurs (après lopération). –Le journal est mis à jour avant que les changement soient faits dans le fichier.

7 7 Exemple de journalisation Exemple de transaction utilisant deux variables partagées: x = 0; y = 0; Journal Journal Journal Début_Transaction x = x+1; y = y+2; x = y*y; Fin_Transaction X= 0 / 1 Y = 0 / 2 X = 0 / 1 Y = 0 / 2 X = 1 / 4

8 8 Propriétés dun protocole de validation C'est un protocole de consensus sur lexécution dune transaction entre les participant qui émettent un vote Oui pour une validation (« commit ») Non pour un abandon (« rollback ») 1.La décision générale de validation est prise si tous les participants ont votés oui 2.Un participant ne peut plus revenir sur sa décision

9 9 Le protocole de validation à deux phases Phase 1: -> Le coordinateur C écrit dans son journal -> C envoie « préparation" à tous les sites Si -> Chaque site Si prend une décision : - s'il valide Ti, alors :. Si écrit dans son journal. Si envoie "T prête" au coordinateur C - s'il ne valide pas Ti, alors :. Si écrit dans son journal. Si envoie « abandon T" au site C

10 10 Le protocole de validation à deux phases PHASE 2 ->A partir des messages reçus des sites Si, C prend une décision : -il valide T s'il a reçu "T prête" de tous les sites Si :. il ajoute à son journal. il envoie "valider T" à tous les sites Si -il abandonne T s'il a reçu au moins un message « abandon T" d'un site Si :. il ajoute à son journal. il envoie à tous les sites Si

11 11 Le protocole de validation à deux phases Chaque site Si : - inscrit dans son journal le message envoyé par C ( ou ) - envoie un accusé de réception au coordinateur C ->Quand le coordinateur C a reçu tous les accusés des sites Si, il ajoute : à son journal

12 12 Problèmes liés aux pannes Pour détecter les situations de pannes, on arme des délais de garde Délai de garde dépassé chez le coordinateur 1.Coordinateur en attente de validation => décision dabandon 2.Coordinateur en attente dacquittement => répétition du message Délai de garde dépassé chez un exécutant 1.En phase de préparation => décision dabandon 2.Après avoir vote => situation dincertitude => Blocage dune transaction.

13 13 Solution pour lever lincertitude dun exécutant Basée sur un dialogue entre les exécutants : certains sites peuvent savoir quel est le statut de la transaction 1.Lun des exécutants est encore dans la phase préparatoire => il va donc abandonner. 2.Lun des exécutants a déjà abandonné. 3.Lun des exécutants connaît le statut validé de la transaction

14 14 Traitement de reprise après une panne Après panne du coordinateur : Si reprise dans la phase préparatoire avant diffusion du statut de la transaction => abandonner la transaction. Si reprise après décision prise => ne rien faire. Après panne chez un exécutant : Si reprise dans la phase préparatoire => abandon de la transaction. Si reprise en état de décision connue => ne rien faire.

15 15 Programmation de la validation à deux phases Algorithme du coordinateur: Début envoyer message T_PREPERE à tous; écrire_stable début_valid (id_transaction); armer_délai_réponse; attente (évènement); Si (retombée_garde ou réponse non) alors écrire_stable abandon(id_transaction); envoyer T_ROLLBACK à tous; Finsi; Si (tous les exécutants votent oui) alors écrire_stable validation(id_transaction); envoyer C_COMMIT à tous les exécutants; Finsi; Fin coordinateur;

16 16 Début armer(délai_message_prépare); Attendre (évènement); si (retombée_garde) alors écrire_stable abandon(id_transaction); Finsi; Si (T_prépare et vote oui) alors écrire_stable oui (id_transaction); envoyer READY au coordinateur; armer(délai_message_valid_abandon); Attendre (évènement); si (retombée_garde) alors exécuter programme dincertitude; finsi; Algorithme dun exécutant

17 17 Si (message T_COMMIT) alors écrire_stable (validation(id_transaction)); écrire définitivement les modifications; finsi; Si (message T_ROLLBACK) alors écrire_stable (abandon(id_transaction)); envoyer non au coordinateur; détruire les information mémoire stable; finsi; Fin exécutant; Algorithme dun exécutant (suite)

18 18 Phase de dialogue entre participants Algorithme du demandeur du statut de la transaction Début envoyer DEM_statut(transaction) à tous; armer (délai_réponse); attendre (évènement); si (message_réponse T_COMMIT) alors écrire_stable (validation(id_transaction)); écrire définitivement les modifications; finsi; si (message_réponse T_ROLLBACK) alors écrire_stable (abandon(id_transaction)); détruire les modifications ; finsi; si (retombée_garde) alors état dincertitude non levé recommencer; finsi; Fin demandeur;

19 19 Phase de dialogue entre participants Algorithme du répondeur aux demandes du statut de la transaction Début attendre (évènement); si (message DEM_statut) alors; si (le site a voté non ou il a noté abandon(transaction)) alors envoyer(T_ROLLBACK); sinon si (le site a noté validation(transaction)) alors envoyer(T_COMMIT); finsi; Fin répondeur;

20 20 CONCLUSION Le protocole de validation en deux phases nest pas unique mais,cest le plus utilisés les transactions atomiques.