Teilen über

Konfigurieren der SQL Server-Verfügbarkeitsgruppe für hohe Verfügbarkeit unter Linux

Gilt für:SQL Server unter 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 Artikel wird erläutert, wie Sie die AG für hohe Verfügbarkeit erstellen.

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 AG für Read-Scale finden Sie unter Configure a SQL Server availability group for read-scale on 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 besteht, da die Zäunungsagenten plattformspezifisch sind. Informationen finden Sie unter Richtlinien für Gastcluster.

Installationsschritte

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

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

    Von Bedeutung

    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:

    Von Bedeutung

    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 sind nur für Tests und Validierung vorgesehen.

    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

Führen Sie vor dem Erstellen der Verfügbarkeitsgruppe die folgenden Schritte aus:

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

Unter Linux müssen Sie eine Verfügbarkeitsgruppe erstellen, bevor Sie sie als Clusterressource für den Zu verwaltenden Cluster hinzufügen. Dieser Artikel enthält ein Beispiel, das die Verfügbarkeitsgruppe erstellt.

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

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

    • 15 Zeichen oder weniger.
    • Eindeutig innerhalb des Netzwerks

    Um den Computernamen festzulegen, bearbeiten Sie /etc/hostname. Das folgende Beispiel zeigt, wie Sie /etc/hostname mit vi bearbeiten:

    sudo vi /etc/hostname

  2. Konfigurieren Sie die Hostdatei.

    Hinweis

    Wenn der DNS-Server Hostnamen mit ihren IP-Adressen registriert, 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 an der Verfügbarkeitsgruppe teilnehmen.

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

    sudo ip addr show

    Aktualisieren Sie /etc/hosts. Das folgende Beispiel zeigt, wie 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:

Hinweis

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

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 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, an denselben Ort. 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.

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 mit dem Kennwort identisch, das Sie für die Erstellung der .pvk-Datei in einem vorherigen Schritt verwendet 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>'
);

Ersetzen Sie im vorherigen Beispiel <private-key-password> durch dasselbe Kennwort, das Sie beim Erstellen des Zertifikats im primären Replikat verwendet haben.

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 < ... >. Optional können Sie eine IP-Adresse LISTENER_IP = (0.0.0.0)einschließen. 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;

Sie müssen den TCP-Port in der Firewall für den Listenerport öffnen.

Von Bedeutung

Die einzige für den Datenbankspiegelungsendpunkt unterstützte Authentifizierungsmethode ist CERTIFICATE. Die Option WINDOWS ist nicht verfügbar.

Weitere Informationen finden Sie unter Dem Datenbankspiegelungsendpunkt (SQL Server).For more information, see The database mirroring endpoint (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. Wenn Sie eine AG mit dem Assistenten erstellen, wird ein Fehler zurückgegeben, wenn Sie die Replikate in die AG aufnehmen. Um diesen Fehler zu beheben, gewähren Sie dem Pacemaker auf der AG ALTER auf allen Replikaten CONTROL den ZugriffVIEW DEFINITIONS. Nachdem Sie Berechtigungen für das primäre Replikat erteilt haben, verbinden Sie die Knoten über den Assistenten mit der AG, aber damit HA ordnungsgemäß funktioniert, erteilen Sie allen Replikaten die Berechtigung.

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 die CREATE AVAILABILITY GROUP-Anweisung 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.

Führen Sie nur eines der folgenden Skripte aus:

Den Knotennamen mit der ServerName-Eigenschaft abgleichen

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

Diese Regel ist wichtig, wenn Sie vollqualifizierte Domänennamen verwenden. Wenn Sie z. B. während des Clustersetups als Knotennamen verwenden node1.yourdomain.com , stellen Sie sicher, dass SERVERPROPERTY('ServerName') zurückgegeben node1.yourdomain.comwird und nicht nur node1. Um dieses Problem zu beheben, haben Sie folgende Möglichkeiten:

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

Erstellen einer Verfügbarkeitsgruppe mit drei synchronen Replikaten

Erstellen einer AG 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;

Von Bedeutung

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 Sie eine AG mit zwei synchronen Replikaten und einem Konfigurationsreplikat:

Von Bedeutung

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 Sie eine AG 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.

Von Bedeutung

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 ALTER, CONTROLund VIEW DEFINITION Berechtigungen für die Verfügbarkeitsgruppe für alle Replikate. Führen Sie zum Erteilen dieser Berechtigungen das folgende Transact-SQL Skript aus, nachdem Sie die Verfügbarkeitsgruppe für das primäre Replikat erstellt haben. Führen Sie das Skript für jedes sekundäre Replikat unmittelbar nach dem Hinzufügen zur Verfügbarkeitsgruppe aus. Ersetzen Sie <pacemakerLogin> vor dem Ausführen des Skripts 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;

Hinweis

Für ein Konfigurationsreplikat ist nur der Verknüpfungsschritt erforderlich.

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 Ihre Datenbank 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 (T-SQL)-Skript aus, um eine Datenbank mit dem Namen db1 zu erstellen und zu sichern:

CREATE DATABASE [db1];
GO

ALTER DATABASE [db1]
    SET RECOVERY FULL;
GO

BACKUP DATABASE [db1]
    TO DISK = N'/var/opt/mssql/data/db1.bak';

Führen Sie auf dem primären SQL Server-Replikat das folgende T-SQL-Skript aus, um einer Verfügbarkeitsgruppe mit dem Namen db1 eine Datenbank mit dem Namen ag1 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;
GO

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 Artikel ausgeführt haben, verfügen Sie über eine AG, die noch nicht gruppiert ist. Der nächste Schritt besteht darin, den Cluster hinzuzufügen. Diese Konfiguration gilt für Szenarien mit Lese-Skalierung und Lastenausgleich, ist aber nicht ausreichend für eine hohe Verfügbarkeit. Für Hochverfügbarkeit müssen Sie die Verfügbarkeitsgruppe als Clusterressource hinzufügen. Anweisungen finden Sie unter Verwandte Inhalte.

Bemerkungen

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 pcsin RHEL oder Ubuntu . Verwenden Sie crm in SLES.

Wenn die AG eine Clusterressource ist, gibt es ein bekanntes Problem in der aktuellen Version, bei dem erzwungenes Failover mit Datenverlust zu einem asynchronen Replikat nicht funktioniert. Dieses Problem wird in einer bevorstehenden Version behoben. Ein manuelles oder automatisches Failover zu einem synchronen Replikat ist erfolgreich.

Verwandte Inhalte

  • Last updated on