CREATE AVAILABILITY GROUP (Transact-SQL)

  • Artikel

Erstellt eine neue Verfügbarkeitsgruppe, wenn die Instanz von SQL Server für die AlwaysOn-Verfügbarkeitsgruppen-Funktion aktiviert wird.

Wichtiger HinweisWichtig

Führen Sie CREATE AVAILABILITY GROUP auf die Instanz von SQL Server aus, die als ursprüngliches primäres Replikat der neuen Verfügbarkeitsgruppe verwendet werden soll. Diese Serverinstanz muss sich in einem WSFC-Knoten (Windows Server Failover Clustering) befinden.

Themenlink (Symbol) Transact-SQL-Syntaxkonventionen

Syntax

CREATE AVAILABILITY GROUP group_name
   WITH (<with_option_spec> [ ,...n ] )
   FOR [ DATABASE database_name [ ,...n ] ]
   REPLICA ON <add_replica_spec> [ ,...n ]
   [ LISTENER ‘dns_name’ ( <listener_option> ) ]
[ ; ]

<with_option_spec>::= 
    AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECONDARY | NONE }
  | FAILURE_CONDITION_LEVEL  = { 1 | 2 | 3 | 4 | 5 } 
  | HEALTH_CHECK_TIMEOUT = milliseconds 

<add_replica_spec>::=
  <server_instance> WITH
    (
       ENDPOINT_URL = 'TCP://system-address:port',
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT },
       FAILOVER_MODE = { AUTOMATIC | MANUAL }
       [ , <add_replica_option> [ ,...n ] ]
    ) 

  <add_replica_option>::=
       BACKUP_PRIORITY = n
     | SECONDARY_ROLE ( { 
            [ ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL } ] 
        [,] [ READ_ONLY_ROUTING_URL = 'TCP://system-address:port' ]
     } )
     | PRIMARY_ROLE ( { 
            [ ALLOW_CONNECTIONS = { READ_WRITE | ALL } ] 
        [,] [ READ_ONLY_ROUTING_LIST = { ( ‘<server_instance>’ [ ,...n ] ) | NONE } ]
     } )
     | SESSION_TIMEOUT = integer 

<listener_option> ::=
   {
      WITH DHCP [ ON ( <network_subnet_option> ) ]
    | WITH IP ( { ( <ip_address_option> ) } [ , ...n ] ) [ , PORT = listener_port ]
   }

  <network_subnet_option> ::=
     ‘four_part_ipv4_address’, ‘four_part_ipv4_mask’  

  <ip_address_option> ::=
     { 
        ‘four_part_ipv4_address’, ‘four_part_ipv4_mask’
      | ‘ipv6_address’
     }

Argumente

  • group_name
    Gibt den Namen der neuen Verfügbarkeitsgruppe an. group_name muss ein gültiger SQL Server-Bezeichner und in allen Verfügbarkeitsgruppen im WSFC-Cluster eindeutig sein. Die maximale Länge eines Verfügbarkeitsgruppennamens beträgt 128 Zeichen.

  • AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECONDARY | NONE }
    Legt fest, wie ein Sicherungsauftrag das primäre Replikat auswerten soll, wenn ausgewählt wird, wo Sicherungen ausgeführt werden müssen. Sie können einen gegebenen Sicherungsauftrag erstellen, um die automatisierte Sicherungseinstellung zu berücksichtigen. Die Einstellung wird nicht von SQL Server erzwungen und weist deshalb keine Auswirkungen auf Ad-hoc-Sicherungen auf.

    Die folgenden Werte werden unterstützt:

    • PRIMARY
      Gibt an, dass die Sicherungen immer auf dem primären Replikat erfolgen müssen. Diese Option ist hilfreich, wenn Sie Sicherungsfunktionen benötigen, z. B. das Erstellen differenzieller Sicherungen, die nicht unterstützt werden, wenn die Sicherung auf einem sekundären Replikat ausgeführt wird.

      Wichtiger HinweisWichtig

      Wenn Sie den Protokollversand verwenden möchten, um sekundäre Datenbanken auf eine Verfügbarkeitsgruppe vorzubereiten, legen Sie die Voreinstellung für automatisierte Sicherungen auf Primär fest, bis alle sekundären Datenbanken vorbereitet und mit der Verfügbarkeitsgruppe verknüpft worden sind.

    • SECONDARY_ONLY
      Gibt an, dass Sicherungen nie auf dem primären Replikat ausgeführt werden dürfen. Wenn es sich beim primären Replikat um das einzige Onlinereplikat handelt, darf keine Sicherung erfolgen.

    • SECONDARY
      Gibt an, dass Sicherungen auf einem sekundären Replikat erfolgen müssen, außer wenn es sich beim primären Replikat um das einzige Onlinereplikat handelt. In diesem Fall muss die Sicherung auf dem primären Replikat erfolgen. Dies ist das Standardverhalten.

    • NONE
      Gibt an, dass Sicherungsaufträge die Rolle der Verfügbarkeitsreplikate ignorieren sollen, wenn sie das Replikat zum Durchführen der Sicherungen auswählen. Hinweis: Sicherungsaufträge können andere Faktoren auswerten, wie z. B. die Sicherungspriorität jedes Verfügbarkeitsreplikats in Verbindung mit seinem Betriebszustand und Verbindungsstatus.

    Wichtiger HinweisWichtig

    Die Einstellung AUTOMATED_BACKUP_PREFERENCE wird nicht erzwungen. Die Interpretation dieser Einstellung hängt von der Logik ab, die Sie ggf. per Skript in Sicherungsaufträge für die Datenbanken in einer angegebenen Verfügbarkeitsgruppe integriert haben. Die Voreinstellung für die automatisierte Sicherung hat keine Auswirkungen auf Ad-hoc-Sicherungen. Weitere Informationen finden Sie unter Konfigurieren der Sicherung auf Verfügbarkeitsreplikaten (SQL Server).
    HinweisHinweis

    Um die automatisierte Sicherungseinstellung einer vorhandenen Verfügbarkeitsgruppe anzuzeigen, wählen Sie die Spalte automated_backup_preference oder automated_backup_preference_desc der Katalogsicht sys.availability_groups aus. Darüber hinaus können Sie mit sys.fn_hadr_backup_is_preferred_replica (Transact-SQL) das bevorzugte Sicherungsreplikat ermitteln. Diese Funktion gibt immer 1 für mindestens eines der Replikate zurück, selbst wenn AUTOMATED_BACKUP_PREFERENCE = NONE.

  • FAILURE_CONDITION_LEVEL = { 1 | 2 | 3 | 4 | 5 }
    Gibt an, welche Fehlerbedingungen ein automatisches Failover für diese Verfügbarkeitsgruppe auslösen. FAILURE_CONDITION_LEVEL wird auf Gruppenebene festgelegt, ist aber nur auf Verfügbarkeitsreplikaten relevant, die für den Verfügbarkeitsmodus mit synchronen Commits (AVAILIBILITY_MODE = SYNCHRONOUS_COMMIT) konfiguriert sind. Weiterhin können Fehlerbedingungen ein automatisches Failover nur auslösen, wenn das primäre und das sekundäre Replikat für den automatischen Failovermodus konfiguriert sind (FAILOVER_MODE = AUTOMATIC) und das sekundäre Replikat gerade mit dem primären Replikat synchronisiert wird.

    Die Fehlerbedingungsebenen (1-5) reichen von der Ebene 1 mit den wenigsten Einschränkungen bis zur Ebene 5 mit den meisten Einschränkungen. Jede Bedingungsebene umfasst stets auch sämtliche weniger restriktiven Ebenen. Daher schließt die strengste Bedingungsebene 5 die vier Bedingungsebenen mit weniger Einschränkungen (1-4) ein, Ebene 4 schließt die Ebenen 1-3 ein usw. In der folgenden Tabelle wird die Fehlerbedingung beschrieben, die der jeweiligen Ebene entspricht.

    Ebene

    Fehlerbedingung

    1

    Gibt an, dass in einem der folgenden Fälle ein automatisches Failover initiiert werden muss:

    • Der SQL Server-Dienst ist ausgefallen.

    • Das Leasing der Verfügbarkeitsgruppe für die Verbindung mit dem WSFC-Cluster läuft ab, da keine ACK-Meldung von der Serverinstanz empfangen wird. Weitere Informationen finden Sie unter Funktionsweise: AlwaysOn-Leasetimeout bei SQL Server.

    2

    Gibt an, dass in einem der folgenden Fälle ein automatisches Failover initiiert werden muss:

    • Die Instanz von SQL Server stellt keine Verbindung mit dem Cluster her, und der vom Benutzer angegebene HEALTH_CHECK_TIMEOUT-Schwellenwert der Verfügbarkeitsgruppe wurde überschritten.

    • Das Verfügbarkeitsreplikat weist einen fehlerhaften Status auf.

    3

    Gibt an, dass ein automatisches Failover bei kritischen internen SQL Server-Fehlern initiiert werden soll, z. B. verwaisten Spinlocks, schwerwiegenden Schreibzugriffsverletzungen oder zu vielen Sicherungen.

    Dies ist das Standardverhalten.

    4

    Gibt an, dass ein automatisches Failover bei mittelschweren internen SQL Server-Fehlern initiiert werden soll, z. B. bei dauerhaft unzureichendem Arbeitsspeicher im internen SQL Server-Ressourcenpool.

    5

    Gibt an, dass ein automatisches Failover bei sämtlichen qualifizierten Fehlerbedingungen initiiert werden soll, einschließlich:

    • Erschöpfung der SQL Engine-Arbeitsthreads.

    • Erkennung eines unlösbaren Deadlocks.
    HinweisHinweis

    Das Fehlen einer Reaktion auf Clientanforderungen durch eine SQL Server-Instanz ist für Verfügbarkeitsgruppen nicht relevant.

    Der FAILURE_CONDITION_LEVEL- und der HEALTH_CHECK_TIMEOUT-Wert definieren eine flexible Failoverrichtlinie für eine angegebene Gruppe. Diese flexible Failoverrichtlinie bietet eine präzise Kontrolle der Bedingungen, die ein automatisches Failover verursachen müssen. Weitere Informationen finden Sie unter Flexible Failoverrichtlinie für automatisches Failover einer Verfügbarkeitsgruppe (SQL Server).

  • HEALTH_CHECK_TIMEOUT = milliseconds
    Gibt die Wartezeit (in Millisekunden) für die gespeicherte sp_server_diagnostics-Systemprozedur an, um Informationen über den Serverzustand zurückzugeben, ehe das WSFC-Cluster annimmt, dass die Serverinstanz langsam oder blockiert ist. HEALTH_CHECK_TIMEOUT wird auf Gruppenebene festgelegt, ist aber nur für Verfügbarkeitsreplikate relevant, die für den Verfügbarkeitsmodus für synchrone Commits mit automatischem Failover (AVAILIBILITY_MODE = SYNCHRONOUS_COMMIT) konfiguriert sind. Weiterhin kann ein Integritätsprüfungstimeout nur ein automatisches Failover auslösen, wenn das primäre und das sekundäre Replikat für den automatischen Failovermodus konfiguriert sind (FAILOVER_MODE = AUTOMATIC) und das sekundäre Replikat gerade mit dem primären Replikat synchronisiert wird.

    Der standardmäßige HEALTH_CHECK_TIMEOUT-Wert beträgt 30.000 Millisekunden (30 Sekunden). Der minimale Wert beträgt 15.000 Millisekunden (15 Sekunden) und der maximale Wert 4.294.967.295 Millisekunden.

    Wichtiger HinweisWichtig

    sp_server_diagnostics führt keine Integritätsprüfungen auf Datenbankebene aus.

  • DATABASE database_name
    Gibt eine Liste mit mindestens einer Benutzerdatenbank auf der lokalen SQL Server-Instanz an (der Serverinstanz, auf der Sie die Verfügbarkeitsgruppe erstellen). Sie können mehrere Datenbanken für eine Verfügbarkeitsgruppe angeben, aber jede Datenbank kann nur zu einer Verfügbarkeitsgruppe gehören. Informationen zu den von einer Verfügbarkeitsgruppe unterstützten Datenbanktypen finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server). In der replica_id-Spalte in der sys.databases-Katalogsicht können Sie herausfinden, welche lokalen Datenbanken bereits zu einer Verfügbarkeitsgruppe gehören.

    Die DATABASE-Klausel ist optional. Wenn sie weglassen wird, ist die neue Verfügbarkeitsgruppe leer.

    Nachdem Sie eine Verfügbarkeitsgruppe erstellt haben, müssen Sie wiederum eine Verbindung zu jeder Serverinstanz herstellen, die ein sekundäres Replikat hostet, und anschließend jede sekundäre Datenbank vorbereiten und mit der Verfügbarkeitsgruppe verknüpfen. Weitere Informationen finden Sie unter Starten der Datenverschiebung auf einer sekundären AlwaysOn-Datenbank (SQL Server).

    HinweisHinweis

    Später können Sie berechtigte Datenbanken auf der Serverinstanz hinzufügen, die das primäre Replikat für eine Verfügbarkeitsgruppe hostet. Sie können zudem eine Datenbank aus einer Verfügbarkeitsgruppe entfernen. Weitere Informationen finden Sie unter ALTER AVAILABILITY GROUP (Transact-SQL).

  • REPLICA ON
    Gibt eine bis fünf SQL Server-Instanzen als Hostverfügbarkeitsreplikate in der neuen Verfügbarkeitsgruppe an. Jedes Replikat wird von seiner Serverinstanzadresse gefolgt von einer WITH (…)-Klausel angegeben. Sie müssen mindestens die lokale Serverinstanz angeben, die das ursprüngliche primäre Replikat wird. Optional können Sie auch bis zu vier sekundäre Replikate angeben.

    Sie müssen jedes sekundäre Replikat mit der Verfügbarkeitsgruppe verknüpfen. Weitere Informationen finden Sie unter ALTER AVAILABILITY GROUP (Transact-SQL).

    HinweisHinweis

    Wenn Sie weniger als vier sekundäre Replikate beim Erstellen einer Verfügbarkeitsgruppe angeben, können Sie jederzeit mit der Transact-SQL-Anweisung ALTER AVAILABILITY GROUP ein zusätzliches sekundäres Replikat hinzufügen. Außerdem können Sie mit dieser Anweisung alle sekundären Replikate aus einer vorhandenen Verfügbarkeitsgruppe entfernen.

  • <server_instance>
    Gibt die Adresse der Instanz von SQL Server an, die als Host für ein Replikat fungiert. Das Adressformat hängt davon ab, ob die Instanz die Standardinstanz oder eine benannte Instanz ist und ob es eine eigenständige Instanz oder eine Failoverclusterinstanz (FCI) ist, wie dies im Folgenden beschrieben ist:

    { 'system_name[\instance_name]' | 'FCI_network_name[\instance_name]' }

    Diese Adresse weist die folgenden Komponenten auf:

    • system_name
      Der NetBIOS-Name des Computersystems, auf dem sich eine SQL Server-Zielinstanz befindet. Dieser Computer muss ein WSFC-Knoten sein.

    • FCI_network_name
      Ist der Netzwerkname, der verwendet wird, um auf einen SQL Server-Failovercluster zuzugreifen. Verwenden Sie diesen Namen, wenn die Serverinstanz als SQL Server-Failoverpartner beteiligt ist. Wenn SELECT @@SERVERNAME in einer FCI-Serverinstanz ausgeführt wird, wird die gesamte 'FCI_network_name[\instance_name]'-Zeichenfolge zurückgegeben (dabei handelt es sich um den vollständigen Replikatnamen).

    • instance_name
      Ist der Name einer SQL Server-Instanz, die von system_name oder FCI_network_name gehostet wird und für die der HADR-Dienst aktiviert ist. Bei einer Standardserverinstanz ist instance_name optional. Bei dem Instanznamen wird die Groß-/Kleinschreibung berücksichtigt. In einer eigenständigen Serverinstanz stimmt der Name dieses Werts mit dem Wert überein, der beim Ausführen von SELECT @@SERVERNAME zurückgegeben wird.

    • \
      Ist ein Trennzeichen, das nur bei der Angabe von instance_name verwendet wird, um den Namen von system_name oder FCI_network_name zu trennen.

    Informationen zu den erforderlichen Komponenten für WSFC-Knoten und Serverinstanzen finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

  • ENDPOINT_URL = 'TCP://system-address:port'
    Gibt den URL-Pfad des Datenbankspiegelungs-Endpunkts in der SQL Server-Instanz an, die das in der aktuellen REPLICA ON-Klausel definierte Verfügbarkeitsreplikat hostet.

    Die ENDPOINT_URL-Klausel ist erforderlich. Weitere Informationen finden Sie unter Angeben der Endpunkt-URL beim Hinzufügen oder Ändern eines Verfügbarkeitsreplikats (SQL Server).

  • 'TCP://system-address:port'
    Gibt eine URL zum Bestimmen einer Endpunkt-URL oder einer URL für das schreibgeschützte Routing an. Die URL-Parameter lauten wie folgt:

    • system-address
      Ist eine Zeichenfolge, beispielsweise ein Systemname, ein vollqualifizierter Domänenname oder eine IP-Adresse, ie das Zielcomputersystem eindeutig identifiziert.

    • port
      Ist eine Portnummer, die dem Spiegelungsendpunkt der Partnerserverinstanz (für die ENDPOINT_URL-Option) oder der Portnummer, die von Database Engine (Datenbankmodul) der Serverinstanz (für die READ_ONLY_ROUTING_URL-Option) verwendet wird, zugeordnet ist.

  • AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }
    Gibt an, ob das primäre Replikat auf das sekundäre Replikat warten muss, um das Verstärken (Schreiben) der Protokolldatensätze auf einem Datenträger zu bestätigen, bevor das primäre Replikat die Transaktion auf einer bestimmten primären Datenbank ausführen kann. Die Transaktionen auf anderen Datenbanken über dasselbe primäre Replikat können unabhängig einen Commit ausführen.

    • SYNCHRONOUS_COMMIT
      Gibt an, dass das primäre Replikat mit der Ausführung von Transaktionen wartet, bis sie auf diesem sekundären Replikat (Modus mit synchronem Commit) verstärkt wurden. Sie können SYNCHRONOUS_COMMIT für bis zu drei Replikate angeben, einschließlich des primären Replikats.

    • ASYNCHRONOUS_COMMIT
      Gibt an, dass das primäre Replikat einen Commit für Transaktionen ausführt, ohne zu warten, bis dieses sekundäre Replikat das Protokoll verstärkt (Verfügbarkeitsmodus mit synchronem Commit). Sie können ASYNCHRONOUS_COMMIT für bis zu fünf Verfügbarkeitsreplikate angeben, einschließlich des primären Replikats.

    Die AVAILABILITY_MODE-Klausel ist erforderlich. Weitere Informationen finden Sie unter Verfügbarkeitsmodi (AlwaysOn-Verfügbarkeitsgruppen).

  • FAILOVER_MODE = { AUTOMATIC | MANUAL }
    Gibt den Failovermodus des Verfügbarkeitsreplikats an, das Sie definieren.

    • AUTOMATIC
      Aktiviert das automatische Failover. Diese Option wird nur unterstützt, wenn Sie auch AVAILABILITY_MODE = SYNCHRONOUS_COMMIT angeben. Sie können AUTOMATIC für zwei Verfügbarkeitsreplikate angeben, einschließlich des primären Replikats.

      HinweisHinweis

      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.

    • MANUAL
      Ermöglicht ein geplantes manuelles Failover oder ein erzwungenes manuelles Failover (üblicherweise als erzwungenes Failover bezeichnet) durch den Datenbankadministrator.

    Die FAILOVER_MODE-Klausel ist erforderlich. Die beiden Typen des manuellen Failovers, manuelles Failover ohne Datenverlust und erzwungenes Failover (mit möglichem Datenverlust), werden unter unterschiedlichen Bedingungen unterstützt. Weitere Informationen finden Sie unter Failover und Failovermodi (AlwaysOn-Verfügbarkeitsgruppen).

  • BACKUP_PRIORITY **=**n
    Gibt die Priorität für die Ausführung von Sicherungen auf diesem Replikat in Relation zu den anderen Replikaten in derselben Verfügbarkeitsgruppe an. Der Wert ist im Bereich von "0..100" und eine ganze Zahl. Diese Werte haben die folgenden Bedeutungen:

    • 1..100 gibt an, dass das Verfügbarkeitsreplikat zum Ausführen von Sicherungen ausgewählt werden könnte. 1 gibt die niedrigste Priorität und 100 die höchste Priorität an. Wenn BACKUP_PRIORITY = 1, würde das Verfügbarkeitsreplikat nur zum Ausführungen von Sicherungen ausgewählt werden, wenn gerade keine höheren Prioritätsverfügbarkeitsreplikate verfügbar sind.

    • 0 gibt an, dass dieses Verfügbarkeitsreplikat nie zum Ausführen von Sicherungen ausgewählt wird. Dies ist zum Beispiel für ein Remoteverfügbarkeitsreplikat hilfreich, für das keine Failover bei Sicherungen auftreten sollen.

    Weitere Informationen finden Sie unter Aktive sekundäre Replikate: Sicherung auf sekundären Replikaten (AlwaysOn-Verfügbarkeitsgruppen).

  • SECONDARY_ROLE ( … )
    Gibt rollenspezifische Einstellungen an, die wirksam werden, wenn dieses Verfügbarkeitsreplikat die sekundäre Rolle (d. h. wenn es gerade ein sekundäres Replikat ist) gerade besitzt. Geben Sie innerhalb der Klammern eine oder beide sekundäre Rollenoptionen an. Wenn Sie beide angeben, verwenden Sie eine durch Trennzeichen getrennte Liste.

    Folgende Optionen stehen für die sekundäre Rolle zur Verfügung:

    • ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL }
      Gibt an, ob die Datenbanken eines bestimmten Verfügbarkeitsreplikats, das die sekundäre Rolle einnimmt (das heißt, als sekundäres Replikat dient), Verbindungen von Clients akzeptieren können, z. B.:

      • NO
        Es werden keine Verbindungen mit sekundären Datenbanken dieses Replikats zugelassen. Sie sind nicht für Lesezugriff verfügbar. Dies ist das Standardverhalten.

      • READ_ONLY
        Verbindungen mit den Datenbanken im sekundären Replikat sind nur zulässig, wenn die Anwendungsabsicht-Eigenschaft auf ReadOnly festgelegt ist. Weitere Informationen zu dieser Eigenschaft finden Sie unter Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit SQL Server Native Client.

      • ALL
        Für alle Verbindungen mit den Datenbanken im sekundären Replikat ist der schreibgeschützte Zugriff zugelassen.

      Weitere Informationen finden Sie unter Aktive sekundäre Replikate: Lesbare sekundäre Replikate (AlwaysOn-Verfügbarkeitsgruppen).

    • READ_ONLY_ROUTING_URL = 'TCP://system-address:port'
      Gibt die URL an, die zum Weiterleiten von Verbindungsanforderungen für beabsichtigte Lesevorgänge zu diesem Verfügbarkeitsreplikat verwendet werden soll. Dies ist die URL, die das SQL Server-Datenbankmodul überwacht. In der Regel überwacht die Standardinstanz des SQL Server-Datenbankmoduls auf TCP-Port 1433.

      Für eine benannte Instanz können Sie die Portnummer durch das Abfragen der port- und der type_desc-Spalten der dynamischen sys.dm_tcp_listener_states-Verwaltungssicht abrufen. Die Serverinstanz verwendet den Transact-SQL-Listener (type_desc = 'TSQL').

      Weitere Informationen zum Berechnen der schreibgeschützten Routing-URL für ein Verfügbarkeitsreplikat finden Sie unter Berechnen von read_only_routing_url für AlwaysOn.

      HinweisHinweis

      Für eine benannte Instanz von SQL Server sollte der Transact-SQL-Listener konfiguriert werden, um einen bestimmten Port zu verwenden. Weitere Informationen finden Sie unter Konfigurieren eines Servers zum Lauschen an einem bestimmten TCP-Port (SQL Server-Konfigurations-Manager).

  • PRIMARY_ROLE ( … )
    Gibt rollenspezifische Einstellungen an, die wirksam werden, wenn dieses Verfügbarkeitsreplikat die primäre Rolle (d. h. wenn es gerade ein primäres Replikat ist) gerade besitzt. Geben Sie innerhalb der Klammern eine oder beide primäre Rollenoptionen an. Wenn Sie beide angeben, verwenden Sie eine durch Trennzeichen getrennte Liste.

    Folgende Optionen stehen für die primäre Rolle zur Verfügung:

    • ALLOW_CONNECTIONS = { READ_WRITE | ALL }
      Gibt den Verbindungstyp an, den die Datenbanken eines bestimmten Verfügbarkeitsreplikats, das die primäre Rolle einnimmt (das heißt, als primäres Replikat dient), von Clients akzeptieren können, z. B.:

      • READ_WRITE
        Verbindungen, bei denen die Verbindungseigenschaft für die Anwendungsabsicht auf ReadOnly festgelegt ist, werden nicht zugelassen. Wenn die Eigenschaft für die Anwendungsabsicht auf ReadWrite festgelegt ist oder keine Verbindungseigenschaft für die Anwendungsabsicht festgelegt wurde, wird die Verbindung zugelassen. Weitere Informationen zur Verbindungseigenschaft für die Anwendungsabsicht finden Sie unter Verwenden von Schlüsselwörtern für Verbindungszeichenfolgen mit SQL Server Native Client.

      • ALL
        Für die Datenbanken im primären Replikat sind alle Verbindungen zugelassen. Dies ist das Standardverhalten.

    • READ_ONLY_ROUTING_LIST = { (‘<server_instance>’ [ ,...n ] ) | NONE }
      Gibt beim Ausführen unter der sekundären Rolle eine durch Trennzeichen getrennte Liste von Serverinstanzen an, die Verfügbarkeitsreplikate für diese Verfügbarkeitsgruppe hosten, die die folgenden Anforderungen erfüllt:

      • Wird konfiguriert, um alle Verbindungen oder schreibgeschützte Verbindungen (siehe das obige ALLOW_CONNECTIONS-Argument der SECONDARY_ROLE-Option) zuzulassen.

      • Die schreibgeschützte Routing-URL wurde definiert (siehe das obige READ_ONLY_ROUTING_URL-Argument der SECONDARY_ROLE-Option).

      Die READ_ONLY_ROUTING_LIST-Werte lauten wie folgt:

      • <server_instance>
        Gibt die Adresse der Instanz von SQL Server an, die als Host für ein Verfügbarkeitsreplikat fungiert, das ein lesbares sekundäres Replikat ist, wenn es unter der sekundären Rolle ausgeführt wird.

        Verwenden Sie eine durch Trennzeichen getrennte Liste, um alle Serverinstanzen anzugeben, die ein lesbares sekundäres Replikat hosten könnten. Schreibgeschütztes Routing erfolgt in der Reihenfolge, in der Serverinstanzen in der Liste angegeben werden. Wenn Sie die Hostserverinstanz eines Replikats auf der schreibgeschützten Routingliste des Replikats einschließen, ist es eine empfohlene Vorgehensweise, diese Serverinstanz am Ende der Liste zu platzieren, damit Verbindungen für beabsichtigte Lesevorgänge bei Verfügbarkeit zu einem sekundären Replikat wechseln.

      • NONE
        Gibt an, dass, wenn dieses Verfügbarkeitsreplikat das primäre Replikat ist, schreibgeschütztes Routing nicht unterstützt wird. Dies ist das Standardverhalten.

  • SESSION_TIMEOUT = integer
    Gibt den Zeitraum für das Sitzungstimeout in Sekunden an. Wenn Sie die Option nicht angeben, beträgt der Timeoutzeitraum standardmäßig 10 Sekunden. Der Wert muss mindestens 5 Sekunden betragen.

    Wichtiger HinweisWichtig

    Es wird empfohlen, einen Timeoutzeitraum von 10 Sekunden oder mehr zu wählen.

    Weitere Informationen zum Sitzungstimeout finden Sie unter Übersicht über AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

  • LISTENER ‘dns_name’ ( <listener_option> )
    Definiert einen neuen Verfügbarkeitsgruppenlistener für diese Verfügbarkeitsgruppe. LISTENER ist ein optionales Argument.

    Wichtiger HinweisWichtig

    Vor dem Erstellen des ersten Listeners empfehlen wir dringend, dass Sie Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server) lesen.

    Nachdem Sie einen Listener für eine Verfügbarkeitsgruppe erstellt haben, empfehlen wir dringend, folgende Schritte auszuführen:

    • Bitten Sie den Netzwerkadministrator, die IP-Adresse des Listeners zur exklusiven Verwendung zu reservieren.

    • Geben Sie den DNS-Hostnamen des Listeners an Anwendungsentwickler weiter, damit diese ihn in Verbindungszeichenfolgen verwenden, wenn sie Clientverbindungen zu dieser Verfügbarkeitsgruppe anfordern.

  • dns_name
    Gibt den DNS-Hostnamen des Verfügbarkeitsgruppenlisteners an. Der DNS-Name des Listeners muss in der Domäne und NetBIOS eindeutig sein.

    Bei dns_name handelt es sich um einen Zeichenfolgenwert. Dieser Name darf nur alphanumerische Zeichen, Bindestriche (-) und Unterstriche (_) enthalten (in beliebiger Reihenfolge). Bei DNS-Hostnamen muss die Groß-/Kleinschreibung beachtet werden. Die maximale Länge beträgt 63 Zeichen.

    Wir empfehlen, dass Sie eine sinnvolle Zeichenfolge angeben. Für eine Verfügbarkeitsgruppe mit dem Namen AG1 wäre ein sinnvoller DNS-Hostname z. B. ag1-listener.

    Wichtiger HinweisWichtig

    NetBIOS erkennt nur die ersten 15 Zeichen im dns_name. Wenn Sie zwei WSFC-Cluster verwenden, die vom gleichen Active Directory gesteuert werden, und Sie versuchen, Verfügbarkeitsgruppenlistener in beiden Clustern mit Namen mit mehr als 15 Zeichen und einem identischen 15-Zeichen-Präfix zu erstellen, erhalten Sie eine Fehlermeldung mit dem Hinweis, dass die VNN-Ressource nicht online geschaltet werden konnte. Informationen zu Präfix-Benennungsregeln für DNS-Namen finden Sie unter Zuweisen von Domänennamen.

  • <listener_option>
    LISTENER verwendet eine der folgenden <listener_option>-Optionen:

    • WITH DHCP [ ON { (‘four_part_ipv4_address’,‘four_part_ipv4_mask’) } ]
      Gibt an, dass der Verfügbarkeitsgruppenlistener das Dynamic Host Configuration-Protokoll (DHCP) verwendet. Verwenden Sie die ON-Klausel optional, um das Netzwerk zu identifizieren, auf dem dieser Listener erstellt wird. DHCP ist auf ein einzelnes Subnetz beschränkt, das für alle Serverinstanzen verwendet wird, die ein Verfügbarkeitsreplikat in der Verfügbarkeitsgruppe hosten.

      Wichtiger HinweisWichtig

      DHCP wird in einer Produktionsumgebung nicht empfohlen. Wenn es zu einer Ausfallzeit kommt und das DHCP-IP-Leasing abläuft, ist eine Verlängerung erforderlich, um die neue DHCP-Netzwerk-IP-Adresse zu registrieren, die dem DNS-Namen des Listener zugeordnet ist, was sich auf die Clientkonnektivität auswirkt. DHCP ist eignet sich jedoch gut zum Einrichten der Entwicklungs- und Testumgebung, um grundlegende Funktionen von Verfügbarkeitsgruppen und die Integration mit Ihren Anwendungen zu überprüfen.

      Beispiel:

      WITH DHCP ON ('10.120.19.0','255.255.254.0')

    • WITH IP ( { (‘four_part_ipv4_address’,‘four_part_ipv4_mask’) | (‘ipv6_address’) } [ , ...n ] ) [ , PORT **=**listener_port ]
      Gibt an, dass, der Listener der Verfügbarkeitsgruppe statt DHCPr eine oder mehrere statische IP-Adressen verwendet. Um eine Verfügbarkeitsgruppe über mehrere Subnetze zu erstellen, erfordert jedes Subnetz in der Listenerkonfiguration eine statische IP-Adresse. Für ein angegebenes Subnetz kann die statische IP-Adresse entweder eine IPv4-Adresse oder eine IPv6-Adresse sein. Wenden Sie sich an Ihren Netzwerkadministrator, um eine statische IP-Adresse für jedes Subnetz zu erhalten, das ein Verfügbarkeitsreplikat für die neue Verfügbarkeitsgruppe hostet.

      Beispiel:

      WITH IP ( ('10.120.19.155','255.255.254.0') )

  • four_part_ipv4_address
    Gibt eine vierteilige IPv4-Adresse für einen Verfügbarkeitsgruppenlistener an. Beispiel: 10.120.19.155.

  • four_part_ipv4_mask
    Gibt eine vierteilige IPv4-Maske für einen Verfügbarkeitsgruppenlistener an. Beispiel: 255.255.254.0.

  • ipv6_address
    Gibt eine IPv6-Adresse für einen Verfügbarkeitsgruppenlistener an. Beispiel: 2001::4898:23:1002:20f:1fff:feff:b3a3.

  • PORT = listener_port
    Gibt die Portnummer – listener_port – an, die von einem Verfügbarkeitsgruppenlistener verwendet wird, der anhand einer WITH IP-Klausel angegeben wird. PORT ist optional.

    Die Standardportnummer 1433 wird unterstützt. Wenn Sie jedoch Sicherheitsbedenken hegen, empfehlen wir die Verwendung einer anderen Portnummer.

    Beispiel: WITH IP ( ('2001::4898:23:1002:20f:1fff:feff:b3a3') ) , PORT = 7777.

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird[Nach oben]

Voraussetzungen und Einschränkungen

Informationen zu den erforderlichen Komponenten zum Erstellen einer Verfügbarkeitsgruppe finden Sie unter Voraussetzungen, Einschränkungen und Empfehlungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

Informationen zu Einschränkungen in Bezug auf die AVAILABILITY GROUP-Transact-SQL-Anweisungen finden Sie unter Übersicht über Transact-SQL-Anweisungen für AlwaysOn-Verfügbarkeitsgruppen (SQL Server).

Sicherheit

Berechtigungen

Erfordert die Mitgliedschaft in der festen sysadmin-Serverrolle und die CREATE AVAILABILITY GROUP-Serverberechtigung, ALTER ANY AVAILABILITY GROUP-Berechtigung oder CONTROL SERVER-Berechtigung.

Beispiele

A.Konfigurieren der Sicherung für sekundäre Replikate, flexible Failoverrichtlinien und Verbindungszugriff

Im folgenden Beispiel wird eine Verfügbarkeitsgruppe mit dem Namen MyAg für die zwei Benutzerdatenbanken ThisDatabase und ThatDatabase erstellt. In der folgenden Tabelle werden die Werte zusammengefasst, die für die Optionen angegeben wurden, die für die Verfügbarkeitsgruppe als Ganzes festgelegt sind.

Gruppenoption

Einstellung

Beschreibung

AUTOMATED_BACKUP_PREFERENCE

SECONDARY

Diese automatisierte Sicherungseinstellung gibt an, dass Sicherungen auf einem sekundären Replikat erfolgen sollen, außer wenn das primäre Replikat das einzige Replikat online ist (dies ist das Standardverhalten). Damit die AUTOMATED_BACKUP_PREFERENCE-Einstellung in Kraft tritt, müssen Sicherungsaufträge in Verfügbarkeitsdatenbanken so verfasst werden, dass die automatische Sicherungseinstellung berücksichtigt wird.

FAILURE_CONDITION_LEVEL

3

Diese Einstellung für die Fehlerbedingungsebene gibt an, dass ein automatisches Failover bei kritischen internen SQL Server-Fehlern initiiert werden soll, z. B. verwaisten Spinlocks, ernsten Schreibzugriffsverletzungen oder zu vielen Sicherungen.

HEALTH_CHECK_TIMEOUT

600000

Ein Timeoutwert für die Integritätsprüfung von 60 Sekunden besagt, dass der WSFC-Cluster 60.000 Millisekunden wartet, bis die gespeicherte Systemprozedur sp_server_diagnostics Serverzustand-Informationen über eine Serverinstanz zurückgibt, die ein Replikat mit synchronem Commit automatisch hostet, bevor der Cluster annimmt, dass die Hostserverinstanz langsam oder blockiert ist. (Der Standardwert beträgt 30.000 Millisekunden.)

Drei Verfügbarkeitsreplikate müssen von den Standardserverinstanzen auf Computern mit der Bezeichnung COMPUTER01, COMPUTER02 und COMPUTER03 gehostet werden. In der folgenden Tabelle werden die für die Replikatoptionen jedes Replikats angegebenen Werte zusammengefasst.

Replikatoption

Einstellung auf COMPUTER01

Einstellung auf COMPUTER02

Einstellung auf COMPUTER03

Beschreibung

ENDPOINT_URL

TCP://COMPUTER01:5022

TCP://COMPUTER02:5022

TCP://COMPUTER03:5022

In diesem Beispiel weisen die Systeme dieselbe Domäne auf. Daher können die Endpunkt-URLs den Namen des Computersystems als Systemadresse verwenden.

AVAILABILITY_MODE

SYNCHRONOUS_COMMIT

SYNCHRONOUS_COMMIT

ASYNCHRONOUS_COMMIT

Zwei der Replikate verwenden den Modus mit synchronem Commit. Nach der Synchronisierung unterstützen sie Failover ohne Datenverlust. Das dritte Replikat verwendet den Verfügbarkeitsmodus mit asynchronem Commit.

FAILOVER_MODE

AUTOMATIC

AUTOMATIC

MANUAL

Die Replikate mit synchronem Commit unterstützen automatisches Failover und geplantes manuelles Failover. Das Verfügbarkeitsmodusreplikat mit synchronem Commit unterstützt nur erzwungenes manuelles Failover.

BACKUP_PRIORITY

30

30

90

Dem Replikat mit asynchronem Commit wird eine höhere Priorität (90) als dem Replikat mit synchronem Commit zugewiesen. Sicherungen erfolgen tendenziell auf der Serverinstanz, die das Replikat mit asynchronem Commit hostet.

SECONDARY_ROLE

( ALLOW_CONNECTIONS = NO,

READ_ONLY_ROUTING_URL = 'TCP://COMPUTER01:1433' )

( ALLOW_CONNECTIONS = NO,

READ_ONLY_ROUTING_URL = 'TCP://COMPUTER02:1433' )

( ALLOW_CONNECTIONS = READ_ONLY, READ_ONLY_ROUTING_URL = 'TCP://COMPUTER03:1433' )

Nur das Replikat mit asynchronem Commit fungiert als lesbares sekundäres Replikat.

Gibt den Computernamen und die standardmäßige Datenbank-Modulportnummer (1433) an.

Dieses Argument ist optional.

PRIMARY_ROLE

( ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (COMPUTER03) )

( ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (COMPUTER03) )

( ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = NONE )

In der primären Rolle lehnen alle Replikate Verbindungsversuche mit Leseabsicht ab.

Verbindungsanforderungen für beabsichtigte Lesevorgänge werden zu COMPUTER03 weitergeleitet, wenn das lokale Replikat unter der sekundären Rolle ausgeführt wird. Wenn dieses Replikat unter der primären Rolle ausgeführt wird, wird das schreibgeschützte Routing deaktiviert.

Dieses Argument ist optional.

SESSION_TIMEOUT

10

10

10

In diesem Beispiel wird der Timeoutwert für die Standardsitzung (10) angegeben. Dieses Argument ist optional.

Im Beispiel wird schließlich die optionale LISTENER-Klausel angegeben, um einen Verfügbarkeitsgruppenlistener für die neue Verfügbarkeitsgruppe zu erstellen. Der eindeutige DNS-Name MyAgListenerIvP6 wird für diesen Listener angegeben. Die zwei Replikate befinden sich auf anderen Subnetzen, daher muss der Listener statische IP-Adressen verwenden. Für die beiden Verfügbarkeitsreplikate gibt die WITH IP-Klausel jeweils eine statische IP-Adresse an, nämlich 2001:4898:f0:f00f::cf3c und 2001:4898:e0:f213::4ce2, die das IPv6-Format verwenden. In diesem Beispiel wird zudem das optionale PORT-Argument verwendet, um Port 60173 als Listenerport anzugeben.

CREATE AVAILABILITY GROUP MyAg 
   WITH (
      AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
      FAILURE_CONDITION_LEVEL  =  3, 
      HEALTH_CHECK_TIMEOUT = 600000
       )
   
   FOR 
      DATABASE  ThisDatabase, ThatDatabase 
   REPLICA ON 
      'COMPUTER01' WITH 
         (
         ENDPOINT_URL = 'TCP://COMPUTER01:5022',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = AUTOMATIC,
         BACKUP_PRIORITY = 30,
         SECONDARY_ROLE (ALLOW_CONNECTIONS = NO, 
            READ_ONLY_ROUTING_LIST = (COMPUTER03) ), 
         PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE, 
            READ_ONLY_ROUTING_LIST = (COMPUTER03) ),
         SESSION_TIMEOUT = 10
         ), 
         
      'COMPUTER02' WITH 
         (
         ENDPOINT_URL = 'TCP://COMPUTER02:5022',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = AUTOMATIC,
         BACKUP_PRIORITY = 30,
         SECONDARY_ROLE (ALLOW_CONNECTIONS = NO, 
            READ_ONLY_ROUTING_URL = 'TCP://COMPUTER02:1433' ),
         PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE, 
            READ_ONLY_ROUTING_LIST = (COMPUTER03) ),
         SESSION_TIMEOUT = 10
         ), 
         
      'COMPUTER03' WITH 
         (
         ENDPOINT_URL = 'TCP://COMPUTER03:5022',
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
         FAILOVER_MODE =  MANUAL,
         BACKUP_PRIORITY = 90,
         SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY, 
            READ_ONLY_ROUTING_URL = 'TCP://COMPUTER03:1433' ),
         PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE, 
            READ_ONLY_ROUTING_LIST = NONE ),
         SESSION_TIMEOUT = 10
         )

LISTENER ‘MyAgListenerIvP6’ ( WITH IP ( ('2001:db88:f0:f00f::cf3c'),('2001:4898:e0:f213::4ce2') ) , PORT = 60173 ); 
GO

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird[Nach oben]

Verwandte Aufgaben

Pfeilsymbol, dass mit dem Link "Zurück zum Anfang" verwendet wird[Nach oben]

Siehe auch

Verweis

ALTER AVAILABILITY GROUP (Transact-SQL)

ALTER DATABASE SET HADR (Transact-SQL)

DROP AVAILABILITY GROUP (Transact-SQL)

Konzepte

Problembehandlung für die AlwaysOn-Verfügbarkeitsgruppenkonfiguration (SQL Server)

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

Verfügbarkeitsgruppenlistener, Clientkonnektivität und Anwendungsfailover (SQL Server)