SQL Server Always On Verfügbarkeitsgruppen: Vollständiger Leitfaden [2026]

1. Always On-Verfügbarkeitsgruppen verstehen

1.1 Was es ist und wie es funktioniert

Always On Verfügbarkeitsgruppen (AG) sind eine SQL Server Unternehmen hohe Verfügbarkeit und eine Disaster-Recovery-Lösung, die auf Datenbankebene arbeitet. Eine Verfügbarkeitsgruppe fasst eine oder mehrere Benutzerdatenbanken zu einer einzigen Failover-Einheit zusammen und repliziert diese mittels kontinuierlicher Transaktionsprotokollübertragung auf bis zu acht sekundäre Replikate. Fällt das primäre Replikat aus, übernimmt automatisch ein designiertes synchrones sekundäres Replikat und stellt den Zugriff innerhalb von Sekunden ohne gemeinsam genutzten Speicher oder manuelle Eingriffe wieder her.

1.2 Always On-Verfügbarkeitsgruppen vs. Failoverclusterinstanzen

SQL Server Always On umfasst zwei unterschiedliche Technologien: Verfügbarkeitsgruppen (AG) und Failoverclusterinstanzen (FCI):

	Always On-Verfügbarkeitsgruppen	Always On Failover Cluster Instances
Failover-Bereich	Datenbankebene	Instanzebene (alle Datenbanken führen gleichzeitig ein Failover durch)
Datenreplikation	Protokollbasierte Replikation auf jeden sekundären Server	Keine – alle Knoten teilen sich denselben Speicher.
Geteiltes Lager	Nicht erforderlich	Erforderlich (Storage Area Network (SAN), iSCSI, S2D oder SMB)
Lesbare Sekundärdaten	Ja	Nein
Katastrophale Erholung	Eingebaute (asynchrone Replikate über verschiedene Standorte hinweg)	Ohne Kopplung mit AG ist die Integration nicht möglich.

Wann ist was zu verwenden: Verwenden Sie FCI, wenn Sie ein Failover auf Instanzebene benötigen und bereits über eine gemeinsam genutzte Speicherinfrastruktur verfügen. Verwenden Sie AG, wenn Sie eine Granularität auf Datenbankebene, lesbare Sekundärspeicher oder Disaster Recovery benötigen. Für die most Für einen vollständigen Schutz kombinieren Sie beides: Betreiben Sie jede Replik als FCI-Knoten und verbinden Sie sie in einer AG.

1.3 Vorteile und Einschränkungen

Vorteile:

• Automatisches Failover mit nahezu null Wiederherstellungszeitvorgabe (RTO) für synchrone Replikate;
• kein Datenverlust (Recovery Point Objective (RPO) = 0) im synchronen Commit-Modus;
• Kein gemeinsamer Speicher erforderlich – jede Replik verwendet einen unabhängigen lokalen Speicher;
• Lesbare Sekundärserver entlasten den Primärserver von Berichts- und Backup-Workloads;
• Unterstützt sowohl lokale Hochverfügbarkeit (HA) als auch standortübergreifende Notfallwiederherstellung (DR) innerhalb einer einzigen Konfiguration.

Einschränkungen:

• Erfordert Windows Server Failover Clustering auf allen Replikaten;
• Enterprise Edition für den vollen Funktionsumfang (Standard Edition unterstützt Basic AG mit erheblichen Einschränkungen);
• Der synchrone Commit-Modus erhöht die Latenz von Schreibvorgängen proportional zur Netzwerk-Roundtrip-Zeit;
• Anmeldungen, SQL-Agent-Aufträge und verknüpfte Server werden nicht automatisch synchronisiert in SQL Server 2019 und früher (gelöst in SQL Server 2022 enthielt Verfügbarkeitsgruppen).

2. Architektur von Always On-Verfügbarkeitsgruppen

2.1 Kernkomponenten und Konzepte

2.1.1 Verfügbarkeitsdatenbanken

Verfügbarkeitsdatenbanken sind Benutzerdatenbanken, die an einer Verfügbarkeitsgruppe teilnehmen. Diese Datenbanken müssen bestimmte Anforderungen erfüllen: Sie müssen das vollständige Wiederherstellungsmodell verwenden, über eine vollständige Sicherung verfügen und auf dem primären Replikat vorhanden sein, bevor sie einer Verfügbarkeitsgruppe hinzugefügt werden.

Wenn eine Datenbank einer Verfügbarkeitsgruppe beitritt, wird sie Teil eines synchronisierten Satzes, der im Fehlerfall als Einheit ausfällt. Alle Datenbanken in einer Verfügbarkeitsgruppe haben denselben Failover-Status. Das bedeutet: Fällt die primäre Replik aus, wechseln alle Datenbanken gleichzeitig zur selben sekundären Replik. Dies gewährleistet die Datenkonsistenz für Anwendungen, die auf mehrere zusammengehörige Datenbanken angewiesen sind.

2.1.2 Verfügbarkeitsreplikate

Verfügbarkeitsreplikate sind SQL Server Fälle, die host Kopien der Verfügbarkeitsdatenbanken. Jede Replik verwaltet eine eigene physische Kopie der Datenbanken, die über den Versand von Transaktionsprotokolleinträgen synchronisiert wird. Eine Verfügbarkeitsgruppe kann bis zu neun Replikate enthalten: ein primäres Replikat und bis zu acht sekundäre Replikate.

2.1.3 Primärreplikat

Die primäre Replik hostDie primäre Replik ist die Lese-/Schreibkopie der Verfügbarkeitsdatenbanken. Alle Datenänderungen (Einfügen, Aktualisieren, Löschen) erfolgen auf der primären Replik. Clientanwendungen verbinden sich für alle Schreibvorgänge und standardmäßig auch für Lesevorgänge mit der primären Replik.

2.1.4 Sekundäre Replikate

Sekundäre Repliken host Es werden schreibgeschützte Kopien der Verfügbarkeitsdatenbanken erstellt, die durch die kontinuierliche Anwendung von Transaktionsprotokolleinträgen der primären Replik aufrechterhalten werden. Jede sekundäre Replik empfängt, härtet und wendet Protokolleinträge an, um ihre Datenbankkopien mit der primären Replik synchron zu halten.

2.2 Verfügbarkeitsmodi

2.2.1 Synchroner Commit-Modus

Der synchrone Commit-Modus gewährleistet vollständigen Datenverlust, indem er die primäre Replik verpflichtet, auf die Bestätigung der Härtung der Transaktionsprotokolleinträge auf der sekundären Replik zu warten, bevor Transaktionen abgeschlossen werden. Dieser Modus ist unerlässlich für Hochverfügbarkeitskonfigurationen, bei denen Datenverlust inakzeptabel ist.

2.2.2 Asynchroner Commit-Modus

Der asynchrone Commit-Modus priorisiert die Leistung der primären Replikate, indem er Transaktionen ermöglicht, ohne auf die Bestätigung der Protokollhärtung durch die sekundären Replikate zu warten. Dieser Modus eignet sich für Disaster-Recovery-Replikate oder wenn die Netzwerklatenz einen synchronen Commit unpraktisch macht.

Der Nachteil besteht in einem potenziellen Datenverlust während des Failovers. Fällt die primäre Replik aus, erreichen einige festgeschriebene Transaktionen möglicherweise nicht die sekundäre Replik. Das Ausmaß des potenziellen Datenverlusts hängt von der Netzwerkbandbreite, der Leistung der sekundären Replik und dem Zeitpunkt des Ausfalls ab. Unternehmen müssen dieses Risiko bei der Verwendung des asynchronen Modus in Kauf nehmen.

2.3 Failover-Typen

2.3.1 Automatisches Failover

Die automatische Failover-Funktion ermöglicht es der Verfügbarkeitsgruppe, den Ausfall der primären Replik zu erkennen und eine sekundäre Replik automatisch zur primären Replik hochzustufen, ohne dass ein Administrator eingreifen muss. Diese Funktion minimiert die Wiederherstellungszeit (RTO), da manuelle Reaktionen auf Ausfälle entfallen.

Automatisches Failover erfordert den synchronen Commit-Modus, um Datenverlust zu vermeiden. Ist diese Funktion aktiviert, überwacht die Verfügbarkeitsgruppe kontinuierlich den Zustand des primären Replikats. Reagiert das primäre Replikat nicht mehr oder fällt es aus, leitet der Windows Server-Failovercluster ein automatisches Failover auf ein festgelegtes sekundäres Replikat ein.

2.3.2 Manuelles Failover

Die manuelle Failover-Funktion ermöglicht es Administratoren, die Rolle der primären Replik gezielt auf eine sekundäre Replik umzuschalten, typischerweise für geplante Wartungs- oder Testzwecke. Im Gegensatz zum automatischen Failover erfordert die manuelle Failover-Funktion eine explizite Aktion des Administrators.

Für Replikate mit synchronem Commit ist ein manuelles Failover ohne Datenverlust möglich. Der Administrator initiiert das Failover über SQL Server Management Studio, Transact-SQL oder PowerShell. Die primäre Replik beendet die Verarbeitung der aktuellen Transaktionen und sendet alle verbleibenden Protokolleinträge an die tarSie erhält die sekundäre Rolle und wartet auf die Bestätigung, bevor sie die primäre Rolle überträgt.

Manuelles Failover ist auch bei Replikaten mit asynchronem Commit möglich, erfordert jedoch ein erzwungenes Failover mit potenziellem Datenverlust. Administratoren sollten ein erzwungenes manuelles Failover nur in tatsächlichen Katastrophenszenarien einsetzen, wenn das primäre Replikat nicht verfügbar ist und ein Datenverlust im Vergleich zu längeren Ausfallzeiten akzeptabel ist.

2.3.3 Erzwungenes Failover

Die erzwungene Ausfallsicherung ermöglicht den Wechsel zu einer asynchronen sekundären Replik oder zu einer nicht vollständig synchronisierten sekundären Replik, wobei ein potenzieller Datenverlust explizit in Kauf genommen wird. Diese Option dient als letztes Mittel, wenn die primäre Replik nicht verfügbar ist und keine synchronisierte sekundäre Replik existiert.

2.4 Datensynchronisation

2.4.1 Funktionsweise der Datensynchronisation

Die Datensynchronisierung in Always On-Verfügbarkeitsgruppen erfolgt durch die kontinuierliche Übertragung von Transaktionsprotokolleinträgen von der primären Replik an alle sekundären Replikate. Diese protokollbasierte Synchronisierung gewährleistet Datenkonsistenz und ermöglicht gleichzeitig die unabhängige Speicherung für jedes Replikat.

2.4.2 Transaktionsprotokolle und Härtung

Die Härtung der Transaktionsprotokolle ist ein entscheidender Schritt, bei dem Protokolleinträge auf sekundären Replikaten dauerhaft gespeichert werden. Durch die Härtung wird sichergestellt, dass die Protokolleinträge auch bei Ausfällen sekundärer Replikate erhalten bleiben und bei der Wiederherstellung wiederhergestellt werden können.

2.5 Leseskalierung und lesbare sekundäre Replikate

2.5.1 Auslagerung von schreibgeschützten Arbeitslasten

Lesbare sekundäre Replikate ermöglichen es Unternehmen, leseintensive Workloads vom primären Replikat auszulagern und so die Systemleistung und Ressourcennutzung zu verbessern. Diese Skalierbarkeit ist einer der Hauptvorteile von Verfügbarkeitsgruppen gegenüber älteren Hochverfügbarkeitslösungen.

Organisationen sollten bei der Konfiguration von Verfügbarkeitsgruppen die Anforderungen an schreibgeschützte Arbeitslasten berücksichtigen. Mehrere lesbare sekundäre Server können die Berichtslast auf mehrere Server verteilen. Schreibgeschützte Routinglisten definieren die Reihenfolge, in der sekundäre Server Lesezugriffe erhalten, und ermöglichen so Lastverteilungsstrategien.

2.5.2 Sicherungsvorgänge auf sekundären Replikaten

Durch die Ausführung von Backups auf sekundären Replikaten wird die E/A- und CPU-Last des primären Replikats reduziert, sodass dieses sich auf Transaktionsprozesse konzentrieren kann. Diese Funktion hilft Unternehmen, ihre Backup-Anforderungen zu erfüllen, ohne die Produktionsleistung zu beeinträchtigen.

SQL Server Unterstützt werden vollständige Datenbanksicherungen, differenzielle Sicherungen und Transaktionsprotokollsicherungen auf sekundären Replikaten. Die Sicherungseinstellungen können so konfiguriert werden, dass sekundäre Replikate, primäre Replikate, nur sekundäre oder beliebige Replikate bevorzugt werden. Das Sicherungssystem wählt automatisch ein geeignetes Replikat basierend auf diesen Einstellungen und der aktuellen Verfügbarkeit aus.

Weitere Details zu SQL Server Backup, siehe unsere umfassende Anleitung.

2.6 Verfügbarkeitsgruppen-Hörer

2.6.1 Was ist ein Zuhörer?

Ein Verfügbarkeitsgruppenlistener ist ein virtueller Netzwerkname (VNN) und eine IP-Adresse, die Clientanwendungen verwenden, um eine Verbindung zu Verfügbarkeitsgruppendatenbanken herzustellen. Der Listener leitet Verbindungen automatisch an die aktuelle primäre Replik weiter, sodass Anwendungen nicht mehr nachverfolgen müssen, welcher Server aktuell primär ist.

2.6.2 Client-Verbindungsrouting

Die Client-Verbindungsweiterleitung über den Listener unterstützt sowohl Lese-/Schreib- als auch Nur-Lese-Verbindungen. Der Listener prüft die Verbindungsanfrage und leitet sie basierend auf der Absicht der Anwendung an die entsprechende Replik weiter.

3. Voraussetzungen und Anforderungen

3.1 Windows Server-Failoverclustering für Verfügbarkeitsgruppen

3.1.1 Grundlagen des Windows Server-Failoverclusters

Windows Server Failover Clustering (WSFC) bildet die Grundlage für Always On-Verfügbarkeitsgruppen, indem es die Clusterzugehörigkeit, die Integritätsüberwachung und die Failover-Orchestrierung verwaltet. Im Gegensatz zu Failoverclusterinstanzen verwenden Verfügbarkeitsgruppen WSFC ausschließlich zur Clusterkoordination, nicht jedoch zur Verwaltung des gemeinsam genutzten Speichers.

. Der SQL Server Eine Instanz, die an einer Verfügbarkeitsgruppe teilnimmt, muss ein Knoten in einem WSFC-Cluster sein. Der Cluster verwaltet das Quorum, die Knotenzustandsüberwachung und den Ressourcenstatus der Verfügbarkeitsgruppe. Fällt die primäre Replik aus, koordiniert WSFC den Failover-Prozess und aktualisiert die Clusterressourcen, um die neue primäre Replik widerzuspiegeln.

3.1.2 Cluster-Quorum-Konfiguration

Das Cluster-Quorum bestimmt, welche Knoten bei Netzwerkproblemen operieren können und verhindert so Split-Brain-Szenarien, in denen mehrere Knoten unabhängig voneinander den Anspruch erheben, primär zu sein. Die Quorum-Konfiguration definiert, was eine Mehrheitsentscheidung im Cluster darstellt.

Für Verfügbarkeitsgruppen stehen verschiedene Quorummodi zur Verfügung:

• Node Majority verwendet ausschließlich die Stimmen der Clusterknoten und eignet sich gut für Cluster mit einer ungeraden Anzahl von Knoten.
• Node and File Share Majority fügt eine Zeugenabstimmung für Dateifreigaben hinzu, die sich für Cluster mit gerader Knotenzahl eignet.
• Node and Disk Majority verwendet einen Disk Witness, ist aber für Verfügbarkeitsgruppen weniger üblich, da kein gemeinsamer Speicher benötigt wird.

3.1.3 Multi-Subnet-Clustering

Multi-Subnet-Clustering ermöglicht es, Verfügbarkeitsgruppenreplikate über verschiedene Netzwerk-Subnetze zu erstrecken und so geografisch verteilte Bereitstellungen in Rechenzentren zu unterstützen. Diese Funktion ist unerlässlich für Disaster-Recovery-Konfigurationen, bei denen sich Replikate an unterschiedlichen Standorten befinden.

3.2 SQL Server Editionsanforderungen

3.2.1 Funktionen der Enterprise Edition

SQL Server Die Enterprise Edition bietet uneingeschränkten Funktionsumfang für Verfügbarkeitsgruppen. Sie unterstützt bis zu acht sekundäre Replikate, lesbare sekundäre Replikate, automatisches Seeding, verteilte Verfügbarkeitsgruppen und alle erweiterten Funktionen.

3.2.2 Funktionen der Standard Edition (Basisverfügbarkeitsgruppen)

SQL Server Die Standard Edition 2016 und spätere Versionen unterstützen Basic Availability Groups (BAGs) mit erheblichen Einschränkungen. BAGs bieten grundlegende Hochverfügbarkeitsfunktionen bei geringeren Ressourcen.ost, geeignet für Organisationen mit einfacheren Anforderungen.

4. Konfigurieren von Always On-Verfügbarkeitsgruppen

4.1 Vorbereitung der Umgebung

Bevor eine Verfügbarkeitsgruppe erstellt werden kann, muss die Umgebung ordnungsgemäß vorbereitet sein, d. h. Active Directory-Konten, Serverkonfigurationen und die Netzwerkinfrastruktur müssen vorhanden sein.

4.1.1 Domänencontroller-Einrichtung

Der Active Directory-Domänencontroller muss so konfiguriert sein, dass er den Verfügbarkeitsgruppencluster unterstützt. SQL Server Dienstkonten.

1. Melden Sie sich mit den Anmeldeinformationen eines Domänenadministrators am Domänencontroller an.
2. Öffne Server-Manager und navigieren Sie zu Zubehör -> Aktive Verzeichnisse Benutzer und Computer.
3. Erstellen Sie eine Organisationseinheit für SQL Server Objekte, falls keines existiert.
4. Überprüfen Sie, ob Computerobjekte für alle Clusterknoten in Active Directory vorhanden sind.
5. Stellen Sie sicher, dass die Domain Name System (DNS)-Dienste ordnungsgemäß konfiguriert sind und alle Servernamen korrekt aufgelöst werden.

4.1.2 Erstellen von Servicekonten

Erstellen Sie dedizierte Active Directory-Dienstkonten für SQL Server Dienste auf jedem Knoten.

1. Öffne Aktive Verzeichnisse Benutzer und Computer auf dem Domänencontroller.
2. Klicken Sie mit der rechten Maustaste auf die entsprechende Organisationseinheit und wählen Sie aus New -> Mitglied.
3. Geben Sie den Namen des Dienstkontos ein (z. B. svc_SQLServer) und legen Sie die Anmeldename des Benutzers.
4. Gehen Sie auf Weiter und geben Sie ein sicheres Passwort ein.
5. Wählen Sie Benutzer kann Kennwort nicht ändern , Passwort verfällt niemals.
6. Gehen Sie auf Weiter und dann Farbe um das Konto zu erstellen.
7. Wiederholen Sie den Vorgang für alle weiteren benötigten Servicekonten (SQL Server Agent, SSRS usw.).

4.1.3 Konfigurieren von Administratorberechtigungen

Dienstkonten und die Konten, die zur Konfiguration verwendet werden SQL Server muss über die entsprechenden Berechtigungen auf allen Clusterknoten verfügen.

1. Melden Sie sich auf jedem Clusterknotenserver an.
2. Öffne Computer-Management von der Start Menü oder Server-Manager.
3. Erweitern Sie die Funktionalität der Lokale Benutzer und Gruppen gedrückt und wählen Sie Groups.
4. Der rechten Maustaste auf Administratoren gedrückt und wählen Sie Eigenschaften im Vergleich.
5. Gehen Sie auf Speichern und geben Sie den Namen des Dienstkontos ein.
6. Gehen Sie auf Überprüfen Sie die Namen Klicken Sie anschließend auf „Konto bestätigen“. OK.
7. Gehen Sie auf OK um das Dialogfeld „Administratoreigenschaften“ zu schließen.
8. Wiederholen Sie den Vorgang auf allen Clusterknoten.

4.2 Installation und Konfiguration von WSFC

Windows Server Failover Clustering muss auf allen Knoten installiert und konfiguriert sein, bevor Always On-Verfügbarkeitsgruppen aktiviert werden können.

4.2.1 Installation der Failover-Clustering-Funktion

Installieren Sie die Failover-Clustering-Funktion auf jedem Server, der an der Verfügbarkeitsgruppe teilnehmen soll.

1. Öffne Server-Manager auf dem ersten Clusterknoten.
2. Gehen Sie auf Verwalten -> Rollen und Funktionen hinzufügen.
3. Gehen Sie auf Weiter durch die Einführungsbildschirme.
4. Wählen Sie Rollenbasierte oder funktionsbasierte Installation und klicken auf Weiter.
5. Wählen Sie den lokalen Server aus und klicken Sie auf Weiter.
6. Überspringen Sie den Bildschirm „Rollen“ und klicken Sie auf Weiter.
7. Wählen Sie im Bildschirm „Funktionen“ Folgendes aus: Failover-Clustering.
8. Gehen Sie auf Funktionen hinzufügen wenn sie aufgefordert werden, Management-Tools einzubeziehen.
9. Gehen Sie auf Weiter und dann Installieren.
10. Warten Sie, bis die Installation abgeschlossen ist, und klicken Sie dann. Menu.
11. Wiederholen Sie den Vorgang auf allen Servern, die am Cluster teilnehmen sollen.

4.2.2 Erstellen des Failoverclusters

Nachdem die Failover-Clustering-Funktion auf allen Knoten installiert wurde, erstellen Sie den Cluster von einem Knoten aus.

1. Öffne Failover-Cluster-Manager von Server-Manager -> Zubehör.
2. Gehen Sie auf Cluster erstellen im Aktionsbereich.
3. Gehen Sie auf Weiter auf der Seite „Bevor Sie beginnen“.
4. Gehen Sie auf Jetzt entdecken und fügen Sie alle Server hinzu, die als Clusterknoten fungieren sollen.
5. Gehen Sie auf Weiter nach dem Hinzufügen aller Knoten.
6. Verlassen Alle Tests durchführen (empfohlen) ausgewählt und angeklickt Weiter.
7. Prüfen Sie die Ergebnisse der Validierungstests und beheben Sie etwaige Fehler oder Warnungen.
8. Gehen Sie auf Farbe nach erfolgreicher Validierung.
9. Geben Sie einen Namen für den Cluster und eine IP-Adresse ein.
10. Deaktivieren Fügen Sie den gesamten geeigneten Speicher zum Cluster hinzu da kein gemeinsamer Speicher benötigt wird.
11. Gehen Sie auf Weiter und überprüfen Sie die Bestätigung.
12. Gehen Sie auf Farbe um den Cluster zu erstellen.

4.2.3 Validierung der Clusterkonfiguration

Überprüfen Sie die Clusterkonfiguration, um sicherzustellen, dass alle Knoten ordnungsgemäß kommunizieren können und der Cluster korrekt funktioniert.

1. In Failover-Cluster-ManagerKlicken Sie mit der rechten Maustaste auf den Clusternamen.
2. Wählen Sie Cluster validieren aus dem Menü.
3. Gehen Sie auf Weiter auf der Seite „Bevor Sie beginnen“.
4. Wählen Sie Alle Tests durchführen (empfohlen) und klicken auf Weiter.
5. Gehen Sie auf Weiter mit den Validierungstests beginnen.
6. Prüfen Sie den Validierungsbericht nach Abschluss der Tests.
7. Beheben Sie alle im Bericht aufgeführten Fehler oder Warnungen.
8. Gehen Sie auf Farbe Um den Assistenten zu schließen.

4.3 Installieren SQL Server für Verfügbarkeitsgruppen

Installieren SQL Server auf jedem Knoten, der an der Verfügbarkeitsgruppe teilnehmen soll, unter Verwendung der Option für die eigenständige Installation.

1. Führen Sie die SQL Server Installationsmedien auf dem ersten Knoten.
2. Wählen Sie New SQL Server eigenständige Installation.
3. Geben Sie den Produktkey ein oder wählen Sie die Testversion aus.
4. Akzeptieren Sie die Lizenzbedingungen und klicken Sie Weiter.
5. Prüfen Sie alle Voraussetzungen und beheben Sie etwaige Probleme.
6. Wählen Sie auf der Seite „Funktionsauswahl“ Folgendes aus: Datenbank-Engine-Dienste.
7. Konfigurieren Sie den Instanznamen (verwenden Sie auf allen Knoten denselben Instanznamen).
8. Geben Sie auf der Seite Serverkonfiguration die Anmeldeinformationen des Dienstkontos an.
9. Dienste konfigurierentartup-Typen als automatische.
10. Wählen Sie auf der Seite „Datenbankmodulkonfiguration“ den Authentifizierungsmodus aus.
11. Administratorkonten hinzufügen.
12. Konfigurieren Sie die Datenverzeichnisse mithilfe einheitlicher Pfade auf allen Knoten.
13. Schließen Sie die Installation ab und überprüfen Sie den Erfolg.
14. Die Installation wird auf allen anderen Clusterknoten mit identischen Einstellungen wiederholt.

4.4 Aktivieren der Funktion „Immer aktive Verfügbarkeitsgruppen“

Nach der Installation SQL Server Aktivieren Sie auf allen Knoten die Funktion „Always On Availability Groups“ auf jeder Instanz.

4.4.1 Aktivieren über SQL Server Konfigurationsmanager

Arbeiten jederzeit weiterbearbeiten können. Jede Präsentation und jeder KI-Avatar, den Sie von Grund auf neu erstellen oder hochladen, SQL Server Configuration Manager zur Aktivierung von Always On-Verfügbarkeitsgruppen über die grafische Benutzeroberfläche.

1. Öffne SQL Server Konfigurationsmanager am ersten Knoten.
2. Erweitern Sie die Funktionalität der SQL Server Leistungen im linken Bereich.
3. Klicken Sie mit der rechten Maustaste auf SQL Server Instanz und wählen Sie Eigenschaften im Vergleich.
4. Klicken Sie auf Hochverfügbarkeit ohne Unterbrechung Tab.
5. Einblick in das AlwaysOn-Verfügbarkeitsgruppen aktivieren.
6. Überprüfen Sie, ob der Name des Windows-Failoverclusters korrekt ist.
7. Gehen Sie auf OK um die Änderungen zu speichern.
8. Gehen Sie auf OK auf die Warnung, dass der Dienst res sein musstarted.
9. Klicken Sie mit der rechten Maustaste auf SQL Server Service und auswählen Restart.
10. Warten Sie, bis der Dienst beendet isttart erfolgreich.
11. Wiederholen Sie den Vorgang auf allen Clusterknoten.

4.4.2 Aktivierung über PowerShell

PowerShell bietet eine skriptbasierte Methode, um Always On-Verfügbarkeitsgruppen über mehrere Knoten hinweg zu aktivieren.

1. Öffnen Sie PowerShell als Administrator auf dem ersten Knoten.
2. Importieren Sie die SQL Server PowerShell-Modul:

   Import-Module SQLPS -DisableNameChecking

3. Always On-Verfügbarkeitsgruppen aktivieren:

   Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force

4. Der Dienst wird automatisch neu gestartettart bei Verwendung des Force-Parameters.
5. Überprüfen Sie, ob die Funktion aktiviert ist:

   Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled

6. Wiederholen Sie dies für jeden Clusterknoten und ersetzen Sie dabei die Server- und Instanznamen durch die entsprechenden Werte.

4.4.3 Überprüfen, ob die Funktion aktiviert ist

Bevor Sie mit der Konfiguration fortfahren, vergewissern Sie sich, dass Always On Availability Groups auf allen Instanzen aktiviert ist.

1. Verbinde dich mit jedem SQL Server Instanz mit SQL Server Management-Studio.
2. Öffnen Sie ein neues Abfragefenster und führen Sie Folgendes aus:

   SELECT SERVERPROPERTY('IsHadrEnabled')

3. Prüfen Sie, ob das Ergebnis 1 (aktiviert) ist.
4. Überprüfen Sie, dass die SQL Server Die Instanz wird im Failovercluster-Manager unter den Clusterrollen angezeigt.
5. Überprüfen Sie, ob der Verfügbarkeitsgruppenendpunkt existiert, indem Sie Folgendes ausführen:

   SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'

6. Falls der Endpunkt nicht existiert, wird er während der Erstellung der Verfügbarkeitsgruppe erstellt.

4.5 Datenbanken für Verfügbarkeitsgruppen vorbereiten

Datenbanken müssen bestimmte Anforderungen erfüllen, bevor sie einer Verfügbarkeitsgruppe hinzugefügt werden können.

4.5.1 Anforderungen an das Datenbank-Wiederherstellungsmodell

Ändern Sie das Datenbankwiederherstellungsmodell auf der primären Replik auf FULL, bevor Sie sie einer Verfügbarkeitsgruppe hinzufügen.

1. Stellen Sie eine Verbindung zur primären Replik her über SQL Server Management-Studio.
2. Klicken Sie mit der rechten Maustaste auf die Datenbank und wählen Sie aus Eigenschaften im Vergleich.
3. Wähle aus Einstellungen
4. Ändern Wiederherstellungsmodell zu Vollständiger.
5. Gehen Sie auf OK um die Änderung zu speichern.
6. Alternativ können Sie Transact-SQL verwenden:

   ALTER DATABASE DatabaseName SET RECOVERY FULL;

4.5.2 Erstellung vollständiger Datenbanksicherungen

Erstellen Sie eine vollständige Datenbanksicherung, um die für Verfügbarkeitsgruppen erforderliche Sicherungskette herzustellen.

1. In SQL Server Im Management Studio klicken Sie mit der rechten Maustaste auf die Datenbank.
2. Wählen Sie Aufgaben -> Sichern.
3. Verify Sicherungstyp eingestellt ist Vollständiger.
4. Wählen Sie ein Sicherungsziel aus oder fügen Sie ein neues Ziel hinzu.
5. Gehen Sie auf OK um die Datensicherung durchzuführen.
6. Alternativ können Sie Transact-SQL verwenden:

   BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';

4.5.3 Sicherung des Transaktionsprotokolls

Erstellen Sie eine Sicherungskopie des Transaktionsprotokolls, um sicherzustellen, dass die Protokollkette aufgebaut ist und die Initialisierungszeit minimiert wird.

1. In SQL Server Im Management Studio klicken Sie mit der rechten Maustaste auf die Datenbank.
2. Wählen Sie Aufgaben -> Sichern.
3. Ändern Sicherungstyp zu Transaktionsprotokoll.
4. Wählen Sie ein Sicherungsziel aus.
5. Gehen Sie auf OK um die Datensicherung durchzuführen.
6. Alternativ können Sie Transact-SQL verwenden:

   BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';

4.6 Erstellen der Verfügbarkeitsgruppe

Erstellen Sie die Verfügbarkeitsgruppe mithilfe einer der verfügbaren Methoden, je nach Ihren Präferenzen und Automatisierungsanforderungen.

4.6.1 Verwenden des Assistenten für neue Verfügbarkeitsgruppen

Der Assistent für neue Verfügbarkeitsgruppen bietet eine grafische Benutzeroberfläche zum Erstellen von Verfügbarkeitsgruppen.

1. In SQL Server Management Studio, stellen Sie eine Verbindung zu der Instanz her, die host das Hauptreplikat.
2. Erweitern Sie die Funktionalität der Hochverfügbarkeit ohne Unterbrechung im Objekt-Explorer.
3. Der rechten Maustaste auf Verfügbarkeitsgruppen gedrückt und wählen Sie Assistent für neue Verfügbarkeitsgruppen.
   
4. Gehen Sie auf Weiter auf der Einführungsseite.
5. Geben Sie einen Namen für die Verfügbarkeitsgruppe ein und klicken Sie auf Weiter.
6. Wählen Sie auf der Seite „Datenbanken auswählen“ die einzuschließenden Datenbanken aus.
7. Vergewissern Sie sich, dass die Datenbanken alle Voraussetzungen erfüllen, und klicken Sie auf Weiter.
8. Klicken Sie auf der Seite „Replikate angeben“ auf Replik hinzufügen.
9. Verbindung zu jeder sekundären Replikatinstanz herstellen.
10. Konfigurieren Sie die Replikateigenschaften für jede Instanz (Verfügbarkeitsmodus, Failover-Modus).
11. Klicken Sie auf Endpunkte Registerkarte und Endpunktkonfiguration überprüfen.
12. Klicken Sie auf Backup-Einstellungen Registerkarte und Backup-Prioritäten konfigurieren.
13. Klicken Sie auf Hörer Tabulator und optional einen Listener erstellen.
14. Gehen Sie auf Weiter und wählen Sie die Datensynchronisierungsmethode aus.
15. Prüfen Sie die Validierungsergebnisse und beheben Sie etwaige Probleme.
16. Gehen Sie auf Weiter und lesen Sie die Zusammenfassung.
17. Gehen Sie auf Farbe um die Verfügbarkeitsgruppe zu erstellen.
18. Den Fortschritt überwachen und die erfolgreiche Erstellung bestätigen.

4.6.2 Verwendung von Transact-SQL

Erstellen Sie Verfügbarkeitsgruppen mithilfe von Transact-SQL für skriptfähige, wiederholbare Bereitstellungen.

1. Erstellen Sie die Verfügbarkeitsgruppe auf dem primären Replikat:

   CREATE AVAILABILITY GROUP AG_Name
   FOR DATABASE DatabaseName
   REPLICA ON
     'PrimaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
     'SecondaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

2. Fügen Sie die sekundäre Replik der Verfügbarkeitsgruppe hinzu:

   ALTER AVAILABILITY GROUP AG_Name JOIN;

3. Treten Sie der sekundären Datenbank bei:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 Verwendung von PowerShell

PowerShell bietet Skripting-Funktionen für die Erstellung und Verwaltung von Verfügbarkeitsgruppen.

1. Erstellen Sie das Verfügbarkeitsgruppenobjekt:

   $AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"

2. Datenbanken hinzufügen:

   Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

3. Konfigurieren Sie Replikate mit den gewünschten Eigenschaften mithilfe des Cmdlets New-SqlAvailabilityReplica.
4. Verbinden Sie sekundäre Replikate mithilfe des Cmdlets Join-SqlAvailabilityGroup.

4.7 Hinzufügen von Replikaten zur Verfügbarkeitsgruppe

Konfigurieren Sie replikatspezifische Eigenschaften, die steuern, wie jede Instanz an der Verfügbarkeitsgruppe teilnimmt.

4.7.1 Konfigurieren der Replikateigenschaften

Legen Sie für jede Replik Eigenschaften fest, um ihre Rolle und Fähigkeiten innerhalb der Verfügbarkeitsgruppe zu definieren.

1. In SQL Server Management Studio erweitern Hochverfügbarkeit ohne Unterbrechung -> Verfügbarkeitsgruppen.
2. Erweitern Sie die Verfügbarkeitsgruppe und anschließend die Erweiterung Verfügbarkeitsrepliken.
   
3. Klicken Sie mit der rechten Maustaste auf eine Replik und wählen Sie aus Eigenschaften im Vergleich.
4. Überprüfen und ändern Sie die Verbindungseinstellungen für die primäre und sekundäre Rolle.
5. Konfigurieren Sie bei Bedarf die Werte für das Sitzungs-Timeout.
6. Gehen Sie auf OK um Änderungen zu speichern.

4.7.2 Einstellen von Verfügbarkeitsmodi

Konfigurieren Sie den Verfügbarkeitsmodus, um das Synchronisierungsverhalten zwischen Replikaten zu steuern.

1. Klicken Sie mit der rechten Maustaste auf die Verfügbarkeitsgruppe und wählen Sie aus Eigenschaften im Vergleich.
2. Bei Allgemein Seite, gehen Sie zu Verfügbarkeitsrepliken .
3. Wählen Sie für jede Replik aus Synchroner Commit or Asynchroner Commit aus dem Dropdown.
4. Verwenden Sie synchrones Commit für lokale Hochverfügbarkeitsreplikate.
5. Verwenden Sie asynchrone Commits für geografisch weit entfernte Disaster-Recovery-Replikate.
6. Gehen Sie auf OK um die Konfiguration zu speichern.

4.7.3 Festlegen von Ausfallmodi

Konfigurieren Sie den Failover-Modus, um zu steuern, wie ein Failover für jede Replikat-Komponente erfolgt.

1. Klicken Sie mit der rechten Maustaste auf die Verfügbarkeitsgruppe und wählen Sie aus Eigenschaften im Vergleich.
2. Bei Allgemein Seite, gehen Sie zu Verfügbarkeitsrepliken .
3. Wählen Sie für synchrone Commit-Replikate Folgendes aus: automatische or Handbuch Ausfallmodus.
4. Die automatische Failover-Funktion erfordert den synchronen Commit-Modus und ermöglicht ein unbeaufsichtigtes Failover.
5. Bei asynchronen Commit-Replikaten ist nur ein manuelles Failover möglich.
6. Konfigurieren Sie bis zu drei Replikate für automatisches Failover (ein primäres und zwei sekundäre).
7. Gehen Sie auf OK um die Einstellungen zu übernehmen.

4.7.4 Konfigurieren der Sicherungseinstellungen

Legen Sie die Sicherungseinstellungen fest, um zu steuern, wo Sicherungsvorgänge durchgeführt werden sollen.

1. Klicken Sie mit der rechten Maustaste auf die Verfügbarkeitsgruppe und wählen Sie aus Eigenschaften im Vergleich.
2. Wählen Sie Backup-Einstellungen im linken Bereich.
3. Wählen Sie eine der Backup-Optionen aus:
   • Bevorzugen Sie die SekundarstufeBackups werden, falls verfügbar, auf dem sekundären Speicher, andernfalls auf dem primären Speicher erstellt.
   • Nur sekundär: Backups nur auf sekundären Replikaten
   • primär: Backups nur auf der primären Replik
   • Jede Replik: Backups auf jeder verfügbaren Replik
4. Legen Sie für jede Replik Prioritätswerte für die Datensicherung fest (0-100).
5. Höhere Prioritätswerte kennzeichnen bevorzugte Backups. tarbekommt.
6. Gehen Sie auf OK um die Einstellungen zu speichern.

4.8 Konfigurieren des Verfügbarkeitsgruppenlisteners

Erstellen Sie einen Listener, der einen einzigen Verbindungspunkt bereitstellt, der automatisch zur aktuellen primären Replik weiterleitet.

4.8.1 Erstellen des Listeners

Fügen Sie der Verfügbarkeitsgruppe einen Listener für die Clientverbindungsverwaltung hinzu.

1. In SQL Server Management Studio, Verfügbarkeitsgruppe erweitern.
2. Der rechten Maustaste auf Verfügbarkeitsgruppen-Hörer gedrückt und wählen Sie Zuhörer hinzufügen.
   
3. Geben Sie einen DNS-Namen für den Listener ein (z. B. AG_Listener).
4. Geben Sie die Portnummer ein (Standard ist 1433).
5. Wählen Sie Statische IP für den Netzwerkmodus.
6. Gehen Sie auf Speichern Um jedem Subnetz eine IP-Adresse hinzuzufügen.
7. Geben Sie die IP-Adresse ein und wählen Sie das Subnetz aus.
8. Gehen Sie auf OK um den Listener zu erstellen.
9. Überprüfen Sie, ob der Listener im Objekt-Explorer angezeigt wird und online ist.

4.8.2 Konfigurieren der DNS- und IP-Einstellungen

Überprüfen Sie die DNS-Registrierung und die Netzwerkkonfiguration für den Listener.

1. Öffnen Sie den DNS-Manager auf dem Domänencontroller.
2. Überprüfen Sie, ob der Listener-Name bei allen IP-Adressen registriert wurde.
3. DNS-Auflösung von Client-Rechnern testen:

   nslookup ListenerName

4. Prüfen Sie, ob alle konfigurierten IP-Adressen zurückgegeben werden.
5. Im Failovercluster-Manager erweitern Rollen und wählen Sie die Verfügbarkeitsgruppe aus.
6. Überprüfen Sie, ob die Ressourcen der IP-Adresse online sind.
7. Prüfen Sie, ob die Netzwerknamensressource online ist.
   

4.8.3 Testen der Listener-Konnektivität

Überprüfen Sie, ob Clientanwendungen über den Listener eine Verbindung herstellen können.

1. Öffnen Sie von einem Client-Rechner aus SQL Server Management-Studio.
2. Stellen Sie die Verbindung über den Listener-Namen anstelle des Servernamens her.
3. Führen Sie eine Abfrage aus, um die Verbindung zum aktuellen primären Replikat zu überprüfen:

   SELECT @@SERVERNAME;

4. Testen Sie das Read-Intent-Routing, indem Sie ApplicationIntent=ReadOnly zur Verbindungszeichenfolge hinzufügen.
5. Überprüfen Sie, ob die Verbindung auf eine lesbare sekundäre Replik umgeleitet wird.
6. Testen Sie das Failover, indem Sie die Verfügbarkeitsgruppe manuell umschalten und die Wiederverbindung überprüfen.

4.9 Datensynchronisationsmethoden

Wählen Sie eine Datensynchronisierungsmethode, um sekundäre Replikate mit Datenbankkopien zu initialisieren.

4.9.1 Automatische Aussaat

Die automatische Seeding-Methode überträgt Datenbankdaten über das Netzwerk, ohne dass manuelle Backups und Wiederherstellungen erforderlich sind.

1. Wählen Sie bei der Erstellung der Verfügbarkeitsgruppe Folgendes aus: Automatische Aussaat als Synchronisationsmethode.
   
2. Stellen Sie die Netzwerkverbindung und ausreichende Bandbreite zwischen den Replikaten sicher.
3. Die primäre Replik streamt Datenbankdaten automatisch an sekundäre Replikate.
4. Überwachen Sie den Fortschritt der Seeding-Vorgänge mithilfe des Dashboards der Verfügbarkeitsgruppe oder der DMVs.
5. Automatische Aussaat erfordert SQL Server 2016 oder höher.
6. Bei großen Datenbanken sollten die Auswirkungen auf das Netzwerk berücksichtigt und die Auslastung in Zeiten geringer Nutzung geplant werden.

4.9.2 Manuelles Seeding (Sicherung und Wiederherstellung)

Manuelles Seeding beinhaltet das Erstellen von Backups auf dem primären Server und deren Wiederherstellung auf sekundären Replikaten.

1. Auf dem primären Replikat ein vollständiges Backup erstellen:

   BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';

2. Erstellen Sie eine Sicherungskopie des Transaktionsprotokolls:

   BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';

3. Auf jeder sekundären Replik das vollständige Backup wiederherstellen:

   RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;

4. Protokollsicherung wiederherstellen:

   RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;

5. Verknüpfen Sie die Datenbank mit der Verfügbarkeitsgruppe:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

6. Überprüfen Sie, ob die Synchronisierung beginnt und die Datenbank den Status SYNCHRONISIERT erreicht.

4.9.3 Datenbank-Snapshot-Dateien

Verwenden Sie Datenbank-Snapshot-Dateien, um sekundäre Replikate aus vorhandenen Datenbankdateien zu initialisieren.

1. Trennen oder sichern Sie die Datenbank auf der primären Replik.
2. Kopieren Sie die Datenbankdateien auf jede sekundäre Replik unter Verwendung der gleichen Dateipfade.
3. Auf sekundären Replikaten die Datenbank anhängen oder ohne Wiederherstellung wiederherstellen.
4. Stellen Sie sicher, dass sich die Datenbank im Status „Wiederherstellung“ befindet.
5. Verknüpfen Sie die Datenbank mit der Verfügbarkeitsgruppe.
6. Diese Methode ist nützlich für sehr große Datenbanken, bei denen eine Netzwerkübertragung unpraktisch wäre.

5. FAQ

5.1 Allgemeine Fragen

F: Worin besteht der Unterschied zwischen Always On FCI und Always On AG?

A: Always On Failover Cluster-Instanzen bieten hohe Verfügbarkeit auf Instanzebene durch gemeinsam genutzten Speicher, während Always On Availability Groups hohe Verfügbarkeit auf Datenbankebene ohne gemeinsam genutzten Speicher gewährleisten. AGs bieten lesbare sekundäre Instanzen und eine flexiblere geografische Verteilung.

F: Kann ich Always On-Verfügbarkeitsgruppen verwenden mit SQL Server Standardausgabe?

A: Ja, SQL Server Die Standard Edition 2016 und spätere Versionen unterstützen Basic Availability Groups mit Einschränkungen, darunter eine Datenbank pro AG, maximal zwei Replikate und keine Unterstützung für lesbare sekundäre Replikate.

F: Benötige ich gemeinsam genutzten Speicher für Always On-Verfügbarkeitsgruppen?

A: Nein, Verfügbarkeitsgruppen benötigen keinen gemeinsam genutzten Speicher. Jede Replik verwaltet unabhängige Kopien der Datenbanken auf lokalem Speicher, die über die Übertragung von Transaktionsprotokollen synchronisiert werden.

F: Wie viele Replikate kann eine Verfügbarkeitsgruppe maximal enthalten?

A: SQL Server Die Enterprise Edition unterstützt bis zu neun Replikate (ein primäres und acht sekundäre). Verteilte Verfügbarkeitsgruppen können insgesamt bis zu 18 Replikate über zwei Verfügbarkeitsgruppen hinweg unterstützen.

5.2 Konfigurationsfragen

F: Wie wähle ich zwischen synchronem und asynchronem Commit-Modus?

A: Verwenden Sie synchrones Commit für Anforderungen an verlustfreie Daten innerhalb desselben Rechenzentrums oder in Netzwerken mit geringer Latenz. Verwenden Sie asynchrones Commit für entfernte Disaster-Recovery-Replikate, bei denen synchrones Commit die Leistung beeinträchtigen würde.

F: Kann ich synchrone und asynchrone Replikate in derselben Verfügbarkeitsgruppe mischen?

A: Ja, Verfügbarkeitsgruppen unterstützen gemischte Konfigurationen mit synchronen und asynchronen Replikaten. Dies ermöglicht lokale Hochverfügbarkeit mit synchronen Replikaten und entfernte Notfallwiederherstellung mit asynchronen Replikaten.

F: Was passiert mit meinen Verbindungen während eines Failovers?

A: Bestehende Verbindungen werden beim Failover getrennt. Anwendungen mit einer Logik zur Verbindungswiederholung stellen automatisch über den Listener eine Verbindung zum neuen primären Server her. Der Failover-Prozess ist in der Regel innerhalb von Sekunden bis Minuten abgeschlossen.

F: Muss ich Anmeldungen und Aufträge über Replikate hinweg synchronisieren?

A: Ein SQL Server Bei Versionen von 2019 und früher ist dies der Fall – Anmeldungen, SQL-Agent-Aufträge und verknüpfte Server müssen manuell synchronisiert werden. SQL Server 2022 werden enthaltene Verfügbarkeitsgruppen eingeführt, die diese Objekte automatisch einschließen.

5.3 Managementfragen

F: Kann ich Backups auf sekundären Replikaten ausführen?

A: Ja, sekundäre Replikate unterstützen vollständige, differenzielle und Transaktionsprotokollsicherungen. Konfigurieren Sie die Sicherungseinstellungen, um Sicherungen vom primären Replikat auszulagern und dessen Ressourcennutzung zu reduzieren.

F: Wie patche ich? SQL Server mit minimalen Ausfallzeiten?

A: Verwenden Sie Rolling Upgrades, indem Sie zuerst die sekundären Replikate patchen, dann ein manuelles Failover auf ein gepatchtes sekundäres Replikat durchführen und schließlich das ehemalige primäre Replikat patchen. Dadurch wird die Ausfallzeit auf die Dauer des Failovers minimiert.

F: Kann ich Datenbanken zu einer bestehenden Verfügbarkeitsgruppe hinzufügen?

A: Ja, Datenbanken können zu laufenden Verfügbarkeitsgruppen hinzugefügt werden. Die Datenbank muss sich im vollständigen Wiederherstellungsmodell mit einer vollständigen Sicherung befinden, und sekundäre Replikate müssen entweder automatisch oder manuell mit Sicherung und Wiederherstellung initialisiert werden.

F: Was ist automatische Aussaat und sollte ich sie nutzen?

A: Die automatische Initialisierung überträgt Datenbankdaten über das Netzwerk, um sekundäre Replikate ohne manuelle Datensicherung zu initialisieren. Verwenden Sie diese Funktion für kleinere Datenbanken oder wenn die Netzwerkbandbreite ausreicht. Bei sehr großen Datenbanken kann die manuelle Initialisierung schneller sein.

F: Wo sollte ich DBCC CHECKDB in einer Verfügbarkeitsgruppe ausführen?

A: Sie sollten DBCC CHECKDB auf den sekundären Replikaten ausführen, um die Last auf dem primären Replikat zu reduzieren. Datenbankkonsistenzprüfungen können auf sekundären Datenbanken durchgeführt werden, ohne die Leistung des primären Replikats zu beeinträchtigen.

Weitere Details zu DBCC CHECKDB finden Sie in unserer umfassende Anleitung.

5.4 Fragen zur Fehlerbehebung

F: Warum befindet sich meine Datenbank im Status „NICHT SYNCHRONISIERT“?

A: Häufige Ursachen sind Netzwerkverbindungsprobleme, unterbrochene Datenübertragung, unzureichender Speicherplatz auf sekundären Replikaten oder Endpunktprobleme. Überprüfen Sie die Beschreibung des Synchronisierungsstatus und SQL Server Fehlerprotokolle für detaillierte Informationen. Wenn die sekundäre Datenbank einen Fehler aufgetreten ist Erholungszustand oder zeigt Wiederherstellung ausstehendSiehe die verlinkten Anleitungen für tarbehoben.

F: Wie kann ich ein Failover erzwingen, wenn der primäre Server nicht verfügbar ist?

A: Stellen Sie eine Verbindung zu einer sekundären Replik her und führen Sie den Befehl ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS aus. Dadurch wird ein potenzieller Datenverlust erkannt und die sekundäre Replik sofort zur primären Replik hochgestuft.

F: Warum können Clients keine Verbindung zu meinem Listener herstellen?

A: Überprüfen Sie im Failover Cluster Manager, ob der Listener online ist, ob die DNS-Registrierung erfolgreich war, ob alle Listener-IPs von Clients aus erreichbar sind und ob die Firewall-Regeln den Datenverkehr zum Listener-Port zulassen.

F: Was bedeutet eine große Redo-Warteschlange?

A: Eine große Redo-Warteschlange deutet darauf hin, dass die sekundäre Replik die Protokolleinträge nicht so schnell anwenden kann, wie sie eintreffen. Dies kann auf Engpässe bei der Festplatten-E/A, CPU-Beschränkungen oder Blockierungen durch schreibgeschützte Abfragen auf der sekundären Replik hinweisen.

F: Was soll ich tun, wenn ein Katastrophenfall alle Replikate betrifft und meine Backups ebenfalls beschädigt sind?

A: Dieses Worst-Case-Szenario ist zwar extrem rarDies kann beispielsweise durch Ransomware-Angriffe, großflächige Speicherausfälle oder Kettenreaktionen von Katastrophen verursacht werden. Ihre wichtigste Verteidigung ist Prävention: Pflegen Sie geografisch verteilte Replikate, speichern Sie Backups an separaten Standorten und
Testen Sie Ihre Notfallwiederherstellungsverfahren regelmäßig. Wenn alle Standardwiederherstellungsoptionen fehlschlagen, ist ein spezialisiertes System erforderlich. SQL-Datenwiederherstellungstool kann als letzte Notfallmaßnahme versuchen, Daten aus beschädigten MDF-Dateien zu extrahieren.

5.5 Lizenzierung und Cost Fragen

F: Wie werden Always On Verfügbarkeitsgruppen lizenziert?

A: SQL Server Die Lizenzierung hängt von der Edition und dem Bereitstellungsmodell ab. Verfügbarkeitsgruppen der Enterprise Edition erfordern Enterprise-Lizenzen auf allen Replikaten. Passive sekundäre Replikate können unter bestimmten Bedingungen für eine kostenlose Lizenzierung in Frage kommen.

F: Kann ich verwenden? SQL Server Developer Edition für Verfügbarkeitsgruppen?

A: Ja, die Developer Edition umfasst alle Funktionen der Enterprise Edition, einschließlich der vollständigen Unterstützung von Verfügbarkeitsgruppen. Sie ist jedoch nur für Entwicklungs- und Testzwecke lizenziert, nicht für den Produktiveinsatz.

F: Benötigen lesbare Sekundärdateien zusätzliche Lizenzen?

A: Die Lizenzierung hängt vom jeweiligen Szenario ab. Passive Sekundärserver für die Notfallwiederherstellung benötigen in der Regel keine Lizenzen. Aktive Sekundärserver, die schreibgeschützte Arbeitslasten bedienen, benötigen im Allgemeinen Lizenzen, wobei die genauen Bedingungen variieren.

F: Gibt es eine kostenlose Möglichkeit, hohe Verfügbarkeit zu erreichen mit SQL Server?

A: SQL Server Die Express Edition unterstützt keine Verfügbarkeitsgruppen. SQL Server Die Standard Edition unterstützt Basic Availability Groups.tarting mit SQL Server 2016, Bereitstellung grundlegender Hochverfügbarkeit bei der Standard Edition-Lizenzierung costs.

F: Was sind verteilte Verfügbarkeitsgruppen?

A: Verteilte Verfügbarkeitsgruppen sind eine spezielle Art von Verfügbarkeitsgruppe, die sich über zwei separate Verfügbarkeitsgruppen erstreckt und Szenarien ermöglicht, die die Fähigkeiten herkömmlicher Verfügbarkeitsgruppen übertreffen. Eingeführt in SQL Server Seit 2016 werden mit verteilten Verfügbarkeitsgruppen die Anforderungen an Skalierung und geografische Verteilung erfüllt.

6. Fazit

6.1 Zusammenfassung der wichtigsten Punkte

SQL Server Always On Availability Groups sind Microsofts führende Lösung für Hochverfügbarkeit und Disaster Recovery in unternehmenskritischen Datenbanken. Sie bieten Failover auf Datenbankebene ohne gemeinsam genutzten Speicher, lesbare sekundäre Replikate zur Auslagerung von Workloads und eine flexible geografische Verteilung für umfassenden Datenschutz. Für Unternehmen, die noch Lösungen wie … verwenden Holztransport or ReplikationVerfügbarkeitsgruppen bieten einen robusteren und betrieblich einfacheren Upgrade-Pfad.

6.2 Wann Always On-Verfügbarkeitsgruppen verwenden?

Wählen Sie Verfügbarkeitsgruppen, wenn Sie hohe Verfügbarkeit auf Datenbankebene mit automatischer Failover-Funktion benötigen. Organisationen, die für kritische Datenbanken einen vollständigen Schutz vor Datenverlust benötigen, profitieren von synchronen Commit-Replikaten mit automatischer Failover-Funktion. Anwendungen, die Leseskalierungsfunktionen benötigen, nutzen lesbare sekundäre Replikate, um Abfragelasten zu verteilen.

6.3 S erhaltentarted mit Ihrer Implementierung

Beginnen Sie die Planung der Verfügbarkeitsgruppe mit der Bewertung der Geschäftsanforderungen, einschließlich RTO, RPO und Budgetbeschränkungen. Dokumentieren Sie die bestehende Datenbankinfrastruktur, Anwendungsabhängigkeiten und Lücken in der Hochverfügbarkeit. Entwerfen Sie eine Architektur für die Verfügbarkeitsgruppe, die die Anforderungen erfüllt und gleichzeitig die Ressourcenbeschränkungen einhält.

Referenzen

• Offizielles Microsoft-Dokument: Was ist eine Always On-Verfügbarkeitsgruppe?
• Offizielles Microsoft-Dokument: S bekommentarted mit Always On Verfügbarkeitsgruppen
• Offizielles Microsoft-Dokument: Verteilte Verfügbarkeitsgruppen

---

Über den Autor

Yuan Sheng ist ein erfahrener Datenbankadministrator (DBA) mit über 10 Jahren Erfahrung in SQL Server Umgebungen und Unternehmensdatenbankverwaltung. Er hat Hunderte von Datenbankwiederherstellungsszenarien in Finanzdienstleistungs-, Gesundheits- und Fertigungsunternehmen erfolgreich gelöst.

Yuan ist spezialisiert auf SQL Server Datenbankwiederherstellung, Hochverfügbarkeitslösungen und Leistungsoptimierung. Seine umfangreiche praktische Erfahrung umfasst die Verwaltung von Multi-Terabyte-Datenbanken, die Implementierung von Always On Availability Groups und die Entwicklung automatisierter Backup- und Wiederherstellungsstrategien für unternehmenskritische Geschäftssysteme.

Durch sein technisches Fachwissen und seinen praktischen Ansatz konzentriert sich Yuan auf die Erstellung umfassender Anleitungen, die Datenbankadministratoren und IT-Experten bei der Lösung komplexer SQL Server Herausforderungen effizient. Er bleibt auf dem Laufenden mit den neuesten SQL Server und die sich entwickelnden Datenbanktechnologien von Microsoft und testet regelmäßig Wiederherstellungsszenarien, um sicherzustellen, dass seine Empfehlungen den bewährten Vorgehensweisen der Praxis entsprechen.

Haben Sie Fragen zu SQL Server Wiederherstellung oder benötigen Sie zusätzliche Anleitung zur Datenbank-Fehlerbehebung? Yuan begrüßt Feedback und Vorschläge zur Verbesserung dieser technischen Ressourcen.