Reprises sur Pannes d'une BD

1
Reprises sur Pannes d'une BD

• Witold Litwin

2
Pannes d'une BD

• Matériel
• RAM ou CPU
• données sont perdues
• Disque
• données sont perdues ou corrompues
• Coupures de alimentation
• il faut "shut-down" la BD proprement
• Logiciel
• tout peut arriver

3
Reprises sur pannes

• Panne régulière
• reprise à partir du journal et du checkpoint
• Panne catastrophique
• reprise à partir d'une sauvegarde (copie globale)
  de la BD
• A froid (règle générale)
• l'accès des usagers à la base est arrêté
• A chaud
• l'accès à la base continue
• préférable dans une BD répartie

4
Principes généraux de reprise

• Une transaction unité de reprise
• l'effet de toute transaction commise doit être
  restauré
• l'effet de toute transaction avortée doit être
  annulé
• Un fichier dit journal (log file) doit survivre
  aux pannes sur une mémoire stable
• bande ou disque

CT
OP
AT
CT
ChP
BT
temps
5
Articles du journal

• TID (début)
• TID (commit/abort)
• TID, Op, TupleId, BeforeImage, AfterImage
• BeforeImage Null pour un Insert
• AfterImage Null pour un Delete
• Log physique contient l'image-après physique
• Log logique permet de le déduire de Op
• Checkpoint record
• timestamp t
• copie du cache au moment t
• TIDs des transactions en cours au moment t

6
Reprise à partir du journal

• Les checkpoints sont pris aux intervalles
  réguliers
• Tout article du journal est écrit avant l'op.
  corresp.
• write-ahead protocol
• Et quand une reprise est à faire

7
Algo général de reprise

• on trouve le dernier checkpoint
• on restaure le cache
• on crée deux listes vides UNDO et REDO
• On lit le journal en arrière, 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
• Défais les transactions dans UNDO
• Refais les transaction dans REDO

8
C
T1
T2
A
T6
C
T3
C
T4
T5
panne
checkpoint
REDO ?
UNDO ?
9
Journalisation cache

• L'algo de reprise discuté ne marche que si toute
  opération est dans le journal avant d'être sur le
  disque
• Mais, écrire chaque opération dans le journal
  tout-de-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

10
Journalisation cache

• Problème
• la gestion du cache (ex. LRU) pourrait écrire une
  page de données 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 données du cache sur le
  disque que si
• LSN-max dans la page lt LSN-min du log-buffer

11
Tolérance aux pannes

• Possibilité de fonctionnement malgré les pannes
• en général avec une reprise à chaud
• Approche traditionnelle
• duplication en miroir du matériel et des données
• avantage suppl. le partage de charge
• ex. Tandem Non-Stop SQL

12
Tolérance aux pannes

• Duplication des CPU avec l'accès croisé aux
  disques est difficile à réaliser sur le matériel
  de grande diffusion
• Deux techniques en vogue pour ce matériel
• enregistrements en miroir sur les disques
• RAID 1
• enregistrements partiellement redondants
• RAID 2,..

13
Miroirs

• Tout enregistrement est fait en n - copies sur
  des disques indépendants
• par le SGBD
• par le SGF
• le SGBD n'écrit que la copie primaire
• le SGF propage l'enregistrement aux copies
• Les lectures sont réparties sur les copies
• pour maximiser la charge possible
• en général on reparti l'accès uniformément
• n copies permettent à la BD de survivre sans
  perte toute panne simultanée de (n - 1) volumes

n 2 en général
14
Miroirs

• Si une panne arrive à un volume, alors on lit une
  autre copie de l'enregistrement
• Le gestionnaire de reprise recrée alors le volume
  en panne sur un autre disque
• en général à chaud

15
Miroirs

• Coût
• n fois plus d'espace mémoire
• n fois plus d'accès en MAJ
• temps allongé d'une transaction
• si le SGBD gère tous les accès
• une incohérence temporaire entre les copies
• si le SGF gère les copies
• Avantage
• probabilité de panne totale décroît en facteur pn
• les perf. I/O en lecture croient en facteur n
• si le CPU n'est pas saturé

16
RAID

• Redundant Arrays of Independent Disks
• Plusieurs disques de petite taille et de grande
  diffusion
• coûtent moins qu'un grand disque d'une même
  capacité
• offrent plus de parallélisme
• sont plus fiable dans l'ensemble
• R. Katz D. Patterson, UC Berkeley
• RAID-1 - les miroirs
• RAID-2 - voir la littérature

17
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

18
RAID-4
Segment de parité
Segments de données
101...
001...
111...
100...
111...
...
...
Write
le tuple
101...
001...
111...
100...
...
19
RAID-4
Segment de parité
Segments de données
101...
001...
111...
100...
111...
...
...
Read
le tuple
101...
001...
111...
100...
...
20
RAID-4
Segment de parité
Segments de données
101...
001...
111...
100...
111...
...
...
Read
101...
001...
111...
100...
le tuple
21
RAID-4
Segment de parité
Segments de données
001...
111...
100...
111...
Reconstruction sur un disque nouveau (spare disk)
22
RAID-4
Segment de parité
Segments de données
spare disk
101...
001...
111...
100...
111...
Reconstruction sur un disque nouveau (spare disk)
23
RAID-5
S1,1
P1
S1,2
S1,3
S1,4
P2
S2,1
S2,3
S2,4
S2,2
P3
S3,1
P4
P5
Segments de données
Segment de parité
24
RAID

• Avantages RAID - 3 / RAID-1
• moins de mémoire additionnelle
• combien ?
• I/O rapide
• - de transfert
• parallélisme
• moindre coût
• disques bon marchés
• Limitation (peu importante en pratique)
• La BD ne survie que la panne d'un volume à la fois

Technologie en vogue
25
Multiordinateurs

• On peut stocker les données redondant d'une BD
  sur plusieurs sites
• même distants
• données d'une SDDS
• Structure de Données Distribuée et Scalable
• Une meilleure protection contre une panne
  catastrophique
• explosion, panne de courant, grève...
• Une meilleure sécurité
• il peut être nécessaire de pénétrer plusieurs
  sites pour avoir une donnée

26
Multiordinateurs

• Deux SDDSs haute-disponibilité connues
• LHM stocke la BD en miroirs
• LHS stocke la BD en segments, comme RAID
• mais en général en RAM distribuée
• et sur un nombre scalable de sites
• securité accrue
• l'accès pirate à un site amène des données
  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

27
Conclusion

• Les SGBDs peuvent tomber en panne
• La sauvegarde et reprise fiable d'une BD est un
  problème capital pour un SGBD
• Toute donnée commise doit être préservée
• On peut restaurer les données à partir du journal
• On peut aussi prévenir la perte de données par le
  stockage redondant
• RAID tout particulièrement
• et SDDS haute-disponibilité

28
FIN
29
(No Transcript)