Konfigurera lässkalning för en AlwaysOn-tillgänglighetsgrupp

Artikel
2025-03-15

gäller för:SQL Server

Du kan konfigurera en SQL Server AlwaysOn-tillgänglighetsgrupp för lässkalningsarbetsbelastningar i Windows. Det finns två typer av arkitektur för tillgänglighetsgrupper:

En arkitektur för hög tillgänglighet som använder en klusterhanterare för att ge bättre affärskontinuitet och som kan innehålla läsbara sekundära repliker. Information om hur du skapar den här arkitekturen med hög tillgänglighet finns i Skapa och konfigurera tillgänglighetsgrupper i Windows.
En arkitektur som endast stöder läsbar arbetsbelastning.

Den här artikeln beskriver hur du skapar en tillgänglighetsgrupp utan klusterhanterare för arbetsbelastningar med lässkala. Den här arkitekturen ger endast lässkalning. Det ger inte hög tillgänglighet.

Not

En tillgänglighetsgrupp med CLUSTER_TYPE = NONE kan innehålla repliker som finns på en mängd olika operativsystemplattformar. Det kan inte ha stöd för hög tillgänglighet. För Linux-operativsystemet, se Konfigurera en SQL Server-tillgänglighetsgrupp för lässkalning i Linux.

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. Mer information finns i Installera SQL Server-.

Aktivera AlwaysOn-tillgänglighetsgrupper och starta om mssql-server

Not

Följande kommando använder cmdletar från sqlserver-modulen som publiceras i PowerShell-galleriet. Du kan installera den här modulen med hjälp av kommandot Install-Module.

Aktivera AlwaysOn-tillgänglighetsgrupper på varje replik som är värd för en SQL Server-instans. Starta sedan om SQL Server-tjänsten. Kör följande kommando för att aktivera och starta sedan om SQL Server-tjänsterna:

Enable-SqlAlwaysOn -ServerInstance <server\instance> -Force

Aktivera en AlwaysOn_health evenemangssession

Om du vill hjälpa till med rotorsaksdiagnos när du felsöker en tillgänglighetsgrupp kan du aktivera en XEvents-session (AlwaysOn-tillgänglighetsgrupper för utökade händelser). Det gör du genom att köra följande kommando på varje instans av SQL Server:

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

Mer information om denna XEvents-session finns under Always On tillgänglighetsgrupper med utökade händelser.

Autentisering av slutpunkt för databasspegling

För att synkroniseringen ska fungera korrekt måste de repliker som ingår i tillgänglighetsgruppen för "read-scale" autentiseras via slutpunkten. De två huvudscenarier som du kan använda för sådan autentisering beskrivs i nästa avsnitt.

Tjänstkonto

I en Active Directory-miljö där alla sekundära repliker är anslutna till samma domän kan SQL Server autentisera genom att använda tjänstkontot. Du måste uttryckligen skapa en inloggning för tjänstkontot på varje SQL Server-instans:

CREATE LOGIN [<domain>\service account] FROM WINDOWS;

I miljöer där de sekundära replikerna kanske inte är anslutna till en Active Directory-domän måste du använda SQL-autentisering. Följande Transact-SQL skript skapar en inloggning med namnet dbm_login och en användare med namnet dbm_user. Ersätt <password> med ett giltigt lösenord. Om du vill skapa slutpunktsanvändaren för databasspegling kör du följande kommando på alla SQL Server-instanser.

CREATE LOGIN dbm_login WITH PASSWORD = '<password>';
CREATE USER dbm_user FOR LOGIN dbm_login;

Certifikatautentisering

Om du använder en sekundär replik som kräver autentisering med SQL-autentisering använder du ett certifikat för autentisering 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. Kör skriptet på den primära SQL Server-instansen för att skapa certifikatet:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate
   TO FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.cer'
   WITH PRIVATE KEY (
       FILE = 'c:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\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å c:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.cer och en privat nyckel på c:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.pvk. Kopiera dessa två filer till samma plats på alla servrar som ska vara värdar för tillgänglighetsrepliker.

På varje sekundär replik kontrollerar du att tjänstkontot för SQL Server-instansen har behörighet att komma åt certifikatet.

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. Kommandot tillåter också användare att komma åt certifikatet. Uppdatera skriptet med starka lösenord. Dekrypteringslösenordet är samma lösenord som du använde för att skapa filen .pvk i föregående steg. Skapa certifikatet genom att köra följande skript på alla sekundära repliker:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate
    AUTHORIZATION dbm_user
    FROM FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.cer'
    WITH PRIVATE KEY (
        FILE = 'c:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.pvk',
        DECRYPTION BY PASSWORD = '**<Private_Key_Password>**'
    );

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. Ändpunkten för databasspegling lyssnar på ett unikt TCP-portnummer.

Följande Transact-SQL-skript skapar en slutpunkt för avlyssning namngiven Hadr_endpoint för tillgänglighetsgruppen. Den startar slutpunkten och ger anslutningsbehörighet till tjänstkontot eller SQL-inloggningen som du skapade i ett tidigare steg. 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;
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [<service account or user>];

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

För mer information, se Slutpunkten för databasspegling (SQL Server).

Skapa en tillgänglighetsgrupp

Skapa en tillgänglighetsgrupp. Ange CLUSTER_TYPE = NONE. Ange dessutom varje replik med FAILOVER_MODE = NONE. 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 anslutningsförfrågningar för läsning till var och en av de sekundära replikerna från routningslistan i tur och ordning.

Följande Transact-SQL skript skapar en tillgänglighetsgrupp med namnet ag1. Skriptet konfigurerar tillgänglighetsgruppens repliker 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 tillgänglighetsgruppen

Följande Transact-SQL-skript ansluter en server till en tillgänglighetsgrupp med namnet ag1. Uppdatera skriptet för din miljö. Om du vill ansluta till tillgänglighetsgruppen kör du följande Transact-SQL skript på varje sekundär SQL Server-replik:

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. Om du vill skapa och säkerhetskopiera en databas med namnet db1kör du följande Transact-SQL skript på den primära SQL Server-instansen:

CREATE DATABASE [db1];
ALTER DATABASE [db1] SET RECOVERY FULL;
BACKUP DATABASE [db1]
   TO DISK = N'c:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Backup\db1.bak';

Om du vill lägga till en databas med namnet db1 i en tillgänglighetsgrupp med namnet ag1kör du följande Transact-SQL skript på den primära SQL Server-repliken:

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

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

Om du vill se om db1-databasen har skapats och synkroniserats kör du följande fråga på varje sekundär SQL Server-replik:

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;

Den här tillgänglighetsgruppen är inte en konfiguration med hög tillgänglighet. Om du behöver hög tillgänglighet följer du anvisningarna i Konfigurera en AlwaysOn-tillgänglighetsgrupp för SQL Server i Linux eller Skapa och konfigurera tillgänglighetsgrupper i Windows.

Ansluta till skrivskyddade sekundära repliker

Du kan ansluta till skrivskyddade sekundära repliker på ett av två sätt:

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. För mer information, se läsbara sekundära repliker.
Program kan också använda skrivskyddad routning, vilket kräver en lyssnare. Om du implementerar ett scenario för lässkalning utan en klusterhanterare kan du fortfarande skapa en lyssnare som pekar på IP-adressen till den aktuella primära repliken och samma port som SQL Server använder. Du måste återskapa lyssnaren för att peka på den nya primära IP-adressen efter en redundansväxling. Mer information finns i Endast läsbar routning.

Växla över den primära repliken i en tillgänglighetsgrupp för lässkala

Varje tillgänglighetsgrupp har bara en primär replik. Den primära repliken tillåter läsningar och skrivningar. För att ändra vilken replik som är primär kan du genomföra en failover. 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 redundans utan dataförlust
Tvingad manuell failover med dataförlust

Manuell omkoppling 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 målsekundärrepliken är uppdaterad innan du utför den manuella omställningen för att undvika potentiell dataförlust.

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

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

För att identifiera att aktiva transaktioner har slutförts till den primära replikan och minst en synkron sekundär replik, kör följande fråga:

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.

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 minst en synkron sekundär replik.

Not

Den här inställningen är inte specifik för redundans och bör anges baserat på miljökraven.
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
```

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

ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

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.
Å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
```
Återskapa alla lyssnare som du har skapat för läs-skalning och som inte hanteras av en klusterhanterare. Om den ursprungliga lyssnaren pekar på den gamla primären, ta bort den och återskapa den för att den pekar på den nya primären.

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. Om den ursprungliga primära repliken återhämtar sig efter omkopplingen, kommer den att återta den primära rollen. För att undvika att varje replik hamnar i olika tillstånd, ta bort den ursprungliga primära från tillgänglighetsgruppen efter en tvingad omkoppling med dataförlust. När den ursprungliga primära filen ä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:

På den sekundära repliken (N2) initierar du den framtvingade redundansväxlingen:
```
ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;
```
På den nya primära repliken (N2) tar du bort den ursprungliga primära (N1):
```
ALTER AVAILABILITY GROUP [AGRScale]
REMOVE REPLICA ON N'N1';
```
Kontrollera att all programtrafik pekar på lyssnaren och/eller den nya primära repliken.
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
```
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.
Ta sedan bort tillgänglighetsgruppen från den ursprungliga primära (N1):
```
DROP AVAILABILITY GROUP [AGRScale];
```
Ta bort databasen för tillgänglighetsgruppen på ursprungsprimärreplikan (N1):
```
USE [master]
GO
DROP DATABASE [AGDBRScale]
GO
```
(Valfritt) Om du vill kan du nu lägga till N1 som en ny sekundär replica i tillgänglighetsgruppen AGRScale.

Observera att om du använder en lyssnare för att ansluta måste du återskapa lyssnaren efter att du har gjort överväxlingen.

Dela via