Konfigurieren einer SQL Server-Verfügbarkeitsgruppe für Leseskalierung auf Linux.

Gilt für:SQL Server unter Linux

In diesem Artikel wird das Erstellen von SQL Server-Always On-Verfügbarkeitsgruppen unter Linux ohne einen Cluster-Manager erläutert. Diese Architektur unterstützt ausschließlich die Skalierung von Lesezugriffen. Sie bietet keine Hochverfügbarkeit.

Es gibt zwei Arten von Architekturen für Verfügbarkeitsgruppen. In einer Architektur für Hochverfügbarkeit wird ein Cluster-Manager verwendet, um bessere Geschäftskontinuität bereitzustellen. Informationen zum Erstellen der Hochverfügbarkeitsarchitektur finden Sie unter Konfigurieren SQL Server Verfügbarkeitsgruppe für hohe Verfügbarkeit unter Linux.

Eine Verfügbarkeitsgruppe mit CLUSTER_TYPE = NONE kann Replikate enthalten, die auf verschiedenen Betriebssystemplattformen gehostet werden. Sie kann keine Unterstützung für Hochverfügbarkeit bieten.

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 im Netzwerk

    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.

    Note

    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:

Note

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 Sie die Datenbankspiegelungsendpunkte auf allen Replikaten.

Datenbankspiegelungsendpunkte verwenden das Transmission Control Protocol (TCP), um Nachrichten zwischen den an Datenbankspiegelungssitzungen beteiligten Serverinstanzen oder beim Hosten von Verfügbarkeitsreplikaten zu senden und zu empfangen. 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;

Note

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.

Important

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).

Erstellen der Verfügbarkeitsgruppe

Erstellen Sie die AG. Legen Sie CLUSTER_TYPE = NONE fest. Darüber hinaus konfigurieren Sie jedes Replikat mit FAILOVER_MODE = MANUAL. Clientanwendungen, die Analysen durchführen oder Berichte zu Workloads erstellen, können eine direkte Verbindung mit der sekundären Datenbank herstellen. Sie können auch eine schreibgeschützte Routingliste erstellen. Verbindungen zum primären Replikat leiten Leseverbindungsanforderungen im Round-Robin-Verfahren an die einzelnen sekundären Replikate aus der Routingliste weiter.

Das folgende Transact-SQL-Skript erstellt eine Verfügbarkeitsgruppe mit dem Namen 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, nachdem sie der AG hinzugefügt wurde. Aktualisieren Sie das folgende Skript für Ihre Umgebung. Ersetzen Sie die Werte <node1> und <node2> durch die Namen der SQL Server-Instanzen, auf denen die Replikate gehostet werden. Ersetzen Sie den Wert <5022> durch den Port, den Sie für den Endpunkt festgelegt haben. Führen Sie auf dem primären SQL Server-Replikat das folgende Transact-SQL-Skript aus:

CREATE AVAILABILITY GROUP [ag1]
    WITH (CLUSTER_TYPE = NONE)
    FOR REPLICA ON
        N'<node1>' WITH (
            ENDPOINT_URL = N'tcp://<node1>:<5022>',
            AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC,
                    SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
        ),
        N'<node2>' WITH (
            ENDPOINT_URL = N'tcp://<node2>:<5022>',
            AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC,
            SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
        );

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Sekundäre SQL Server-Instanzen mit der Verfügbarkeitsgruppe verbinden

Das folgende Transact-SQL-Skript verknüpft einen Server mit einer Verfügbarkeitsgruppe mit dem Namen ag1. Aktualisieren Sie das Skript für Ihre Umgebung. Führen Sie das folgende Transact-SQL-Skript auf jedem sekundären SQL Server-Replikat aus, um der AG beizutreten:

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

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 Ihre Datenbank eine Test- oder neu erstellte Datenbank ist, führen Sie eine Datenbanksicherung durch. 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

Diese AG ist keine Hochverfügbarkeitskonfiguration. Wenn Sie hohe Verfügbarkeit benötigen, befolgen Sie die Anweisungen unter Configure SQL Server Verfügbarkeitsgruppe für hohe Verfügbarkeit unter Linux. Erstellen Sie die AG insbesondere mit CLUSTER_TYPE=WSFC (unter Windows) oder CLUSTER_TYPE=EXTERNAL (unter Linux). Sie können anschließend mit einem Clustermanager integrieren, indem Sie entweder Windows Server-Failoverclustering unter Windows oder Pacemaker unter Linux verwenden.

Mit schreibgeschützten sekundären Replikaten verbinden

Es gibt zwei Möglichkeiten, eine Verbindung mit schreibgeschützten sekundären Replikaten herzustellen. Anwendungen können eine direkte Verbindung mit der SQL Server-Instanz herstellen, auf der das sekundäre Replikat gehostet wird, und die Datenbanken abfragen. Sie können auch schreibgeschütztes Routing verwenden, wozu ein Listener erforderlich ist.

Failover des primären Replikats in einer Verfügbarkeitsgruppe für Leseskalierung durchführen

Jede Verfügbarkeitsgruppe hat nur ein primäres Replikat. Das primäre Replikat lässt Lese- und Schreibvorgänge zu. Sie können ein Failover ausführen, um das primäre Replikat zu ändern. In einer typischen Verfügbarkeitsgruppe automatisiert der Cluster-Manager den Failoverprozess. In einer Verfügbarkeitsgruppe mit dem Clustertyp „NONE“ erfolgt der Failovervorgang manuell.

Es gibt zwei Möglichkeiten, ein Failover für ein primäres Replikat in einer Verfügbarkeitsgruppe mit dem Clustertyp „NONE“ auszuführen:

  • Manuelles Failover ohne Datenverlust
  • Erzwungenes manuelles Failover mit Datenverlust

Manuelles Failover ohne Datenverlust

Verwenden Sie diese Methode, wenn das primäre Replikat verfügbar ist. Dabei müssen Sie allerdings vorübergehend oder dauerhaft ändern, welche Instanz das primäre Replikat hostet. Um potenzielle Datenverluste zu vermeiden, stellen Sie vor der Ausführung eines manuellen Failovers sicher, dass das sekundäre Zielreplikat aktuell ist.

Um ein manuelles Failover ohne Datenverlust auszuführen:

  1. Verwenden Sie SYNCHRONOUS_COMMIT für das aktuelle primäre Replikat und das sekundäre Zielreplikat.

    ALTER AVAILABILITY GROUP [AGRScale] 
     MODIFY REPLICA ON N'<node2>' 
     WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

  2. Um zu ermitteln, ob aktive Transaktionen auf das primäre Replikat und mindestens ein synchrones sekundäres Replikat übertragen werden, führen Sie die folgende Abfrage aus:

    SELECT ag.name, 
   drs.database_id, 
   drs.group_id, 
   drs.replica_id, 
   drs.synchronization_state_desc, 
   ag.sequence_number
FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups ag
WHERE drs.group_id = ag.group_id;

    Das sekundäre Replikat wird synchronisiert, wenn synchronization_state_descSYNCHRONIZED ist.

  3. Aktualisieren Sie REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf 1.

    Das folgende Skript legt REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf „1“ für eine Verfügbarkeitsgruppe mit dem Namen ag1 fest. Ersetzen Sie ag1 vor der Ausführung des Skripts durch den Namen Ihrer Verfügbarkeitsgruppe:

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);

    Diese Einstellung stellt sicher, dass für jede aktive Transaktion ein Commit auf das primäre Replikat und auf mindestens ein synchrones sekundäres Replikat ausgeführt wurde.

    Note

    Diese Einstellung ist nicht failoverspezifisch und sollte anhand der Umgebungsanforderungen festgelegt werden.

  4. Legen Sie zur Vorbereitung auf die Rollenänderung das primäre Replikat und die sekundären Replikate, die nicht am Failover beteiligt sind, offline fest:

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Stufen Sie das sekundäre Zielreplikat auf ein primäres hoch.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

  6. Aktualisieren Sie die Rolle des alten primären Replikats und weiterer sekundärer Replikate auf SECONDARY, und führen Sie den folgenden Befehl auf der SQL Server-Instanz aus, die das alte primäre Replikat hostet:

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (ROLE = SECONDARY);

    Note

    Um eine Verfügbarkeitsgruppe zu löschen, verwenden Sie DROP AVAILABILITY GROUP. Führen Sie bei Verfügbarkeitsgruppen, die mit dem Clustertyp „NONE“ oder „EXTERNAL“ erstellt wurden, den Befehl für alle Replikate aus, die der Verfügbarkeitsgruppe angehören.

  7. Setzen Sie die Datenverschiebung fort, und führen Sie folgenden Befehl für jede Datenbank in der Verfügbarkeitsgruppe auf der SQL Server-Instanz aus, die das primäre Replikat hostet:

    ALTER DATABASE [db1]
     SET HADR RESUME

  8. Erstellen Sie jeden Listener neu, den Sie für Leseskalierungszwecke erstellt haben und der nicht von einem Cluster-Manager verwaltet wird. Wenn der ursprüngliche Listener auf das alte primäre Replikat zeigt, löschen Sie ihn, und erstellen Sie ihn neu, um auf das neue primäre Replikat zu verweisen.

Erzwungenes manuelles Failover mit Datenverlust

Wenn das primäre Replikat nicht verfügbar ist und nicht sofort wieder hergestellt werden kann, müssen Sie ein Failover auf das sekundäre Replikat mit Datenverlust erzwingen. Wenn das ursprüngliche primäre Replikat sich jedoch nach einem Failover erholt, übernimmt es wieder die primäre Rolle. Um zu vermeiden, dass jedes Replikat einen anderen Zustand aufweist, entfernen Sie das ursprüngliche primäre Replikat nach einem erzwungenen Failover mit Datenverlust aus der Verfügbarkeitsgruppe. Sobald die ursprüngliche primäre Instanz wieder online ist, entfernen Sie die Verfügbarkeitsgruppe vollständig.

Gehen Sie folgendermaßen vor, um ein manuelles Failover mit Datenverlust vom primären Replikat N1 zum sekundären Replikat N2 zu erzwingen:

  1. Initiieren Sie auf dem sekundären Replikat (N2) das erzwungene Failover:

    ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;

  2. Entfernen Sie auf dem neuen primären Replikat (N2) das ursprüngliche primäre Replikat (N1):

    ALTER AVAILABILITY GROUP [AGRScale]
REMOVE REPLICA ON N'N1';

  3. Überprüfen Sie, ob der gesamte Anwendungsdatenverkehr auf den Listener und/oder das neue primäre Replikat verweist.

  4. Wenn das ursprüngliche primäre Replikat (N1) online geschaltet wird, nehmen Sie die Verfügbarkeitsgruppe „AGRScale“ auf dem ursprünglichen primären Replikat (N1) offline.

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Wenn Daten oder nicht synchronisierte Änderungen vorhanden sind, behalten Sie diese Datei über Sicherungskopien oder andere Datenreplikationsoptionen bei, die Ihren Geschäftsanforderungen entsprechen.

  6. Entfernen Sie als Nächstes die Verfügbarkeitsgruppe aus der ursprünglichen primären Datenbank (N1):

    DROP AVAILABILITY GROUP [AGRScale];

  7. Löschen Sie die Datenbank der Verfügbarkeitsgruppe auf dem ursprünglichen primären Replikat (N1):

    USE [master]
GO
DROP DATABASE [AGDBRScale]
GO

  8. (Optional) Sie können, wenn gewünscht, N1 jetzt wieder als neues sekundäres Replikat der Verfügbarkeitsgruppe „AGRScale“ hinzufügen.

Verwandte Inhalte

  • Last updated on