1 Reprises sur Pannes d'une BD Witold Litwin

2 Pannes d'une BD n 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 n Logiciel –tout peut arriver

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

4 Principes généraux de reprise n Une transaction = unité de reprise –l'effet de toute transaction commise doit être restauré –l'effet de toute transaction avortée doit être annulé n Un fichier dit journal (log file) doit survivre aux pannes sur une mémoire stable –bande ou disque CTOPATCTChPBT temps

5 Articles du journal n TID (début) n TID (commit/abort) n 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 n Checkpoint record –timestamp t –copie du cache au moment t –TIDs des transactions en cours au moment t

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

7 n on trouve le dernier checkpoint n on restaure le cache n on crée deux listes vides UNDO et REDO n 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 ; n Défais les transactions dans UNDO n Refais les transaction dans REDO Algo général de reprise

8 panne T1 C T5 T3 C checkpoint T4 C T2 T6 A REDO = ?UNDO = ?

9 Journalisation & cache n L'algo de reprise discuté ne marche que si toute opération est dans le journal avant d'être sur le disque n Mais, écrire chaque opération dans le journal tout-de-suite est cher n 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 n 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 n 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 < LSN-min du log-buffer

11 Tolérance aux pannes n Possibilité de fonctionnement malgré les pannes –en général avec une reprise à chaud n 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 n Duplication des CPU avec l'accès croisé aux disques est difficile à réaliser sur le matériel de grande diffusion n Deux techniques en vogue pour ce matériel –enregistrements en miroir sur les disques »RAID 1 –enregistrements partiellement redondants »RAID 2,..

13MiroirsMiroirs n 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 n 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 n copies permettent à la BD de survivre sans perte toute panne simultanée de (n - 1) volumes n = 2 en général

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

15MiroirsMiroirs n 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 n Avantage –probabilité de panne totale décroît en facteur p n –les perf. I/O en lecture croient en facteur n »si le CPU n'est pas saturé

16RAIDRAID n Redundant Arrays of Independent Disks n 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 n RAID-1- les miroirs n RAID-2 - voir la littérature

17 n RAID-3 –bit-interleaving + parity n RAID-4 –block-interleaving + parity n RAID-5 –block-interleaving + rotated parity n RAID-6 –dual-redundancy »invention commerciale RAID-3,4,5RAID-3,4,5

18RAID-4RAID Segment de parité Segments de données Write le tuple...

19RAID-4RAID Segment de parité Segments de données Read le tuple

20RAID-4RAID Segment de parité Segments de données Read le tuple...

21RAID-4RAID Segment de parité Segments de données Reconstruction sur un disque nouveau (spare disk)

22RAID-4RAID Segment de parité Segments de données Reconstruction sur un disque nouveau (spare disk) spare disk

23RAID-5RAID-5 S1,1P1 Segment de parité Segments de données S1,2S1,3 P2S2,1 S1,4 P3 P4 P5 S2,3S2,4 S3,1 S2,2

24RAIDRAID n 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 n Limitation (peu importante en pratique) –La BD ne survie que la panne d'un volume à la fois Technologie en vogue

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

26MultiordinateursMultiordinateurs n Deux SDDSs haute-disponibilité connues –LH* M stocke la BD en miroirs –LH* S 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 n Un domaine de recherche –W. Litwin, M.-A. Neimat. High-Availability LH* Schemes with Mirroring. COOPIS-96, Bruxelles, Juin –W. Litwin, M-A Neimat. Scattered LH* files for high availability and security. Tech. Rep HPL & GERM, Sept. 1995

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

28 FINFIN

29