Erstellen und Konfigurieren einer Verfügbarkeitsgruppe für SQL Server für Linux

Artikel
01/02/2024

Gilt für: SQL Server – Linux

In diesem Tutorial wird gezeigt, wie eine Verfügbarkeitsgruppe (AG) für SQL Server für Linux erstellt und konfiguriert wird. Im Gegensatz zu SQL Server 2016 (13.x) und früheren Versionen unter Windows ist es zum Aktivieren einer Verfügbarkeitsgruppe nun egal, ob Sie zuerst den zugrunde liegenden Cluster erstellen oder nicht. Die Integration in den Cluster erfolgt bei Bedarf erst später.

Im Tutorial werden die folgenden Aufgaben behandelt:

Aktivieren von Verfügbarkeitsgruppen
Erstellen von Verfügbarkeitsgruppenendpunkten und -zertifikaten
Verwenden von SQL Server Management Studio (SSMS) oder Transact-SQL zum Erstellen einer Verfügbarkeitsgruppe
Erstellen des SQL Server-Anmeldenamens und der Berechtigungen für Pacemaker
Erstellen von Verfügbarkeitsgruppenressourcen in einem Pacemaker-Cluster (nur externer Typ)

Voraussetzungen

Stellen Sie den Pacemaker-Cluster mit Hochverfügbarkeit wie in Deploy a Pacemaker cluster for SQL Server on Linux (Bereitstellen eines Pacemaker-Clusters für SQL Server für Linux) beschrieben bereit.

Aktivieren der Verfügbarkeitsgruppenfunktion

Anders als unter Windows können Sie PowerShell oder SQL Server Configuration Manager nicht verwenden, um die Verfügbarkeitsgruppenfunktion (AG) zu aktivieren. Unter Linux müssen Sie mssql-conf zum Aktivieren der Funktion verwenden. Es gibt zwei Möglichkeiten, die Verfügbarkeitsgruppenfunktion zu aktivieren: Entweder Sie verwenden das mssql-conf-Hilfsprogramm, oder Sie Bearbeiten die mssql.conf-Datei manuell.

Wichtig

Die Verfügbarkeitsgruppenfunktion muss nur für Replikate im Modus „Nur Konfiguration“ aktiviert werden (auch für SQL Server Express).

Verwenden des mssql-conf-Hilfsprogramms

Geben Sie bei einer Eingabeaufforderung folgenden Befehl ein:

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1

Bearbeiten der mssql.conf-Datei

Sie können zum Hinzufügen der folgenden Zeilen auch die mssql.conf-Datei ändern, die sich unter dem Ordner /var/opt/mssql befindet:

[hadr]

hadr.hadrenabled = 1

SQL Server neu starten

Nachdem Sie Verfügbarkeitsgruppen wie unter Windows aktiviert haben, müssen Sie SQL Server mit dem folgenden Befehl neu starten.

sudo systemctl restart mssql-server

Erstellen der Verfügbarkeitsgruppenendpunkte und -zertifikate

Eine Verfügbarkeitsgruppe verwendet TCP-Endpunkte für die Kommunikation. Unter Linux werden Endpunkte für eine Verfügbarkeitsgruppe nur dann unterstützt, wenn Zertifikate für die Authentifizierung verwendet werden. Sie müssen das Zertifikat von einer Instanz auf allen anderen Instanzen wiederherstellen, die als Replikate an der gleichen AG teilnehmen werden. Der Zertifikatprozess ist auch für ein Replikat im Modus „Nur Zertifikat“ erforderlich.

Das Erstellen von Endpunkten und Speichern von Zertifikaten ist nur über Transact-SQL möglich. Sie können auch nicht von SQL Server generierte Zertifikate verwenden. Außerdem benötigen Sie einen Prozess zum Verwalten und Ersetzen von Zertifikaten, die ablaufen.

Wichtig

Wenn Sie den SQL Server Management Studio-Assistenten zum Erstellen der Verfügbarkeitsgruppe verwenden möchten, müssen Sie die Zertifikate mithilfe von Transact-SQL unter Linux erstellen und wiederherstellen.

Eine vollständige Syntax der Optionen, die für die verschiedenen Befehle verfügbar sind (wie zusätzliche Sicherheit), finden Sie unter:

Hinweis

Obwohl Sie eine Verfügbarkeitsgruppe erstellen, verwendet der Typ des Endpunkts FOR DATABASE_MIRRORING, da einige zugrunde liegende Aspekte einmal mit dem mittlerweile veralteten Feature freigegeben wurden.

In diesem Beispiel werden Zertifikate für eine Konfiguration mit drei Knoten erstellt. Die Instanz sind LinAGN1, LinAGN2 und LinAGN3.

Führen Sie auf LinAGN1 das folgende Skript aus, um den Hauptschlüssel, das Zertifikat und den Endpunkt zu erstellen, und sichern Sie das Zertifikat. In diesem Beispiel wird der typische TCP-Port 5022 für den Endpunkt verwendet.

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<StrongPassword>';
GO

CREATE CERTIFICATE LinAGN1_Cert
    WITH SUBJECT = 'LinAGN1 AG Certificate';
GO

BACKUP CERTIFICATE LinAGN1_Cert TO FILE = '/var/opt/mssql/data/LinAGN1_Cert.cer';
GO

CREATE ENDPOINT AGEP STATE = STARTED AS TCP (
    LISTENER_PORT = 5022,
    LISTENER_IP = ALL
)
FOR DATABASE_MIRRORING(AUTHENTICATION = CERTIFICATE LinAGN1_Cert, ROLE = ALL);
GO

Führen Sie die das Gleiche auf LinAGN2 aus:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<StrongPassword>';
GO

CREATE CERTIFICATE LinAGN2_Cert
WITH SUBJECT = 'LinAGN2 AG Certificate';
GO

BACKUP CERTIFICATE LinAGN2_Cert
TO FILE = '/var/opt/mssql/data/LinAGN2_Cert.cer';
GO

CREATE ENDPOINT AGEP
STATE = STARTED
AS TCP (
    LISTENER_PORT = 5022,
    LISTENER_IP = ALL)
FOR DATABASE_MIRRORING (
    AUTHENTICATION = CERTIFICATE LinAGN2_Cert,
    ROLE = ALL);
GO

Führen Sie schließlich die gleiche Sequenz auf LinAGN3 aus:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<StrongPassword>';
GO

CREATE CERTIFICATE LinAGN3_Cert
    WITH SUBJECT = 'LinAGN3 AG Certificate';
GO

BACKUP CERTIFICATE LinAGN3_Cert TO FILE = '/var/opt/mssql/data/LinAGN3_Cert.cer';
GO

CREATE ENDPOINT AGEP STATE = STARTED AS TCP (
    LISTENER_PORT = 5022,
    LISTENER_IP = ALL
)
FOR DATABASE_MIRRORING(AUTHENTICATION = CERTIFICATE LinAGN3_Cert, ROLE = ALL);
GO

Kopieren Sie mithilfe von scp oder einem anderen Hilfsprogramm die Sicherungsdateien des Zertifikats auf jedem Knoten, der Teil der Verfügbarkeitsgruppe wird.

In diesem Beispiel:
- Kopieren Sie LinAGN1_Cert.cer in LinAGN2 und LinAGN3.
- Kopieren Sie LinAGN2_Cert.cer in LinAGN1 und LinAGN3.
- Kopieren Sie LinAGN3_Cert.cer in LinAGN1 und LinAGN2.
Ändern Sie den Besitzer und die Gruppe, die mssql zusammen mit den kopierten Zertifikatsdateien zugeordnet sind.
```
sudo chown mssql:mssql <CertFileName>
```

Erstellen Sie die Anmeldenamen auf Instanzebene und die Benutzer, die LinAGN2 und LinAGN3 auf LinAGN1 zugeordnet sind.

CREATE LOGIN LinAGN2_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN2_User FOR LOGIN LinAGN2_Login;
GO

CREATE LOGIN LinAGN3_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN3_User FOR LOGIN LinAGN3_Login;
GO

Stellen Sie LinAGN2_Cert und LinAGN3_Cert auf LinAGN1 wieder her. Die Zertifikate der anderen Replikate sind ein wichtiger Aspekt der Kommunikation und Sicherheit der Verfügbarkeitsgruppe.

CREATE CERTIFICATE LinAGN2_Cert AUTHORIZATION LinAGN2_User
FROM FILE = '/var/opt/mssql/data/LinAGN2_Cert.cer';
GO

CREATE CERTIFICATE LinAGN3_Cert AUTHORIZATION LinAGN3_User
FROM FILE = '/var/opt/mssql/data/LinAGN3_Cert.cer';
GO

Erteilen Sie den Anmeldenamen, die LinAG2 und LinAGN3 zugeordnet sind, die Berechtigungen, eine Verbindung mit dem Endpunkt auf LinAGN1 herzustellen.
```
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN2_Login;
GO

GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN3_Login;
GO
```

Erstellen Sie die Anmeldenamen auf Instanzebene und die Benutzer, die LinAGN1 und LinAGN3 auf LinAGN2 zugeordnet sind.

CREATE LOGIN LinAGN1_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN1_User FOR LOGIN LinAGN1_Login;
GO

CREATE LOGIN LinAGN3_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN3_User FOR LOGIN LinAGN3_Login;
GO

Stellen Sie LinAGN1_Cert und LinAGN3_Cert auf LinAGN2 wieder her.

CREATE CERTIFICATE LinAGN1_Cert
AUTHORIZATION LinAGN1_User
FROM FILE = '/var/opt/mssql/data/LinAGN1_Cert.cer';
GO

CREATE CERTIFICATE LinAGN3_Cert
AUTHORIZATION LinAGN3_User
FROM FILE = '/var/opt/mssql/data/LinAGN3_Cert.cer';
GO

Erteilen Sie den Anmeldenamen, die LinAG1 und LinAGN3 zugeordnet sind, die Berechtigungen, eine Verbindung mit dem Endpunkt auf LinAGN2 herzustellen.
```
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN1_Login;
GO

GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN3_Login;
GO
```

Erstellen Sie die Anmeldenamen auf Instanzebene und die Benutzer, die LinAGN1 und LinAGN2 auf LinAGN3 zugeordnet sind.

CREATE LOGIN LinAGN1_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN1_User FOR LOGIN LinAGN1_Login;
GO

CREATE LOGIN LinAGN2_Login WITH PASSWORD = '<StrongPassword>';
CREATE USER LinAGN2_User FOR LOGIN LinAGN2_Login;
GO

Stellen Sie LinAGN1_Cert und LinAGN2_Cert auf LinAGN3 wieder her.

CREATE CERTIFICATE LinAGN1_Cert
AUTHORIZATION LinAGN1_User
FROM FILE = '/var/opt/mssql/data/LinAGN1_Cert.cer';
GO

CREATE CERTIFICATE LinAGN2_Cert
AUTHORIZATION LinAGN2_User
FROM FILE = '/var/opt/mssql/data/LinAGN2_Cert.cer';
GO

Erteilen Sie den Anmeldenamen, die LinAG1 und LinAGN2 zugeordnet sind, die Berechtigungen, eine Verbindung mit dem Endpunkt auf LinAGN3 herzustellen.
```
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN1_Login;
GO

GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN2_Login;
GO
```

Erstellen der Verfügbarkeitsgruppe

In diesem Abschnitt wird beschrieben, wie SQL Server Management Studio (SSMS) oder Transact-SQL zum Erstellen der Verfügbarkeitsgruppe für SQL Server verwendet wird.

Verwenden Sie SQL Server Management Studio

In diesem Abschnitt wird gezeigt, wie mithilfe von SSMS mit dem neuen Verfügbarkeitsgruppenassistenten eine Verfügbarkeitsgruppe mit dem Clustertyp „Extern“ erstellt wird.

Erweitern Sie in SSMS Hochverfügbarkeit mit Always On, klicken Sie mit der rechten Maustaste auf Verfügbarkeitsgruppen, und wählen Sie dann Assistent für neue Verfügbarkeitsgruppen aus.
Wählen Sie im Dialogfeld „Einführung“ die Option Weiter aus.
Geben Sie im Dialogfeld „Optionen der Verfügbarkeitsgruppe angeben“ einen Namen für die Verfügbarkeitsgruppe ein, und wählen Sie in der Dropdownliste den Clustertyp „EXTERNAL“ oder „NONE“ aus. „Extern“ sollte verwendet werden, wenn Pacemaker bereitgestellt wird. „Keine“ ist für spezialisierte Szenarios wie Leseaufskalierung. Die Auswahl der Option für die Integritätserkennung auf Datenbankebene ist optional. Weitere Informationen zu dieser Option finden Sie unter Availability group database level health detection failover option (Failoveroption für die Integritätserkennung auf Datenbankebene in einer Verfügbarkeitsgruppe). Wählen Sie Weiter aus.
Klicken Sie im Dialogfeld „Datenbanken auswählen“ auf die Datenbanken, die in die Verfügbarkeitsgruppe vorhanden sein sollen. Jede Datenbank muss über eine vollständige Sicherung verfügen, bevor sie zur Verfügbarkeitsgruppe hinzugefügt werden kann. Wählen Sie Weiter aus.
Wählen Sie im Dialogfeld „Replikate angeben“ die Option Replikat hinzufügen aus.
Geben Sie im Dialogfeld „Verbindung mit Server herstellen“ den Namen der Linux-Instanz von SQL Server, die das sekundäre Replikat sein wird, und die Anmeldeinformationen zum Herstellen einer Verbindung ein. Wählen Sie Verbinden.
Wiederholen Sie die vorherigen beiden Schritte für die Instanz, die ein Replikat im Modus „Nur Konfiguration“ oder ein anderes sekundäres Replikat enthalten soll.
Alle drei Instanzen sollten jetzt im Dialogfeld „Replikate angeben“ aufgeführt werden. Wenn Sie den Clustertyp „Extern“ verwenden, sollten Sie sicherstellen, dass der „Verfügbarkeitsmodus“ für das (tatsächlich) sekundäre Replikat mit dem des primären Replikats übereinstimmt, und dass der Failovermodus auf „Extern“ festgelegt ist. Wählen Sie für das Replikat im Modus „Nur Konfiguration“ den Verfügbarkeitsmodus „Nur Konfiguration“ aus.

Das folgende Beispiel zeigt eine Verfügbarkeitsgruppe mit zwei Replikaten, den Clustertyp „Extern“ und ein Replikat im Modus „Nur Konfiguration“.

Das folgende Beispiel zeigt eine Verfügbarkeitsgruppe mit zwei Replikaten, den Clustertyp „Keine“ und ein Replikat im Modus „Nur Konfiguration“.
Klicken Sie auf die Registerkarte „Sicherungseinstellungen“, wenn Sie die Sicherungseinstellungen ändern möchten. Weitere Informationen zu Sicherungseinstellungen für Verfügbarkeitsgruppen finden Sie unter Konfigurieren von Sicherungen auf sekundären Replikaten einer Always On-Verfügbarkeitsgruppe.
Wenn Sie lesbare sekundäre Replikate verwenden oder eine Verfügbarkeitsgruppe mit dem Clustertyp „Keine“ für die Leseskalierung erstellen, können Sie durch Auswählen der Registerkarte „Listener“ einen Listener erstellen. Ein Listener kann auch zu einem späteren Zeitpunkt hinzugefügt werden. Klicken Sie zum Erstellen eines Listeners auf die Option Verfügbarkeitsgruppenlistener erstellen. Geben Sie dann einen Namen und einen TCP/IP-Port ein, und legen Sie fest, ob eine statisch oder automatisch zugewiesene DHCP-IP-Adresse verwendet werden soll. Beachten Sie, dass die IP-Adresse für eine Verfügbarkeitsgruppe mit dem Clustertyp „Keine“ statisch sein sollte und auf die IP-Adresse des primären Replikats festgelegt ist.
Wenn für lesbare Szenarios ein Listener erstellt wird, ermöglicht SSMS 17.3 oder höher die Erstellung des schreibgeschützten Routings im Assistenten. Er kann auch später über SSMS oder Transact-SQL hinzugefügt werden. So fügen Sie das schreibgeschützte Routing jetzt hinzu:
1. Klicken Sie auf die Registerkarte „Read-Only Routing“ (Schreibgeschütztes Routing).
2. Geben Sie die URLs für die schreibgeschützten Replikate ein. Diese URLs ähneln den Endpunkten, mit dem Unterschied, dass sie anstelle des Endpunkts den Port der Instanz verwenden.
3. Wählen Sie die einzelnen URLs und weiter unten die lesbaren Replikate aus. Sie können die UMSCHALTTASTE gedrückt halten oder klicken und ziehen, um mehrere auszuwählen.
Wählen Sie Weiter aus.
Wählen Sie aus, wie die sekundären Replikate initialisiert werden sollen. Standardmäßig wird das automatische Seeding verwendet, das denselben Pfad auf allen an der Verfügbarkeitsgruppe beteiligten Server benötigt. Sie können die Datenbank auch mithilfe des Assistenten sichern, kopieren und wiederherstellen (zweite Option). Wenn Sie die Datenbank manuell gesichert, kopiert und wiederhergestellt haben, wird diese auf den Replikaten verknüpft (dritte Option). Eine weitere Möglichkeit besteht darin, die Datenbank zu einem späteren Zeitpunkt hinzuzufügen (letzte Option). Wie bei Zertifikaten müssen beim manuellen Sichern und Kopieren Berechtigungen für die Sicherungsdateien für die anderen Replikate festgelegt werden. Wählen Sie Weiter aus.
Wenn nicht alles als „Erfolgreich“ zurückgegeben wird, können Sie die Ergebnisse im Dialogfeld „Validierung“ überprüfen. Einige Warnungen, die beispielsweise ausgegeben werden, wenn Sie keinen Listener erstellen, sind nicht so schlimm und haben keine großen Auswirkungen. Wählen Sie Weiter aus.
Wählen Sie im Dialogfeld „Zusammenfassung“ die Option Fertig stellen aus. Der Prozess zum Erstellen der Verfügbarkeitsgruppe beginnt jetzt.
Wählen Sie nach der Erstellung der Verfügbarkeitsgruppe auf der Registerkarte „Ergebnisse“ die Option Schließen aus. Jetzt können Sie in der dynamischen Verwaltungssicht und unter dem Ordner „Hochverfügbarkeit mit Always On“ in SSMS die Verfügbarkeitsgruppe auf den Replikaten sehen.

Verwenden von Transact-SQL

Dieser Abschnitt enthält Beispiele für das Erstellen einer Verfügbarkeitsgruppe mithilfe von Transact-SQL. Der Listener und das schreibgeschützte Routing können nach dem Erstellen der Verfügbarkeitsgruppe konfiguriert werden. Die Verfügbarkeitsgruppe kann zwar mit ALTER AVAILABILITY GROUP geändert werden, doch der Clustertyp kann in SQL Server 2017 (14.x) nicht geändert werden. Wenn Sie keine Verfügbarkeitsgruppe mit dem Clustertyp „Extern“ erstellen wollten, müssen Sie sie löschen, und neu mit dem Clustertyp „Keine“ erstellen. Weitere Informationen und andere Optionen finden Sie unter den folgenden Links:

Beispiel A: Zwei Replikate mit einem Replikat im Modus „Nur Konfiguration“ (externer Clustertyp)

Dieses Beispiel zeigt, wie Sie eine Verfügbarkeitsgruppe mit zwei Replikaten erstellen, die ein Replikat im Modus „Nur Konfiguration“ verwendet.

Die Ausführung erfolgt auf dem Knoten, der das primäre Replikat mit der vollständigen Lese-/Schreibkopie der Datenbanken sein soll. In diesem Beispiel wird das automatische Seeding verwendet.

CREATE AVAILABILITY GROUP [<AGName>]
WITH (CLUSTER_TYPE = EXTERNAL)
FOR DATABASE <DBName>
REPLICA ON N'LinAGN1' WITH (
   ENDPOINT_URL = N' TCP://LinAGN1.FullyQualified.Name:5022',
   FAILOVER_MODE = EXTERNAL,
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
N'LinAGN2' WITH (
   ENDPOINT_URL = N'TCP://LinAGN2.FullyQualified.Name:5022',
   FAILOVER_MODE = EXTERNAL,
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
   SEEDING_MODE = AUTOMATIC),
N'LinAGN3' WITH (
   ENDPOINT_URL = N'TCP://LinAGN3.FullyQualified.Name:5022',
   AVAILABILITY_MODE = CONFIGURATION_ONLY);
GO

Führen Sie in einem Abfragefenster, das mit dem anderen Replikat verbunden ist, Folgendes aus, um das Replikat mit der Verfügbarkeitsgruppe zu verknüpfen und den Seedingprozess vom primären zum sekundären Replikat zu initiieren.
```
ALTER AVAILABILITY GROUP [<AGName>] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [<AGName>] GRANT CREATE ANY DATABASE;
GO
```
Verknüpfen Sie es in einem Abfragefenster, das mit dem Replikat im Modus „Nur Konfiguration“ verbunden ist, mit der Verfügbarkeitsgruppe.
```
ALTER AVAILABILITY GROUP [<AGName>] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO
```

Beispiel B: Drei Replikate mit schreibgeschütztem Routing (externer Clustertyp)

In diesem Beispiel werden drei vollständige Replikate und die Konfiguration des schreibgeschützten Routings als Teil der Erstellung der anfänglichen Verfügbarkeitsgruppe veranschaulicht.

Die Ausführung erfolgt auf dem Knoten, der das primäre Replikat mit der vollständigen Lese-/Schreibkopie der Datenbanken sein soll. In diesem Beispiel wird das automatische Seeding verwendet.

CREATE AVAILABILITY GROUP [<AGName>] WITH (CLUSTER_TYPE = EXTERNAL)
FOR DATABASE < DBName > REPLICA ON
    N'LinAGN1' WITH (
        ENDPOINT_URL = N'TCP://LinAGN1.FullyQualified.Name:5022',
        FAILOVER_MODE = EXTERNAL,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
            (
                'LinAGN2.FullyQualified.Name',
                'LinAGN3.FullyQualified.Name'
                )
            )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN1.FullyQualified.Name:1433')
    ),
    N'LinAGN2' WITH (
        ENDPOINT_URL = N'TCP://LinAGN2.FullyQualified.Name:5022',
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
            (
                'LinAGN1.FullyQualified.Name',
                'LinAGN3.FullyQualified.Name'
                )
            )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN2.FullyQualified.Name:1433')
    ),
    N'LinAGN3' WITH (
        ENDPOINT_URL = N'TCP://LinAGN3.FullyQualified.Name:5022',
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
            (
                'LinAGN1.FullyQualified.Name',
                'LinAGN2.FullyQualified.Name'
                )
            )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN3.FullyQualified.Name:1433')
    )
    LISTENER '<ListenerName>' (
        WITH IP = ('<IPAddress>', '<SubnetMask>'), Port = 1433
    );
GO

Bei dieser Konfiguration sind einige Punkte zu beachten:

AGName ist der Name der Verfügbarkeitsgruppe.
DBName ist der Name der Datenbank, die mit der Verfügbarkeitsgruppe verwendet wird. Dies kann auch eine Liste mit durch Kommas getrennte Namen sein.
ListenerName ist ein Name, der sich von den zugrunde liegenden Servern/Knoten unterscheidet. Er wird in DNS zusammen mit IPAddress registriert.
IPAddress ist eine IP-Adresse, die ListenerName zugeordnet ist. Sie ist eindeutig und mit keinem Server/Knoten identisch. Anwendungen und Endbenutzer verwenden entweder ListenerName oder IPAddress, um eine Verbindung mit der Verfügbarkeitsgruppe herzustellen.
SubnetMask ist die Subnetzmaske von IPAddress. In SQL Server 2019 (15.x) und früheren Versionen ist dies 255.255.255.255. In SQL Server 2022 (16.x) und höheren Versionen ist dies 0.0.0.0.

Führen Sie in einem Abfragefenster, das mit dem anderen Replikat verbunden ist, Folgendes aus, um das Replikat mit der Verfügbarkeitsgruppe zu verknüpfen und den Seedingprozess vom primären zum sekundären Replikat zu initiieren.
```
ALTER AVAILABILITY GROUP [<AGName>] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO

ALTER AVAILABILITY GROUP [<AGName>] GRANT CREATE ANY DATABASE;
GO
```
Wiederholen Sie Schritt 2 für das dritte Replikat.

Beispiel C: Zwei Replikate mit schreibgeschütztem Routing (Clustertyp „Keine“)

In diesem Beispiel wird gezeigt, wie eine Konfiguration mit zwei Replikaten mit dem Clustertyp „Keine“ erstellt wird. Dieses wird für das Leseskalierungsszenario verwendet, bei dem kein Failover erwartet wird. Dadurch wird der Listener, der tatsächlich das primäre Replikat ist, sowie das schreibgeschützte Routing mit der Roundrobin-Funktionalität erstellt.

Die Ausführung erfolgt auf dem Knoten, der das primäre Replikat mit der vollständigen Lese-/Schreibkopie der Datenbanken sein soll. In diesem Beispiel wird das automatische Seeding verwendet.

CREATE AVAILABILITY
GROUP [<AGName>]
WITH (CLUSTER_TYPE = NONE)
FOR DATABASE <DBName> REPLICA ON
    N'LinAGN1' WITH (
        ENDPOINT_URL = N'TCP://LinAGN1.FullyQualified.Name: <PortOfEndpoint>',
        FAILOVER_MODE = MANUAL,
        AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(
            ALLOW_CONNECTIONS = READ_WRITE,
            READ_ONLY_ROUTING_LIST = (('LinAGN1.FullyQualified.Name'.'LinAGN2.FullyQualified.Name'))
        ),
        SECONDARY_ROLE(
            ALLOW_CONNECTIONS = ALL,
            READ_ONLY_ROUTING_URL = N'TCP://LinAGN1.FullyQualified.Name:<PortOfInstance>'
        )
    ),
    N'LinAGN2' WITH (
        ENDPOINT_URL = N'TCP://LinAGN2.FullyQualified.Name:<PortOfEndpoint>',
        FAILOVER_MODE = MANUAL,
        SEEDING_MODE = AUTOMATIC,
        AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
        PRIMARY_ROLE(ALLOW_CONNECTIONS = READ_WRITE, READ_ONLY_ROUTING_LIST = (
                 ('LinAGN1.FullyQualified.Name',
                    'LinAGN2.FullyQualified.Name')
                 )),
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL, READ_ONLY_ROUTING_URL = N'TCP://LinAGN2.FullyQualified.Name:<PortOfInstance>')
    ),
    LISTENER '<ListenerName>' (WITH IP = (
             '<PrimaryReplicaIPAddress>',
             '<SubnetMask>'),
            Port = <PortOfListener>
    );
GO

Hierbei gilt:

AGName ist der Name der Verfügbarkeitsgruppe.
DBName ist der Name der Datenbank, die mit der Verfügbarkeitsgruppe verwendet wird. Dies kann auch eine Liste mit durch Kommas getrennte Namen sein.
PortOfEndpoint ist die Portnummer, die vom erstellten Endpunkt verwendet wird.
PortOfInstance ist die Portnummer, die von der Instanz von SQL Server verwendet wird.
ListenerName ist ein Name, der sich von den zugrunde liegenden Replikaten unterscheidet, aber nicht verwendet wird.
PrimaryReplicaIPAddress ist die IP-Adresse des primären Replikats.
SubnetMask ist die Subnetzmaske von IPAddress. In SQL Server 2019 (15.x) und früheren Versionen ist dies 255.255.255.255. In SQL Server 2022 (16.x) und höheren Versionen ist dies 0.0.0.0.

Verknüpfen Sie das sekundäre Replikat mit der Verfügbarkeitsgruppe, und initiieren Sie das automatische Seeding.

ALTER AVAILABILITY GROUP [<AGName>] JOIN WITH (CLUSTER_TYPE = NONE);
GO

ALTER AVAILABILITY GROUP [<AGName>] GRANT CREATE ANY DATABASE;
GO

Ein unter Linux SQL Server zugrunde liegender Pacemaker-Cluster mit Hochverfügbarkeit benötigt Zugriff auf die SQL Server-Instanz und Berechtigungen für die Verfügbarkeitsgruppe selbst. Mit diesen Schritten werden der Anmeldename und die zugehörigen Berechtigungen zusammen mit einer Datei erstellt, die Pacemaker mitteilt, wie die Anmeldung bei SQL Server erfolgen soll.

Führen Sie in einem Abfragefenster, das mit dem ersten Replikat verbunden ist, das folgende Skript aus:

CREATE LOGIN PMLogin WITH PASSWORD ='<StrongPassword>';
GO

GRANT VIEW SERVER STATE TO PMLogin;
GO

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::<AGThatWasCreated> TO PMLogin;
GO

Geben Sie auf Knoten 1 den Befehl ein.
```
sudo emacs /var/opt/mssql/secrets/passwd
```
Dadurch wird der Emacs-Editor geöffnet.
Geben Sie die beiden folgenden Zeilen in den Editor ein:
```
PMLogin

<StrongPassword>
```
Halten Sie die Ctrl-Taste gedrückt, drücken Sie X und anschließend C, um die Datei zu beenden und zu speichern.

Execute

sudo chmod 400 /var/opt/mssql/secrets/passwd

um die Datei zu sperren.

Wiederholen Sie die Schritte 1 bis 5 auf den anderen Servern, die als Replikate fungieren.

Erstellen der Verfügbarkeitsgruppenressourcen im Pacemaker-Cluster (nur „Extern“)

Nachdem eine Verfügbarkeitsgruppe in SQL Server erstellt wurde, müssen die entsprechenden Ressourcen in Pacemaker erstellt werden, wenn der Clustertyp „Extern“ angegeben wird. Einer Verfügbarkeitsgruppe sind zwei Ressourcen zugeordnet: die Verfügbarkeitsgruppe selbst und eine IP-Adresse. Das Konfigurieren der IP-Adressressource ist zwar optional, wird allerdings empfohlen, wenn Sie die Listenerfunktion nicht verwenden.

Die erstellte Verfügbarkeitsgruppenressource ist eine Art von Ressource, die als Klon bezeichnet wird. Die Verfügbarkeitsgruppe verfügt im Wesentlichen über Kopien der einzelnen Knoten, und es gibt eine Steuerungsressource, die als Master bezeichnet wird. Diese Ressource wird dem Server zugeordnet, der das primäre Replikat hostet. Die anderen Ressourcen hosten sekundäre Replikate („Regulär“ oder „Nur Konfiguration“) und können in einem Failover zum Master heraufgestuft werden.

Hinweis

Vorurteilsfreie Kommunikation

In diesem Artikel wird der Begriff Slave (Sklave) verwendet, der in diesem Kontext von Microsoft als beleidigend eingestuft wird. Der Begriff wird in diesem Artikel verwendet, weil er derzeit in der Software verwendet wird. Sobald der Begriff aus der Software entfernt wird, wird er auch aus dem Artikel entfernt.

Red Hat Enterprise Linux (RHEL) und Ubuntu
SUSE Linux Enterprise Server (SLES)

Erstellen Sie die Verfügbarkeitsgruppenressource mit der folgenden Syntax:
```
sudo pcs resource create <NameForAGResource> ocf:mssql:ag ag_name=<AGName> meta failure-timeout=30s --master meta notify=true
```
Dabei ist NameForAGResource der eindeutige Name dieser Clusterressource für die Verfügbarkeitsgruppe und AGName der Name der erstellten Verfügbarkeitsgruppe.

Unter RHEL 7.7 und Ubuntu 18.04 und höher tritt möglicherweise eine Warnung zur Verwendung von --master oder ein Fehler wie sqlag_monitor_0 on ag1 'not configured' (6): call=6, status=complete, exitreason='Resource must be configured with notify=true' auf. So vermeiden Sie diese Situation:
```
sudo pcs resource create <NameForAGResource> ocf:mssql:ag ag_name=<AGName> meta failure-timeout=30s master notify=true
```
Erstellen Sie die IP-Adressressource für die Verfügbarkeitsgruppe, die der Listenerfunktion zugeordnet wird.
```
sudo pcs resource create <NameForIPResource> ocf:heartbeat:IPaddr2 ip=<IPAddress> cidr_netmask=<Netmask>
```
Dabei ist NameForIPResource der eindeutige Name der IP-Adressressource und IPAddress die der Ressource zugewiesene statische IP-Adresse.
Es muss eine Kollokationseinschränkung konfiguriert werden, um sicherzustellen, dass die IP-Adresse und die Verfügbarkeitsgruppenressource auf demselben Knoten ausgeführt werden.
```
sudo pcs constraint colocation add <NameForIPResource> <NameForAGResource>-master INFINITY with-rsc-role=Master
```
Dabei ist NameForIPResource der Name der IP-Ressource und NameForAGResource der Name für die Ressource der Verfügbarkeitsgruppe.
Erstellen Sie eine Sortierungseinschränkung, um sicherzustellen, dass die Verfügbarkeitsgruppenressource vor der IP-Adresse ausgeführt wird. Obwohl die Kollokationseinschränkung eine Sortierungseinschränkung impliziert, erzwingt sie diese.
```
sudo pcs constraint order promote <NameForAGResource>-master then start <NameForIPResource>
```
Dabei ist NameForIPResource der Name der IP-Ressource und NameForAGResource der Name für die Ressource der Verfügbarkeitsgruppe.

Erstellen Sie die Verfügbarkeitsgruppenressource mit der folgenden Syntax:

primitive <NameForAGResource> \
ocf:mssql:ag \
params ag_name="<AGName>" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag_cluster <NameForAGResource> \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true" \
commit

Dabei ist NameForAGResource der eindeutige Name dieser Clusterressource für die Verfügbarkeitsgruppe und AGName der Name der erstellten Verfügbarkeitsgruppe.

Erstellen Sie die IP-Adressressource für die Verfügbarkeitsgruppe, die der Listenerfunktion zugeordnet wird.
```
crm configure \
primitive <NameForIPResource> \
   ocf:heartbeat:IPaddr2 \
   params ip=<IPAddress> \
      cidr_netmask=<Netmask>
```
Dabei ist NameForIPResource der eindeutige Name der IP-Adressressource und IPAddress die der Ressource zugewiesene statische IP-Adresse. In SLES müssen Sie auch die Netzmaske angeben. So hat 255.255.255.0 für Netmask beispielsweise den Wert „24“.
Es muss eine Kollokationseinschränkung konfiguriert werden, um sicherzustellen, dass die IP-Adresse und die Verfügbarkeitsgruppenressource auf demselben Knoten ausgeführt werden.
```
crm configure <NameForConstraint> inf: \
<NameForIPResource> <NameForAGResource>:Master
commit
```
Dabei ist NameForIPResource der Name der IP-Ressource, NameForAGResource der Name für die Ressource der Arbeitsgruppe und NameForConstraint der Name für die Einschränkung.
Erstellen Sie eine Sortierungseinschränkung, um sicherzustellen, dass die Verfügbarkeitsgruppenressource vor der IP-Adresse ausgeführt wird. Obwohl die Kollokationseinschränkung eine Sortierungseinschränkung impliziert, erzwingt sie diese.
```
crm configure \
order <NameForConstraint> inf: <NameForAGResource>:promote <NameForIPResource>:start
commit
```
Dabei ist NameForIPResource der Name der IP-Ressource, NameForAGResource der Name für die Ressource der Arbeitsgruppe und NameForConstraint der Name für die Einschränkung.

Nächster Schritt

In diesem Tutorial wurde gezeigt, wie eine Verfügbarkeitsgruppe für SQL Server unter Linux erstellt und konfiguriert wird. Sie haben Folgendes gelernt:

Aktivieren von Verfügbarkeitsgruppen
Erstellen von Verfügbarkeitsgruppenendpunkten und -zertifikaten
Verwenden von SQL Server Management Studio (SSMS) oder Transact-SQL zum Erstellen einer Verfügbarkeitsgruppe
Erstellen des SQL Server-Anmeldenamens und der Berechtigungen für Pacemaker
Erstellen von Verfügbarkeitsgruppenressourcen in einem Pacemaker-Cluster

Informationen zu den meisten Verwaltungsaufgaben in Bezug auf Verfügbarkeitsgruppen einschließlich Upgrades und Failovers finden Sie unter:

Arbeiten mit einer Verfügbarkeitsgruppe mit Hochverfügbarkeit für SQL Server für Linux

Teilen über

Erstellen und Konfigurieren einer Verfügbarkeitsgruppe für SQL Server für Linux

Voraussetzungen

Aktivieren der Verfügbarkeitsgruppenfunktion

Verwenden des mssql-conf-Hilfsprogramms

Bearbeiten der mssql.conf-Datei

SQL Server neu starten

Erstellen der Verfügbarkeitsgruppenendpunkte und -zertifikate

Erstellen der Verfügbarkeitsgruppe

Verwenden Sie SQL Server Management Studio

Verwenden von Transact-SQL

Beispiel A: Zwei Replikate mit einem Replikat im Modus „Nur Konfiguration“ (externer Clustertyp)

Beispiel B: Drei Replikate mit schreibgeschütztem Routing (externer Clustertyp)

Beispiel C: Zwei Replikate mit schreibgeschütztem Routing (Clustertyp „Keine“)

Erstellen der Verfügbarkeitsgruppenressourcen im Pacemaker-Cluster (nur „Extern“)

Nächster Schritt

Feedback

Zusätzliche Ressourcen

Teilen über

Erstellen und Konfigurieren einer Verfügbarkeitsgruppe für SQL Server für Linux

Voraussetzungen

Aktivieren der Verfügbarkeitsgruppenfunktion

Verwenden des mssql-conf-Hilfsprogramms

Bearbeiten der mssql.conf-Datei

SQL Server neu starten

Erstellen der Verfügbarkeitsgruppenendpunkte und -zertifikate

Erstellen der Verfügbarkeitsgruppe

Verwenden Sie SQL Server Management Studio

Verwenden von Transact-SQL

Beispiel A: Zwei Replikate mit einem Replikat im Modus „Nur Konfiguration“ (externer Clustertyp)

Beispiel B: Drei Replikate mit schreibgeschütztem Routing (externer Clustertyp)

Beispiel C: Zwei Replikate mit schreibgeschütztem Routing (Clustertyp „Keine“)

Erstellen des SQL Server-Anmeldenamens und der Berechtigungen für Pacemaker

Erstellen der Verfügbarkeitsgruppenressourcen im Pacemaker-Cluster (nur „Extern“)

Nächster Schritt

Feedback

Zusätzliche Ressourcen