Konfigurera SQL Server AlwaysOn-tillgänglighetsgrupp i Windows och Linux (plattformsoberoende)

gäller för: SQL Server 2017 (14.x) och senare

I den här artikeln beskrivs stegen för att skapa en AlwaysOn-tillgänglighetsgrupp (AG) med en replik på en Windows-server och den andra repliken på en Linux-server.

Den här konfigurationen är plattformsoberoende eftersom replikerna finns på olika operativsystem. Använd den här konfigurationen för migrering från en plattform till en annan eller återställning vid katastrof. Den här konfigurationen stöder inte hög tillgänglighet.

Innan du fortsätter bör du känna till installation och konfiguration för SQL Server-instanser i Windows och Linux.

Scenario

I det här scenariot finns två servrar på olika operativsystem. En Windows Server 2022 med namnet WinSQLInstance är värd för den primära repliken. En Linux-server som heter LinuxSQLInstance är värd för den sekundära repliken.

Konfigurera AG

Stegen för att skapa en tillgänglighetsgrupp är desamma som stegen för att skapa en tillgänglighetsgrupp för lässkalningsarbetsbelastningar. Ag-klustertypen är NONE eftersom det inte finns någon klusterhanterare.

För skripten i den här artikeln indikerar vinkelparenteserna < och > värden som du måste ersätta i din miljö. Själva vinkelparenteserna krävs inte för skripten.

1. Installera SQL Server 2022 (16.x) på Windows Server 2022, aktivera AlwaysOn-tillgänglighetsgrupper från SQL Server Configuration Manager och ange autentisering i blandat läge.

   Tips

   Om du verifierar den här lösningen i Azure placerar du båda servrarna i samma tillgänglighetsuppsättning för att säkerställa att de är avgränsade i datacentret.

   Aktivera tillgänglighetsgrupper

   Anvisningar finns i Aktivera eller inaktivera Always On-tillgänglighetsgruppsfunktionen.

   

   SQL Server Configuration Manager noterar att datorn inte är en nod i ett redundanskluster.

   När du har aktiverat tillgänglighetsgrupper startar du om SQL Server.

   Ange autentisering i blandat läge

   Anvisningar finns i Ändra serverautentiseringsläge.

2. Installera SQL Server 2022 (16.x) på Linux. Anvisningar finns i Installationsvägledning för SQL Server på Linux. Aktivera hadr med mssql-conf.

   Om du vill aktivera hadr via mssql-conf från en kommandotolk utfärdar du följande kommando:

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

   När du har aktiverat hadrstartar du om SQL Server-instansen:

   sudo systemctl restart mssql-server.service
   

3. Konfigurera hosts-filen på båda servrarna eller registrera servernamnen med DNS.

4. Öppna brandväggsportar för TCP 1433 och 5022 i både Windows och Linux.

5. På den primära repliken skapar du en databasinloggning och ett lösenord.

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

   Försiktighet

   Lösenordet bör följa SQL Server-standardprincipen för lösenord. Lösenordet måste som standard vara minst åtta tecken långt och innehålla tecken från tre av följande fyra uppsättningar: versaler, gemener, bas-10 siffror och symboler. Lösenord kan vara upp till 128 tecken långa. Använd lösenord som är så långa och komplexa som möjligt.

6. På den primära repliken skapar du en huvudnyckel och ett certifikat och säkerhetskopierar sedan certifikatet med en privat nyckel.

   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\MSSQL16.MSSQLSERVER\MSSQL\DATA\dbm_certificate.cer'
       WITH PRIVATE KEY (
            FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\dbm_certificate.pvk',
            ENCRYPTION BY PASSWORD = '<private-key-password>'
   );
   GO
   

   Försiktighet

   Lösenordet bör följa SQL Server-standardprincipen för lösenord. Lösenordet måste som standard vara minst åtta tecken långt och innehålla tecken från tre av följande fyra uppsättningar: versaler, gemener, bas-10 siffror och symboler. Lösenord kan vara upp till 128 tecken långa. Använd lösenord som är så långa och komplexa som möjligt.

7. Kopiera certifikatet och den privata nyckeln till Linux-servern (sekundär replik) på /var/opt/mssql/data. Du kan använda pscp för att kopiera filerna till Linux-servern.

8. Ange gruppen och ägarskapet för den privata nyckeln och certifikatet till mssql:mssql.

   Följande skript anger gruppen och ägarskapet för filerna.

   sudo chown mssql:mssql /var/opt/mssql/data/dbm_certificate.pvk
   sudo chown mssql:mssql /var/opt/mssql/data/dbm_certificate.cer
   

   I följande diagram anges ägarskap och grupp korrekt för certifikatet och nyckeln.

   

9. På den sekundära repliken skapar du en databasinloggning och ett lösenord och skapar en huvudnyckel.

   CREATE LOGIN dbm_login
       WITH PASSWORD = '<password>';
   
   CREATE USER dbm_user FOR LOGIN dbm_login;
   GO
   
   CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
   GO
   

   Försiktighet

   Lösenordet bör följa SQL Server-standardprincipen för lösenord. Lösenordet måste som standard vara minst åtta tecken långt och innehålla tecken från tre av följande fyra uppsättningar: versaler, gemener, bas-10 siffror och symboler. Lösenord kan vara upp till 128 tecken långa. Använd lösenord som är så långa och komplexa som möjligt.

10. På den sekundära repliken återställer du certifikatet som du kopierade till /var/opt/mssql/data.

    CREATE CERTIFICATE dbm_certificate
        AUTHORIZATION dbm_user
        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>'
    );
    GO
    

    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.

11. Skapa en slutpunkt på den primära repliken.

    CREATE ENDPOINT [Hadr_endpoint]
        AS TCP
    (
                LISTENER_IP = (0.0.0.0),
                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 [dbm_login];
    GO
    

    Viktig

    Brandväggen måste vara öppen för lyssnarens TCP-port. I föregående skript är porten 5022. Använd valfri tillgänglig TCP-port.

12. Skapa slutpunkten på den sekundära repliken. Upprepa föregående skript på den sekundära repliken för att skapa slutpunkten.

13. På den primära repliken skapar du tillgänglighetsgruppen med CLUSTER_TYPE = NONE. Exempelskriptet använder SEEDING_MODE = AUTOMATIC för att skapa AG.

    Anmärkning

    När Windows-instansen av SQL Server använder olika sökvägar för data och loggfiler misslyckas automatisk seeding till Linux-instansen av SQL Server, eftersom dessa sökvägar inte finns på den sekundära repliken. Om du vill använda följande skript för en plattformsoberoende tillgänglighetsgrupp kräver databasen samma sökväg för data och loggfiler på Windows-servern. Alternativt kan du uppdatera skriptet för att ställa in SEEDING_MODE = MANUAL och sedan säkerhetskopiera och återställa databasen med NORECOVERY för att initiera databasen.

    Det här beteendet gäller för Azure Marketplace-avbildningar.

    Mer information om automatisk seeding finns i Automatisk seeding – disklayout.

    Innan du kör skriptet uppdaterar du värdena för dina AG:er.

    • Ersätt <WinSQLInstance> med servernamnet för sql server-instansen för den primära repliken.

    • Ersätt <LinuxSQLInstance> med servernamnet för den sekundära SQL Server-replikinstansen.

    För att skapa AG, uppdatera värdena och kör skriptet på den primära repliken.

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

    Mer information finns i CREATE AVAILABILITY GROUP.

14. På den sekundära repliken ansluter du till tillgänglighetsgruppen.

    ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = NONE);
    ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
    GO
    

15. Skapa en databas för AG. I exempelstegen används en databas med namnet TestDB. Om du använder automatisk seeding anger du samma sökväg för både data och loggfilerna.

    Innan du kör skriptet uppdaterar du värdena för databasen.

    • Ersätt TestDB med namnet på databasen.

    • Ersätt <F:\Path> med sökvägen för databasen och loggfilerna. Använd samma sökväg för databasen och loggfilerna.

    Du kan också använda standardsökvägarna.

    Kör skriptet för att skapa databasen.

    CREATE DATABASE [TestDB] CONTAINMENT = NONE
        ON
        PRIMARY(NAME = N'TestDB', FILENAME = N'<F:\Path>\TestDB.mdf')
        LOG ON (NAME = N'TestDB_log', FILENAME = N'<F:\Path>\TestDB_log.ldf');
    GO
    

16. Gör en fullständig säkerhetskopia av databasen.

17. Om du inte använder automatisk seeding återställer du databasen på den sekundära replikservern (Linux). Migrera en SQL Server-databas från Windows till Linux med hjälp av säkerhetskopiering och återställning. Återställ databasen WITH NORECOVERY på den sekundära repliken.

18. Lägg till databasen i tillgänglighetsgruppen. Uppdatera exempelskriptet. Ersätt TestDB med namnet på databasen. På den primära repliken kör du T-SQL-frågan för att lägga till databasen i tillgänglighetsgruppen.

    ALTER AG [ag1] ADD DATABASE TestDB;
    GO
    

19. Kontrollera att databasen fylls i på den sekundära repliken.

Växla över den primära repliken

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 gö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älja över den primära replikan i en hög tillgänglighetsgrupp med klustertypen NONE.

• Manuell övergång utan att förlora data
• Tvingad manuell redundansväxling 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 målsekundärrepliken är uppdaterad innan du utför den manuella övervä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 fastställts i 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 garanterar att varje pågående transaktion committeras till den primära repliken och minst en synkron sekundär replik.

   Notis

   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ässkala och som inte hanteras av klusterhanteraren. Om den ursprungliga lyssnaren pekar på den gamla primären, ta bort den och återskapa den så 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. Men om den ursprungliga primära repliken återställs efter felövergång, kommer den att återta den primära rollen. ** Om du vill undvika att varje replik är i ett annat tillstånd, tar du bort den ursprungliga primärservern från tillgänglighetsgruppen efter en tvingad överflyttning med dataförlust. När den ursprungliga primärinstansen ä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. Släpp 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 replika i tillgänglighetsgruppen AGRScale.

I den här artikeln granskas stegen för att skapa en plattformsoberoende AG (tillgänglighetsgrupp) som stöder migrering eller läsintensiva arbetsbelastningar. Den kan användas för manuell katastrofåterställning. Den förklarade också hur man hanterar felöverföring för tillgänglighetsgruppen. En korsplattform AG använder klustertyp NONE och stöder inte hög tillgänglighet.

Relaterat innehåll

• Vad är en AlwaysOn-tillgänglighetsgrupp?
• grunderna för SQL Server-tillgänglighet för Linux-distributioner