Vous êtes sur la page 1sur 34

Chapitre 1

Systèmes transactionnels (suite)

3.3 Atomicité et durabilité

• Atomicité et durabilité sont liées:

1: begin-transaction 2: read(account1, v1) 3: read(account2, v2) 4: v1 v1 – 1 5: v2 v2 + 1 6: write(account1, v1) 7: write(account2, v2) 8: end-transaction

• La transaction se termine par commit, mais:

– v1 écrit en mémoire permanente, mais pas v2 (en raison d'un crash)

– atomicité violée, ou durabilité violée ?

• Conséquence: il est difficile de séparer les mécanismes qui assurent l’atomicité et de ceux qui assurent la durabilité

Atomicité et durabilité (2)

Idée générale:

• S’appuyer sur des protocoles locaux, qui chacun assure localement atomicité et durabilité

• Coordonner les protocoles locaux pour assurer que tous les sites accédés par la transaction décident commit ou tous les sites décident abort

Mémoire permanente vs. mémoire stable

• L'information sur disque est supposée permanente. Mais l'écriture sur disque n'est pas forcément atomique (donc risque d'état incohérent)

• Trois cas à considérer pour l'écriture d'un bloc sur disque:

1. écriture se termine correctement: le bloc contient la nouvelle valeur

2. crash durant l'écriture du bloc: le bloc est partiellement écrit, et se trouve dans un état incohérent

3. crash avant l'écriture (aucune donnée écrite): le bloc contient l'ancienne valeur

• Mémoire stable: abstraction introduite pour modéliser une mémoire permanente toujours dans un état cohérent (écriture sur disque atomique)

Mémoire stable

• Mémoire stable implémentée par réplication (un bloc logique de la mémoire stable implémenté par deux blocs physiques)

• Un checksum par bloc physique permet de savoir si le contenu d’un bloc est cohérent (bloc complètement écrit)

Ecriture d'un bloc (logique) en mémoire stable

• Ecriture du premier bloc (physique)

• Ecriture de la même information sur le deuxième bloc (physique)

L'écriture est considérée réussie dès que l'écriture du premier bloc se termine.

Lecture d'un bloc (logique) en mémoire stable

• Lecture des deux blocs physiques

• Si les deux blocs sont identiques (notamment checksums corrects), retourner le contenu de n'importe quel bloc

• Si un des blocs contient un checksum incorrect, alors mettre à jour l'autre bloc, et retourner le contenu du bloc correct (si premier bloc incorrect, alors retourne l'ancienne valeur, si le deuxième bloc incorrect, alors retourne la nouvelle valeur)

• Si les deux blocs contiennent un checksum correct, mais sont différents, alors mettre à jour le deuxième bloc avec le contenu du premier, et retourner le contenu du premier bloc (masque le crash durant l'écriture du deuxième bloc)

NB Ce protocole coûteux peut être exécuté lors d’un recovery. Cela permet par la suite de ne lire qu’un seul bloc.

Protocole de recouvrement local

• Exécuté par le LRM (Local Recovery Manager)

• Protocole LRM dépend de la technique utilisée pour l'écriture:

(1) in-place updating: valeur précédente écrasée (avant commit) (2) out-of-place updating: nouvelle valeur écrite n'écrase pas la précédente (avant le commit)

In-place updating

• La plupart des bases de données implémentent la technique in-place updating (raison d'efficacité)

• Cette technique nécessite en général de garder l’ancienne valeur et la nouvelle valeur dans un journal (log file):

– pré-image (before image): ancienne valeur

– post-image (after image): nouvelle valeur

In-place updating (2)

Buffers de logs

Log stable (sur disque)

BM
BM

Buffers de données

de logs Log stable (sur disque) BM Buffers de données Données stables (sur disque) Read/Write SysRép

Données stables (sur disque)

Read/Write

In-place updating (3)

Crash à l'instant t:

• Cas 1: une transaction T1 a committé, mais à l'instant t, les écritures de T1 n'ont pas été répercutées en mémoire stable

• Cas 2: une transaction T2 n'a pas committé, mais des écritures de T2 ont été répercutées en mémoire stable (cas possible si l'écriture du cache est sous le seul contrôle du BM).

• Cas 1: lors du recovery, le LRM lit la post-image de T1 du journal (en mémoire stable), et réécrit la post-image (action redo)

• Cas 2: lors du recovery, le LRM lit la pré-image de T2 du journal (en mémoire stable), et réécrit la pré-image (action undo)

Gestion du cache

Quatre stratégies:

• fix: le BM n'écrit aucune donnée non committée (le cache est fixé en mémoire principale) Définit une interdiction

• no fix: le BM peut propager en mémoire stable des données non committées Pas d’interdiction

• flush: le BM est forcé d'écrire des données committées en mémoire stable au moment du commit Définit une obligation

• no flush: le BM n'est pas forcé d'écrire des données committées en mémoire stable Pas d’obligation

Gestion du cache (2)

Quatre algorithmes:

• no-fix / no-flush (correspond à l'exemple des transactions T1, T2 ci- dessus) Technique utilisée dans les bases de données commerciales.

• no-fix / flush

• fix / no-flush

• fix / flush

Gestion du cache (3)

Dans ces quatre algorithmes:

• Début de transaction: le LRM écrit un enregistrement begin- transaction dans le journal

• Read: la donnée est lue depuis le cache (si disponible). Sinon la donnée est lue depuis la mémoire stable dans le cache, et la donnée est retournée à la transaction

• Write, Commit, Abort, Recovery: dépend de l'algorithme

No-fix / no-flush (redo / undo)

• Write: la donnée est mise à jour dans le cache (si présente). Sinon la page contenant la donnée est lue en mémoire stable, et la donnée est mise à jour. La pré-image et la post-image sont écrites dans le journal.

• Commit: le LRM écrit un enregistrement end-of-transaction dans le journal, et le journal est écrit en mémoire stable. Le LRM informe ensuite le scheduler du commit (le scheduler peut relâcher les verrous détenus par la transaction)

• Abort: le journal est utilisé pour exécuter les actions undo. Le LRM lit les pages modifiées dans le cache et utilise le journal pour écrire la pré- image (undo). Le LRM informe ensuite le scheduler de l'avortement (le scheduler peut relâcher les verrous détenus par la transaction).

Terminologie

• Un enregistrement du journal doit être écrit en mémoire stable avant l'écriture de la donnée correspondante. Ceci est appelé write ahead log protocol.

No-fix / no-flush (redo / undo) (2)

• Recovery: le LRM lit le journal depuis la mémoire stable et distingue deux cas:

(1) les transactions tels que begin-transaction et end-of-transaction sont dans le journal (la transaction a committé) (2) les transactions tels que begin-transaction uniquement est dans le journal (la transaction a avorté)

• Cas 1: le LRM exécute les actions redo, en utilisant la post-image du journal

• Cas 2: le LRM exécute les actions undo, en utilisant la pré-image du journal (Hyp: protocole write-ahead log)

Exemple

• Initialement: a=10, b=10

• T1 lit a et b, écrit a-10 dans a et b-10 dans b; commit de T1

• T2: identique à T1, crash avant commit de T2

• Recovery

• T3 identique à T1, T3 avorte

Réduction de la taille du journal

Il faut périodiquement vider le journal (sinon « recovery » prendrait beaucoup de temps).

Deux techniques:

• L’opération de réduction est exécutée lorsqu’aucune transaction n'est exécutée. Ceci est appelé réduction synchrone du journal

• L’opération de réduction est exécutée pendant l’exécution de transactions. Ceci est appelé réduction asynchrone du journal

Réduction synchrone du journal

Solution: mettre le données en mémoire stable à jour par rapport au contenu du journal (checkpointing):

• Ecrire begin-checkpoint dans le journal

• Exécuter les actions permettant de mettre les données en mémoire stable à jour par rapport au contenu du journal

• Ecrire end-checkpoint dans le journal

• Effacer tous les enregistrements du journal

Si un crash survient avant l'écriture de end-checkpoint, on recommence depuis le début (mise à jour des données en mémoire stable avec le contenu du journal).

Protocoles répartis

• Protocole local: exécute une action lors de commit et lors de abort

• Il faut un protocole pour assurer que tous les sites décident commit ou tous les sites décident abort:

– protocole de validation atomique (atomic commitment ou AC)

• Problème: le LRM ne peut pas attendre de connaître la décision commit avant d’exécuter les actions locales liées au commit:

– Transaction qui accède un site S1 et un site S2

– Les actions locales pour commit pas exécutées à l’instant t1

– La décision est commit

– Le site S1 crashe à l’instant t1

Solution: le LRM doit écrire le journal sur disque pour rendre « commit » possible (avant que le protocole de validation atomique ne décide « commit » ou « abort »)

Spécification du problème AC

Les processus doivent se mettre d’accord sur une décision commune

La décision est binaire: valider (commit) ou avorter

La décision est basée sur une valeur initiale pour chaque processus

La valeur initiale d’un processus est oui (= valider) ou non (= avorter)

La valeur initiale est appelée le vote du processus

.

Spécification du problème AC (2)

Le problème AC est spécifié par les propriétés suivantes:

• AC – Agrément Uniforme: Deux processus (coordinateurs ou participants) ne peuvent décider différemment.

• AC – Validité: Si un processus vote non, le décision doit être abort. Si tous les processus votent oui, et qu'il n'y a pas de défaillance, la décision doit être commit.

• AC- Terminaison: Tous les processus doivent décider.

Spécification du problème AC (3)

Remarque:

• Un processus ne vote oui qu’après avoir écrit dans le journal les informations rendant le commit local possible (puisque dans ce cas la décision peut être « commit ».

Validation atomique

Deux protocoles:

• 2PC (2 Phase Commit)

• 3PC (3 Phase Commit)

• 2PC est un protocole bloquant: le crash d’un processus p peut empêcher le protocole de se terminer avant le recouvrement de p

• 3PC est un protocole non bloquant

• Pour l’instant on ne discute que le protocole 2PC

• Le protocole (2PC ou 3PC) est initié par le TM (Transaction Manager), appelé aussi coordinateur du protocole. Le TM demande le vote des autres processus (appelés participants).

Algorithme 2PC

Deux phases:

• phase de vote

• phase de décision

coordinateur

participant

participant

vote-req

commit / abort

coordinateur participant participant vote-req commit / abort vote (yes/no) ack SysRép – Transactions-B A. Schiper

vote (yes/no)

ack

2PC: protocole du coordinateur

write begin-commit to the log send vote-req to the participants if all votes are received and all votes are yes then write commit to the log send commit to the participants else write abort to the log send abort to the participants wait for the ack from the participants write end-of-transaction to the log

2PC: protocole d’un participant

upon reception of vote-req do if participant is ready to commit then execute LRM actions to make later commit possible write ready to the log send yes to the coordinator else write abort to the log send no to the coordinator wait for the decision message

if the decision is commit then write commit to the log send ack to the coordinator perform local commit processing else write abort to the log send ack to the coordinator perform local abort processing

Défaillances

• Un crash peut empêcher le protocole de se terminer

• On distingue

– Protocole de terminaison: protocole exécuté par un processus en attente d’un message Exemple: un participant attend la décision du coordinateur. Si time-out expire, protocole de terminaison exécuté

– Protocole de recovery: protocole exécuté par un processus p lors du recouvrement de p après un crash.

Exemple de protocole de terminaison

upon reception of vote-req do if participant is ready to commit then execute LRM actions to make later commit possible write ready to the log; send yes to the coordinator else write abort to the log; send no to the coordinator

wait for the decision message

Après expiration du time-out:

• Contacter un autre participant

• Si un participant contacté a voté no, alors la décision est abort

• Si un partiticpant contacté a décidé commit, alors la décision est commit

Exemple de protocole de recovery

Processus p i recouvre après un crash:

• Aucun enregistrement ready dans son log:

– Pas de vote envoyé

– p i peut décider abort

• ready mais pas commit / abort dans le log

– Identique au cas d’une attente de la décision du coordinateur

– p i peut utiliser le protocole de terminaison

Variantes du 2PC

• Optimisations permettant de réduire le nombre de messages et le nombre d'enregistrements écrits dans le journal.

• Les deux variantes sont liées au message ack.

Presumed Abort 2PC.

• Principe: lorsqu'un participant recouvre, et contacte le coordinateur, si celui-ci ne trouve aucune information à propos de la décision, le coordinateur répond abort.

• Modification par rapport au 2PC:

– Si la décision est abort, le coordinateur n'attend pas les messages ack, et n'écrit pas abort dans son journal.

– Si la décision est abort, un participant n'envoie dans de ack au coordinateur

Presumed Commit 2PC.

• Le protocole presumed abort optimise le cas du abort.

• Il est plus logique d'optimiser le cas du commit (qui est en principe plus fréquent). C'est ce que fait le protocole presumed commit 2PC.

• Le protocole presumed commit est légèrement plus compliqué que le protocole presumed abort.