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 < 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 S1,2 S1,3 S1,4 P1 S2,2 S2,3 S2,4 P2 S2,1 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 • 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 • 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