Datenbanken. Inhalt. 12 Backup / Recovery. Yesterday Grundlagen Transaktionen MySQL Internals Clustering. Karl Meier karl.meier@kasec.ch

Transkript

1 Datenbanken 12 Backup / Recovery Karl Meier karl.meier@kasec.ch Yesterday Grundlagen Transaktionen MySQL Internals Clustering Inhalt 2 1

2 A DBA s backup song Yesterday, All those backups seemed a waste of pay Now my database has gone away Oh I believe in yesterday Suddenly, There's not half the files there used to be And there's a deadline hanging over me The system crashed so suddenly. I pushed something wrong What it was I could not say Now my data's gone and I long for yesterday-ay-ay-ay. Yesterday, The need for back-ups seemed so far away. Thought all my data was here to stay, Now I believe in yesterday. 3 Grundsatz The key to safe database management is taking regular backups. Aus dem InnoDB Handbuch 4 2

3 Einführung Ein RDBMS bietet verschiedene Funktionen, welche die Zuverlässigkeit der Datenbank und ihr Verbleiben in einem integeren Zustand gewährleisten soll. Diese Integrität muss erhalten bleiben, wenn Hard- oder Softwarefehler auftreten oder wenn mehrere Benutzer auf die Datenbank zugreifen. Ein Datenbankausfall kann verschiedene Ursachen haben: Systemabsturz Media Failure (Headcrash, Brand, ) Softwarefehler Handlingfehler Mutwillige Zerstörung oder Manipulation 5 Definition Datenbank-Recovery (Wiederherstellung einer Datenbank) Der Prozess des Zurückführens der Datenbank in einen korrekten Status nach dem Auftreten eines Fehlers. Unabhängig von der Ursache des Fehlers muss das RDBMS in der Lage sein, diesen zu beheben und die Datenbank in einen integeren Zustand zurückzuführen. 6 3

4 Medientypen Die Datenspeicherung umfasst im Allgemeinen vier unterschiedliche Medientypen: Hauptspeicher (Memory) Flüchtiger Speicher, gehen bei Systemausfällen verloren Festplatte (Disk) Nicht-flüchtiger Speicher, rechnerabhängig Magnetband (Tape) Nicht-flüchtiger Speicher, rechnerunabhängig, serieller Zugriff Optische Speicherung (Optical Device) Nicht-flüchtiger Speicher, rechnerunabhängig, Direktzugriff 7 Charakteristiken Preis Zuverlässigkeit Performance 8 4

5 Entwicklung Speicherdichte 1952 speicherte eine schrankgrosse IBM 726 noch ein Megabyte mit 100 Bits per Inch (bpi) in 9 Spuren/Inch auf 330 Meter Band war die Speicherdichte schon auf 1600 bpi gestiegen, ein Megabyte Daten liess sich jetzt auf 25 Metern Tape unterbringen schreibt ein S-DLT-Laufwerk auf 448 Spuren je Inch bei bpi ein MByte Daten auf 2,5 mm Band. 9 Stand heute 22. Januar 2010: Forscher von IBM Research Zürich haben in Zusammenarbeit mit dem japanischen Unternehmen FUJIFILM 29,5 Gigabit pro Quadratzoll (rund 6,45 cm2) auf ein weiterentwickeltes Test- Magnetband geschrieben das entspricht der 39-fachen Speicherdichte des momentan führenden Industriestandard-Magnetbandproduktes. Dieser Meilenstein zeigt, dass eine der ältesten Technologien zur Datenspeicherung das Potential besitzt, weitere Kapazitätssteigerungen für viele Jahre zu bieten

6 Stand heute in Zahlen Eine Bandkassette in der Grösse einer im Industriestandard LTO (Linear Tape Open) spezifizierten Kassette könnte mit den neuentwickelten Technologien und Bändern bis zu 35 Terabytes an unkomprimierten Daten aufnehmen. Dies entspricht ungefähr dem 44- fachen der Kapazität heutiger LTO-Kassetten der vierten Generation. Zur Veranschaulichung: 35 Terabytes an Daten entsprechen der Textmenge in circa 35 Millionen Büchern. Um diese aufzubewahren, würde man ein Bücherregal in einer Länge von etwa 400 Kilometern benötigen. 11 LTO Ultrium Linear Tape Open Spezifikation für Magnetbänder und Bandlaufwerke IBM, HP, Seagate (heute Quantum) Lösung für mehrere Hersteller Seit LTO 3 auch WORM möglich Halbleiterspeicher in der Kassette

7 Immer mehr Immer schneller 13 Dauerhaftigkeit Dauerhaftes Speichern bezieht sich auf Informationen, welche auf verschiedene nichtflüchtige Speichermedien mit unabhängigen Fehlermodi repliziert wurde. Speicherung mit der RAID Technologie zum Beispiel verhindert, dass Fehler auf einer einzelnen Festplatte, auch während der Datenübertragung, zu Datenverlust führt. 14 7

8 RAID Erhöhung der Ausfallsicherheit (Redundanz) Steigerung der Transferraten (Performance) Aufbau grosser logischer Laufwerke Austausch von Festplatten und Erhöhung der Speicherkapazität während des Systembetriebes Kostenreduktion durch Einsatz mehrerer preiswerter Festplatten hohe Steigerung der Systemleistungsfähigkeit 15 RAID Level 16 8

9 Fehlertypen Systemabsturz wegen Hard- oder Softwarefehlern führt zum Verlust des Hauptspeichers Media Failure wegen Headcrash oder unlesbaren Speichermedien führt zum Verlust eines Teiles des sekundären Speichers Fehler der Anwendungssoftware wegen eines Programmierfehlers führt zum Versagen einer oder mehrerer Transaktionen Katastrophen wie Feuer, Wasser, Erdbeben können zum Verlust von primärem und sekundärem Speicher führen Nachlässigkeit oder unbeabsichtigte Zerstörung Sabotage oder Manipulation von Daten oder Hardware 17 Auswirkungen Unabhängig von der Ursache des Fehlers müssen zwei grundsätzliche Auswirkungen berücksichtigt werden: Verlust des Hauptspeichers (inklusive Data Buffer) Verlust der Daten auf der Festplatte 18 9

10 Transaktionen Transaktionen stellen die grundlegende Einheit der Wiederherstellung in einem Datenbanksystem dar. Es ist Aufgabe des Wiederherstellungsmanagers, bei Auftretenden Fehlern zwei der vier ACID-Eigenschaften der Transaktionen zu garantieren, nämlich Atomicity (Alles-oder-nichts) und Durability (Dauerhaftigkeit). Das Schreiben in eine Datenbank ist kein atomarer Vorgang! Es ist zum Beispiel möglich, dass eine Transaktion zwar mit COMMIT beendet wurde, aber noch nicht dauerhaft auf die Festplatte geschrieben ist. 19 Ablauf (1) Eine Schreiboperation sucht die Adresse des Plattenblocks, der den Datensatz enthält überträgt den Plattenblock in den Data Buffer im Hauptspeicher ändert die Daten im Data Buffer schreibt den Data Buffer auf die Festplatte zurück Erst nachdem der Data Buffer in den sekundären Speicher entleert wurde, kann die Änderungsoperation als dauerhaft bezeichnet werden

11 Ablauf (2) Die Übertragung des Buffers in den sekundären Speicher kann durch ein COMMIT explizit ausgelöst werden (Erzwungenes Schreiben). Tritt nun vor dem Entleeren in den sekundären Speicher ein Fehler auf, muss der Wiederherstellungsmanager den Status der Transaktion bestimmen. Ist der Status Commited, muss wegen der Dauerhaftigkeit die Transaktion wiederhergestellt werden (Rollforward). 21 Ablauf (3) Es kann auch automatisch zu einer Entleerung kommen, wenn die Buffer voll sind. Tritt nun während oder nach dem Entleeren in den sekundären Speicher ein Fehler auf, muss auch in diesem Fall der Wiederherstellungsmanager den Status der Transaktion bestimmen. Ist der Status nicht Commited, muss wegen der Alles-oder-nichts Regel die Transaktion rückgängig gemacht werden (Rollback)

12 Beispiel T1 T2 T3 T4 T5 T6 t 0 t f 23 Beispiel InnoDB InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number InnoDB: Doing recovery: scanned up to log sequence number InnoDB: Doing recovery: scanned up to log sequence number InnoDB: Doing recovery: scanned up to log sequence number InnoDB: Doing recovery: scanned up to log sequence number InnoDB: Doing recovery: scanned up to log sequence number InnoDB: 1 uncommitted transaction(s) which must be rolled back InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx no InnoDB: Rolling back of trx no completed InnoDB: Rollback of uncommitted transactions completed InnoDB: Starting an apply batch of log records to the database... InnoDB: Apply batch completed InnoDB: Started mysqld: ready for connections 24 12

13 Einrichtungen zum Recovery Sicherungsmechanismus, welcher regelmässig Sicherungskopien der Datenbank erstellt Protokollierung, um den aktuellen Status der Transaktionen und Änderungen der Datenbank aufzunehmen (Redo Log) Checkpoints, welche an der Datenbank stattfindende Aktualisierungen dauerhaft machen Wiederherstellungsmanager, der dem System ermöglicht, die Datenbank nach einem Fehler in einen konsistenten Zustand zurückzuführen 25 Grundregeln Protokollierung auf stabilem Speicher UNDO Information, REDO Information Atomaritätsregel Stabile UNDO Information vor DB-Eintrag Persistenzregel (Durability) Stabile REDO Information vor DB-Eintrag Idempotenzregel Recoverymassnahmen sind beliebig oft wiederholbar 26 13

14 Sicherungsmechanismus Automatische Erstellung von regelmässigen Sicherungskopien der Datenbank Regelmässige Erstellung von Sicherungskopien der Protokolldatei Das System sollte zur Sicherung Online bleiben können Full / Differential / Incremental Save Rechnerunabhängiges Speichermedium 27 Protokollierung Spezielle Datei, als Protokoll (Journal) bezeichnet Enthält Informationen über Änderungen der DB Transaktionseinträge Checkpointeinträge Das Protokoll wird häufig für andere Zwecke als die Wiederherstellung verwendet. In diesem Fall können zusätzliche Informationen in der Protokolldatei enthalten sein

15 Protokollierung Ist sehr wichtig, daher mehrere Kopien Früher auf Tape wegen Zuverlässigkeit Heute Online auf Disk wegen Performance Schnelle Wiederherstellung nach kleinen Fehlern (z.b. deadlocks) Bei grosser Menge zusätzlich Offline Dateien Kann massgeblichen Einfluss auf die Gesamtleistung des Datenbanksystems haben 29 Checkpoint Checkpoint (Prüfpunkt) Der Punkt der Synchronisierung zwischen der Datenbank und der Transaktionsprotokolldatei. Alle Buffer werden in den Sekundärspeicher zwangsgeschrieben. Checkpoints sind in vorbestimmten Abständen zeitlich geplant und umfassen: Protokolleinträge Geänderte Blöcke im Data Buffer Checkpointeintrag (Alle aktiven Transaktionen) 30 15

16 Beispiel T1 T2 T3 T4 T5 T6 t 0 t c t f 31 Komponenten des DB Systems Offline Redolog PMON SMON Shared Pool SGA DB Buffer Pool Redo Log Buffer ARCH DBWR LGWR Daten Online Redolog 32 16

17 Techniken der Wiederherstellung Head Crash (starke Beschädigung) Backup Datenbackup Offline Redolog Online Redolog Zeit 33 Techniken der Wiederherstellung Systemausfall (kein physischer Schaden) (Backup) Datenbank Online Redolog Zeit 34 17

18 Techniken der Wiederherstellung Verzögerte Aktualisierung: Datenbankeintrag erfolgt erst nach COMMIT Allfälliges Rollforward erforderlich Transaktionsstart > Protokoll Aktualisierung > Protokoll Transaktionscommit > Protokoll Protokolleinträge > Disk (Protokoll) COMMIT wird ausgeführt Disk (Protokoll) > Datenbank 35 Techniken der Wiederherstellung Unmittelbare Aktualisierung: Datenbankeintrag erfolgt laufend (vor COMMIT) Allfälliges Rollback erforderlich Transaktionsstart > Protokoll Aktualisierung > Protokoll Aktualisierung > Data Buffer Protokoll Buffer > Disk Write-Ahead-Protokoll Data Buffer > Disk Transaktionscommit > Protokoll 36 18

19 Erweiterte Betrachtungen Transaktionen können heute auch sehr komplex sein, viele Datenelemente umfassen und sehr lange Dauern. Als Folge des Zeitfaktors ist eine lang andauernde Transaktion fehleranfälliger. Ein Abbruch dieser Transaktion kann oft nicht akzeptiert werden. Daher wird versucht, diese Transaktion in einen Zustand zurückzuführen, der kurz vor dem Ausfall bestand. Einsatz von Savepoints (Sicherungspunkten). 37 MySQL InnoDB Engine in MySQL: Reference Manual Kapitel Backing Up and recovering an InnoDB database

20

21

22

23 MySQL Internals 45 Storage Engine Konzept Parse MySQL Optimize Retrieve Store Database Management Level MyISAM InnoDB... Storage Engine Level 46 23

24 InnoDB InnoDB ist eine ACID konforme Storage Engine für MySQL für folgende Aufgaben commit / rollback recovery handling row level locking consistent, non-blocking reads FOREIGN KEYS 47 InnoDB Storage Engine 48 24

25 InnoDB Logging Hauptaufgabe ist die Sicherstellung der ACID Konformität beim Crash Recovery. redo log ( Rollforward ) Ein Redo Log für den gesamten Workspace Eine Transaktion kann mehrere Einträge schreiben undo log ( Rollback ) Zwei Undo Logs für jede Transaktion: UPDATE/DELETE, INSERT checkpoint Sicherungspunkt ( changes flushed to disk ) 49 Parameter 50 25

26 Backup Methoden Offline Backup DB kann zur Sicherung heruntergefahren werden Online Backup DB steht auch während Sicherung zur Verfügung 51 Offline Backup (binary) Datenbankverzeichnisse werden auf Betriebssystemebene kopiert. Vorteile: Nachteil: Geschwindigkeit Einfachheit DB darf während des Backups nicht geändert werden. Nur empfohlen für MyISAM Tabellen 52 26

27 InnoDB Offline Backup (binary) MySQL DB herunterfahren und kontrollieren, dass dies fehlerfrei geschieht. Alle Datenfiles kopieren. Alle InnoDB Logdateien kopieren. my.cnf/my.ini Konfigurationsdatei(en) kopieren. Alle.frm Dateien der InnoDB Tabellen kopieren. 53 Vorteile: einfach schnell Nachteile: Vorteile / Nachteile nicht kontrollierbar (Binary Dateien können korrupt sein, ohne dass dies beim Backup bemerkt wird) 54 27

28 Offline Backup (mysqldump) liefert eine Datei mit SQL-Kommandos Vorteil: Portabilität Nachteil: Geschwindigkeit 55 mysqldump C:\mysql\bin>mysqldump -u root -p mav t_ma Enter password: **** -- MySQL dump Host: localhost Database: mav Server version nt Table structure for table 't_ma' Dumping data for table 't_ma'

29 Backup aller Datenbanken mysqldump -u root --password=xxx --opt --all-databases >fullbak.sql Der Benutzer root muss auf alle Datenbanken Zugriff haben. Während des Backups ist die jeweilige DB für Schreiboperationen gesperrt. 57 mysqldump Syntax mysqldump [Optionen] dbname [Tabellen] >filename Ohne Tabelleangabe werden alle gesichert --opt als Kurzschreibweise für die Optionen: --add-drop-table, --add-locks, --quick, --all, --extendedinsert, --lock-tables --opt nicht ideal für InnoDB Tabellen 58 29

30 DB wiederherstellen (mysql) Einzelne Datenbank: mysql u root p mav < backup.sql ( In diesem Fall muss die Datenbank bereits existieren! ) Mehrere Datenbanken: mysql u root p < fullbak.sql 59 Schnelle Backups (mysqlhotcopy) Perl Script unter Linux/Unix LOCK TABLES und FLUSH TABLES Direkte Kopie von Tabellendateien Dieses Tool ist nur für MyISAM geeignet Achtung: Keine Fehlermeldung bei InnoDB! root# mysqlhotcopy dbname1 dbname2 dbname3 backup/ 60 30

31 ZRM for MySQL 61 Online Backup Für den Online-Backup steht MySQL Enterprise Backup zur Verfügung, welches Bestandteil der kommerziellen MySQL Enterprise Edition ist. InnoDB, MyISAM, Merge, Partition, Archive 62 31

32 ARCserve 63 Backup Exec Agenten für Oracle, DB2 oder MS SQL 64 32

33 Tivoli Storage Manager Data Protection for Oracle Data Protection for Microsoft SQL Data Protection for IBM Informix 65 MySQL Upgrades Datenbank sichern Server stoppen Neue Version MySQL installieren Grant Tabellen updaten (mysql DB) Konfigurationsparameter anpassen Achtung: Die DB mysql muss vor der Deinstallation gesichert werden, da diese gelöscht bzw. überschrieben wird

34 Datenbankmigration Für die Migration eines beliebigen Datenbanksystems auf MySQL stehen in der Regel mit mysqldump vergleichbare Werkzeuge zur Verfügung. MySQL Migration Toolkit SQLPorter Access-to-MySQL ( Freeware FmPro Migrator ( 350$ Die resultierenden SQL-Dateien sind selten voll kompatibel und müssen manuell nachbearbeitet werde. Meist bleiben dabei nicht alle Details der Spaltendefinitionen erhalten. 67 MySQL Migration Toolkit

35 SQLPorter Microsoft SQL Server Oracle Sybase Adaptive Server IBM DB2, UDB PostgreSQL MySQL Interbase 69 Screenshot

36 Import/Export von Textdateien LOAD DATA mysqlimport SELECT INTO OUTFILE mysqldump mysql (Text-, HTML-, XML-Export) eigene Scripts (z.b. mit Perl) 71 Beispiel /08/27 15:30 "Unbekanntes Ereignis" /08/27 15:47 "Keine Verbindung" /08/28 08:33 "Internetverbindung unterbrochen" /08/29 12:16 "Unbekannter Port" USE import; LOAD DATA INFILE c:/mysql/data/import/beispiel1.txt INTO TABLE t_beispiel1 FIELDS TERMINATED BY \t ENCLOSED BY \ LINES TERMINATED BY \r\n (port, date, time, text); 72 36

37 HTML-Datei erzeugen mysql -u root --password=xxx --html --execute= SELECT * FROM t_ma; mav > c:\temp\mav.html 73 Replikation Die Replikation ermöglicht es, zwei oder mehrere MySQL-Server auf unterschiedlichen Rechnern zu synchronisieren. MySQL unterstützt zur Zeit ausschliesslich eine Master(read-write)/Slave(read-only)-Replikation. Vorteile: Sicherheit und Performance Nachteil: Keine fail safe replication 74 37

38 Topologie 75 Zusammenfassung Concurrency Control Ziel: Isolation parallel laufender Transaktionen Datenkonsistenz: Serialisierbarkeit Verschiedene Isolationsstufen Methoden: Sperrverfahren / Nicht-Sperrverfahren pessimistisch / optimistisch Recovery Ziel: Abstraktion von Hardware- und Softwarefehlern Fehlerarten: Transaktions-, System- und Medienfehler Atomarität durch UNDO Information Dauerhaftigkeit durch REDO Information 76 38

39 News vom MySQL, Hersteller der gleichnamigen Open-Source- Datenbank, übernimmt das auf Cluster-Lösungen spezialisierte Softwarehaus Alzato. Hauptprodukt des im Jahr 2000 von Ericsson gegründeten Unternehmens ist der NDB-Cluster, ein hochverfügbares Datenmanagement-System, das vor allem im Telekommunikations- und IP-Umfeld eingesetzt wird. Die verwendete Technik, die nach Herstellerangaben bereits heute eine Verfügbarkeit von 99,999 Prozent ermöglicht, soll als Datenmanagement-Engine in die für das kommende Jahr geplante nächste Version der MySQL- Datenbank einfließen. (c t) 77 Clustering Der MySQL Cluster stellt eine Verbindung aus der bekannten MySQL Datenbank mit einer verteilten speicherresidenten Clustering-Architektur dar, die 99,999% Verfügbarkeit für geschäftskritische Datenbank-Anwendungen liefert. Hohe Verfügbarkeit ohne "Single Point of Failure". Grosse Leistungsfähigkeit Skalierbarkeit Tiefer Preis Datenblatt zum MySQL Cluster:

40 99.999% Verfügbarkeit Fehlertolerante Architektur Geplante Wartungsarbeit inklusive Automatische Übernahme im Fehlerfall Automatische Wiederherstellung Replikation über Regionen hinweg Recovery Mechanismus bei Totalausfall 79 Grosse Leistungsfähigkeit Kurze Antwortzeiten und hoher Datendurchsatz Datenbank im Hauptspeicher Asynchrones Schreiben von Logdateien Verteilte Prozesse innerhalb eines Clusters 80 40

41 Failover Extrem schnell (< 1Sek.) Automatisch Synchrone Replikation Kein single point of failure Hot Backups 81 Kennzahlen Availability % (<5 min downtime / year) Performance Response Time 5-10 millisecond (with synchronous replication) Throughput of 10,000+ replicated transactions/sec on a 2 Node Cluster, with 1 CPU Per Node (minimal configuration) Throughput of 100,000 replicated transactions/sec on 4 Node Cluster, with 2 CPU Per Node (low-end configuration) Failover Sub-second failover enables you to deliver service without interruption Scalability Near-linear scalability shown on system where each storage node executed on the following hardware: CPU:2x Intel Xeon Processors at 2.8 GHz, Memory:16GB RAM, HDD:4 x 73GB SCSI RAID 1, ControllerGigabit Ethernet For cost-effective scale-out: Add more storage nodes (8, 16, 32, etc.) per cluster, or Add more CPUs (4, 8, etc.) or Add more Memory (16GB, 32GB, etc.) per storage node Quelle: MySQL Cluster FAQ 82 41

42 Architektur 83 Architektur Der MySQL Cluster besteht aus drei Knotentypen: Storage Nodes (SN) Datenreplikation zwischen einzelnen Knoten Bearbeiten alle DB Transaktionen Management Server Node (MGM) System Konfiguration Üblicherweise ein MGM im Einsatz Aktiv beim Start und bei Systemrekonfiguration MySQL Server Nodes / Client Nodes (API) Verbindung zu allen DB Nodes Standard SQL Interface 84 42

43 Beispiel SN1 SN2 SN3 SN4 Node Group Node Group API1 MGM API2 85 Storage Engine NDB Entwickelt in Zusammenarbeit mit Ericsson für die Bedürfnisse von Telekommunikationsunternehmen. In-Memory Datenbank mit Logging-to-disk Shared Nothing Architektur MySQL Reference Manual : 17 MySQL Cluster

44 87 44