Använda automatisk seeding för att initiera en AlwaysOn-tillgänglighetsgrupp

Gäller för:SQL Server

SQL Server 2016 infördes automatisk seeding av tillgänglighetsgrupper. När du skapar en tillgänglighetsgrupp med automatisk seeding skapar SQL Server automatiskt de sekundära replikerna för varje databas i gruppen. Du behöver inte längre säkerhetskopiera och återställa sekundära repliker manuellt. Om du vill aktivera automatisk seeding skapar du tillgänglighetsgruppen med T-SQL eller använder den senaste versionen av SQL Server Management Studio.

Bakgrundsinformation finns i Automatisk seeding för sekundära repliker.

Förutsättningar

I SQL Server 2016 kräver automatisk seeding att data- och loggfilsökvägen är densamma på varje SQL Server instans som deltar i tillgänglighetsgruppen. I SQL Server 2017 kan du använda olika sökvägar, men Microsoft rekommenderar att du använder samma sökvägar när alla repliker finns på samma plattform (till exempel antingen Windows eller Linux). Plattformsoberoende tillgänglighetsgrupper har olika sökvägar för replikerna. Mer information finns i Disklayout.

Tillgänglighetsgruppens seeding kommunicerar via databasens speglingsslutpunkt. Öppna inkommande brandväggsregler till speglingsslutpunktsporten på varje server.

Databaser i en tillgänglighetsgrupp måste vara i en fullständig återställningsmodell. Databasen måste ha en aktuell fullständig säkerhetskopia och säkerhetskopiering av transaktionsloggar. Dessa säkerhetskopieringsfiler används inte för automatisk seeding, men de krävs innan databasen inkluderas i en tillgänglighetsgrupp.

Skapa tillgänglighetsgrupp med automatisk seeding

Om du vill skapa en tillgänglighetsgrupp med automatisk seeding anger du SEEDING_MODE=AUTOMATIC.

I följande exempel skapas en tillgänglighetsgrupp på ett Windows Server redundanskluster med två noder. Innan du kör skripten uppdaterar du värdena för din miljö.

1. Skapa slutpunkterna. Varje server behöver en slutpunkt. Följande skript skapar en slutpunkt som använder TCP-port 5022 för lyssnaren. Ange <endpoint_name> och LISTENER_PORT för att matcha din miljö och kör skriptet på båda servrarna:

   CREATE ENDPOINT [<endpoint_name>] 
       STATE=STARTED
       AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
       FOR DATA_MIRRORING (
           ROLE = ALL, 
           AUTHENTICATION = WINDOWS NEGOTIATE, 
           ENCRYPTION = REQUIRED ALGORITHM AES
           )
   GO
   

2. Skapa tillgänglighetsgruppen. Följande skript skapar tillgänglighetsgruppen. Uppdatera värdena inom vinkelparenteser <> för gruppnamn, servernamn och domännamn och kör det på den primära instansen av SQL Server.

   CREATE AVAILABILITY GROUP [<availability_group_name>]
       FOR DATABASE db1
       REPLICA ON'<*primary_server*>'
       WITH (ENDPOINT_URL = N'TCP://<primary_server>.<fully_qualified_domain_name>:5022', 
           FAILOVER_MODE = AUTOMATIC, 
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
           BACKUP_PRIORITY = 50, 
           SECONDARY_ROLE(ALLOW_CONNECTIONS = NO), 
           SEEDING_MODE = AUTOMATIC),
       N'<secondary_server>' WITH (ENDPOINT_URL = N'TCP://<secondary_server>.<fully_qualified_domain_name>:5022', 
           FAILOVER_MODE = AUTOMATIC, 
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
           BACKUP_PRIORITY = 50, 
           SECONDARY_ROLE(ALLOW_CONNECTIONS = NO), 
           SEEDING_MODE = AUTOMATIC);
   GO
   

3. Anslut den sekundära serverinstansen till tillgänglighetsgruppen och bevilja skapa databasbehörighet till tillgänglighetsgruppen. Uppdatera följande skript, ersätt värdena i vinkelparenteser <> för din miljö och kör det på den sekundära replikinstansen av SQL Server:

   ALTER AVAILABILITY GROUP [<availability_group_name>] JOIN
   GO  
   ALTER AVAILABILITY GROUP [<availability_group_name>] GRANT CREATE ANY DATABASE
   GO
   

SQL Server skapar automatiskt databasrepliken på den sekundära servern. Om databasen är stor kan det ta lite tid att slutföra synkroniseringen av databasen. Om en databas finns i en tillgänglighetsgrupp som är konfigurerad för automatisk seeding kan du köra frågor mot sys.dm_hadr_automatic_seeding systemvyn för att övervaka seeding-förloppet. Följande fråga returnerar en rad för varje databas som finns i en tillgänglighetsgrupp som konfigurerats för automatisk seeding.

SELECT start_time,
    ag.name,
    db.database_name,
    current_state,
    performed_seeding,
    failure_state,
    failure_state_desc
FROM sys.dm_hadr_automatic_seeding autos 
    JOIN sys.availability_databases_cluster db 
        ON autos.ag_db_id = db.group_database_id
    JOIN sys.availability_groups ag 
        ON autos.ag_id = ag.group_id

Förhindra automatisk seeding efter en tillgänglighetsgrupp

Om du tillfälligt vill förhindra att den primära repliken seedar fler databaser till den sekundära repliken kan du neka tillgänglighetsgruppen behörighet att skapa databaser. Kör följande fråga på den instans som är värd för den sekundära repliken för att neka tillgänglighetsgruppen behörighet att skapa replikdatabaser.

ALTER AVAILABILITY GROUP [<availability_group_name>] 
    DENY CREATE ANY DATABASE
GO

Aktivera automatisk seeding i en befintlig tillgänglighetsgrupp

Du kan ange automatisk seeding på en befintlig databas. Följande kommando ändrar en tillgänglighetsgrupp så att den använder automatisk seeding. Kör följande kommando på den primära repliken.

ALTER AVAILABILITY GROUP [<availability_group_name>] 
    MODIFY REPLICA ON '<secondary_node>' 
    WITH (SEEDING_MODE = AUTOMATIC)
GO

Föregående kommando tvingar en databas att starta om seeding om det behövs. Om seeding till exempel misslyckas på grund av otillräckligt diskutrymme på den sekundära repliken kör ALTER AVAILABILITY GROUP ... WITH (SEEDING_MODE=AUTOMATIC) du för att starta om seeding när du har lagt till ledigt utrymme.

Stoppa automatisk seeding

Om du vill stoppa automatisk seeding för en tillgänglighetsgrupp kör du följande skript på den primära repliken:

ALTER AVAILABILITY GROUP [<availability_group_name>] 
    MODIFY REPLICA ON '<secondary_node>'   
    WITH (SEEDING_MODE = MANUAL)
GO

Föregående skript avbryter alla repliker som för närvarande är seeding och förhindrar att SQL Server automatiskt initierar eventuella repliker i den här tillgänglighetsgruppen. Det stoppar inte synkroniseringen för alla repliker som redan har initierats.

Övervaka tillgänglighetsgrupp för automatisk seeding

Använda dynamiska hanteringsvyer för system för att övervaka seeding

Följande systemvyer visar status för SQL Server automatisk seeding.

sys.dm_hadr_automatic_seeding

På den primära repliken frågar du sys.dm_hadr_automatic_seeding för att kontrollera statusen för den automatiska seeding-processen. Vyn returnerar en rad för varje seedingprocess. Ett exempel:

SELECT start_time, 
    completion_time
    is_source,
    current_state,
    failure_state,
    failure_state_desc
FROM sys.dm_hadr_automatic_seeding

sys.dm_hadr_physical_seeding_stats

På den primära repliken frågar du sys.dm_hadr_physical_seeding_stats DMV för att se den fysiska statistiken för varje seedingprocess som körs för närvarande. Följande fråga returnerar rader när seeding körs:

SELECT * FROM sys.dm_hadr_physical_seeding_stats;

De två kolumnerna total_disk_io_wait_time_ms och total_network_wait_time_ms kan användas för att fastställa flaskhalsar för prestanda i processen för automatisk seeding. De två kolumnerna finns också i den hadr_physical_seeding_progress utökade händelsen.

• total_disk_io_wait_time_ms representerar den tid som används av säkerhetskopierings-/återställningstråden i väntan på disken. Det här värdet är kumulativt sedan start av seeding-åtgärden. Om diskarna inte är redo att läsa eller skriva säkerhetskopieringsströmmen övergår tråden för säkerhetskopiering/återställning till viloläge och vaknar varje sekund för att kontrollera om disken är klar.

• total_network_wait_time_ms tolkas på olika sätt för den primära och sekundära repliken. Vid den primära repliken representerar den här räknaren tiden för nätverksflödeskontroll. På den sekundära repliken representerar detta den tid då återställningstråden väntar på att ett meddelande ska vara tillgängligt för skrivning till disken.

Diagnostisera databasinitiering med hjälp av automatisk seeding i felloggen

När du lägger till en databas i en tillgänglighetsgrupp som konfigurerats för automatisk seeding utför SQL Server en VDI-säkerhetskopiering över tillgänglighetsgruppens slutpunkt. Granska SQL Server felloggen för information om när säkerhetskopian slutfördes och den sekundära synkroniserades.

Diagnostisera hälsotillstånd på databasnivå med utökade händelser

Automatisk seeding har nya utökade händelser för spårning av tillståndsändringar, fel och prestandastatistik under initieringen.

Det här skriptet skapar till exempel en utökad händelsesession som samlar in händelser relaterade till automatisk seeding:

CREATE EVENT SESSION [AlwaysOn_autoseed] ON SERVER 
    ADD EVENT sqlserver.hadr_automatic_seeding_state_transition,
    ADD EVENT sqlserver.hadr_automatic_seeding_timeout,
    ADD EVENT sqlserver.hadr_db_manager_seeding_request_msg,
    ADD EVENT sqlserver.hadr_physical_seeding_backup_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_failure,
    ADD EVENT sqlserver.hadr_physical_seeding_forwarder_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_forwarder_target_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_progress,
    ADD EVENT sqlserver.hadr_physical_seeding_restore_state_change,
    ADD EVENT sqlserver.hadr_physical_seeding_submit_callback
    ADD TARGET package0.event_file(
        SET filename=N'autoseed.xel',
            max_file_size=(5),
            max_rollover_files=(4)
        )
WITH (
    MAX_MEMORY=4096 KB,
    EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,
    MAX_DISPATCH_LATENCY=30 SECONDS,
    MAX_EVENT_SIZE=0 KB,
    MEMORY_PARTITION_MODE=NONE,
    TRACK_CAUSALITY=OFF,
    STARTUP_STATE=ON
    )
GO 

ALTER EVENT SESSION AlwaysOn_autoseed ON SERVER STATE=START
GO 

I följande tabell visas utökade händelser relaterade till automatisk seeding:

Andra felsökningsöverväganden

Övervaka vid automatisk seeding

Fråga sys.dm_hadr_physical_seeding_stats efter automatiska seedingprocesser som körs för tillfället. Vyn returnerar en rad för varje databas. Ett exempel:

SELECT local_database_name, 
    role_desc, 
    internal_state_desc, 
    transfer_rate_bytes_per_second, 
    transferred_size_bytes, 
    database_size_bytes, 
    start_time_utc, 
    end_time_utc, estimate_time_complete_utc, 
    total_disk_io_wait_time_ms, 
    total_network_wait_time_ms, 
    is_compression_enabled 
FROM sys.dm_hadr_physical_seeding_stats

Felsök varför en databas inte visas i en tillgänglighetsgrupp som har konfigurerats för automatisk seeding

När en databas inte visas som en del av en tillgänglighetsgrupp med automatisk seeding aktiverad, misslyckades sannolikt den automatiska seedingen. Detta förhindrar att databasen läggs till i tillgänglighetsgruppen på antingen den primära och sekundära repliken. Fråga sys.dm_hadr_automatic_seeding på både de primära och sekundära replikerna. Kör till exempel följande fråga för att identifiera feltillståndet för automatisk seeding.

SELECT start_time, 
    completion_time, 
    is_source, 
    current_state, 
    failure_state, 
    failure_state_desc, 
    error_code 
FROM sys.dm_hadr_automatic_seeding

Överväganden för automatisk seeding och prestanda

SQL Server använder ett fast antal trådar för automatisk seeding. På den primära instansen använder SQL Server en tråd per LUN för att läsa ändringar. På den sekundära instansen använder SQL Server en tråd per LUN för att initiera databasen.

Ange spårningsflagga 9567 på den primära repliken för att aktivera komprimering av dataströmmen under automatisk seeding. Detta kan avsevärt minska överföringstiden för automatisk seeding, men det ökar också CPU-användningen. Mer information finns i Finjustera komprimering för tillgänglighetsgrupp.

När du inte ska använda automatisk seeding

I vissa scenarier är automatisk seeding kanske inte optimalt för att initiera en sekundär replik. Under automatisk seeding utför SQL Server en säkerhetskopia över nätverket för initiering. Den här processen kan vara långsam om databaserna är mycket stora eller om den sekundära repliken är fjärransluten. Transaktionsloggen för dessa databaser kan inte trunkeras under säkerhetskopieringsprocessen, så en långvarig initieringsprocess i en upptagen databas kan leda till betydande tillväxt i transaktionsloggen. Innan du lägger till en databas i en tillgänglighetsgrupp med automatisk seeding utvärderar du databasens storlek, belastning och platsavstånd mellan repliker.

Se även

• CREATE AVAILABILITY GROUP (Transact-SQL)
• Övervaka och felsöka tillgänglighetsgrupper