LinuxTag 2007: High- Availability PostgreSQL and clustering concepts
Hans-Jürgen Schönig spricht über die verschiedenen Möglichkeiten, mit Postgres eine hochverfügbare Lösung zu bauen und stellt dabei zunächst die »klassischen« Alternativen hot standby/failover, synchrone Replikation und asynchrone Replikation vor. Dabei weißt er auch jeweils auf die Vor- und Nachteile hin:
- failover schützt nicht vor PEBKAC: Wenn der Admin einen Table dropt, dann ist der weg, und zwar auch auf dem Failover-Rechner. Von Vorteil ist allerdings die einfache Implementierung, da Lösungen sowohl auf Hardware- (SAN) als auch auf Softwarebasis bestehen.
- Synchrone Replikation kann ebenfalls nicht vor PEBKAC schützen; hinzu kommt, dass der Kommunikationsaufwand hierbei noch einmal deutlich höher wird.
- Asynchrone Replikation bietet die Möglichkeit, Fehler noch abfangen zu können, bevor sie repliziert werden. Außerdem wird Synchronisierung über schlechte Leitungen und über weite Entfernungen möglich und kann zeit- oder ereignisgesteuert getriggert werden. Vor allem diese erhöhte Flexibilität spricht für die asynchrone Replikation.
- 2-Phase-Commit: Kennt man aus dem Informatik-Studium. Soll zwar absolut unfehlbar sein und auch einen Reboot mitten in der Transaktion überstehen, in der Praxis kann halt doch immer etwas schief gehen.
Was HJS dann als Ansatz vorschlug, hat man schon unter vielerlei Namen gehört: HJS nennt es (Data) Queing, in der aktuellen DB-Forschung wird es wohl strombasierte Verarbeitung genannt, früher einmal hieß so etwas pipe oder auch batch processing. Die zu replizierenden Objekte (Daten, Metadaten, ...) werden asynchron vom Master auf den Slave übertragen und dort in die Datenbasis übernommen. Dabei muss die replizierende DB nicht die gleiche Struktur – noch nicht einmal das gleiche DBMS aufweisen.
Durch diesen Ansatz erhöht sich noch einmal die Flexibilität: Man kann weniger wichtige oder besonders umfangreiche Daten off-peak replizieren, wichtige Daten werden im Sekundentakt gepusht, und man kann auf Master und Slave(s) unterschiedliche DB-Schemata haben, die über Skripte (oder anderes) aufeinander abgebildet werden. Besonders dieser letzte Punkt ist für verteilte und gewachsene Anwendungen sehr interessant: Da kann man nicht mal kurz runterfahren, um auf ein anderes System oder ein anderes Schema umzusteigen.
Da ist tatsächlich high availability gefragt, und genau die wird mit diesem Ansatz erreicht.
Guter Vortrag, danke!
Ähnliche Artikel in diesem Blog:
