9 Replizierte Datenbanken
9.1 Write-All-Ansätze
Die bekannteste Variante ist die sogenannte Write-All-Read-Any- bzw. Read-Once-Write-All (ROWA)-Strategie. Sie verlangt die synchrone Änderung aller Replikate vor Abschluß einer Änderungstransaktion. Dadurch ist gesichert, daß jedes Replikat auf dem aktuellen Stand ist, so daß zum Lesen jedes beliebige ausgewählt werden kann. Die Auswahl kann im Hinblick auf minimale Kommunikationskosten oder zur Unterstützung von Lastbalancierung erfolgen. Weiterhin ergibt sich für Lesezugriffe eine erhöhte Verfügbarkeit, da diese durchführbar sind, solange wenigstens eine Kopie erreichbar bleibt.
Diese Vorteile gehen jedoch auf Kosten der Änderungstransaktionen. Zum einen ist es beim Einsatz eines verteilten Sperrverfahrens erforderlich, vor jeder Änderung eine Schreibsperre auf allen Kopien zu erwerben, was einen enormen Zusatzaufwand an Kommunikation einführen kann[36]. Die betroffenen Knoten sind ferner alle im Commit-Protokoll zu beteiligen. Bei einem Zwei-Phasen-Commit-Protokoll werden zunächst in Phase 1 die Änderungen an alle Knoten übertragen und dort protokolliert, bevor in der zweiten Commit-Phase die Replikate selbst aktualisiert und die Sperren freigegeben werden. Ein weiterer Schwachpunkt liegt darin, daß die Verfügbarkeit für Änderer schlechter ist als bei fehlender Replikation! Denn eine Änderung ist nicht mehr möglich, sobald einer der Rechner ausfällt, an dem ein Replikat des zu ändernden Objekts gespeichert ist.
Beispiel 9-2
- Für die Situation aus Beispiel 9-1 (Abb. 9-1) können mit dem ROWA-Protokoll in der Zentralen R2 sämtliche Lesezugriffe ohne Kommunikation auf der lokalen Kopie abgewickelt werden. Ebenso erfordert in den Filialen der Lesezugriff auf lokale Konten (A in R1, B in R3) keine Kommunikation. Jede Änderung eines Kontosatzes erfordert dagegen das Sperren sowie synchrone Aktualisieren beider Kopien. Nach einem Ausfall der Zentralen können daher nur noch Lesezugriffe erfolgen; der Ausfall eines Filialrechners verhindert weitere Änderungen von Konten der entsprechenden Filiale. Lesezugriffe auf lokale Kopien sind nach einem Rechnerausfall weiterhin möglich.
Zur Abschwächung des Verfügbarkeitsproblems wurde die Write-All-Available-Variante vorgeschlagen [BHG87], bei der nur die Replikate der verfügbaren Rechner gesperrt und aktualisiert werden müssen. Für einen ausgefallenen Rechner werden die nicht vorgenommenen Modifikationen eigens protokolliert und nach Wiedereinbringen des Rechners nachgefahren. Dieses Verfahren eignet sich allerdings nicht bei Netzwerk-Partitionierungen, da hierbei ein Auseinanderlaufen der in verschiedenen Teilnetzen vorgenommenen Änderungen droht. Ferner bleibt natürlich der hohe Mehraufwand für Änderer bezüglich Sperranforderungen und Commit-Protokoll.
[36] Dieser Aufwand ließe sich mit einem verteilten optimistischen Synchronisationsprotokoll (Kap. 8.3.3) vermeiden, bei dem Synchronisation sowie Aktualisierung der Replikate vollständig ins Commit-Protokoll integriert werden können. Optimistische Synchronisationsverfahren werden in diesem Kapitel jedoch nicht weiter betrachtet.