Freigeben über

Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server)

In diesem Thema werden die Konzepte der Always On-Verfügbarkeitsgruppen vorgestellt, die für die Konfiguration und Verwaltung einer oder mehrerer Verfügbarkeitsgruppen in SQL Server 2014 zentral sind. Eine Zusammenfassung der Vorteile von Verfügbarkeitsgruppen und eine Übersicht über die Terminologie von AlwaysOn-Verfügbarkeitsgruppen finden Sie unter AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

Eine Verfügbarkeitsgruppe unterstützt eine Failoverumgebung für einen diskreten Satz von Benutzerdatenbanken (als Verfügbarkeitsdatenbankenbezeichnet), die zusammen ein Failover ausführen. Eine Verfügbarkeitsgruppe unterstützt eine Reihe primärer Datenbanken und eine bis acht Sätze entsprechender sekundärer Datenbanken. Sekundäre Datenbanken sind keine Sicherungen. Sichern Sie Ihre Datenbanken und ihre Transaktionsprotokolle regelmäßig.

Tipp

Von einer primären Datenbank können beliebige Sicherungstypen erstellt werden. Alternativ können Sie Protokollsicherungen und vollständige Kopiesicherungen von sekundären Datenbanken erstellen. Weitere Informationen finden Sie unter Active Secondaries: Backup on Secondary Replicas (AlwaysOn Availability Groups).

Jede Verfügbarkeitsdatenbank wird von einem Verfügbarkeitsreplikat gehostet. Es gibt zwei Arten von Verfügbarkeitsreplikaten: ein einzelnes primäres Replikat. welche die primären Datenbanken und ein bis acht sekundäre Replikate hostet, von denen jede eine Reihe von sekundären Datenbanken hostet und als potenzielle Failoverziele für die Verfügbarkeitsgruppe dient. Eine Verfügbarkeitsgruppe führt auf der Ebene eines Verfügbarkeitsreplikats ein Failover aus. Ein Verfügbarkeitsreplikat bietet Redundanz nur auf Datenbankebene für die Datenbankgruppe in einer Verfügbarkeitsgruppe. Failovers werden nicht durch Datenbankprobleme verursacht, wie z. B. eine Datenbank, die aufgrund eines Verlusts einer Datendatei oder beschädigung eines Transaktionsprotokolls verdächtig wird.

Das primäre Replikat stellt die primären Datenbanken für Lese-/Schreibverbindungen von Clients bereit. Außerdem geschieht ein als Datensynchronisierung bekannter Prozess auf der Datenbankebene. Vom primären Replikat werden Transaktionsprotokoll-Datensätze jeder primären Datenbank an jede sekundäre Datenbank gesendet. Die Transaktionsprotokoll-Datensätze werden von jedem sekundären Replikat zwischengespeichert (das Protokoll wirdfestgeschrieben ) und anschließend auf die entsprechende sekundäre Datenbank angewendet. Die Datensynchronisierung erfolgt zwischen der primären Datenbank und jeder verbundenen sekundären Datenbank unabhängig von den anderen Datenbanken. Daher kann eine sekundäre Datenbank angehalten werden oder einen Fehler verursachen, ohne andere sekundäre Datenbanken zu beeinträchtigen, und eine primäre Datenbank kann angehalten werden oder einen Fehler verursachen, ohne andere primäre Datenbanken zu beeinträchtigen.

Optional können Sie mindestens ein sekundäres Replikat konfigurieren, um schreibgeschützten Zugriff auf sekundäre Datenbanken zu unterstützen, und ein beliebiges sekundäres Replikat konfigurieren, um Sicherungen auf sekundären Datenbanken zuzulassen.

Für die Bereitstellung von AlwaysOn-Verfügbarkeitsgruppen ist ein Windows Server-Failoverclustering (WSFC)-Cluster erforderlich. Jedes Verfügbarkeitsreplikat einer bestimmten Verfügbarkeitsgruppe muss sich auf einem anderen Knoten desselben WSFC-Clusters befinden. Die einzige Ausnahme besteht darin, dass sich eine Verfügbarkeitsgruppe während der Migration zu einem anderen WSFC-Cluster vorübergehend auf zwei Cluster erstrecken kann.

Für jede erstellte Verfügbarkeitsgruppe wird eine WSFC-Ressourcengruppe erstellt. Der WSFC-Cluster überwacht diese Ressourcengruppe, um den Status des primären Replikats auszuwerten. Das Quorum für Always On-Verfügbarkeitsgruppen basiert auf allen Knoten im WSFC-Cluster, unabhängig davon, ob ein bestimmter Clusterknoten Verfügbarkeitsreplikate hostet. Im Gegensatz zur Datenbankspiegelung gibt es in AlwaysOn-Verfügbarkeitsgruppen keine Zeugenrolle.

Hinweis

Informationen zur Beziehung von SQL Server AlwaysOn-Komponenten zum WSFC-Cluster finden Sie unter Windows Server Failover Clustering (WSFC) mit SQL Server.

In der folgenden Abbildung ist eine Verfügbarkeitsgruppe dargestellt, die ein primäres Replikat und vier sekundäre Replikate enthält. Bis zu acht sekundäre Replikate werden unterstützt, darunter ein primäres Replikat und zwei synchrone sekundäre Replikate.

Verfügbarkeitsgruppe mit fünf Replikaten

Verfügbarkeitsdatenbanken

Zum Hinzufügen einer Datenbank zu einer Verfügbarkeitsgruppe muss die Datenbank eine Onlinedatenbank mit Lese-/Schreibzugriff auf der Serverinstanz sein, die das primäre Replikat hostet. Wenn Sie eine Datenbank hinzufügen, wird sie als primäre Datenbank mit der Verfügbarkeitsgruppe verknüpft, wobei sie für Clients verfügbar bleibt. Es ist keine entsprechende sekundäre Datenbank vorhanden, bis Sicherungen der neuen primären Datenbank mithilfe von RESTORE WITH NORECOVERY auf der Serverinstanz wiederhergestellt werden, die das sekundäre Replikat hostet. Die neue sekundäre Datenbank befindet sich im Wiederherstellungszustand, bis sie in die Verfügbarkeitsgruppe aufgenommen wurde. Weitere Informationen finden Sie unter Starten Sie die Datenbewegung auf einer AlwaysOn-Sekundärdatenbank (SQL Server).

Durch das Hinzufügen wechselt die sekundäre Datenbank in den Status ONLINE und initiiert die Datensynchronisierung mit der entsprechenden primären Datenbank. DieDatensynchronisierung ist der Prozess, durch den Änderungen an einer primären Datenbank auf einer sekundären Datenbank reproduziert werden. Bei der Datensynchronisierung sendet die primäre Datenbank Transaktionsprotokoll-Datensätze an die sekundäre Datenbank.

Von Bedeutung

Eine Verfügbarkeitsdatenbank wird in Transact-SQL-, PowerShell- und SQL Server Management Objects-Namen (SMO) manchmal als Datenbankreplikat bezeichnet. Beispielsweise wird der Begriff "Datenbankreplikat" in den Namen der dynamischen AlwaysOn-Verwaltungsansichten verwendet, die Informationen zu Verfügbarkeitsdatenbanken zurückgeben: sys.dm_hadr_database_replica_states und sys.dm_hadr_database_replica_cluster_states. In der SQL Server-Onlinedokumentation bezieht sich der Begriff "Replikat" jedoch in der Regel auf Verfügbarkeitsreplikate. Zum Beispiel sind mit "primäres Replikat" und "sekundäres Replikat" stets Verfügbarkeitsreplikate gemeint.

Verfügbarkeitsreplikate

Jede Verfügbarkeitsgruppe definiert einen Satz von zwei oder mehr Failoverpartnern, bekannt als Verfügbarkeitsreplikate. Verfügbarkeitsreplikate sind Komponenten der Verfügbarkeitsgruppe. Jedes Verfügbarkeitsreplikat hostet eine Kopie der Verfügbarkeitsdatenbanken in der Verfügbarkeitsgruppe. Die Verfügbarkeitsreplikate der jeweiligen Verfügbarkeitsgruppe müssen von separaten SQL Server-Instanzen gehostet werden, die sich in unterschiedlichen Knoten eines WSFC-Clusters befinden. Jede dieser Serverinstanzen muss für AlwaysOn aktiviert sein.

Eine Instanz kann nur ein Verfügbarkeitsreplikat pro Verfügbarkeitsgruppe hosten. Allerdings kann jede Instanz für zahlreiche Verfügbarkeitsgruppen verwendet werden. Eine Instanz kann entweder eine eigenständige Instanz oder eine SQL Server-Failoverclusterinstanz (FCI) sein. Falls Sie Redundanz auf Serverebene benötigen, verwenden Sie Failoverclusterinstanzen.

Allen Verfügbarkeitsreplikaten wird eine Anfangsrolle zugewiesen: entweder die primäre Rolle oder die sekundäre Rolle, die von den Verfügbarkeitsdatenbanken dieses Replikats geerbt wird. Die Rolle eines bestimmten Replikats legt fest, ob Datenbanken mit Lese-/Schreibzugriff oder schreibgeschützte Datenbanken gehostet werden. Einem als primäres Replikatbezeichneten Replikat wird die primäre Rolle zugewiesen. Es hostet Datenbanken mit Lese-/Schreibzugriff, die als primäre Datenbankenbezeichnet werden. Mindestens einem anderen Replikat, das als sekundäres Replikatbezeichnet wird, wird die sekundäre Rolle zugewiesen. Ein sekundäres Replikat hostet schreibgeschützte Datenbanken, sogenannte sekundäre Datenbanken.

Hinweis

Wenn die Rolle eines Verfügbarkeitsreplikats unbestimmt ist, z. B. während eines Failovers, befinden sich seine Datenbanken vorübergehend im NOT SYNCHRONIZING-Status. Ihre Rolle wird auf RESOLVING festgelegt, bis die Rolle des Verfügbarkeitsreplikats aufgelöst wurde. Wird ein Verfügbarkeitsreplikat zur primären Rolle aufgelöst, werden seine Datenbanken zu primären Datenbanken. Wird ein Verfügbarkeitsreplikat zur sekundären Rolle aufgelöst, werden seine Datenbanken sekundäre Datenbanken.

Verfügbarkeitsmodi

Der Verfügbarkeitsmodus ist eine Eigenschaft jedes Verfügbarkeitsreplikats. Der Verfügbarkeitsmodus bestimmt, ob das primäre Replikat wartet, um Transaktionen in einer Datenbank zu übernehmen, bis ein bestimmtes sekundäres Replikat die Transaktionsprotokolldatensätze auf den Datenträger geschrieben hat (das Protokoll wurde gehärtet). Always On Availability Groups unterstützt zwei Verfügbarkeitsmodi– asynchronen Commit-Modus und synchronen Commit-Modus.

  • Asynchroner Commitmodus

    Ein Verfügbarkeitsreplikat, das diesen Verfügbarkeitsmodus verwendet, wird alsasynchrones Commit-Replikat bezeichnet. Im Modus für asynchrone Commits führt das primäre Replikat einen Commit für Transaktionen aus, ohne auf die Bestätigung zu warten, dass ein sekundäres Replikat mit asynchronem Commit das Protokoll geschrieben hat. Im Modus für asynchrone Commits wird die Transaktionswartezeit auf den sekundären Datenbanken minimiert. Dabei liegen sie jedoch möglicherweise hinter den primären Datenbanken zurück, was Datenverluste zur Folge haben kann.

  • Synchroner Commitmodus

    Ein Verfügbarkeitsreplikat, das diesen Verfügbarkeitsmodus verwendet, wird als Replikat mit synchronem Commitbezeichnet. Im Modus für synchrone Commits wartet ein primäres Replikat mit synchronen Commits vor dem Commit für Transaktionen auf ein sekundäres Replikat mit synchronen Commits, um zu bestätigen, dass das Schreiben des Protokolls abgeschlossen wurde. Im Modus für synchrone Commits wird sichergestellt, dass Transaktionen, für die ein Commit ausgeführt wird, vollständig geschützt sind, sobald eine angegebene sekundäre Datenbank mit der primären Datenbank synchronisiert wird. Dieser Schutz führt jedoch zu einer erhöhten Transaktionswartezeit.

Weitere Informationen finden Sie unter Verfügbarkeitsmodi (AlwaysOn-Verfügbarkeitsgruppen).

Typen von Failover

Im Kontext einer Sitzung zwischen dem primären Replikat und einem sekundären Replikat sind die primären und sekundären Rollen in einem als Failoverbezeichneten Prozess potenziell austauschbar. Während eines Failovers wechselt das sekundäre Zielreplikat zur primären Rolle und wird zum neuen primären Replikat. Das neue primäre Replikat schaltet seine Datenbanken als primäre Datenbanken online. Clientanwendungen können eine Verbindung mit ihnen herstellen. Wenn das zuvor primäre Replikat verfügbar ist, geht es in die sekundäre Rolle über und wird dadurch zu einem sekundären Replikat. Die zuvor primären Datenbanken werden sekundäre Datenbanken, und die Datensynchronisierung wird fortgesetzt.

Man unterscheidet drei Failovertypen: automatisches Failover, manuelles Failover und erzwungenes Failover (mit möglichem Datenverlust). Die von einem bestimmten sekundären Replikat unterstützten Failovertypen hängen von seinem Verfügbarkeitsmodus und beim Modus für synchrone Commits vom Failovermodus für das primäre Replikat und das sekundäre Zielreplikat ab:

  • Der Synchron-Commit-Modus unterstützt zwei Formen des Failovers: geplantes manuelles Failover und automatisches Failover, vorausgesetzt, dass die sekundäre Replikation derzeit mit dem avt1 synchronisiert ist. Die Unterstützung für diese Formen des Failovers hängt von der Einstellung der Failovermoduseigenschaft der Failoverpartner ab. Ist der Failovermodus für das primäre oder sekundäre Replikat auf "manuell" festgelegt, wird nur ein manuelles Failover für dieses sekundäre Replikat unterstützt. Ist der Failovermodus für das primäre und sekundäre Replikat auf "automatisch" festgelegt, wird sowohl das automatische als auch das manuelle Failover auf diesem sekundären Replikat unterstützt.

    • Geplantes manuelles Failover (ohne Datenverlust)

      Ein manuelles Failover erfolgt nach der Ausgabe eines Failoverbefehls durch einen Datenbankadministrator. Es verursacht den Übergang eines synchronisierten sekundären Replikats in die primäre Rolle (mit garantiertem Datenschutz) und den Übergang des primären Replikats in die sekundäre Rolle. Ein manuelles Failover erfordert, dass sowohl das primäre Replikat als auch das sekundäre Zielreplikat im Modus für synchrone Commits ausgeführt wird, und dass das sekundäre Replikat bereits synchronisiert wurde.

    • Automatisches Failover (ohne Datenverlust)

      Ein automatisches Failover tritt als Reaktion auf einen Fehler auf, der den Übergang eines synchronisierten Replikats in eine primäre Rolle (mit garantiertem Datenschutz) verursacht. Wenn das frühere primäre Replikat verfügbar wird, geht es in die sekundäre Rolle über. Das automatische Failover erfordert, dass sowohl das primäre Replikat als auch das sekundäre Zielreplikat im synchronen Commit-Modus ausgeführt werden, wobei der Failovermodus auf "Automatisch" festgelegt ist. Darüber hinaus muss das sekundäre Replikat bereits synchronisiert werden, über das WSFC-Quorum verfügen und die bedingungen erfüllen, die durch die flexible Failoverrichtlinieder Verfügbarkeitsgruppe angegeben sind.

      Von Bedeutung

      SQL Server-Failoverclusterinstanzen (FCIs) unterstützen kein automatisches Failover durch Verfügbarkeitsgruppen. Daher können die Verfügbarkeitsreplikate, die von einer FCI gehostet werden, nur für manuelles Failover konfiguriert werden.

    Hinweis

    Wenn Sie einen erzwungenen Failoverbefehl für ein synchronisiertes sekundäres Replikat ausgeben, verhält sich das sekundäre Replikat genauso wie bei einem geplanten manuellen Failover.

  • Im Modus für asynchrone Commits ist die einzige Form des Failovers ein erzwungenes manuelles Failover (mit möglichem Datenverlust), das in der Regel als erzwungenes Failoverbezeichnet wird. Erzwungenes Failover wird als eine Art manuelles Failover angesehen, da es nur manuell initiiert werden kann. Erzwungenes Failover ist eine Option zur Notfallwiederherstellung. Es ist die einzige Form des Failovers, die möglich ist, wenn das sekundäre Zielreplikat nicht mit dem primären Replikat synchronisiert wird.

Weitere Informationen finden Sie unter Failover- und Failovermodi (AlwaysOn-Verfügbarkeitsgruppen).

Clientverbindungen

Sie können Clientkonnektivität für das primäre Replikat einer angegebenen Verfügbarkeitsgruppe bereitstellen, indem Sie einen Verfügbarkeitsgruppenlistener erstellen. Ein Verfügbarkeitsgruppenlistener stellt einen Satz von Ressourcen bereit, der an eine bestimmte Verfügbarkeitsgruppe angefügt wird, um Clientverbindungen an das entsprechende Verfügbarkeitsreplikat umzuleiten.

Ein Verfügbarkeitsgruppenlistener ist einem eindeutigen DNS-Namen, der als virtueller Netzwerkname (VNN) dient, mindestens einer virtuellen IP-Adresse (VIPs) und einer TCP-Portnummer zugeordnet. Weitere Informationen finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server).

Tipp

Wenn eine Verfügbarkeitsgruppe nur über zwei Verfügbarkeitsreplikate verfügt und nicht für den Lesezugriff auf das sekundäre Replikat konfiguriert ist, können Clients mithilfe einer Verbindungszeichenfolge für die Datenbankspiegelung eine Verbindung mit dem primären Replikat herstellen. Dieser Ansatz kann vorübergehend hilfreich sein, nachdem Sie eine Datenbank von der Datenbankspiegelung zu AlwaysOn-Verfügbarkeitsgruppen migriert haben. Bevor Sie zusätzliche sekundäre Replikate hinzufügen, müssen Sie einen Verfügbarkeitsgruppenlistener für die Verfügbarkeitsgruppe erstellen und Ihre Anwendungen so aktualisieren, dass der Netzwerkname des Listeners verwendet wird.

Aktive sekundäre Replikate

AlwaysOn-Verfügbarkeitsgruppen unterstützen aktive sekundäre Replikate. Die Funktionen für aktive sekundäre Replikate umfassen auch die Unterstützung für Folgendes:

  • Ausführen von Sicherungsvorgängen auf sekundären Replikaten

    Die sekundären Replikate unterstützen das Ausführen von Protokollsicherungen und Kopiesicherungen einer vollständigen Datenbank, Datei oder Dateigruppe. Sie können die Verfügbarkeitsgruppe konfigurieren, um eine Einstellung dafür anzugeben, wo Sicherungen ausgeführt werden sollen. Es ist wichtig zu verstehen, dass die Präferenz nicht von SQL Server erzwungen wird, sodass sie keine Auswirkungen auf Ad-hoc-Sicherungen hat. Die Interpretation dieser Einstellung hängt ggf. von der Logik ab, die Sie in Ihre Backaufträge für jede Datenbank in einer bestimmten Verfügbarkeitsgruppe eingeben. Für einzelne Verfügbarkeitsreplikate können Sie die Priorität für die Ausführung von Sicherungen auf diesem Replikat in Relation zu den anderen Replikaten in derselben Verfügbarkeitsgruppe angeben. Weitere Informationen finden Sie unter Active Secondaries: Backup on Secondary Replicas (AlwaysOn Availability Groups).

  • Schreibgeschützter Zugriff auf ein oder mehrere sekundäre Replikate (lesbare sekundäre Replikate)

    Jedes Verfügbarkeitsreplikat kann so konfiguriert werden, dass auf seine lokalen Datenbanken im schreibgeschützten Modus zugegriffen werden kann, wenn es die sekundäre Rolle ausführt, einige Vorgänge jedoch nicht vollständig unterstützt werden. Wenn Sie außerdem verhindern möchten, dass schreibgeschützte Arbeitslasten im primären Replikat ausgeführt werden, können Sie die Replikate so konfigurieren, dass nur Lese-/Schreibzugriff zulässig ist, wenn sie unter der primären Rolle ausgeführt werden. Weitere Informationen finden Sie unter Active Secondaries: Lesbare sekundäre Replikate (AlwaysOn-Verfügbarkeitsgruppen).For more information, see Active Secondaries: Readable Secondary Replicas (AlwaysOn Availability Groups).

    Wenn eine Verfügbarkeitsgruppe derzeit einen Verfügbarkeitsgruppenlistener und mindestens ein lesbares sekundäres Replikat besitzt, können Verbindungsanforderungen für beabsichtigte Lesevorgänge von SQL Server an eines dieser Replikate weitergeleitet werden (schreibgeschütztes Routing). Weitere Informationen finden Sie unter Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server).

Session-Timeout Zeitraum

Das Sitzungstimeout ist eine Eigenschaft von Verfügbarkeitsreplikaten, die bestimmt, wie lange eine Verbindung mit einem anderen Verfügbarkeitsreplikat inaktiv sein darf, bevor die Verbindung geschlossen wird. Die primären und sekundären Replikate pingen einander, um zu signalisieren, dass sie noch aktiv sind. Beim Empfangen eines Pings vom anderen Replikat während des Timeoutzeitraums wird angegeben, dass die Verbindung noch geöffnet ist und dass die Serverinstanzen kommunizieren. Beim Empfang eines Pings setzt ein Verfügbarkeitsreplikat seinen Sitzungstimeoutzähler für diese Verbindung zurück.

Das Sitzungstimeout verhindert, dass Replikate unbegrenzt auf ein Ping vom anderen Replikat warten. Wenn innerhalb des Zeitraums für das Sitzungstimeout kein Ping vom anderen Replikat empfangen wird, tritt für das Replikat ein Timeout ein. Die Verbindung wird geschlossen, und der Status des Replikats mit dem Timeout ändert sich in DISCONNECTED. Auch wenn ein getrenntes Replikat für den synchronen Commit-Modus konfiguriert ist, warten Transaktionen nicht, bis dieses Replikat erneut verbunden und erneut synchronisiert wird.

Das Standardsitzungstimeout für alle Verfügbarkeitsreplikate liegt bei 10 Sekunden. Dieser Wert kann vom Benutzer konfiguriert werden, muss aber mindestens 5 Sekunden betragen. Im Allgemeinen wird empfohlen, einen Timeoutzeitraum von 10 Sekunden oder mehr zu wählen. Wenn Sie diesen Wert auf weniger als 10 Sekunden festlegen, kann ein stark ausgelastetes System einen falschen Fehler melden.

Hinweis

In der Rolle der Auflösung gilt der Sitzungstimeoutzeitraum nicht, da kein Pingen stattfindet.

Automatische Seitenreparatur

Jedes Verfügbarkeitsreplikat versucht, durch das Auflösen bestimmter Fehlertypen, die das Lesen einer Datenseite verhindern, beschädigte Seiten auf einer lokalen Datenbank automatisch wiederherzustellen. Wenn ein sekundäres Replikat keine Seite lesen kann, fordert das Replikat eine neue Kopie der Seite aus dem primären Replikat an. Wenn das primäre Replika keine Seitenkopie lesen kann, sendet das Replika eine Anforderung für eine neue Kopie an alle sekundären Repliken und erhält die Seite von dem ersten Antwortenden. Ist diese Anforderung erfolgreich, wird die nicht lesbare Seite durch die Kopie ersetzt. Dadurch kann der Fehler normalerweise behoben werden.

Weitere Informationen finden Sie unter "Automatische Seitenreparatur" (Für Verfügbarkeitsgruppen und Datenbankspiegelung).

Verwandte Aufgaben

Verwandte Inhalte

Siehe auch

Verfügbarkeitsmodi (AlwaysOn-Verfügbarkeitsgruppen)Failover- und Failovermodi (AlwaysOn-Verfügbarkeitsgruppen)Übersicht über Transact-SQL Anweisungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server)Übersicht über PowerShell-Cmdlets für AlwaysOn-Verfügbarkeitsgruppen (SQL Server)Hochverfügbarkeitsunterstützung für In-Memory OLTP-DatenbankenVoraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server)Erstellung und Konfiguration von Verfügbarkeitsgruppen (SQL Server)Aktive Sekundäre: Lesbare sekundäre Replikate (AlwaysOn-Verfügbarkeitsgruppen)Aktive Sekundäre: Sicherung auf sekundären Replikaten (AlwaysOn-Verfügbarkeitsgruppen)Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server)

  • Last updated on