Betrieb von SQL Server Always On AG (Windows und Linux)

Keine Installation, sondern Betrieb im Alltag und Störungsszenarien einer installierten Always On Availability Group: Health Check, Diagnose von Verzögerung und Log-Wachstum, geplantes Failover, erzwungenes Failover (FORCE_FAILOVER_ALLOW_DATA_LOSS) und Nacharbeiten, Datenverschiebung anhalten/fortsetzen, synchroner/asynchroner Modus, Datenbanken hinzufügen (Automatic Seeding oder Backup/Restore), Replicas hinzufügen/entfernen, Read-Only Routing und Änderungen am Listener. Unter Windows mit WSFC-, unter Linux mit Pacemaker-Befehlen (pcs).

Wähle auf der Szenariokarte, was du tun möchtest; du kannst das passende Szenario auch direkt öffnen, indem du die Fehlernummer (z. B. 9002, 35264, 41142) in die Katalogsuche eingibst. Gibt es noch keine AG: AG (Windows) oder AG (Linux).

Topologie: AG mit 2–9 Replicas (Windows WSFC oder Linux Pacemaker)

Szenarien

• AG-Health-Check (Dashboard-Abfragen) — Ist alles in Ordnung? Replica-/Datenbankstatus, Failover-Bereitschaft, Cluster und letzte Rollenwechsel. Ändert nichts.
• Secondary fällt zurück / Logdatei wächst (Diagnose der Verzögerung) — Die Send-/Redo-Queue wächst, die Daten auf dem Secondary sind veraltet, das Log auf dem Primary läuft bald voll (log_reuse_wait = AVAILABILITY_REPLICA) oder Commits sind langsam (HADR_SYNC_COMMIT).
• Geplantes Failover (Switchover, kein Datenverlust) — Verschiebt den Primary für Wartung, Patching oder Tests auf einen synchronen, SYNCHRONIZED Secondary; einige Sekunden Unterbrechung, kein Datenverlust.
• Primary verloren: erzwungenes Failover (FORCE_FAILOVER_ALLOW_DATA_LOSS) — Der Primary (oder der ganze Standort / das Cluster-Quorum) ist verloren und Warten ist keine Option: Ein Secondary wird unter Inkaufnahme von Datenverlust zum Primary gemacht; danach werden die Daten verglichen und die anderen Replicas fortgesetzt.
• Datenverschiebung anhalten / fortsetzen (SUSPEND / RESUME) — Das Senden von Daten an einen Secondary vorübergehend anhalten (Netzwerkwartung, Massenverarbeitung) oder eine im Status SUSPENDED hängende Datenbank fortsetzen.
• Synchronen / asynchronen Modus ändern — Ein Replica zwischen SYNCHRONOUS_COMMIT und ASYNCHRONOUS_COMMIT umstellen (entfernter Standort, langsames Netzwerk, DR-Übung) und den Commit-Schutz (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT) einstellen.
• Datenbank zur AG hinzufügen (Automatic Seeding oder Backup/Restore) — Eine neue oder vorhandene Datenbank in die AG aufnehmen: Automatic Seeding für kleine/mittlere Datenbanken, aus dem Backup für große Datenbanken oder bei langsamem Netzwerk.
• Replica (Node) hinzufügen — Einen neuen Secondary zur AG hinzufügen: Der Node tritt dem Cluster bei, der Endpoint wird vorbereitet, ADD REPLICA + JOIN, die Datenbanken kommen per Seeding.
• Replica (Node) entfernen — Einen Secondary, der dauerhaft abgeschaltet oder neu aufgebaut wird, aus der AG und dem Cluster entfernen.
• Read-Only Routing (Leseweiterleitung) — Verbindungen mit ApplicationIntent=ReadOnly über den Listener an lesbare Secondaries weiterleiten (Reporting-Last vom Primary nehmen).
• Listener erstellen oder ändern (IP, Port) — Den Listener erstellen, falls keiner existiert, seinen Port ändern oder (Windows) eine IP für ein zweites Subnetz hinzufügen.

Vor dem Start

• Auf jedem Node sqlcmd (/opt/mssql-tools18/bin/sqlcmd) und … als sysadmin; root-Rechte (pcs). Passwort: read -rsp 'Passwort: ' SQLCMDPASSWORD; export SQLCMDPASSWORD und sudo --preserve-env=SQLCMDPASSWORD bash <script>.sh.
• PowerShell ist als Administrator mit einem Domänenkonto geöffnet, das in SQL Server sysadmin und im WSFC Administrator ist; sqlcmd und das Modul FailoverClusters sind vorhanden.
• Zeile 1 der Replica-Liste im Formular ist der aktuelle Primary (prüfe das mit der ersten Abfrage des Health Checks); die Schritte werden anhand dieser Reihenfolge dem richtigen Node zugeordnet.
• Das Change-Fenster ist genehmigt und das Anwendungsteam informiert…: Der Listener ist einige Sekunden unterbrochen, offene Transaktionen werden zurückgesetzt……: Eine Port-/IP-Änderung betrifft die Connection Strings….
• Die Entscheidung für das erzwungene Failover wurde von einer berechtigten Person getroffen und Datenverlust wurde akzeptiert: Der Primary ist nicht erreichbar und kommt in absehbarer Zeit nicht zurück. Kann der Primary zurückkommen, ist Warten oder ein geplantes Failover immer besser.

Phasen der Anleitung

• AG-Health-Check — AG-Dashboard: Replicas, Datenbanken, Failover-Bereitschaft · Cluster-Status (WSFC) · Cluster-Status (Pacemaker) · Letzte Rollenwechsel (AlwaysOn_health)
• Diagnose von Verzögerung und Log-Wachstum — Diagnose: Queues, Raten und geschätzte Aufholzeit (Primary) · Diagnose: Commit-Wartezeiten (Primary) · Diagnose: Wird das Redo blockiert? (auf den Secondaries) · Lösungsoptionen und Log-Prüfung
• Geplantes Failover — Diagnose: Ist das Ziel failover-bereit? (…) · Sicherheitsnetz: Laufen lange Transaktionen oder Jobs? (Primary) · Failover: … zum Primary machen (T-SQL) · Failover: … zum Primary machen (pcs) · Prüfen: neuer Primary und Listener
• Erzwungenes Failover (Datenverlust möglich) — Diagnose: Zustand des Ziels und möglicher Datenverlust (…) · WSFC-Quorum erzwungen starten (…) · Verwaltung der AG-Ressource durch Pacemaker anhalten (…) · Erzwungenes Failover: … zum Primary machen · Prüfen: neuer Primary offen, die anderen SUSPENDED · Snapshot auf dem alten Primary erstellen, um verlorene Daten zu retten (…, sobald er zurück ist) …
• Datenverschiebung anhalten / fortsetzen — Diagnose: angehaltene Datenbanken und Ursache · …Datenverschiebung anhalten (SUSPEND)…Datenverschiebung fortsetzen (RESUME)… · Prüfen und überwachen
• Änderung des Verfügbarkeitsmodus — Diagnose: aktuelle Modi und Commit-Schutz · … → … · Commit-Schutz einstellen (Windows) · Commit-Schutz einstellen (Pacemaker) · Prüfen
• Datenbank zur AG hinzufügen — Diagnose: Ist die Datenbank für die AG geeignet? (Primary) · Vorbereiten: Wiederherstellungsmodell FULL und Backup (Primary) · Replicas auf manuelles Seeding umstellen (Primary) · Datenbank zur AG hinzufügen (Primary) · Seeding überwachen (Primary) · Auf dem Secondary aus dem Backup vorbereiten (NORECOVERY): … …
• Replica hinzufügen — Neuen Node zum WSFC hinzufügen (Primary) · Always On aktivieren (neuer Node) · Endpoint anlegen und Berechtigungen erteilen (neuer Node) · Neuen Node vorbereiten: HA-Agent, Always On, Cluster-Software · Endpoint-Zertifikat auf den neuen Node kopieren (Primary) · Zertifikat, Endpoint und Pacemaker-Login (neuer Node) …
• Replica entfernen — Diagnose: zu entfernendes Replica und verbleibende Konfiguration · Node aus dem Pacemaker-Cluster entfernen (Primary) · Replica aus der AG entfernen (Primary) · Node aus dem WSFC entfernen (optional) · RESTORING-Datenbanken auf dem entfernten Node bereinigen (…)
• Read-only routing — Diagnose: Lesezugriff und aktuelles Routing · Routing-URLs und -Listen festlegen (Primary) · Prüfen: Routing-Liste · Test: Wohin geht eine ReadOnly-Verbindung? · Test: Wohin geht eine ReadOnly-Verbindung?
• Listener — Diagnose: vorhandene Listener · Virtual-IP-Ressource und Constraints anlegen (Pacemaker) · …Listener erstellen…Listener-Port ändern…IP zum Listener hinzufügen… (Primary) · Firewall- und DNS-Einstellungen · Firewall-Einstellungen · Prüfen: Verbindung über den Listener