Freigeben über

Konfigurieren einer SQL Server-Verfügbarkeitsgruppe zur Leseskalierung unter Linux

  • Artikel

Gilt für: SQL Server – Linux

In diesem Artikel wird das Erstellen von SQL Server-Always On-Verfügbarkeitsgruppen unter Linux ohne einen Cluster-Manager erläutert. Diese Architektur bietet nur Leseskalierung. Sie bietet keine Hochverfügbarkeit.

Für Verfügbarkeitsgruppen gibt es zwei Architekturtypen. In einer Architektur für Hochverfügbarkeit wird ein Cluster-Manager verwendet, um bessere Geschäftskontinuität bereitzustellen. Informationen dazu, wie die Architektur für Hochverfügbarkeit erstellt wird, finden Sie unter Konfigurieren von SQL Server-Always On-Verfügbarkeitsgruppen für Hochverfü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

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.

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.

  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. 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 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 (14.x) ist CERTIFICATE die einzige unterstützte Authentifizierungsmethode für den Datenbankspiegelungs-Endpunkt. Die Option WINDOWS ist nicht verfügbar.

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

Erstellen der Verfügbarkeitsgruppe

Erstellen Sie die Verfügbarkeitsgruppe. Legen Sie CLUSTER_TYPE = NONE fest. Darüber hinaus sollten Sie jedes Replikat mit FAILOVER_MODE = MANUAL festlegen. 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. Anforderungen zum Lesen der Verbindung werden dann über Verbindungen mit dem primären Replikat in Round-Robin-Manier an jedes der in der Routingliste enthaltene sekundäre Replikat weitergeleitet.

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 diese der Verfügbarkeitsgruppe 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;

Verknüpfen sekundärer SQL-Serverinstanzen mit der Verfügbarkeitsgruppe

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 auf jedem sekundären SQL Server-Replikat das folgende Transact-SQL-Skript aus, um die Verfügbarkeitsgruppe zu verknüpfen:

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 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 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;
GO

Bei dieser Verfügbarkeitsgruppe handelt es sich um keine Hochverfügbarkeitskonfiguration. Wenn Sie Hochverfügbarkeit benötigen, befolgen Sie die Anweisungen unter Konfigurieren einer Always On-Verfügbarkeitsgruppe von SQL Server für hohe Verfügbarkeit auf Linux. Insbesondere ist zu beachten, dass die Verfügbarkeitsgruppe mit CLUSTER_TYPE=WSFC (unter Windows) oder CLUSTER_TYPE=EXTERNAL (unter Linux) erstellt werden muss. Sie können die Verfügbarkeitsgruppe anschließend in einen Cluster-Manager integrieren, indem Sie entweder Windows Server-Failoverclustering unter Windows oder Pacemaker unter Linux verwenden.

Verbinden mit schreibgeschützten sekundären Replikaten

Es gibt zwei Möglichkeiten für die Verbindung mit schreibgeschützten sekundären Replikaten. 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, wofür ein Listener erforderlich ist.

Ausführen eines Failovers des primären Replikats in einer schreibgeschützten Verfügbarkeitsgruppe

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.

So führen ein manuelles Failover ohne Datenverlust aus:

  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 für aktive Transaktionen ein Commit auf das primäre Replikat und gleichzeitig auf mindestens ein synchrones sekundäres Replikat ausgeführt wurde, 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.

    Hinweis

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

    Hinweis

    Verwenden Sie DROP AVAILABILITY GROUP (Verfügbarkeitsgruppe löschen), um eine Verfügbarkeitsgruppe zu löschen. 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 jedoch nach einem Failover wieder hergestellt wird, nimmt es die primäre Rolle an. 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. Wenn das ursprüngliche primäre Replikat 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, schalten Sie die Verfügbarkeitsgruppe „AGRScale“ auf der ursprünglichen primären Datenbank (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.

Zugehöriger Inhalt