arabam.com: SQL Server Always On Migration ohne eine Minute Ausfallzeit

Die Migration einer produktiven SQL-Server-Instanz zu Always On Availability Groups ohne Ausfallzeit ist eine der folgenreichsten Infrastrukturänderungen, die ein Datenbankteam durchführen kann. Richtig umgesetzt, eliminiert sie geplante Wartungsfenster, bietet automatisches Failover und erschließt Read-Scale-Performance. Schlecht umgesetzt, riskiert sie Datenverlust oder längere Ausfälle während des Cutovers.

Dieses Playbook präsentiert eine rollierende Migrationsstrategie in fünf Phasen, die null sichtbare Ausfallzeit erreicht. Es basiert auf Mustern aus SQL-Server-HA-Migrationen in Enterprise-Umgebungen, einschließlich Datenbanken über 2 TB unter kontinuierlicher Produktionslast.

Wann Sie auf Always On migrieren sollten

Always On Availability Groups (AG) sind die richtige Wahl, wenn Ihre Umgebung diese Kriterien erfüllt:

• Sie nutzen SQL Server Enterprise Edition (2016 oder neuer; Standard Edition unterstützt Basis-AGs mit Einschränkungen)
• Ihr Workload ist leseintensiv (70 %+ Lesevorgänge) und würde von Read-Offloading auf Sekundärreplikate profitieren
• Ihr Geschäft kann keine geplanten Wartungsfenster tolerieren — auch keine 2-stündigen Fenster in Nebenzeiten
• Sie benötigen automatisches Failover mit einer RTO unter 30 Sekunden
• Ihre Datenbankgröße macht Log-Shipping oder Mirroring für moderne RPO-Anforderungen unpraktisch

Voraussetzungen-Checkliste

Überprüfen Sie vor Beginn der Migration Folgendes:

1. Windows Server Failover Clustering (WSFC) ist auf allen Knoten installiert und konfiguriert, die an der AG teilnehmen werden
2. SQL-Server-Versionsgleichheit: Alle Knoten laufen mit derselben SQL-Server-Version und -Edition. Gemischte Versionen erzeugen unvorhersehbares Verhalten
3. Netzwerkbandbreite: Ausreichende Bandbreite zwischen Knoten für synchrone Replikation. Für eine 2-TB-Datenbank mit moderater Schreibaktivität planen Sie mit konstant 100+ Mbps zwischen Replikaten
4. Shared-Nothing-Storage: Jeder Knoten hat seinen eigenen Speicher. AGs verwenden keine geteilten Festplatten
5. Anwendungsverbindungszeichenfolgen sind parametrisiert und können ohne Application-Redeployment aktualisiert werden (idealerweise via Konfiguration oder Umgebungsvariablen)
6. Backup-Strategie ist dokumentiert und getestet. Sie benötigen ein vollständiges Backup + Transaktionslog-Backups während der Migration

Die 5-Phasen-Migrationsstrategie

Phase 1 — Shadow-Knoten-Vorbereitung (Woche 1–2): Neuen Knoten im selben Rechenzentrum bereitstellen. Dieselbe SQL-Server-Version und dasselbe kumulative Update installieren. Dem WSFC beitreten, aber noch keiner AG hinzufügen. Netzwerkkonnektivität, DNS-Auflösung und Dienstkonto-Berechtigungen validieren. Diese Phase hat null Produktionsauswirkung.

Phase 2 — Baseline-Backup und Restore (Woche 3): Vollständiges Backup der Primärdatenbank erstellen und auf dem Sekundärknoten mit NORECOVERY wiederherstellen. Sofort mit Transaktionslog-Restores nachfolgen, um das Aufholfenster zu minimieren. In der verkehrsärmsten Phase einplanen — nicht weil es Nutzer betrifft (tut es nicht), sondern um die Log-Chain-Lücke zu minimieren.

Phase 3 — AG-Formation (Woche 4): Availability Group erstellen mit dem bestehenden Primärknoten als primäres Replikat und dem wiederhergestellten Sekundärknoten als synchron committendes Sekundärreplikat. AG-Listener mit dedizierter IP und DNS-Eintrag erstellen, aber Anwendungsverbindungszeichenfolgen noch nicht aktualisieren. Synchronisierungsstatus überwachen, bis der Sekundärknoten SYNCHRONIZED anzeigt.

Phase 4 — Application-Rerouting (Woche 5–6): Verbindungszeichenfolgen in einem rollierenden Blue-Green-Deployment auf den AG-Listener umstellen. Nur-Lese-Workloads über ApplicationIntent=ReadOnly auf den Sekundärknoten leiten. Dies ist die kritische Phase — Connection-Pool-Drain-Sequenzierung verwenden, um fehlgeschlagene Transaktionen zu vermeiden. Ein gut ausgeführtes Rerouting sollte in unter 15 Minuten abgeschlossen sein, ohne Fehler-Spitzen.

Phase 5 — Validierung und Außerbetriebnahme (Woche 7–8): Den ursprünglichen Primärknoten mindestens 14 Tage als Monitor-Knoten weiterlaufen lassen. Failover-Verhalten mit kontrollierten Tests validieren. Erst außer Betrieb nehmen, wenn saubere Failover- und Failback-Zyklen bestätigt sind.

Der Schlüssel zu einem Cutover ohne Ausfallzeit liegt in der Phase-4-Sequenzierung. Den Connection-Pool jedes Anwendungsservers entleeren, bevor dessen Verbindungszeichenfolge umgestellt wird. Niemals alle Server gleichzeitig umschalten.

Monitoring-Setup

Post-Migrations-Monitoring ist nicht optional. SQL Servers sys.dm_hadr_database_replica_states-DMV als primäre Datenquelle verwenden und Metriken in Ihre Observability-Plattform (Prometheus + Grafana, Datadog oder gleichwertig) einspeisen. Alertschwellen setzen bei:

• Redo-Queue-Größe > 512 MB: Zeigt an, dass der Sekundärknoten beim Anwenden von Transaktionen zurückfällt
• Send-Queue-Größe > 256 MB: Zeigt Netzwerksättigung zwischen Replikaten an
• Synchronisierungsstatus != HEALTHY für > 30 Sekunden: Erfordert sofortige Untersuchung
• Failover-Erkennung: Bei jedem automatischen oder manuellen Failover-Event alarmieren

Häufige Fallstricke

• Read-Only-Routing vergessen: Ohne ApplicationIntent=ReadOnly-Konfiguration treffen alle Abfragen den Primärknoten, wodurch der Read-Scale-Vorteil zunichtegemacht wird
• Failover-Drills überspringen: Quartalsweise Failover-Tests durchführen. Ein ungetestetes HA-Setup ist kein HA-Setup
• Transaktionslog-Wachstum ignorieren: Während Phase 2–3 kann das Transaktionslog des Primärknotens nicht über die älteste nicht wiederhergestellte LSN hinaus abgeschnitten werden. Log-Dateigröße überwachen und ausreichend Festplattenspeicher sicherstellen
• Netzwerklatenz zwischen Replikaten: Synchrones Commit fügt jeder Schreibtransaktion Latenz hinzu. Bei Cross-Datacenter-Replikation asynchrones Commit für das entfernte Replikat in Betracht ziehen

Eine sorgfältig durchgeführte Always-On-Migration transformiert Ihre Datenbankinfrastruktur von einem fragilen Single Point of Failure zu einem resilienten, selbstheilenden System. Die Investition in sorgfältige Planung über diese fünf Phasen amortisiert sich mit dem ersten vermiedenen Ausfall.