# SQL Server Always On: High-Availability & Disaster Recovery

TL;DR / Management Summary Always On Availability Groups (AG) ist die moderne HA-Lösung für den Microsoft SQL Server. Im Gegensatz zum klassischen Failover-Cluster (FCI) benötigt eine AG keinen Shared Storage. Die Daten werden auf Block-Ebene zwischen den Instanzen synchronisiert. Für Senior Admins bietet dies maximale Flexibilität: Wir können Lesezugriffe auf die Replika-Knoten auslagern (Read-Only Routing) und Backups auf den Standby-Server verschieben, um die Produktion zu entlasten.

# 1. Einführung & Architektur

Synchronität im Cluster.

Eine Availability Group ist ein logischer Container für eine Gruppe von Datenbanken, die gemeinsam geschwenkt werden.

# Komponenten

# Architektur-Übersicht (Mermaid)

graph TD
    APP[Application] -->|Connects to| LIS[AG Listener: 10.0.0.100]
    LIS -->|Routes to| PRI[Primary Node: SRV-SQL-01]
    PRI -->|Synchronous Commit| SEC1[Secondary Node: SRV-SQL-02]
    PRI -->|Asynchronous Commit| SEC2[DR Node: Remote-SQL]
    
    subgraph "Windows Failover Cluster"
    PRI
    SEC1
    SEC2
    end

# 2. Einrichtung in der Praxis

Der Weg zum stabilen SQL-Cluster.

# Voraussetzungen

  1. Windows Failover Cluster: Muss auf OS-Ebene konfiguriert sein (Artikel 536).
  2. Service Account: SQL Server muss unter einem Domain-Account (gMSA empfohlen) laufen.
  3. Endpunkte: SQL nutzt Port 5022 für die Datenreplikation.

# Konfiguration (T-SQL)

-- Erstellen eines Endpunkts für die Replikation
CREATE ENDPOINT [Hadr_endpoint] 
    STATE=STARTED 
    AS TCP (LISTENER_PORT = 5022) 
    FOR DATA_MIRRORING (ROLE = ALL);

# 3. Deep Dive: Synchron vs. Asynchron

RPO vs. Performance.

  1. Synchronous-Commit Mode: Die Transaktion wird erst bestätigt, wenn sie auf dem Secondary gehärtet ist.
    • Vorteil: Zero Data Loss (RPO=0).
    • Nachteil: Höhere Latenz für die Applikation.
  2. Asynchronous-Commit Mode: Primary bestätigt sofort.
    • Vorteil: Keine Latenz-Beeinträchtigung.
    • Anwendungsfall: Disaster Recovery Standorte (Zweigstellen).

# 4. Day-2 Operations: Read-Only Routing

Die Hardware effizient nutzen.

Warum sollten die Secondary-Server nur im Standby warten?

# 5. Troubleshooting & “War Stories”

Wenn der Sync bricht.

# Top 3 Fehlerbilder

  1. Symptom: AG-Status steht auf NOT SYNCHRONIZING.

    • Ursache: Firewall blockiert Port 5022 oder das Log-File der Datenbank ist voll.
    • Lösung: sys.dm_hadr_availability_replica_states abfragen.

  2. Symptom: Automatischer Failover schlägt fehl.

    • Ursache: Das Cluster-Quorum (Artikel 508) ist nicht stabil oder der SQL-Service-Account hat keine Rechte im AD.

  3. Symptom: Listener ist nicht erreichbar.

    • Ursache: Multi-Subnet Setup. Der Client-Treiber unterstützt kein MultiSubnetFailover=True.

# “War Story”: Der “Log-Zerstörer”

Ein Admin aktivierte Always On, konfiguriert auf “Synchronous”. Er startete einen Massen-Import von 100 Mio. Zeilen. Das Ergebnis: Der SQL Server fror praktisch ein. Da jeder Insert erst über eine 1 Gbit Leitung zum Secondary bestätigt werden musste, sank die Performance auf ein Zehntel. Lehre: Bei Massen-Datenoperationen schalten Sie die Replikation temporär auf “Asynchron” oder nutzen Sie dedizierte 10G+ Karten für den Hadr_endpoint.

# 6. Monitoring & Alerting

Den Status tracken.

# Wichtige SQL-Metriken

# 7. Fazit & Empfehlung

SQL Always On ist der Industriestandard für Windows-Datenbanken.

# Anhang: Cheatsheet

Aufgabe Befehl / Sicht
Status prüfen sys.dm_hadr_database_replica_states
Failover manuell ALTER AVAILABILITY GROUP [AGName] FAILOVER;
Dashboard SQL Server Management Studio -> Always On Dashboard
Port Check tnc <Knoten> -p 5022

# Referenzen