Hochverfügbare Datenbanken mit Replikation und Failover
Steht die Datenbank, stehen meist auch Shop, Kundenportal und Lager. Sortia Labs plant Replikation und automatisches Failover so, dass der Ausfall eines Servers möglichst wenig Wirkung hat, und probt das Umschalten, bevor es ernst wird. Dahinter steht Erfahrung aus Projekten für Banken, Zahlungsanbieter, Handel und Industrie.
- Datenbank-Cluster
- Failover
- Replikation
- Disaster Recovery
- Oracle Data Guard
- SQL Server Availability Groups
- PrimärknotenNimmt die Schreibzugriffe
- ReplikationLaufend
- ReplikBereit zur Übernahme
- UmschaltungGeplant und geübt
Bausteine einer hochverfügbaren Datenbank
Wie viel Verfügbarkeit Sie brauchen
Ein Onlineshop im Weihnachtsgeschäft braucht etwas anderes als ein internes Archiv. Jede zusätzliche Stufe an Verfügbarkeit kostet Server, Netz und Betreuung, deshalb wägen wir sie gegen das ab, was eine Stunde Stillstand Sie kostet.
Synchron oder asynchron
Synchrone Replikation hält bestätigte Transaktionen auch auf einem zweiten Server, kostet aber Schreibzeit und braucht kurze Netzwege. Asynchrone ist schneller, kann beim Umschalten aber die letzten Sekunden verlieren. Wir entscheiden pro Anwendung.
Cluster für Ihr System
PostgreSQL mit Patroni, MySQL und MariaDB mit Galera oder Percona XtraDB Cluster, MongoDB mit Replica Sets, Oracle mit RAC und Data Guard, SQL Server mit Availability Groups. Wir arbeiten mit den Werkzeugen, die zu Ihrem System gehören.
Umschalten ohne neue Adressen
Nach einem Failover soll die Anwendung weiterlaufen, ohne dass jemand Konfigurationen ändert. Dafür setzen wir je nach Umgebung ProxySQL, einen vorgeschalteten Proxy, eine virtuelle IP oder DNS-Einträge mit kurzer Gültigkeit ein.
Zweiter Standort
Ein Replikat in einem anderen Rechenzentrum ist für den Fall gedacht, dass Strom, Netz oder der ganze Standort ausfallen. Wir planen Latenz und Bandbreite und legen fest, wer im Notfall über die Umschaltung entscheidet.
Vom Ziel zum geprobten Failover
- 1
Anforderungen
Gemeinsam mit Fachbereich und IT legen wir fest, welche Systeme wie lange ausfallen dürfen und welcher Datenverlust tragbar ist. Daraus entsteht ein Zielbild mit Kosten.
- 2
Aufbau
Cluster und Replikate entstehen neben dem laufenden System. Wir synchronisieren die Daten, richten Überwachung und Alarme ein und beschreiben jeden Handgriff für den Notfall.
- 3
Probe
Vor dem Start simulieren wir den Ausfall von Server, Netz und Speicher, messen die Umschaltzeit und wiederholen die Probe in festen Abständen, damit das Verfahren eingeübt bleibt.
Fragen zu Hochverfügbarkeit
Was ist der Unterschied zwischen Hochverfügbarkeit und Disaster Recovery?
Hochverfügbarkeit fängt den Ausfall einzelner Server oder Laufwerke ab, meist automatisch und in Sekunden bis Minuten. Disaster Recovery greift, wenn ein ganzer Standort verloren ist oder Daten beschädigt sind: Dann wird aus der Sicherung wiederhergestellt oder auf einen anderen Standort gewechselt. Ein tragfähiger Plan braucht beides.
Ersetzt Replikation das Backup?
Nein. Replikation überträgt jede Änderung meist binnen Sekunden auf alle Knoten, auch ein versehentliches DELETE oder einen fehlerhaften Import. Dagegen helfen ein Backup mit Point-in-Time-Recovery oder ein Replikat, das Änderungen absichtlich verzögert übernimmt. Das Backup gehört getrennt vom Cluster aufbewahrt.
Wie viele Server braucht ein Cluster?
Für automatisches Failover meist drei Stimmen: zwei Datenbankserver und eine dritte Instanz, die bei einer Netztrennung entscheidet, welche Seite weiterarbeitet. Ohne diese Mehrheit droht Split-Brain, also zwei Server, die beide schreiben. Galera bildet die Mehrheit aus den Knoten selbst, Patroni nutzt dafür einen Konsensdienst wie etcd.
Brauchen wir Hochverfügbarkeit, wenn die Datenbank in der Cloud läuft?
Auch in der Cloud fallen Server und ganze Zonen aus. Verwaltete Datenbanken bieten Replikate in mehreren Zonen, die aber gebucht, eingestellt und getestet sein wollen. Wir prüfen, ob Ihre Einstellungen zu Ihren Zielen passen und was ein Zonenausfall für Ihre Anwendung bedeuten würde.
Weiterlesen.
Wie lange darf Ihre Datenbank ausfallen?
Wir klären die Frage gemeinsam mit Ihnen und schlagen eine Architektur vor, die zu dieser Antwort und zu Ihrem Budget passt.