Modul 11: Failover Replikation

Question 1

RDBMS Replikation

Answer 1

• In-Memory Datenbanken vereinen
OLAP und OLTP in einem System
• Rechenintensive Read-Only OLAP
Transaktionen erzeugen die größte Last
• Idee für sehr grosse Systeme: lagere
diese komplexen Read-Only
Transaktionen durch Replikation in
eigenes System aus

Question 2

Replikation

Welche Eigenschaften hat Replikation?

Welche Vorteile bietet Replikation?

Answer 2

1. Nur committede Transaktionen werden repliziert
2. Reihenfolge der Transaktionen wird immer beibehalten
3. Bei mehreren Replicas werden die Transaktionen unterschiedlich schnell –
   ja nach Last – nachgespielt
4. Vorteil: Master DB wird nicht beeinträchtigt
5. Übliche Verzögerung liegt bei < 1 Sekunde

Question 3

Transaktions Wiederholung

Answer 3

• TAs werden immer atomer ausgeführt (alles oder nichts)
• Sichtbar erst nach COMMIT
• TAs können gruppiert werden durch Group Commits
• Unterscheidung zwischen READ ONLY und MODIFYING Transaktionen
• Kennzeichnung in Tabelle mittels Timestamp

Question 4

Fail-Over`

Fragen:
• Wie wird überhaupt festgestellt,
dass der Master ausgefallen ist?
• Welche Replika soll übernehmen?
• Wie wird sichergestellt, dass der
neue Master den letzten Stand hat?

Answer 4

Schritt 1: Commits von Client an
Replikas durchreichen

Schritt 2: Bestätigung von Replikas an Master

Schritt 3: Bestätigung von Master an Clients

Schritt 4: Ausstehende Acknowledges einholen

Question 5

Fail-Over Steuerung

Answer 5

1. Master sendet „Heartbeat“ Message alle 50 ms an Replikas
2. Gepaart mit Transaktionsdaten oder als leere Nachricht
3. Sobald alle Replikas 3 Nachrichten vermissen, wird Fail-Over initiiert
4. Die Replikas votieren für die Replika, die von allen anderen erkannt wird,
   neuer Master zu werden
5. Die Replika wird zum neuen Master ernannt
6. Alle Replikas informieren den neuen Master über ihren
   Transaktionsstand
7. Neuer Master spielt ggfs. Fehlstand nach

Question 6

Vor-/Nachteile
Real Application Cluster

Vorteile

Answer 6

Vorteile:
• Übernahme der Funktionalität bei Ausfall eines Servers ohne administrativen
Eingriff
• Geringer Zeitaufwand für Wiederanlauf
o Client-Reconnect (erneute Verbindungsaufnahme zur Datenbank über einen anderen Datenbankserver im Cluster)
erfolgt für den Anwender bzw. die Applikation
o SELECT-Statements läuft transparent und innerhalb einiger (Mill-) Sekunden auf Ersatzknoten
• Komplette Hardware kann - anders als beim Fail-Over Cluster - auch während des
Normalbetriebs genutzt werden.
• Parallelisierung über alle Clusterknoten hinweg realisierbar
• Dynamische Zuordnung von Datenbank Services möglich
• Kompensation eines Rechenzentrumsverlustes, wenn der RAC und sein Shared
Media entsprechend verteilt wurde („Stretched Cluster“, bis ca. 2000 m)

Question 7

Vor-/Nachteile
Real Application Cluster

Nachteile:

Answer 7

Nachteile:
• Stretching des Clusters über ca. 2000 m nicht mehr möglich (Latenzprobleme).
• Bei Ausfall des gesamten Rechenzentrums fällt der gesamte Cluster aus.
→ Remote Standby-Datenbank (Oracle Real Application Cluster)
• Kein oder nur eingeschränktes Abfangen von logischen Korruptionen möglich
→ zeitverzögerte Stand-By Datenbank
• Wenn eine Instanz ausfällt, ist die ganze Datenbank nicht verfügbar, und zwar
solange, bis das GRD (Global Resource Directory) neu gestartet wurde
• Werden zur gleichen Zeit bzw. kurz aufeinander folgend auf mehreren Instanzen
des Clusters Daten angefordert, die in denselben Datenbank-Blöcken liegen, so
werden diese zwischen den Buffer-Caches der betroffenen Instanzen transferiert.
→ Gefahr dass die Datenbank sich nur damit beschäftigt, die Blöcke hin und her zu
schieben.