Konfigurieren von SQL Server-Always On-Verfügbarkeitsgruppen für Hochverfügbarkeit unter Linux

  • Artikel

Gilt für:SQL Server – Linux

In diesem Artikel wird beschrieben, wie Sie eine SQL Server-Always On-Verfügbarkeitsgruppe (AG) für Hochverfügbarkeit unter Linux erstellen. Für Verfügbarkeitsgruppen gibt es zwei verschiedene Konfigurationstypen. Eine Konfiguration mit Hochverfügbarkeit verwendet einen Cluster-Manager, um Geschäftskontinuität zu gewährleisten. Diese Konfiguration kann auch Replikate mit Leseskalierung enthalten. In diesem Dokument wird erläutert, wie die Verfügbarkeitsgruppe für Hochverfügbarkeit erstellt wird.

Sie können eine Verfügbarkeitsgruppe auch ohne einen Cluster-Manager für die Leseskalierung erstellen. Die Verfügbarkeitsgruppe für die schreibgeschützte Skalierung stellt schreibgeschützte Replikate für die leistungsbezogene Skalierung bereit. Sie bietet keine Hochverfügbarkeit. Informationen zum Erstellen einer Verfügbarkeitsgruppe für die Leseskalierung finden Sie unter Configure a SQL Server Availability Group for read-scale on Linux (Konfigurieren einer SQL Server-Verfügbarkeitsgruppe für die Leseskalierung unter Linux).

Konfigurationen, die Hochverfügbarkeit und Datenschutz garantieren, benötigen entweder zwei oder drei synchrone Commitreplikate. Bei drei synchronen Replikaten kann die Verfügbarkeitsgruppe automatisch wiederhergestellt werden, auch wenn ein Server nicht verfügbar ist. Weitere Informationen finden Sie unter High availability and data protection for Availability Group configurations (Hochverfügbarkeit und Datenschutz für Verfügbarkeitsgruppenkonfigurationen).

Alle Server müssen entweder physisch oder virtuell sein, und virtuelle Server müssen sich auf derselben Virtualisierungsplattform befinden. Diese Anforderung ist notwendig, da die Fencing-Agents plattformspezifisch sind. Informationen finden Sie unter Richtlinien für Gastcluster.

Roadmap

Die Schritte zum Erstellen einer Verfügbarkeitsgruppe auf Linux-Servern für Hochverfügbarkeit unterscheiden sich von den Schritten in Windows Server-Failoverclustern. Die allgemeinen Schritte werden in der folgenden Liste beschrieben:

  1. Leitfaden für die Installation von SQL Server für Linux.

    Wichtig

    Alle drei Server in der Verfügbarkeitsgruppe müssen sich auf derselben (physischen oder virtuellen) Plattform befinden, da die Linux-Hochverfügbarkeit Fencing-Agents zum Isolieren von Ressourcen auf Servern verwendet. Die Fencing-Agents sind für jede Plattform spezifisch.

  2. Erstellen Sie die Verfügbarkeitsgruppe. Dieser Schritt wird im aktuellen Artikel behandelt.

  3. Konfigurieren Sie einen Cluster Resource Manager wie Pacemaker.

    Die Art und Weise des Konfigurierens eines Clusterressourcen-Managers hängt von der jeweiligen Linux-Distribution ab. Unter den folgenden Links finden Sie distributionsspezifische Anweisungen:

    Wichtig

    In Produktionsumgebungen wird zur Gewährleistung von Hochverfügbarkeit ein Fencing-Agent benötigt. In den Beispielen in diesem Artikel werden keine Fencing-Agents verwendet. Sie werden lediglich für Tests und Überprüfungen verwendet.

    In einem Pacemaker-Cluster wird Fencing verwendet, um den Cluster in einen bekannten Zustand zurückzusetzen. Wie das Fencing konfiguriert wird, hängt von der Verteilung und der Umgebung ab. Derzeit ist Fencing in einigen Cloudumgebungen nicht verfügbar. Weitere Informationen finden Sie unter Supportrichtlinien für RHEL-Hochverfügbarkeitscluster – Virtualisierungsplattformen.

    Informationen zu SLES finden Sie unter SUSE Linux Enterprise-Hochverfügbarkeitserweiterung.

  4. Fügen Sie die Verfügbarkeitsgruppe im Cluster als Ressource hinzu.

    Die Möglichkeit, die Verfügbarkeitsgruppe im Cluster als Ressource hinzuzufügen, hängt von der Linux-Distribution ab. Unter den folgenden Links finden Sie distributionsspezifische Anweisungen:

Überlegungen zu mehreren Netzwerkschnittstellen (NICs)

Informationen zum Einrichten einer Verfügbarkeitsgruppe für Server mit mehreren NICs finden Sie in den entsprechenden Abschnitten:

Voraussetzungen

Bevor Sie die Verfügbarkeitsgruppe erstellen, müssen Sie:

  • Ihre Umgebung so konfigurieren, dass alle Server kommunizieren können, die Verfügbarkeitsreplikate hosten sollen.
  • Installieren Sie SQL Server.

Hinweis

Unter Linux müssen Sie eine Verfügbarkeitsgruppe erstellen, bevor Sie sie als vom Cluster verwaltete Clusterressource hinzufügen. Dieses Dokument enthält ein Beispiel, in dem eine Verfügbarkeitsgruppe erstellt wird. Verteilungsspezifische Anweisungen zum Erstellen des Clusters und Hinzufügen der Verfügbarkeitsgruppe als Clusterressource finden Sie in den Links unter „Nächste Schritte“.

  1. Aktualisieren Sie den Computernamen für jeden Host.

    Ein SQL Server-Name muss folgende Anforderungen erfüllen:

    • Maximal 15 Zeichen
    • Eindeutig innerhalb des Netzwerks

    Um den Computernamen festzulegen, bearbeiten Sie /etc/hostname. Mithilfe des folgenden Skripts können Sie /etc/hostname mit vi bearbeiten:

    sudo vi /etc/hostname

  2. Konfigurieren Sie die Hostdatei.

    Hinweis

    Wenn Hostnamen mit ihren IP-Adressen beim DNS-Server registriert sind, müssen Sie die folgenden Schritte nicht ausführen. Überprüfen Sie, ob alle Knoten, die zur Konfiguration der Verfügbarkeitsgruppe gehören sollen, miteinander kommunizieren können. (Auf ein Pingen des Hostnamens sollte mit der entsprechenden IP-Adresse geantwortet werden.) Stellen Sie außerdem sicher, dass die Datei /etc/hosts keinen Eintrag enthält, in dem die localhost-IP-Adresse 127.0.0.1 dem Hostnamen des Knotens zugeordnet wird.

    Die Hostdatei auf jedem Server enthält die IP-Adressen und Namen aller Server, die in die Verfügbarkeitsgruppe einbezogen werden.

    Der folgende Befehl gibt die IP-Adresse des aktuellen Servers zurück:

    sudo ip addr show

    Aktualisieren Sie /etc/hosts. Mithilfe des folgenden Skripts können Sie /etc/hosts mit vi bearbeiten:

    sudo vi /etc/hosts

    In folgendem Beispiel wird /etc/hosts auf node1 mit Ergänzungen für node1, node2 und node3 veranschaulicht. In diesem Beispiel verweist node1 auf den Server, auf dem das primäre Replikat gehostet wird, und node2 und node3 verweisen auf Server, die die sekundären Replikate hosten.

    127.0.0.1    localhost localhost4 localhost4.localdomain4
::1          localhost localhost6 localhost6.localdomain6
10.128.18.12 node1
10.128.16.77 node2
10.128.15.33 node3

Installieren von SQL Server

Installieren Sie SQL Server. Die folgenden Links verweisen auf SQL Server-Installationsanweisungen für verschiedene Verteilungen:

Aktivieren von Always On-Verfügbarkeitsgruppen

Aktivieren Sie Always On-Verfügbarkeitsgruppen auf jedem Knoten, der eine SQL Server-Instanz hostet, und starten Sie dann mssql-server neu. Führen Sie folgendes Skript aus:

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

Aktivieren einer AlwaysOn_health-Ereignissitzung

Sie können optional erweiterte Ereignisse (extended events, XE) aktivieren, die Ihnen bei der Ursachendiagnose helfen, wenn Sie Probleme in einer Verfügbarkeitsgruppe behandeln. Führen Sie auf jeder SQL Server-Instanz den folgenden Befehl aus:

ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
GO

Weitere Informationen zu dieser XE-Sitzung finden Sie unter Konfigurieren erweiterter Ereignisse von Always On-Verfügbarkeitsgruppen.

Erstellen eines Zertifikats

Der SQL Server-Dienst unter Linux verwendet Zertifikate zum Authentifizieren von Kommunikation zwischen den Spiegelungsendpunkten.

Das folgende Transact-SQL-Skript erstellt einen Hauptschlüssel und ein Zertifikat. Anschließend werden das Zertifikat und die Datei mit einem privaten Schlüssel gesichert. Aktualisieren Sie das Skript durch sichere Kennwörter. Stellen Sie eine Verbindung mit der primären SQL Server-Instanz her. Führen Sie das folgende Transact-SQL-Skript aus, um das Zertifikat zu erstellen:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate
   TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
   WITH PRIVATE KEY (
           FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
           ENCRYPTION BY PASSWORD = '**<Private_Key_Password>**'
        );

Zu diesem Zeitpunkt weist Ihr primäres SQL Server-Replikat ein Zertifikat unter /var/opt/mssql/data/dbm_certificate.cer und einen privaten Schlüssel unter var/opt/mssql/data/dbm_certificate.pvk auf. Kopieren Sie diese beiden Dateien auf allen Servern, die Verfügbarkeitsreplikate hosten werden, an den gleichen Speicherort. Verwenden Sie den mssql-Benutzer, oder erteilen Sie dem mssql-Benutzer Berechtigungen, um auf diese Dateien zuzugreifen.

Der folgende Befehl kopiert z.B. auf dem Quellserver die Dateien auf den Zielcomputer. Ersetzen Sie die **<node2>**-Werte durch die Namen der SQL Server-Instanzen, die die Replikate hosten werden.

cd /var/opt/mssql/data
scp dbm_certificate.* root@**<node2>**:/var/opt/mssql/data/

Erteilen Sie auf jedem Zielserver dem mssql-Benutzer die Berechtigung, damit er auf das Zertifikat zugreifen kann.

cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*

Erstellen des Zertifikats auf sekundären Servern

Das folgende Transact-SQL-Skript erstellt einen Hauptschlüssel und ein Zertifikat aus der Sicherung, die Sie auf dem primären SQL Server-Replikat erstellt haben. Aktualisieren Sie das Skript durch sichere Kennwörter. Das Entschlüsselungskennwort ist das gleiche Kennwort, mit dem Sie die PVK-Datei in einem vorherigen Schritt erstellt haben. Um das Zertifikat zu erstellen, führen Sie das folgende Skript auf allen sekundären Servern aus:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate
    FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
           FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
           DECRYPTION BY PASSWORD = '**<Private_Key_Password>**'
        );

Erstellen des Datenbankspiegelungs-Endpunkte auf allen Replikaten

Datenbank-Spiegelungsendpunkte senden und empfangen Meldungen zwischen den Serverinstanzen beim Teilnehmen an Datenbankspiegelungssitzungen über TCP (Transmission Control Protocol) oder beim Hosten verfügbarer Replikate. Der Datenbank-Spiegelungsendpunkt lauscht an einer eindeutigen TCP-Portnummer.

Das folgende Transact-SQL-Skript erstellt für die Verfügbarkeitsgruppe einen Überwachungsendpunkt mit dem Namen Hadr_endpoint. Es startet den Endpunkt, und erteilt Verbindungsberechtigung an das Zertifikat, das Sie erstellt haben. Bevor Sie das Skript ausführen, ersetzen Sie die Werte zwischen **< ... >**. Sie können optional eine IP-Adresse einschließen LISTENER_IP = (0.0.0.0). Bei der IP-Adresse des Listeners muss es sich um eine IPv4-Adresse handeln. Sie können auch 0.0.0.0 verwenden.

Aktualisieren Sie auf sämtlichen SQL Server-Instanzen das folgende Transact-SQL-Skript für Ihre Umgebung:

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = **<5022>**)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );

ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

Hinweis

Wenn Sie SQL Server Express Edition auf einem Knoten verwenden, um ein Konfigurationsreplikat zu hosten, ist für ROLE nur der Wert WITNESS zulässig. Führen Sie das folgende Skript in SQL Server Express Edition aus:

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = **<5022>**)
    FOR DATABASE_MIRRORING (
        ROLE = WITNESS,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );

ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

Der TCP-Port in der Firewall muss für den Listenerport geöffnet sein.

Wichtig

Für SQL Server 2017 ist CERTIFICATE die einzige Authentifizierungsmethode, die für den Datenbankspiegelungs-Endpunkt unterstützt wird. Die Option WINDOWS wird in einer zukünftigen Version aktiviert.

Weitere Informationen finden Sie unter Der Datenbankspiegelungs-Endpunkt (SQL Server).

Erstellen der Verfügbarkeitsgruppe

In den Beispielen in diesem Abschnitt wird erläutert, wie die Verfügbarkeitsgruppe mithilfe von Transact-SQL erstellt wird. Sie können auch den SQL Server Management Studio-Assistent für Verfügbarkeitsgruppen verwenden. Beim Erstellen einer Verfügbarkeitsgruppe mit dem Assistenten erhalten Sie eine Fehlermeldung, wenn Sie die Replikate der Verfügbarkeitsgruppe hinzufügen. Erteilen Sie dem Pacemaker auf der Verfügbarkeitsgruppe für alle Replikate die Berechtigungen für ALTER, CONTROL und VIEW DEFINITIONS, um dieses Problem zu beheben. Verknüpfen Sie nach Erteilen der Berechtigungen für das primäre Replikat mithilfe des Assistenten die Knoten mit der Verfügbarkeitsgruppe. Erteilen Sie die Berechtigungen für alle Replikate, damit die Hochverfügbarkeit ordnungsgemäß funktioniert.

Für eine Konfiguration für Hochverfügbarkeit erfordert die Verfügbarkeitsgruppe mindestens drei Replikate, um automatische Failover zu gewährleisten. Diese beiden Konfigurationen unterstützen Hochverfügbarkeit:

Weitere Informationen finden Sie unter High availability and data protection for Availability Group configurations (Hochverfügbarkeit und Datenschutz für Verfügbarkeitsgruppenkonfigurationen).

Hinweis

Die Verfügbarkeitsgruppen können zusätzliche synchrone oder asynchrone Replikate enthalten.

Erstellen Sie die Verfügbarkeitsgruppe für Hochverfügbarkeit unter Linux. Verwenden Sie CREATE AVAILABILITY GROUP mit CLUSTER_TYPE = EXTERNAL.

  • Verfügbarkeitsgruppe: CLUSTER_TYPE = EXTERNAL.

    Gibt an, dass ein eine externe Clusterentität die Verfügbarkeitsgruppe verwaltet. Pacemaker ist ein Beispiel für eine externe Clusterentität. Wenn der Clustertyp der Verfügbarkeitsgruppe extern ist,

  • legen Sie das primäre und das sekundäre Replikat auf FAILOVER_MODE = EXTERNAL fest.

    Dies gibt an, dass das Replikat mit einem externen Cluster-Manager wie Pacemaker interagiert.

Die folgenden Transact-SQL-Skripte erstellen eine Verfügbarkeitsgruppe für Hochverfügbarkeit namens ag1. Das Skript konfiguriert die Verfügbarkeitsgruppenreplikate mit SEEDING_MODE = AUTOMATIC. Diese Einstellung bewirkt, dass SQL Server die Datenbank automatisch auf jedem sekundären Server erstellt. Aktualisieren Sie das folgende Skript für Ihre Umgebung. Ersetzen Sie die Werte <node1>, <node2> oder <node3> durch die Namen der SQL Server-Instanzen, auf denen die Replikate gehostet werden. Ersetzen Sie <5022> durch den Port, den Sie für den Datenbankspiegelungsendpunkt festgelegt haben. Führen Sie zum Erstellen der Verfügbarkeitsgruppe das folgenden Transact-SQL-Skript auf der SQL Server-Instanz aus, die das primäre Replikat hostet.

Wichtig

In der aktuellen Implementierung des SQL Server-Ressourcen-Agents muss der Knotenname mit ServerName der Eigenschaft ihrer Instanz übereinstimmen. Wenn Ihr Knotenname beispielsweise node1 ist, stellen Sie sicher, dass SERVERPROPERTY('ServerName') in Ihrer SQL Server-Instanz node1 zurückgibt. Wenn ein Konflikt vorliegt, werden Ihre Replikate in einen Auflösungszustand übergehen, nachdem die Pacemaker-Ressource erstellt wurde.

Ein Szenario, in dem diese Regel wichtig ist, ist die Verwendung vollqualifizierter Domänennamen. Wenn Sie z. B. node1.yourdomain.com während der Clustereinrichtung als Knotennamen verwenden, stellen Sie sicher, dass SERVERPROPERTY('ServerName') node1.yourdomain.com und nicht nur node1 zurückgibt. Die möglichen Umgehungen für dieses Problem sind:

  • Benennen Sie Ihren Hostnamen in den FQDN um, und verwenden Sie die Speicherprozeduren sp_dropserver und sp_addserver, um sicherzustellen, dass die Metadaten in SQL Server der Änderung entsprechen.
  • Verwenden Sie die Option addr im Befehl pcs cluster auth, um den Knotennamen mit dem Wert SERVERPROPERTY('ServerName') abzugleichen und eine statische IP als Knotenadresse zu verwenden.

Führen Sie nur eines der folgenden Skripte aus:

Erstellen einer Verfügbarkeitsgruppe mit drei synchronen Replikaten

Erstellen einer Verfügbarkeitsgruppe mit drei synchronen Replikaten

CREATE AVAILABILITY GROUP [ag1]
      WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL)
      FOR REPLICA ON
         N'<node1>'
               WITH (
            ENDPOINT_URL = N'tcp://<node1>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
         N'<node2>'
         WITH (
            ENDPOINT_URL = N'tcp://<node2>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
         N'<node3>'
         WITH(
            ENDPOINT_URL = N'tcp://<node3>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            );

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Wichtig

Führen Sie das folgende Skript nicht aus, nachdem Sie das vorherige Skript zum Erstellen einer Verfügbarkeitsgruppe mit drei synchronen Replikaten ausgeführt haben:

Erstellen einer Verfügbarkeitsgruppe mit zwei synchronen Replikaten und einem Konfigurationsreplikat

Erstellen einer Verfügbarkeitsgruppe mit zwei synchronen Replikaten und einem Konfigurationsreplikat:

Wichtig

Mit dieser Architektur kann jede SQL Server-Edition das dritte Replikat hosten. Das dritte Replikat kann beispielsweise auf SQL Server Express Edition gehostet werden. Unter Express Edition ist WITNESS der einzige gültige Endpunkttyp.

CREATE AVAILABILITY GROUP [ag1]
   WITH (CLUSTER_TYPE = EXTERNAL)
   FOR REPLICA ON
      N'<node1>' WITH (
         ENDPOINT_URL = N'tcp://<node1>:<5022>',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = EXTERNAL,
         SEEDING_MODE = AUTOMATIC
         ),
      N'<node2>' WITH (
         ENDPOINT_URL = N'tcp://<node2>:<5022>',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = EXTERNAL,
         SEEDING_MODE = AUTOMATIC
         ),
      N'<node3>' WITH (
         ENDPOINT_URL = N'tcp://<node3>:<5022>',
         AVAILABILITY_MODE = CONFIGURATION_ONLY
         );
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Erstellen einer Verfügbarkeitsgruppe mit zwei synchronen Replikaten

Erstellen einer Verfügbarkeitsgruppe mit zwei synchronen Replikaten

Schließt zwei Replikate mit synchronem Verfügbarkeitsmodus ein. Mit dem folgenden Skript wird beispielsweise eine Verfügbarkeitsgruppe namens ag1 erstellt. node1 und node2 hosten Replikate im synchronen Modus mit automatischem Seeding und automatischem Failover.

Wichtig

Führen Sie das folgende Skript nur zum Erstellen einer Verfügbarkeitsgruppe mit zwei synchronen Replikaten aus. Führen Sie das folgende Skript nicht aus, wenn Sie das vorherige Skript ausgeführt haben.

CREATE AVAILABILITY GROUP [ag1]
   WITH (CLUSTER_TYPE = EXTERNAL)
   FOR REPLICA ON
   N'node1' WITH (
      ENDPOINT_URL = N'tcp://node1:5022',
      AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
      FAILOVER_MODE = EXTERNAL,
      SEEDING_MODE = AUTOMATIC
   ),
   N'node2' WITH (
      ENDPOINT_URL = N'tcp://node2:5022',
      AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
      FAILOVER_MODE = EXTERNAL,
      SEEDING_MODE = AUTOMATIC
   );

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Sie können eine Verfügbarkeitsgruppe auch mit CLUSTER_TYPE=EXTERNAL mithilfe von SQL Server Management Studio oder PowerShell konfigurieren.

Verknüpfen sekundärer Replikate mit der Verfügbarkeitsgruppe

Der Pacemaker-Benutzer benötigt für die Verfügbarkeitsgruppe auf allen Replikaten Berechtigungen für ALTER, CONTROL und VIEW DEFINITION. Führen Sie zum Erteilen von Berechtigungen das folgende Transact-SQL-Skript aus, nachdem die Verfügbarkeitsgruppe auf dem primären und jedem sekundären Replikat erstellt wurde, sobald diese zur Verfügbarkeitsgruppe hinzugefügt wurden. Ersetzen Sie vor der Ausführung des Skripts <pacemakerLogin> durch den Namen des Pacemaker-Benutzerkontos. Wenn Sie nicht über eine Pacemaker-Anmeldung verfügen, erstellen Sie einen SQL Server-Anmeldung für Pacemaker.

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO <pacemakerLogin>
GRANT VIEW SERVER STATE TO <pacemakerLogin>

Das folgende Transact-SQL-Skript verknüpft eine SQL Server-Instanz mit einer Verfügbarkeitsgruppe namens ag1. Aktualisieren Sie das Skript für Ihre Umgebung. Führen Sie auf jeder SQL Server-Instanz, die ein sekundäres Replikat hostet, das folgende Transact-SQL-Skript aus, um die Verfügbarkeitsgruppe zu verknüpfen.

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Hinzufügen einer Datenbank zu einer Verfügbarkeitsgruppe

Stellen Sie sicher, dass sich die Datenbank, die Sie der Verfügbarkeitsgruppe hinzufügen, im vollständigen Wiederherstellungsmodell befindet und eine gültige Protokollsicherung hat. Wenn es sich um eine Testdatenbank oder eine neu erstellte Datenbank handelt, nehmen Sie eine Datenbanksicherung vor. Führen Sie auf dem primären SQL Server das folgende Transact-SQL-Skript aus, um eine Datenbank mit dem Namen db1 zu erstellen und zu sichern:

CREATE DATABASE [db1];
ALTER DATABASE [db1] SET RECOVERY FULL;
BACKUP DATABASE [db1]
   TO DISK = N'/var/opt/mssql/data/db1.bak';

Führen Sie auf dem primären SQL Server-Replikat das folgende Transact-SQL-Skript aus, um einer Verfügbarkeitsgruppe mit dem Namen ag1 eine Datenbank mit dem Namen db1 hinzuzufügen:

ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];

Sicherstellen, dass die Datenbank auf den sekundären Servern erstellt wird

Führen Sie auf jedem sekundären SQL Server-Replikat die folgende Abfrage aus, um festzustellen, ob die db1-Datenbank erstellt und synchronisiert wurde:

SELECT * FROM sys.databases WHERE name = 'db1';
GO
SELECT DB_NAME(database_id) AS 'database', synchronization_state_desc FROM sys.dm_hadr_database_replica_states;

Wichtig

Nach dem Erstellen der Verfügbarkeitsgruppe müssen Sie für Hochverfügbarkeit die Integration in eine Clustertechnologie wie Pacemaker konfigurieren. Ab SQL Server 2017 (14.x) ist das Einrichten eines Clusters für eine Leseskalierungskonfiguration mit Verfügbarkeitsgruppen nicht erforderlich.

Wenn Sie die Schritte in diesem Dokument befolgt haben, verfügen Sie über eine Verfügbarkeitsgruppe, die noch nicht gruppiert ist. Der nächste Schritt besteht darin, den Cluster hinzuzufügen. Diese Konfiguration gilt für Leseskalierungs-/Lastenausgleichsszenarios und ist für die Hochverfügbarkeit nicht abgeschlossen. Für Hochverfügbarkeit müssen Sie die Verfügbarkeitsgruppe als Clusterressource hinzufügen. Anweisungen finden Sie unter Verwandte Inhalte.

Hinweise

Wichtig

Nachdem Sie den Cluster konfiguriert und die Verfügbarkeitsgruppe als Clusterressource hinzugefügt haben, können Sie ein Failover der Verfügbarkeitsgruppen nicht mehr mit Transact-SQL durchführen. SQL Server-Clusterressourcen unter Linux sind nicht so eng mit dem Betriebssystem gekoppelt wie in einem Windows Server-Failovercluster (WSFC). Der SQL Server-Dienst kann das Vorhandensein des Clusters nicht erkennen. Die gesamte Orchestrierung erfolgt über die Clusterverwaltungstools. Verwenden Sie in RHEL oder Ubuntu pcs. Verwenden Sie in SLES crm.

Wichtig

Wenn die Verfügbarkeitsgruppe eine Clusterressource ist, gibt es in der aktuellen Version ein bekanntes Problem, bei dem ein erzwungenes Failover mit Datenverlust für ein asynchrones Replikat nicht funktioniert. Dies wird in der nächsten Version korrigiert. Ein manuelles oder automatisches Failover zu einem synchronen Replikat ist erfolgreich.

Zugehöriger Inhalt