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

Gilt für:SQL Server unter Linux

In diesem Lernprogramm wird gezeigt, wie Sie eine Verfügbarkeitsgruppe (AG) für SQL Server unter Linux erstellen und konfigurieren. Im Gegensatz zu SQL Server 2016 (13.x) und früheren Versionen unter Windows können Sie eine Verfügbarkeitsgruppe (AG) mit oder ohne Erstellung des zugrunde liegenden Pacemaker-Clusters aktivieren. Die Integration mit dem Cluster erfolgt bei Bedarf 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 können Sie das Feature für Verfügbarkeitsgruppen auf zwei Arten aktivieren: verwenden Sie das Hilfsprogramm "mssql-conf ", oder bearbeiten Sie die mssql.conf Datei manuell.

Wichtig

Sie müssen das AG-Feature für nur Konfigurationsreplikate aktivieren, auch in SQL Server Express.

Verwenden des mssql-conf-Hilfsprogramms

Führen Sie in einer Eingabeaufforderung den folgenden Befehl aus:

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

Bearbeiten der mssql.conf-Datei

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

[hadr]

hadr.hadrenabled = 1

SQL Server neu starten

Nach dem Aktivieren von Verfügbarkeitsgruppen müssen Sie SQL Server neu starten. Verwenden Sie den folgenden Befehl:

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 aus einer Instanz auf allen anderen Instanzen wiederherstellen, die als Replikate an derselben AG teilnehmen. Der Zertifikatprozess ist auch für ein Replikat im Modus „Nur Zertifikat“ erforderlich.

Sie können nur Endpunkte erstellen und Zertifikate mithilfe von Transact-SQL wiederherstellen. Sie können auch Nicht-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 = '<master-key-password>';
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 = '<master-key-password>';
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 = '<master-key-password>';
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 = '<password>';

CREATE USER LinAGN2_User
FOR LOGIN LinAGN2_Login;
GO

CREATE LOGIN LinAGN3_Login
WITH PASSWORD = '<password>';

CREATE USER LinAGN3_User
FOR LOGIN LinAGN3_Login;
GO
```
Achtung

Ihr Kennwort sollte der standardmäßigen Kennwortrichtlinie von SQL Server folgen. Ein Standardkennwort enthält mindestens acht Zeichen, die aus drei der folgenden vier Kategorien stammen müssen: Großbuchstaben, Kleinbuchstaben, Grundzahlen (0–9) und Symbole. Kennwörter können bis zu 128 Zeichen lang sein. Verwenden Sie möglichst lange und komplexe Kennwörter.

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 LinAGN2 und LinAGN3 zugeordnet sind, die Berechtigungen, eine Verbindung mit dem Endpunkt auf LinAGN1 herzustellen.
```
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN2_Login;
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN3_Login;
```

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

CREATE LOGIN LinAGN1_Login
WITH PASSWORD = '<password>';

CREATE USER LinAGN1_User
FOR LOGIN LinAGN1_Login;
GO

CREATE LOGIN LinAGN3_Login
WITH PASSWORD = '<password>';

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 LinAGN1 und LinAGN3 zugeordnet sind, die Berechtigungen, eine Verbindung mit dem Endpunkt auf LinAGN2 herzustellen.
```
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN1_Login;
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 = '<password>';

CREATE USER LinAGN1_User
FOR LOGIN LinAGN1_Login;
GO

CREATE LOGIN LinAGN2_Login
WITH PASSWORD = '<password>';

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;
GRANT CONNECT ON ENDPOINT::AGEP TO LinAGN2_Login;
GO
```

Erstellen der Verfügbarkeitsgruppe

In diesem Abschnitt wird gezeigt, wie Sie SQL Server Management Studio (SSMS) oder Transact-SQL verwenden, um die Verfügbarkeitsgruppe für SQL Server zu erstellen.

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. Verwenden Sie EXTERNAL, wenn Sie Pacemaker bereitstellen. Verwenden Sie NONE für spezielle Szenarien, wie z. B. Lese-Skalierung. Die Option für die Zustandserkennung 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 sie einer AG hinzufügen können. 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 werden im Dialogfeld "Replikate angeben" angezeigt. Wenn Sie einen Clustertyp von "Extern" verwenden, stellen Sie für das sekundäre Replikat, das ein echtes sekundäres Replikat sein wird, sicher, dass der Verfügbarkeitsmodus mit dem des primären Replikats und des 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 Secondärdateien verwenden oder eine AG mit einem Clustertyp "Keine" zum Lesen erstellen, können Sie einen Listener erstellen, indem Sie die Registerkarte "Listener " auswählen. Sie können später auch einen Listener hinzufügen. Um einen Listener zu erstellen, wählen Sie die Option " Listener für Verfügbarkeitsgruppen erstellen " aus, und geben Sie einen Namen, einen TCP-/IP-Port ein, und ob eine statische oder automatisch zugewiesene DHCP-IP-Adresse verwendet werden soll. Bei einer AG mit einem Clustertyp "None" sollte die IP statisch sein und auf die IP-Adresse der primären Adresse festgelegt werden.
Wenn Sie einen Listener für lesbare Szenarien erstellen, erlaubt SSMS die Erstellung des schreibgeschützten Routings über den Assistenten. Sie können sie auch später über SSMS oder Transact-SQL hinzufügen. 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. 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, wenn Sie Sicherungen manuell erstellen und kopieren, legen Sie Berechtigungen für die Sicherungsdateien für die anderen Replikate fest. 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. Sie können den Listener und das schreibgeschützte Routing nach dem Erstellen der AG konfigurieren. Sie können die AG selbst mit ALTER AVAILABILITY GROUP ändern, aber Sie können den Clustertyp in SQL Server 2017 (14.x) nicht ändern. 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.

Führen Sie die folgende Anweisung auf dem Knoten aus, der als primäres Replikat fungieren wird und die vollständige Lese-/Schreibkopie der Datenbanken enthält. 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, die folgende Anweisung aus, um das Replikat mit der AG zu verbinden 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
```
Führen Sie in einem Abfragefenster, das nur mit dem Konfigurationsreplikat verbunden ist, die folgende Anweisung aus, um es mit der AG zu verbinden.
```
ALTER AVAILABILITY GROUP [<AGName>]
JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO
```

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

Dieses Beispiel zeigt drei vollständige Replikate und wie Sie das schreibgeschützte Routing als Teil der ersten AG-Erstellung konfigurieren können.

Führen Sie die folgende Anweisung auf dem Knoten aus, der als primäres Replikat fungiert und die vollständige Lese-/Schreibkopie der Datenbanken enthält. 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 Sie mit der Verfügbarkeitsgruppe verwenden. Dies kann auch eine Liste mit durch Kommas getrennte Namen sein.
ListenerName ist ein Name, der sich von einem der zugrunde liegenden Server oder Knoten unterscheidet. Es ist zusammen mit IPAddressDNS registriert.
IPAddress ist eine IP-Adresse, die zugeordnet ListenerNameist. Es ist auch einzigartig und nicht identisch mit einem der Server oder Knoten. 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 dieser Wert 255.255.255.255. In SQL Server 2022 (16.x) und höheren Versionen lautet 0.0.0.0dieser Wert .

Führen Sie in einem Abfragefenster, das mit dem anderen Replikat verbunden ist, die folgende Anweisung aus, um das Replikat mit der AG zu verbinden 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. Verwenden Sie diese Konfiguration für das Leseskalierungsszenario, in dem kein Failover erwartet wird. In diesem Schritt wird der Listener erstellt, der tatsächlich das primäre Replikat und das schreibgeschützte Routing mithilfe der Roundrobin-Funktionalität ist.

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

In diesem Beispiel:

AGName ist der Name der Verfügbarkeitsgruppe.
DBName ist der Name der Datenbank, die Sie mit der Verfügbarkeitsgruppe verwenden. Dies kann auch eine Liste mit durch Kommas getrennte Namen sein.
PortOfEndpoint ist die portnummer, die vom von Ihnen erstellten Endpunkt verwendet wird.
- PortOfInstance ist die Portnummer, die von der Instanz von SQL Server verwendet wird.
ListenerName ist ein Name, der sich von einem der zugrunde liegenden Replikate unterscheidet, aber nicht tatsächlich 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 dieser Wert 255.255.255.255. In SQL Server 2022 (16.x) und höheren Versionen lautet 0.0.0.0dieser Wert .

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 Pacemaker-Cluster mit hoher Verfügbarkeit, der SQL Server unter Linux verwendet, 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 ='<password>';
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
```
Mit diesem Befehl wird der Emacs-Editor geöffnet.
Geben Sie die beiden folgenden Zeilen in den Editor ein:
```
PMLogin

<password>
```
Halten Sie die Ctrl-Taste gedrückt, drücken Sie X und anschließend C, um die Datei zu beenden und zu speichern.
Führen Sie folgende Befehle aus:
```
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 dienen.

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

Nachdem Sie eine Verfügbarkeitsgruppe in SQL Server erstellt haben, müssen Sie die entsprechenden Ressourcen in Pacemaker erstellen, wenn Sie einen Clustertyp "Extern" angeben. Zwei Ressourcen sind einer Verfügbarkeitsgruppe zugeordnet: der Verfügbarkeitsgruppe selbst und einer IP-Adresse. Das Konfigurieren der IP-Adressressource ist optional, wenn Sie die Listenerfunktion nicht verwenden, es wird jedoch empfohlen.

Die von Ihnen erstellte AG-Ressource ist ein Ressourcentyp, der als Klon bezeichnet wird. Die AG-Ressource enthält Kopien auf jedem Knoten und eine steuernde Ressource, 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.

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 promotable notify=true
```
In diesem Beispiel ist NameForAGResource der eindeutige Name, den Sie dieser Clusterressource für die AG zuweisen, und AGName ist der Name der AG, die Sie erstellt haben.
Erstellen Sie die IP-Adressressource für das Application Gateway (AG), die Sie der Listener-Funktionalität zuordnen.
```
sudo pcs resource create <NameForIPResource> ocf:heartbeat:IPaddr2 ip=<IPAddress> cidr_netmask=<Netmask>
```
In diesem Beispiel steht NameForIPResource für den eindeutigen Namen der IP-Ressource, und IPAddress ist die statische IP-Adresse, die Sie der Ressource zuweisen.
Um sicherzustellen, dass die IP-Adresse und die AG-Ressource auf demselben Knoten ausgeführt werden, konfigurieren Sie eine Colocation-Einschränkung.
```
sudo pcs constraint colocation add <NameForIPResource> with promoted <NameForAGResource>-clone INFINITY
```
In diesem Beispiel NameForIPResource ist der Name der IP-Ressource und NameForAGResource der Name für die AG-Ressource.
Erstellen Sie eine Sortierungseinschränkung, um sicherzustellen, dass die Verfügbarkeitsgruppenressource vor der IP-Adresse ausgeführt wird. Während die Colocation-Einschränkung eine Sortiereinschränkung impliziert, erzwingt dieser Schritt sie.
```
sudo pcs constraint order promote <NameForAGResource>-clone then start <NameForIPResource>
```
In diesem Beispiel NameForIPResource ist der Name der IP-Ressource und NameForAGResource der Name für die AG-Ressource.

Hinweis

Ab SQL Server 2025 (17.x) wird SUSE Linux Enterprise Server (SLES) nicht unterstützt.

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="Promoted" \
op notify timeout=60s
clone ms-ag_cluster <NameForAGResource> \
meta promoted-max="1" promoted-node-max="1" clone-max="3" \
    promotable="true" clone-node-max="1" notify="true" \
commit

In diesem Beispiel ist NameForAGResource der eindeutige Name, den Sie dieser Clusterressource für die AG zuweisen, und AGName ist der Name der AG, die Sie erstellt haben.

Erstellen Sie die IP-Adressressource für die AG, die Sie der Listenerfunktionalität zuordnen.
```
crm configure \
primitive <NameForIPResource> \
   ocf:heartbeat:IPaddr2 \
   params ip=<IPAddress> \
      cidr_netmask=<Netmask>
```
In diesem Beispiel ist NameForIPResource der eindeutige Name für die IP-Ressource, und IPAddress ist die statische IP-Adresse, die Sie der Ressource zuweisen. In SLES müssen Sie auch die Netzmaske angeben. Beispielsweise hat 255.255.255.0 den Wert 24 für Netmask.
Um sicherzustellen, dass die IP-Adresse und die AG-Ressource auf demselben Knoten ausgeführt werden, konfigurieren Sie eine Colocation-Einschränkung.
```
crm configure <NameForConstraint> inf: \
<NameForIPResource> <NameForAGResource>:Promoted
commit
```
In diesem Beispiel NameForIPResource ist der Name der IP-Ressource, NameForAGResource der Name für die AG-Ressource 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. Während die Colocation-Einschränkung eine Sortiereinschränkung impliziert, erzwingt dieser Schritt sie.
```
crm configure \
order <NameForConstraint> Mandatory: <NameForAGResource>:promote <NameForIPResource>:start
commit
```
In diesem Beispiel NameForIPResource ist der Name der IP-Ressource, NameForAGResource der Name für die AG-Ressource 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:

Failover der Always On-Verfügbarkeitsgruppe unter Linux

Feedback

War diese Seite hilfreich?

Last updated on 2026-01-05