Vous êtes sur la page 1sur 29

Reprises

Reprises sur
sur Pannes
Pannes d'une
d'une BD
BD
Witold Litwin

Pannes
Pannes d'une
d'une BD
BD

Matriel
RAM ou CPU
donnes sont perdues

Disque
donnes sont perdues ou corrompues

Coupures de alimentation
il faut "shut-down" la BD proprement

Logiciel
tout peut arriver

Reprises
Reprises sur
sur pannes
pannes

Panne rgulire
reprise partir du journal et du checkpoint

Panne catastrophique
reprise partir d'une sauvegarde (copie globale) de la BD

A froid (rgle gnrale)


l'accs des usagers la base est arrt

A chaud
l'accs la base continue
prfrable dans une BD rpartie

Principes
Principes gnraux
gnraux de
de reprise
reprise

Une transaction = unit de reprise


l'effet de toute transaction commise doit tre
restaur
l'effet de toute transaction avorte doit tre
annul

Un fichier dit journal (log file) doit survivre


aux pannes sur une mmoire stable
bande ou disque
CT

OP

AT

CT
temps

ChP

BT

Articles
Articles du
du journal
journal

TID (dbut)
TID (commit/abort)
TID, Op, TupleId, BeforeImage, AfterImage
BeforeImage = Null pour un Insert
AfterImage = Null pour un Delete
Log physique contient l'image-aprs physique
Log logique permet de le dduire de Op
Checkpoint record
timestamp t
copie du cache au moment t
TIDs des transactions en cours au moment t

Reprise
Reprise partir
partir du
du journal
journal
Les checkpoints sont pris aux intervalles
rguliers
Tout article du journal est crit avant l'op.
corresp.

write-ahead protocol

Et quand une reprise est faire:

Algo
Algo gnral
gnral de
de reprise
reprise

on trouve le dernier checkpoint


on restaure le cache
on cre deux listes vides UNDO et REDO
On lit le journal en arrire, et la liste des TIDS
dans l'article checkpoint :
si Commit T, alors REDO := REDO + T ;
si Abort T, alors UNDO := UNDO + T ;
si Begin T et T REDO, alors
UNDO := UNDO + T ;

Dfais les transactions dans UNDO


Refais les transaction dans REDO

T1
T2

T3

T6

T4

T5
checkpoint
REDO = ? UNDO = ?

panne

Journalisation
Journalisation &
& cache
cache
L'algo de reprise discut ne marche que si toute
opration est dans le journal avant d'tre sur le
disque
Mais, crire chaque opration dans le journal toutde-suite est cher
On utilise le log-buffer et on crit sur le disque
dans le journal

chaque commit
quand le log-buffer est plein

Journalisation
Journalisation &
& cache
cache

Problme:

la gestion du cache (ex. LRU) pourrait crire une


page de donnes non-commises sur le disque
avant le log-buffer
le log-buffer pourrait se perdre durant la panne
l'algo de reprise ne marcherait plus

Solution typique (une variante de log-ahead)

LSN - Log Sequence # est donn chaque enr. du


journal
on n'crit une page de donnes du cache sur le
disque que si
LSN-max dans la page < LSN-min du log-buffer

10

Tolrance
Tolrance aux
aux pannes
pannes

Possibilit de fonctionnement malgr les pannes


en gnral avec une reprise chaud

Approche traditionnelle
duplication en miroir du matriel et des donnes
avantage suppl. : le partage de charge

ex. Tandem Non-Stop SQL

11

Tolrance
Tolrance aux
aux pannes
pannes
Duplication des CPU avec l'accs crois
aux disques est difficile raliser sur le
matriel de grande diffusion
Deux techniques en vogue pour ce matriel

enregistrements en miroir sur les disques


RAID 1

enregistrements partiellement redondants


RAID 2,..

12

Miroirs
Miroirs

Tout enregistrement est fait en n - copies sur des disques


indpendants
par le SGBD
par le SGF
n = 2 en gnral
le SGBD n'crit que la copie primaire

le SGF propage l'enregistrement aux copies

Les lectures sont rparties sur les copies


pour maximiser la charge possible
en gnral on reparti l'accs uniformment

13

n copies permettent la BD de survivre sans perte toute


panne simultane de (n - 1) volumes

Miroirs
Miroirs

14

Si une panne arrive un volume, alors on lit une


autre copie de l'enregistrement
Le gestionnaire de reprise recre alors le volume
en panne sur un autre disque
en gnral chaud

Miroirs
Miroirs

Cot
n fois plus d'espace mmoire
n fois plus d'accs en MAJ
temps allong d'une transaction
si le SGBD gre tous les accs
une incohrence temporaire entre les copies
si le SGF gre les copies

Avantage
probabilit de panne totale dcrot en facteur pn
les perf. I/O en lecture croient en facteur n
si le CPU n'est pas satur

15

RAID
RAID
Redundant Arrays of Independent Disks
Plusieurs disques de petite taille et de grande
diffusion

cotent moins qu'un grand disque d'une mme capacit


offrent plus de paralllisme
sont plus fiable dans l'ensemble
R. Katz & D. Patterson, UC Berkeley

RAID-1 - les miroirs


RAID-2 - voir la littrature

16

RAID-3,4,5
RAID-3,4,5

RAID-3
bit-interleaving + parity

RAID-4
block-interleaving + parity

RAID-5
block-interleaving + rotated parity

RAID-6
dual-redundancy
invention commerciale

17

RAID-4
RAID-4
Segment
de parit

Segments de donnes

101...

001...

111...

100...

111...

...

...

Write

101...

18

001...

le tuple
111...

100...

...

RAID-4
RAID-4
Segment
de parit

Segments de donnes

101...

001...

111...

100...

111...

...

...

Read
101...

19

001...

le tuple
111...

100...

...

RAID-4
RAID-4
Segment
de parit

Segments de donnes

101...

001...

111...

100...

...

111...

...

Read
101...

20

001...

111...

100...

le tuple

RAID-4
RAID-4
Segment
de parit

Segments de donnes

001...

111...

100...

111...

Reconstruction sur un disque nouveau (spare disk)

21

RAID-4
RAID-4
spare disk

101...

Segment
de parit

Segments de donnes

001...

111...

100...

111...

Reconstruction sur un disque nouveau (spare disk)

22

RAID-5
RAID-5

S1,1

S1,2

S1,3

S1,4

P1

S2,2

S2,3

S2,4

P2

S2,1

P3

S3,1

P4
P5

Segments de donnes

23

Segment de parit

RAID
RAID

Avantages RAID - 3 / RAID-1


moins de mmoire additionnelle
combien ?

I/O + rapide
- de transfert
paralllisme

moindre cot

Technologie en vogue

disques bon marchs

Limitation (peu importante en pratique)


La BD ne survie que la panne d'un volume la fois

24

Multiordinateurs
Multiordinateurs

On peut stocker les donnes redondant d'une BD sur


plusieurs sites
mme distants
donnes d'une SDDS
Structure de Donnes Distribue et Scalable

Une meilleure protection contre une panne catastrophique


explosion, panne de courant, grve...

Une meilleure scurit


il peut tre ncessaire de pntrer plusieurs sites pour avoir une
donne

25

Multiordinateurs
Multiordinateurs

Deux SDDSs haute-disponibilit connues


LH*M stocke la BD en miroirs
LH*S stocke la BD en segments, comme RAID
mais en gnral en RAM distribue
et sur un nombre scalable de sites
securit accrue
l'accs pirate un site amne des donnes partielles
un bit sur n si l'on distribue sur n segments

Un domaine de recherche
W. Litwin, M.-A. Neimat. High-Availability LH* Schemes with Mirroring. COOPIS-96,
Bruxelles, Juin 1996.
W. Litwin, M-A Neimat. Scattered LH* files for high availability and security. Tech. Rep HPL
& GERM, Sept. 1995

26

Conclusion
Conclusion
Les SGBDs peuvent tomber en panne
La sauvegarde et reprise fiable d'une BD est un
problme capital pour un SGBD
Toute donne commise doit tre prserve
On peut restaurer les donnes partir du
journal
On peut aussi prvenir la perte de donnes par
le stockage redondant

RAID tout particulirement


et SDDS haute-disponibilit
27

FIN
FIN
28

29