Failover bezeichnet den automatischen oder manuellen Wechsel von einem ausgefallenen System, einer ausgefallenen Komponente oder einem ausgefallenen Standort auf eine Backup-Instanz oder einen Ersatzstandort – mit dem Ziel, den Betrieb mit minimaler Unterbrechung fortzusetzen. Failover ist der Mechanismus, der Redundanz in Verfügbarkeit umwandelt: Die redundante Komponente ist vorhanden (Redundanz), aber erst der Failover-Prozess aktiviert sie im Ernstfall.
Automatisches Failover ist dabei deutlich vorzuziehen: Es reagiert in Sekunden statt in Minuten oder Stunden, die ein menschlicher Eingriff bräuchte, und funktioniert auch nachts und an Wochenenden ohne Bereitschaftsdienst. Automatisches Failover ist eine der wichtigsten Investitionen für jede Automatisierungsinfrastruktur, die ein ernsthaftes Verfügbarkeits-SLA garantieren soll.
Failover-Modi nach Reaktionszeit
Hot Standby Sekundärsystem läuft parallel aktiv mit: Failover in Sekunden, kein Datenverlust. Höchste Kosten (doppelte Ressourcen). Für kritischste Systeme – Datenbanken, Core-Services.
Warm Standby Sekundärsystem läuft, aber nicht vollständig aktiv: Failover in Minuten, minimaler Datenverlust möglich. Mittlere Kosten. Gut für wichtige, nicht hochkritische Services.
Cold Standby Sekundärsystem ist gestoppt, muss erst gestartet werden: Failover in Minuten bis Stunden. Niedrigste Kosten. Nur für Systeme, bei denen Ausfallzeiten tolerierbar sind.
Failover in der Datenbankpraxis
Datenbankfailover ist der komplexeste und kritischste Failover-Typ in Automatisierungsarchitekturen: Die Datenbank enthält den Prozesszustand aller laufenden Workflows. Ein automatisches Datenbankfailover muss sicherstellen, dass keine Transaktionen verloren gehen, alle laufenden Verbindungen sauber umgeleitet werden und die neue Primary-Instanz konsistent ist. Cloud-managed Datenbanken wie AWS RDS Multi-AZ oder Azure Database for PostgreSQL übernehmen diesen komplexen Failover-Prozess vollautomatisch – typischerweise in 20–60 Sekunden.
Praxisbeispiel
Ein Automationsdienstleister testet seinen Failover-Mechanismus in einer geplanten Übung. Szenario: primäre Datenbankinstanz wird manuell gestoppt (simulierter Hardwareausfall). Automatischer Ablauf: RDS Multi-AZ erkennt Ausfall nach 10 Sekunden. DNS-Eintrag wird auf Replica umgeschaltet. n8n-Instanzen verlieren kurz die Datenbankverbindung und reconnecten automatisch nach 18 Sekunden. Laufende Workflows, die während des Failovers aktiv waren: 7 Stück. Verhalten: 5 Workflows liefen nach Reconnect fehlerfrei weiter (idempotente Schritte). 2 Workflows mussten manuell neu gestartet werden (nicht-idempotente API-Calls). Erkenntnis: Idempotenz als Designprinzip in allen zukünftigen Workflows zwingend einhalten.
