Failover-Übung / geplanter Rollenwechsel

Ein Entscheidungsbaum, der die Art des Rollenwechsels bestimmt (geplanter Switchover, Notfall-Failover oder eine Übung ohne Eingriff in die Produktion) und für jedes Szenario die richtige Befehlsfolge und Prüfschritte liefert. Ziel: bereit sein für einen Wechsel ohne Datenverlust im Planfall, mit minimalem Verlust im Notfall und ganz ohne Ausfallzeit bei einer Übung.

Was willst du tun?

Wähle den Kontext des Rollenwechsels. Führst du einen geplanten Wechsel bei gesundem Primary durch (Wartung/Migration), ist der Primary wirklich ausgefallen und ein Notfallwechsel nötig, oder führst du eine Übung/Bereitschaftsprüfung ohne Eingriff in die Produktion durch?

• Geplanter Switchover (Primary ist gesund)
• Notfall-Failover (Primary ist ausgefallen)
• Übung / Bereitschaftstest (Produktion nicht anfassen)

Geplanter Wechsel — bist du zuerst bereit?

Ziel eines geplanten Switchovers ist NULL Datenverlust. Dafür musst du vor dem Wechsel sicherstellen, dass die Replica den Primary eingeholt hat (Verzug ~0) und gesund ist. Prüfe den Verzug mit den folgenden Befehlen; liegt er nahe null, fahre mit den Wechselschritten fort.

SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;   -- DG: SELECT name, value FROM v$dataguard_stats WHERE name LIKE '%lag%';

• Verzug nahe null, bereit zum Wechsel
• Verzug ist hoch, zuerst auf Synchronisierung warten

Geplanter Switchover (kontrollierter Wechsel ohne Datenverlust)

Solange Primary und Standby gesund und synchron sind, tausche die Rollen kontrolliert. Die Reihenfolge zählt: Schreibvorgänge stoppen, sicherstellen, dass die restlichen Änderungen den Standby erreicht haben, dann die Rolle übergeben und die Anwendung auf den neuen Primary umleiten.

Notfallwechsel — ist der Primary wirklich ausgefallen?

Bevor du ein Failover erzwingst, verifiziere, dass der Primary wirklich nicht erreichbar ist, und bewerte das Split-Brain-Risiko. Lebt der Primary tatsächlich noch (z. B. kurzer Netzwerkausfall), führt ein erzwungener Wechsel zu zwei getrennten beschreibbaren Kopien (Split-Brain). Vergleiche außerdem den Verzug, um den aktuellsten Standby zu wählen.

-- try to reach the primary: tnsping primary_db; and on the standby: SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;

• Ja, der Primary ist ausgefallen — Wechsel erzwingen
• Nicht sicher / der Primary kommt evtl. zurück

Notfall-Failover (Primary ausgefallen, Wechsel mit Datenverlustrisiko)

Der Primary ist nicht erreichbar und du kannst nicht auf seine Rückkehr warten. Du musst den Standby per Force promoten; bei asynchroner Replikation können einige der letzten Transaktionen verloren gehen. Priorität hat die Wiederherstellung des Dienstes; ermittle danach das Verlustfenster und bringe den alten Primary sicher zurück.

Übung / Bereitschaftstest (validieren, ohne die Produktion anzufassen)

Weise nach, dass du für ein Failover bereit bist, ohne einen echten Wechsel durchzuführen. Verifiziere den Zustand der Replica, einen akzeptablen Verzug und die Umleitbarkeit der Anwendung, ohne die Produktion zu beeinträchtigen. Optional probst du einen echten Switchover auf einer isolierten Kopie.