Datenbankmanagementsysteme (DBMS) sind in gegenwärtigen informationsverarbeitenden Applikationen und Diensten aufgrund des immer größer werdenden Datenaufkommens unverzichtbar. Der technische Fortschritt im Ausbau der Netzwerkinfrastrukturen, einhergehend mit einer stetig steigenden Anzahl an Nutzern und informationsverarbeitender Applikationen, steigert die in DBMS zu speichernden und zu verwaltenden Datenmengen. In Folge dessen steigen die Anforderungen an Datenbank-Server hinsichtlich der Systemlast und ihrer Verfügbarkeit. Dies wirft die zentralen Fragen auf:
- Wie kann die System-Verfügbarkeit eines DBMS erhöht werden?
- Wie kann ein DBMS hinsichtlich der Lastverteilung skaliert werden?
Für die Beantwortung dieser Fragen gibt es verschiedene technische Möglichkeiten. Diese Seminarabreit betrachtet Datenbankreplikation-Architekturen.
Inhalt
1. Einleitung
1.1 Motivation
1.2 Ziel der Ausarbeitung
1.3 Grundlagen der Replikation
1.4 Einsatzszenarien von Datenbankreplikationen
1.4.1 Datenverteilung
1.4.2 Lastverteilung und Skalierbarkeit
1.4.3 Verfügbarkeit
1.4.4 Wartung
2. Replikationsverfahren
2.1 Asynchrone Replikation
2.2 Synchrone Replikation
2.3 Semi-Synchrone Replikation
3. Replikationsarten
3.1 Anweisungsbasierte Replikation
3.2 Zeilenbasierte Replikation
3.3 Gemischte Replikation
4. Replikationstopologien
4.1 Master/Slave Replikation
4.2 Master/Master Replikation
4.3 Multi-Master Replikation
5. Fazit
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abbildungsverzeichnis
In Anlehnung an: Oracle Corp.(2010): MySQL Replikation – Höhere Skalierbarkeit und Verfügbarkeit mit MySQL 5.5 Seite 6, „Vergleich zwischen asynchroner und synchroner Replikation“ Abbildung 1: asynchrone Replikation
In Anlehnung an: Hrsg. O’Reilly Verlag (2009): High Performance MySQL, 2. Auflage (2009), Seite 376: „Wie die MySQL-Replikation funktioniert“ Abbildung 2: Funktionsablauf MySQL-Replikation
In Anlehnung an: Oracle Corp.(2010): MySQL Replikation – Höhere Skalierbarkeit und Verfügbarkeit mit MySQL 5.5 Seite 6, „Vergleich zwischen asynchroner und synchroner Replikation“ Abbildung 3: synchrone Replikation
In Anlehnung an: Oracle Corp.(2010):MySQL Replikation – Höhere Skalierbarkeit und Verfügbarkeit mit MySQL 5.5, S. 12, „Allgemeine MySQL Replikationstopologien“ Abbildung 4: Übersicht Replikationstopologien
1. Einleitung
1.1 Motivation
Datenbankmanagementsysteme (DBMS) sind in gegenwärtigen informationsverarbeitenden Applikationen und Diensten aufgrund des immer größer werdenden Datenaufkommens unverzichtbar. Der technische Fortschritt im Ausbau der Netzwerkinfrastrukturen, einhergehend mit einer stetig steigenden Anzahl an Nutzern und informationsverarbeitender Applikationen, steigert die in DBMS zu speichernden und zu verwaltenden Datenmengen. In Folge dessen steigen die Anforderungen an Datenbank-Server hinsichtlich der Systemlast und ihrer Verfügbarkeit. Dies wirft die zentralen Fragen auf:
- Wie kann die System-Verfügbarkeit eines DBMS erhöht werden?
- Wie kann ein DBMS hinsichtlich der Lastverteilung skaliert werden?
Für die Beantwortung dieser Fragen gibt es verschiedene technische Möglichkeiten. Diese Ausarbeitung befasst sich mit der Datenbankreplikation (Replikation), welche in dieser Arbeit die „Vervielfältigung von Daten zu einem oder mehreren“[1] Systemen beschreibt. „Mit einer Replikation kopiert oder dupliziert eine Datenbank Änderungsvorgänge von einem auf ein [weiteres] […] System […].“[2] Diese Systeme können sich dabei an einem oder mehreren physikalischen Standorten befinden.[3]
1.2 Ziel der Ausarbeitung
Diese Ausarbeitung betrachtet die gängigsten Replikationsarchitekturen asynchroner Datenbankreplikationen und befasst sich im Detail mit verschiedenen Replikationsverfahren und möglichen Replikationstopologien.
Das Ziel dieser Ausarbeitung ist die Beantwortung der Fragestellungen aus Absatz 1.1 hinsichtlich der möglichen Lasterverteilung, sowie der Erhöhung der Verfügbarkeit und gibt einen Überblick über die Technologie der Datenbankreplikation.
1.3 Grundlagen der Replikation
Replikation bedeutet im Kontext der DBMS, das Speichern gleicher Informationen auf mehreren physikalischen Datenbank-Systemen, die durch verschiedene Replikationsverfahren auf dem gleichen Informationsstand gehalten werden. Dieser Zusammenschluss wird auch Replikationsgruppe genannt. Dabei ist stets die geltende Voraussetzung an ein verlässliches System einzuhalten, nach welcher ein transaktives Datenbanksystem stets die vier Eigenschaften atomic, consistency, isolation und durability (ACID) aufweisen muss. Transaktive DBMS stellen sicher, dass eine Datenbanktransaktion vollständig abgeschlossen wird oder im Fehlerfall alle Änderungen dieser Transaktion rückgängig gemacht werden. Dabei muss jede Transaktion die vier ACID-Eigenschaften erfüllen (siehe Anlage: ACID (Atomic, Consistency, Isolation, Durability)).[4] Wie bei einem einzelnen System müssen alle Änderungen und replizierten Informationen diese Eigenschaften auch auf einem zweiten System erfüllen. Daher spielt die Replikationskonflikterkennung eine wichtige Rolle. Diese soll Konflikte zwischen den Datenständen (Inkonsistenzen) verhindern und gegebenenfalls auflösen. Dies stellt sich je nach Replikationstopologie (siehe Kapitel 4) einfacher oder komplizierter dar. Der Abgleich der Daten zwischen den einzelnen Systemen erfolgt mittels verschiedener Replikationsverfahren (siehe Absatz 2.1 bis 2.3).
Im Kontext der asynchronen Replikation werden die verschiedenen Systeme in Master- und Slave-Systeme unterschieden. Auf einem Master-System werden sowohl Schreib- (UPDATE, CREATE), wie auch Leseoperationen (SELECT) durchgeführt. Ein Slave-System hingegen dient nur Leseoperationen. Ein Master-System repliziert seine Änderungsdaten an ein Slave-System, nicht aber umgekehrt. Der genauere Ablauf der asynchronen Replikation ist in Absatz 2.1 beschrieben.
1.4 Einsatzszenarien von Datenbankreplikationen
Moderne informationsverarbeitende Systeme haben verschiedene Anwendungsfälle für den Einsatz asynchroner Datenbankreplikationen. Im Folgenden werden einige Szenarien vorgestellt, wie ein DBMS hinsichtlich der Verfügbarkeit und des Lastverhalten mittels Datenbankreplikation effektiver und leistungsfähiger werden kann.
1.4.1 Datenverteilung
Die Datenbankreplikation kann zur Speicherung einer Kopie der Daten zum Beispiel an einem entfernten Ort wie einer Außenstelle eingesetzt werden. Die Daten sind dann an beiden Standorten verfügbar. Abfragen gegen die Datenbank können dann beispielsweise an einem entfernten Standort gegen eine lokales System gestellt werden. Dies kann positive Auswirkungen auf die Antwortzeit des Systems auf Anfragen haben und die Last der Netzwerkverbindung zwischen den Standorten verringern.[5]
1.4.2 Lastverteilung und Skalierbarkeit
In der Regel muss ein DBMS mehr Abfragen als Änderungen auf seine Daten verarbeiten. Durch den Einsatz der Replikation können Abfragen auf mehrere Systeme verteilt werden. Einzelne Applikationen, die zum Beispiel nur Abfragen an die Datenbank stellen, können auch explizit auf ein Slave-System zugreifen.[6] Dies ist vor allem für sehr lastintensive Abfragen wie zum Beispiel durch Business Intelligence oder Data Mining Systeme vorteilhaft. Ein Weiteres Einsatzszenario wäre, ein Slave-System zum Erstellen von Backups zu nutzen, da Backups oftmals das Stoppen der Datenbank erfordern. Um hier die Verfügbarkeitszeit des Master-Systems zu erhöhen und zu entlasten, eignet sich hier ein gesondertes Slave-System.[7]
1.4.3 Verfügbarkeit
Die Verfügbarkeit eines DBMS wird bei der asynchronen Replikation erhöht, da die Daten auf mehreren Systemen vorgehalten werden. Weil das Master-System allerdings als einziges schreibendes System den sogenannten Single Point of Failure darstellt, könnte bei einem Ausfall des Master-Systems ggf. keine Änderungstransaktionen mehr verarbeitet werden. Abfragen gegen das Slave-System sind jedoch weiterhin möglich. Nicht synchronisierte Daten des Masters können hierbei aber verloren gehen.
Durch die Replikation kann die Wiederherstellungszeit gegenüber der Wiederherstellung aus einem herkömmlichen Backup beschleunigt werden, wei das Slave-System bereits die Daten vorhält und die weitaus aufwendigere Wiederherstellung, beispielsweise von einer Bandsicherung, nicht nötig wäre. Auch eine Konfigurationsänderung eines Slave-Systems zum neuen Master-System wäre eine denkbare Lösung für einen solchen Fall (siehe Absatz 4.2).
Zu beachten ist jedoch, dass der Einsatz von Datenbankreplikationen kein Backup ersetzen kann. So kann die Replikation nicht vor Fehlern in der Anwendungssoftware oder vor Bedienfehlern absichern. Würde beispielsweise ein Anwender versehentlich viele Datensätze löschen, würde dieser Vorgang durch die Replikationsmechanismen auch auf einem Slave-System ausgeführt. Womit auf beiden Systemen diese Informationen gelöscht wären. Es kann daher nur ein Teil eines umfassenderen Backupkonzeptes sein.
1.4.4 Wartung
Ein weiteres Einsatzszenario sind Wartungsarbeiten, wie System- und Versionsupdates oder Funktionserweiterungen. Diese können zunächst mit einem Slave-System erprobt werden. Bei Problemen oder Fehlern können auf diese Weise erste Erfahrungen der Administratoren an diesem System gesammelt werden und es wird kein Schaden an den Daten oder ein längerer Systemausfall riskiert. Nach der erfolgreichen Erprobung können die Neuerungen dann auf die weiteren Datenbanksysteme aufgespielt werden.[8]
2. Replikationsverfahren
2.1 Asynchrone Replikation
Bei der asynchronen Replikation werden die Daten vom Master-System zu einem oder mehreren Slave-Systemen kopiert. Dieser Kopiervorgang geschieht nur in eine Richtung (unidirektional) mit einer Zeitverzögerung, sodass nach erfolgreichem Abschluss einer Änderungstransaktion diese möglicherweise noch nicht zum Slave-System repliziert wurden. Eine Änderungstransaktion wird somit mit einem einfachen Commit (Ein-Phasen-Commit) bestätigt. Eine zum gleichen Zeitpunkt gestellte Abfrage an das Slave-System könnte ein veraltetes Ergebnis liefern, da die Daten unter Umständen noch nicht repliziert wurden.[9]
Abbildung in dieser Leseprobe nicht enthalten
In Anlehnung an: Oracle Corp.(2010): MySQL Replikation – Höhere Skalierbarkeit und Verfügbarkeit mit MySQL 5.5 Seite 6, „Vergleich zwischen asynchroner und synchroner Replikation“ Abbildung 1: asynchrone Replikation
Die Replikation findet dabei am Beispiel der MySQL-Replikation (siehe Abbildung 2) vereinfacht dargestellt wie folgt statt:
Das Mastersystem schreibt alle Änderungen in Form von Events in das sogenannte Binärlog. Ein Event beinhaltet genau die Informationen die ein Slave-System benötigt um die Änderung exakt wie das Master-System auszuführen. Im nächsten Schritt triggert das Master-System das Slave-System, dass neue Events im Binärlog vorhanden sind. Das Slave-System kopiert daraufhin das Binärlog vom Master-System auf sich selbst und schreibt alle Änderungen in sein sogenanntes Relay-Log. Dabei merkt es sich exakt die Position des letzten replizierten Events im Binärlog. Ist das Binärlog kopiert, spielt das Slave-System die Anweisungen ab und aktualisiert seine Daten.[10]
[...]
[1] Oracle Corp.(2010): MySQL Replikation – Höhere Skalierbarkeit und Verfügbarkeit mit MySQL 5.5, S. 5
[2] Oracle Corp.(2010): MySQL Replikation – Höhere Skalierbarkeit und Verfügbarkeit mit MySQL 5.5, S. 5
[3] Vgl. Oracle Corp.(2010): MySQL Replikation – Höhere Skalierbarkeit und Verfügbarkeit mit MySQL 5.5, S. 5
[4] Vgl. Theo Haerder, Andreas Reuter (1983): Principles of Transaction-Orientated Database Recovery, in: Computing Surveys Vol. 15 No.4, S. 288f
[5] Vgl. Oracle Corp.(2010):MySQL Replikation –Höhere Skalierbarkeit und Verfügbarkeit mit MySQL 5.5, S. 9f
[6] Vgl. Hrsg. O’Reilly Verlag (2009): High Performance MySQL, 2. Auflage (2009), S. 375
[7] Vgl. Oracle Corp.(2010):MySQL Replikation –Höhere Skalierbarkeit und Verfügbarkeit mit MySQL 5.5, S. 11
[8] Vgl. Hrsg. O’Reilly Verlag (2009): High Performance MySQL, 2. Auflage (2009), S. 375
[9] Vgl. Hrsg. O’Reilly Verlag (2009): High Performance MySQL, 2. Auflage (2009), S. 374
[10] Vgl. Sasha Pachev (2007): Understanding MySQL Internals (2009), S. 216f