Een SQL Server-beschikbaarheidsgroep configureren voor leesschaal in Linux

van toepassing op:SQL Server- - Linux

In dit artikel wordt uitgelegd hoe u een SQL Server AlwaysOn-beschikbaarheidsgroep (AG) maakt op Linux-zonder een clusterbeheerder. Deze architectuur biedt alleen lezen schaalbaarheid. Het biedt geen hoge beschikbaarheid.

Er zijn twee soorten architecturen voor AG's. Een architectuur voor hoge beschikbaarheid maakt gebruik van een clusterbeheer om een verbeterde bedrijfscontinuïteit te bieden. Zie Sql Server AlwaysOn-beschikbaarheidsgroep configureren voor hoge beschikbaarheid op Linuxom de architectuur met hoge beschikbaarheid te maken.

Een beschikbaarheidsgroep met CLUSTER_TYPE = NONE kan replica's bevatten die worden gehost op verschillende besturingssysteemplatforms. Het biedt geen ondersteuning voor hoge beschikbaarheid.

Voorwaarden

Voordat u de beschikbaarheidsgroep maakt, moet u het volgende doen:

• Stel uw omgeving zo in dat alle servers waarop beschikbaarheidsreplica's worden gehost, kunnen communiceren.
• Installeer SQL Server.

In Linux moet u een beschikbaarheidsgroep maken voordat u deze toevoegt als clusterresource die door het cluster moet worden beheerd. Dit document bevat een voorbeeld waarmee de beschikbaarheidsgroep wordt gemaakt.

1. Werk de computernaam voor elke host bij.

   De naam van elk SQL Server-exemplaar moet zijn:

   • 15 tekens of minder.
   • Uniek binnen het netwerk.

   Als u de computernaam wilt instellen, moet u /etc/hostnamebewerken. Met het volgende script kunt u /etc/hostname bewerken met vi-:

   sudo vi /etc/hostname
   

2. Configureer het hosts-bestand.

   Notitie

   Als hostnamen zijn geregistreerd bij hun IP-adres op de DNS-server, hoeft u de volgende stappen niet uit te voeren. Controleer of alle knooppunten die deel uitmaken van de configuratie van de beschikbaarheidsgroep met elkaar kunnen communiceren. (Een ping naar de hostnaam moet reageren met het bijbehorende IP-adres.) Zorg er ook voor dat het /etc/hosts-bestand geen record bevat waarmee het LOCALHOST-IP-adres 127.0.0.1 wordt toegewezen aan de hostnaam van het knooppunt.

   Het hosts-bestand op elke server bevat de IP-adressen en namen van alle servers die deelnemen aan de beschikbaarheidsgroep.

   Met de volgende opdracht wordt het IP-adres van de huidige server geretourneerd:

   sudo ip addr show
   

   Werk /etc/hostsbij. Met het volgende script kunt u /etc/hosts bewerken met vi-:

   sudo vi /etc/hosts
   

   In het volgende voorbeeld ziet u /etc/hosts op node1 met toevoegingen voor node1, node2en node3. In dit voorbeeld verwijst node1 naar de server die als host fungeert voor de primaire replica, en node2 en node3 verwijzen naar servers waarop de secundaire replica's worden gehost.

   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
   

SQL Server installeren

Installeer SQL Server. De volgende koppelingen verwijzen naar sql Server-installatie-instructies voor verschillende distributies:

• quickstart: SQL Server installeren en een database maken op Red Hat
• quickstart: SQL Server installeren en een database maken op SUSE Linux Enterprise Server
• quickstart: SQL Server installeren en een database maken op Ubuntu

AlwaysOn-beschikbaarheidsgroepen inschakelen

Schakel AlwaysOn-beschikbaarheidsgroepen in voor elk knooppunt dat als host fungeert voor een SQL Server-exemplaar en start mssql-serveropnieuw op. Voer het volgende script uit:

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

Een AlwaysOn_health-gebeurtenissessie inschakelen

U kunt eventueel uitgebreide gebeurtenissen (XE) inschakelen om te helpen bij de diagnose van de hoofdoorzaak wanneer u problemen met een beschikbaarheidsgroep oplost. Voer de volgende opdracht uit op elk exemplaar van SQL Server:

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

Zie Uitgebreide gebeurtenissen configureren voor beschikbaarheidsgroepenvoor meer informatie over deze XE-sessie.

Een certificaat maken

De SQL Server-service in Linux gebruikt certificaten om communicatie tussen de mirroring-eindpunten te verifiëren.

Met het volgende Transact-SQL script maakt u een hoofdsleutel en een certificaat. Vervolgens wordt een back-up van het certificaat gemaakt en wordt het bestand beveiligd met een persoonlijke sleutel. Werk het script bij met sterke wachtwoorden. Maak verbinding met het primaire SQL Server-exemplaar. Voer het volgende Transact-SQL script uit om het certificaat te maken:

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

Op dit moment heeft uw primaire SQL Server-replica een certificaat op /var/opt/mssql/data/dbm_certificate.cer en een persoonlijke sleutel op var/opt/mssql/data/dbm_certificate.pvk. Kopieer deze twee bestanden naar dezelfde locatie op alle servers waarop beschikbaarheidsreplica's worden gehost. Gebruik de mssql-gebruiker of geef toestemming aan de mssql-gebruiker om toegang te krijgen tot deze bestanden.

Op de bronserver kopieert de volgende opdracht bijvoorbeeld de bestanden naar de doelcomputer. Vervang de <node2>-waarden door de namen van de SQL Server-exemplaren die de replica's hosten.

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

Geef op elke doelserver toestemming aan de mssql-gebruiker om toegang te krijgen tot het certificaat.

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

Het certificaat maken op secundaire servers

Met het volgende Transact-SQL script maakt u een hoofdsleutel en een certificaat op basis van de back-up die u hebt gemaakt op de primaire SQL Server-replica. Werk het script bij met sterke wachtwoorden. Het ontsleutelingswachtwoord is hetzelfde wachtwoord dat u in een vorige stap hebt gebruikt om het .pvk-bestand te maken. Voer het volgende script uit op alle secundaire servers om het certificaat te maken:

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

Vervang in het vorige voorbeeld <private-key-password> door hetzelfde wachtwoord dat u hebt gebruikt bij het maken van het certificaat op de primaire replica.

De eindpunten voor databasespiegeling maken op alle replica's

Eindpunten voor databasespiegeling gebruiken TCP (Transmission Control Protocol) om berichten te verzenden en te ontvangen tussen de serverinstanties die deelnemen aan database-spiegelingssessies of beschikbaarheidsreplica's hosten. Het eindpunt voor databasespiegeling luistert op een uniek TCP-poortnummer.

Met het volgende Transact-SQL script maakt u een luistereindpunt met de naam Hadr_endpoint voor de beschikbaarheidsgroep. Hiermee wordt het eindpunt gestart en wordt verbinding verleend met het certificaat dat u hebt gemaakt. Voordat u het script uitvoert, vervangt u de waarden tussen < ... >. U kunt eventueel een IP-adres opnemen LISTENER_IP = (0.0.0.0). Het IP-adres van de listener moet een IPv4-adres zijn. U kunt ook 0.0.0.0gebruiken.

Werk het volgende Transact-SQL script voor uw omgeving bij op alle SQL Server-exemplaren:

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;

Notitie

Als u SQL Server Express-editie op één knooppunt gebruikt om een replica met alleen configuraties te hosten, is de enige geldige waarde voor ROLEWITNESS. Voer het volgende script uit op de SQL Server Express-editie:

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;

De TCP-poort op de firewall moet zijn geopend voor de listenerpoort.

Belangrijk

Voor SQL Server 2017 (14.x) is de enige verificatiemethode die wordt ondersteund voor het eindpunt voor databasespiegeling CERTIFICATE. De optie WINDOWS is niet beschikbaar.

Zie Het eindpunt voor databasespiegeling (SQL Server)voor meer informatie.

De beschikbaarheidsgroep maken

Maak de beschikbaarheidsgroep. Stel CLUSTER_TYPE = NONEin. Stel bovendien elke replica in met FAILOVER_MODE = MANUAL. Clienttoepassingen waarop analyse- of rapportageworkloads worden uitgevoerd, kunnen rechtstreeks verbinding maken met de secundaire databases. U kunt ook een alleen-lezen routeringslijst maken. Verbindingen met de primaire replica sturen verbindingsaanvragen door naar elk van de secundaire replica's vanuit de routeringslijst op round robin-wijze.

Met het volgende Transact-SQL script wordt een AG met de naam ag1gemaakt. Het script configureert de AG-replica's met SEEDING_MODE = AUTOMATIC. Deze instelling zorgt ervoor dat SQL Server automatisch de database op elke secundaire server maakt nadat deze is toegevoegd aan de beschikbaarheidsgroep. Werk het volgende script voor uw omgeving bij. Vervang de waarden van de <node1> en <node2> door de namen van de SQL Server-exemplaren die als host fungeren voor de replica's. Vervang de <5022>-waarde door de poort die u voor het eindpunt hebt ingesteld. Voer het volgende Transact-SQL script uit op de primaire SQL Server-replica:

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;

Secundaire SQL Server-exemplaren toevoegen aan de AG

Met het volgende Transact-SQL script wordt een server gekoppeld aan een ag met de naam ag1. Werk het script voor uw omgeving bij. Voer op elke secundaire SQL Server-replica het volgende Transact-SQL script uit om lid te worden van de AG:

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

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Een database toevoegen aan de beschikbaarheidsgroep

Zorg ervoor dat de database die u toevoegt aan de beschikbaarheidsgroep zich in het volledige herstelmodel bevindt en een geldige logboekback-up heeft. Als uw database een testdatabase of een zojuist gemaakte database is, maakt u een back-up van de database. Voer op de primaire SQL Server het volgende Transact-SQL (T-SQL)-script uit om een database met de naam db1te maken en er een back-up van te maken:

CREATE DATABASE [db1];
GO

ALTER DATABASE [db1]
    SET RECOVERY FULL;
GO

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

Voer op de primaire SQL Server-replica het volgende T-SQL-script uit om een database met de naam db1 toe te voegen aan een beschikbaarheidsgroep met de naam ag1:

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

Controleer of de database is gemaakt op de secundaire servers

Voer op elke secundaire SQL Server-replica de volgende query uit om te zien of de db1 database is gemaakt en wordt gesynchroniseerd:

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

Deze AG is geen configuratie met hoge beschikbaarheid. Als u hoge beschikbaarheid nodig hebt, volgt u de instructies in SQL Server AlwaysOn-beschikbaarheidsgroep configureren voor hoge beschikbaarheid op Linux. Maak specifiek de BG met CLUSTER_TYPE=WSFC (in Windows) of CLUSTER_TYPE=EXTERNAL (in Linux). U kunt vervolgens integreren met een clusterbeheerder met behulp van Windows Server-failoverclustering in Windows of Pacemaker op Linux.

Verbinding maken met secundaire replica's in alleen-lezen-modus

Er zijn twee manieren om verbinding te maken met read-only secundaire kopieën. Toepassingen kunnen rechtstreeks verbinding maken met het SQL Server-exemplaar dat als host fungeert voor de secundaire replica en query's uitvoeren op de databases. Ze kunnen ook alleen-lezenroutering gebruiken, waarvoor een listener is vereist.

• Alleen-lezen workload overdragen naar de secundaire replica van een Always On-beschikbaarheidsgroep
• alleen-lezentoegang

Failover van de primaire replica op een beschikbaarheidsgroep met leesschaal

Elke beschikbaarheidsgroep heeft slechts één primaire replica. De primaire replica staat lees- en schrijfbewerkingen toe. Als u wilt wijzigen welke replica primair is, kunt u een failover uitvoeren. In een typische beschikbaarheidsgroep automatiseert de clusterbeheerder het failoverproces. In een beschikbaarheidsgroep met clustertype NONE is het failoverproces handmatig.

Er zijn twee manieren om een failover uit te voeren voor de primaire replica in een beschikbaarheidsgroep met clustertype NONE:

• Handmatige failover zonder gegevensverlies
• Geforceerde handmatige failover met gegevensverlies

Handmatige failover zonder gegevensverlies

Gebruik deze methode wanneer de primaire replica beschikbaar is, maar u moet tijdelijk of permanent wijzigen welk exemplaar als host fungeert voor de primaire replica. Als u mogelijk gegevensverlies wilt voorkomen, moet u ervoor zorgen dat de secundaire doelreplica up-to-date is voordat u de handmatige failover uitvoert.

Handmatig een failover uitvoeren zonder gegevensverlies:

1. Maak de huidige primaire en doelsecondaire replica SYNCHRONOUS_COMMIT.

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

2. Voer de volgende query uit om te bepalen dat actieve transacties worden doorgevoerd in de primaire replica en ten minste één synchrone secundaire replica:

   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; 
   

   De secundaire replica wordt gesynchroniseerd wanneer synchronization_state_desc is SYNCHRONIZED.

3. Werk REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT bij naar 1.

   Met het volgende script wordt REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT ingesteld op 1 op een beschikbaarheidsgroep met de naam ag1. Voordat u het volgende script uitvoert, vervangt u ag1 door de naam van uw beschikbaarheidsgroep:

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

   Deze instelling zorgt ervoor dat elke actieve transactie wordt doorgevoerd in de primaire replica en ten minste één synchrone secundaire replica.

   Notitie

   Deze instelling is niet specifiek voor failover en moet worden ingesteld op basis van de vereisten van de omgeving.

4. Stel de primaire replica en de secundaire replica('s) die niet deelnemen aan de failover offline in om de rolwisseling voor te bereiden:

   ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
   

5. Niveau verhogen van de secundaire doelreplica naar primair.

   ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS; 
   

6. Werk de rol van de oude primaire en andere secundaire databases bij naar SECONDARYen voer de volgende opdracht uit op het SQL Server-exemplaar dat als host fungeert voor de oude primaire replica:

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

   Notitie

   Als u een beschikbaarheidsgroep wilt verwijderen, gebruikt u DROP AVAILABILITY GROUP. Voor een beschikbaarheidsgroep die is gemaakt met clustertype NONE of EXTERNAL, voert u de opdracht uit op alle replica's die deel uitmaken van de beschikbaarheidsgroep.

7. Hervat gegevensverplaatsing, voer de volgende opdracht uit voor elke database in de beschikbaarheidsgroep op het SQL Server-exemplaar dat als host fungeert voor de primaire replica:

   ALTER DATABASE [db1]
        SET HADR RESUME
   

8. Hermaak een listener die u hebt gemaakt voor leesschaaldoeleinden en die niet wordt beheerd door een clusterbeheerder. Als de oorspronkelijke luisteraar naar de oude primaire verwijst, verwijdert en hercreëert u deze zodat deze naar de nieuwe primaire verwijst.

Geforceerde handmatige failover met gegevensverlies

Als de primaire replica niet beschikbaar is en niet onmiddellijk kan worden hersteld, moet u een failover naar de secundaire replica afdwingen met gegevensverlies. Als de oorspronkelijke primaire replica echter na een failover is hersteld, neemt deze weer de primaire rol op zich. Als u wilt voorkomen dat elke replica een andere status heeft, verwijdert u de oorspronkelijke primaire replica uit de beschikbaarheidsgroep na een geforceerde failover met gegevensverlies. Zodra de oorspronkelijke primaire versie weer online is, verwijdert u de beschikbaarheidsgroep volledig.

Als u een handmatige failover wilt afdwingen met gegevensverlies van primaire replica N1 naar secundaire replica N2, voert u de volgende stappen uit:

1. Start op de secundaire replica (N2) de geforceerde failover:

   ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

2. Verwijder op de nieuwe primaire replica (N2) de oorspronkelijke primaire replica (N1):

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

3. Controleer of al het toepassingsverkeer naar de listener en/of de nieuwe primaire replica wijst.

4. Als de oorspronkelijke primaire (N1) online komt, zet u de beschikbaarheidsgroep AGRScale onmiddellijk offline op de oorspronkelijke primaire (N1).

   ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
   

5. Als er gegevens of niet-gesynchroniseerde wijzigingen zijn, behoudt u deze gegevens via back-ups of andere opties voor het repliceren van gegevens die aansluiten bij uw zakelijke behoeften.

6. Verwijder vervolgens de beschikbaarheidsgroep uit de oorspronkelijke primaire groep (N1):

   DROP AVAILABILITY GROUP [AGRScale];
   

7. Verwijder de database van de beschikbaarheidsgroep op de oorspronkelijke primaire replica (N1):

   USE [master]
   GO
   DROP DATABASE [AGDBRScale]
   GO
   

8. (Optioneel) Desgewenst kunt u N1 weer toevoegen als een nieuwe secundaire replica aan de beschikbaarheidsgroep AGRScale.

Verwante inhoud

• gedistribueerde beschikbaarheidsgroepen
• Wat is een AlwaysOn-beschikbaarheidsgroep?
• een geforceerde handmatige failover uitvoeren van een AlwaysOn-beschikbaarheidsgroep (SQL Server)