Konfigurera en SQL Server-tillgänglighetsgrupp för lässkalning i Linux

gäller för:SQL Server – Linux

Den här artikeln beskriver hur du skapar en SQL Server AlwaysOn-tillgänglighetsgrupp (AG) på Linux utan en klusterhanterare. Den här arkitekturen ger endast skalning för läsning. Det garanterar inte hög tillgänglighet.

Det finns två typer av arkitekturer för AG:er. En arkitektur för hög tillgänglighet använder en klusterhanterare för att ge bättre affärskontinuitet. Information om hur du skapar arkitekturen med hög tillgänglighet finns i Konfigurera SQL Server AlwaysOn-tillgänglighetsgrupp för hög tillgänglighet i Linux.

En tillgänglighetsgrupp med CLUSTER_TYPE = NONE kan innehålla repliker som finns på olika operativsystemplattformar. Den har inte stöd för hög tillgänglighet.

Förutsättningar

Innan du skapar tillgänglighetsgruppen måste du:

• Ange din miljö så att alla servrar som ska vara värdar för tillgänglighetsrepliker kan kommunicera.
• Installera SQL Server.

I Linux måste du skapa en tillgänglighetsgrupp innan du lägger till den som en klusterresurs som ska hanteras av klustret. Det här dokumentet innehåller ett exempel som skapar tillgänglighetsgruppen.

1. Uppdatera datornamnet för varje värd.

   Varje SQL Server-instansnamn måste vara:

   • 15 tecken eller färre.
   • Unikt i nätverket.

   Om du vill ange datornamnet redigerar du /etc/hostname. Med följande skript kan du redigera /etc/hostname med vi:

   sudo vi /etc/hostname
   

2. Konfigurera värdfilen.

   Not

   Om värdnamn registreras med deras IP-adress på DNS-servern behöver du inte utföra följande steg. Kontrollera att alla noder som är avsedda att ingå i konfigurationen av tillgänglighetsgruppen kan kommunicera med varandra. (En ping till värdnamnet ska svara med motsvarande IP-adress.) Kontrollera också att filen /etc/hosts inte innehåller en post som mappar localhost-IP-adressen 127.0.0.1 med nodens värdnamn.

   Värdfilen på varje server innehåller IP-adresser och namn på alla servrar som ska delta i tillgänglighetsgruppen.

   Följande kommando returnerar IP-adressen för den aktuella servern:

   sudo ip addr show
   

   Uppdatera /etc/hosts. Med följande skript kan du redigera /etc/hosts med vi:

   sudo vi /etc/hosts
   

   I följande exempel visas /etc/hosts på node1 med tillägg för node1, node2och node3. I det här exemplet refererar node1 till den server som är värd för den primära repliken och node2 och node3 referera till servrar som är värdar för de sekundära replikerna.

   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
   

Installera SQL Server

Installera SQL Server. Följande länkar pekar på installationsanvisningar för SQL Server för olika distributioner:

• snabbstart: Installera SQL Server och skapa en databas på Red Hat
• snabbstart: Installera SQL Server och skapa en databas på SUSE Linux Enterprise Server
• Snabbstart: Installera SQL Server och skapa en databas på Ubuntu

Aktivera AlwaysOn-tillgänglighetsgrupper

Aktivera AlwaysOn-tillgänglighetsgrupper för varje nod som är värd för en SQL Server-instans och starta sedan om mssql-server. Kör följande skript:

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

Aktivera en händelsesession för AlwaysOn_health

Du kan också aktivera utökade händelser (XE) för att hjälpa till med rotorsaksdiagnos när du felsöker en tillgänglighetsgrupp. Kör följande kommando på varje instans av SQL Server:

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

Mer information om den här XE-sessionen finns i Konfigurera utökade händelser för tillgänglighetsgrupper.

Skapa ett certifikat

SQL Server-tjänsten i Linux använder certifikat för att autentisera kommunikationen mellan speglingsslutpunkterna.

Följande Transact-SQL skript skapar en huvudnyckel och ett certifikat. Sedan säkerhetskopieras certifikatet och filen skyddas med en privat nyckel. Uppdatera skriptet med starka lösenord. Anslut till den primära SQL Server-instansen. Skapa certifikatet genom att köra följande Transact-SQL skript:

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

I det här läget har din primära SQL Server-replik ett certifikat på /var/opt/mssql/data/dbm_certificate.cer och en privat nyckel på var/opt/mssql/data/dbm_certificate.pvk. Kopiera dessa två filer till samma plats på alla servrar som ska vara värdar för tillgänglighetsrepliker. Använd mssql-användaren eller ge behörighet till mssql-användaren för att få åtkomst till dessa filer.

På källservern kopierar till exempel följande kommando filerna till måldatorn. Ersätt <node2> värden med namnen på de SQL Server-instanser som ska vara värd för replikerna.

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

Ge mssql-användaren behörighet att komma åt certifikatet på varje målserver.

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

Skapa certifikatet på sekundära servrar

Följande Transact-SQL skript skapar en huvudnyckel och ett certifikat från säkerhetskopian som du skapade på den primära SQL Server-repliken. Uppdatera skriptet med starka lösenord. Dekrypteringslösenordet är samma lösenord som du använde för att skapa filen .pvk i ett tidigare steg. Skapa certifikatet genom att köra följande skript på alla sekundära servrar:

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

I föregående exempel ersätter du <private-key-password> med samma lösenord som du använde när du skapade certifikatet på den primära repliken.

Skapa databasspeglingsslutpunkter på alla repliker

Databasspeglingsslutpunkter använder TCP (Transmission Control Protocol) för att skicka och ta emot meddelanden mellan de serverinstanser som deltar i databasspeglingssessioner eller repliker för värdtillgänglighet. Databasens speglingsslutpunkt lyssnar på ett unikt TCP-portnummer.

Följande Transact-SQL skript skapar en lyssnande slutpunkt med namnet Hadr_endpoint för tillgänglighetsgruppen. Den startar slutpunkten och ger anslutningsbehörighet till certifikatet som du skapade. Innan du kör skriptet ersätter du värdena mellan < ... >. Du kan också inkludera en IP-adress LISTENER_IP = (0.0.0.0). Lyssnarens IP-adress måste vara en IPv4-adress. Du kan också använda 0.0.0.0.

Uppdatera följande Transact-SQL skript för din miljö på alla SQL Server-instanser:

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;

Not

Om du använder SQL Server Express Edition på en nod som värd för en replik med endast konfiguration är det enda giltiga värdet för ROLEWITNESS. Kör följande skript i SQL Server Express Edition:

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;

TCP-porten i brandväggen måste vara öppen för lyssnarporten.

Viktig

För SQL Server 2017 (14.x) är den enda autentiseringsmetod som stöds för databasens speglingsslutpunkt CERTIFICATE. Alternativet WINDOWS är inte tillgängligt.

Mer information finns i SQL Server(Database Mirroring Endpoint).

Skapa tillgänglighetsgruppen

Skapa AG. Ange CLUSTER_TYPE = NONE. Konfigurera dessutom varje replik med FAILOVER_MODE = MANUAL. Klientprogram som kör analys- eller rapporteringsarbetsbelastningar kan ansluta direkt till de sekundära databaserna. Du kan också skapa en skrivskyddad routningslista. Anslutningar till den primära repliken vidarebefordrar läsanslutningsbegäranden till var och en av de sekundära replikerna från routningslistan på ett resursallokeringssätt.

Följande Transact-SQL-skript skapar en AG med namnet ag1. Skriptet konfigurerar AG-replikerna med SEEDING_MODE = AUTOMATIC. Den här inställningen gör att SQL Server automatiskt skapar databasen på varje sekundär server när den har lagts till i tillgänglighetsgruppen. Uppdatera följande skript för din miljö. Ersätt värdena för <node1> och <node2> med namnen på de SQL Server-instanser som är värdar för replikerna. Ersätt värdet <5022> med den port som du angav för slutpunkten. Kör följande Transact-SQL skript på den primära SQL Server-repliken:

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;

Ansluta sekundära SQL Server-instanser till AG

Följande Transact-SQL-skript lägger till en server till en AG med namnet ag1. Uppdatera skriptet för din miljö. På varje sekundär SQL Server-replik, kör följande Transact-SQL-skript för att ansluta AG:

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

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Lägga till en databas i tillgänglighetsgruppen

Kontrollera att databasen som du lägger till i tillgänglighetsgruppen finns i den fullständiga återställningsmodellen och har en giltig loggsäkerhetskopia. Om databasen är en testdatabas eller en nyligen skapad databas ska du göra en säkerhetskopia av databasen. På den primära SQL Server kör du följande Transact-SQL-skript (T-SQL) för att skapa och säkerhetskopiera en databas med namnet db1:

CREATE DATABASE [db1];
GO

ALTER DATABASE [db1]
    SET RECOVERY FULL;
GO

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

På den primära SQL Server-repliken kör du följande T-SQL-skript för att lägga till en databas med namnet db1 i en tillgänglighetsgrupp med namnet ag1:

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

Kontrollera att databasen har skapats på de sekundära servrarna

På varje sekundär SQL Server-replik kör du följande fråga för att se om db1-databasen skapades och synkroniseras:

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

Den här AG är inte en hög-tillgänglighetskonfiguration. Om du behöver hög tillgänglighet följer du anvisningarna i Konfigurera SQL Server AlwaysOn-tillgänglighetsgrupp för hög tillgänglighet i Linux. Mer specifikt skapar du AG med CLUSTER_TYPE=WSFC (i Windows) eller CLUSTER_TYPE=EXTERNAL (i Linux). Du kan sedan integrera med en klusterhanterare genom att använda antingen Windows Server-redundanskluster i Windows eller Pacemaker i Linux.

Ansluta till skrivskyddade sekundära repliker

Det finns två sätt att ansluta till skrivskyddade sekundära repliker. Program kan ansluta direkt till SQL Server-instansen som är värd för den sekundära repliken och köra frågor mot databaserna. De kan också använda skrivskyddad routning, vilket kräver en lyssnare.

• Avlasta skrivskyddad arbetsbelastning till en sekundär replik av en AlwaysOn-tillgänglighetsgrupp
• skrivskyddad routning

Utför redundansväxling av den primära repliken för en lässkalad tillgänglighetsgrupp

Varje tillgänglighetsgrupp har bara en primär replik. Den primära repliken tillåter läsningar och skrivningar. Om du vill ändra vilken replik som är primär kan du redundansväxla. I en typisk tillgänglighetsgrupp automatiserar klusterhanteraren failover-processen. I en tillgänglighetsgrupp med klustertypen NONE är redundansväxlingsprocessen manuell.

Det finns två sätt att växla över den primära repliken i en tillgänglighetsgrupp med klustertypen NONE.

• Manuell övergång utan dataförlust
• Tvingad manuell omkoppling med dataförlust

Manuell övergång utan dataförlust

Använd den här metoden när den primära repliken är tillgänglig, men du måste tillfälligt eller permanent ändra vilken instans som är värd för den primära repliken. Se till att den sekundära målrepliken är uppdaterad innan du utfärdar den manuella redundansväxlingen för att undvika potentiell dataförlust.

Så här redundansväxlar du manuellt utan dataförlust:

1. Gör den aktuella primära och sekundära målrepliken SYNCHRONOUS_COMMIT.

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

2. Kör följande fråga för att identifiera att aktiva transaktioner har bekräftats till den primära repliken och minst en synkron sekundär replik.

   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; 
   

   Den sekundära repliken synkroniseras när synchronization_state_desc är SYNCHRONIZED.

3. Uppdatera REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT till 1.

   Följande skript anger REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT till 1 i en tillgänglighetsgrupp med namnet ag1. Innan du kör följande skript ersätter du ag1 med namnet på din tillgänglighetsgrupp:

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

   Den här inställningen säkerställer att varje aktiv transaktion committeras till den primära repliken och i minst en synkron sekundär replika.

   Not

   Den här inställningen är inte specifik för redundans och bör anges baserat på miljökraven.

4. Ange den primära repliken och de sekundära repliker som inte deltar i redundansväxlingen offline för att förbereda för rolländringen:

   ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
   

5. Höj upp den sekundära målrepliken till primär.

   ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS; 
   

6. Uppdatera rollen för den gamla primära och andra sekundärfilen till SECONDARY, kör följande kommando på SQL Server-instansen som är värd för den gamla primära repliken:

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

   Not

   Om du vill ta bort en tillgänglighetsgrupp använder du SLÄPP TILLGÄNGLIGHETSGRUPP. För en tillgänglighetsgrupp som skapas med klustertypen NONE eller EXTERNAL kör du kommandot på alla repliker som ingår i tillgänglighetsgruppen.

7. Återuppta dataflytten genom att köra följande kommando för varje databas i tillgänglighetsgruppen på SQL Server-instansen som är värd för den primära repliken:

   ALTER DATABASE [db1]
        SET HADR RESUME
   

8. Återskapa alla lyssnare som du har skapat för läsintensitet och som inte hanteras av en klusterhanterare. Om den ursprungliga lyssnartjänsten pekar på den gamla primära instansen, ta bort den och återskapa den så att den pekar på den nya primära instansen.

Tvingad manuell redundansväxling med dataförlust

Om den primära repliken inte är tillgänglig och inte kan återställas omedelbart måste du tvinga fram en redundansväxling till den sekundära repliken med dataförlust. Men om den ursprungliga primära repliken återställs efter redundansväxlingen, kommer den att anta den primära rollen. För att undvika att varje replik är i ett annat tillstånd, ta bort den ursprungliga primären från tillgänglighetsgruppen efter en tvingad överflyttning med dataförlust. När den ursprungliga primära servern är online igen tar du bort tillgänglighetsgruppen helt och hållet.

Om du vill tvinga fram en manuell redundansväxling med dataförlust från den primära repliken N1 till den sekundära repliken N2 följer du dessa steg:

1. På den sekundära repliken (N2) initierar du den framtvingade redundansväxlingen:

   ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

2. På den nya primära repliken (N2) tar du bort den ursprungliga primära (N1):

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

3. Kontrollera att all programtrafik pekar på lyssnaren och/eller den nya primära repliken.

4. Om den ursprungliga primära (N1) är online tar du omedelbart tillgänglighetsgruppen AGRScale offline på den ursprungliga primära (N1):

   ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
   

5. Om det finns data eller osynkroniserade ändringar bevarar du dessa data via säkerhetskopior eller andra alternativ för datareplikering som passar dina affärsbehov.

6. Ta sedan bort tillgänglighetsgruppen från den ursprungliga primära (N1):

   DROP AVAILABILITY GROUP [AGRScale];
   

7. Ta bort tillgänglighetsgruppdatabasen på den ursprungliga primära repliken (N1)

   USE [master]
   GO
   DROP DATABASE [AGDBRScale]
   GO
   

8. (Valfritt) Om du vill kan du nu lägga till N1 som en ny sekundär replik till tillgänglighetsgruppen AGRScale.

Relaterat innehåll

• Distribuerade tillgänglighetsgrupper
• Vad är en AlwaysOn-tillgänglighetsgrupp?
• Utföra en tvingad manuell överflyttning av en Always On-tillgänglighetsgrupp (SQL Server)