Automatische seeding gebruiken om een secundaire replica te initialiseren voor een AlwaysOn-beschikbaarheidsgroep

Van toepassing op:SQL Server

In SQL Server 2012 en 2014 is de enige manier om een secundaire replica te initialiseren in een SQL Server AlwaysOn-beschikbaarheidsgroep het gebruik van back-ups, kopiëren en herstellen. SQL Server 2016 introduceert een nieuwe functie voor het initialiseren van een secundaire replica: automatische seeding. Automatische seeding maakt gebruik van het logboekstroomtransport om de back-up te streamen met behulp van VDI naar de secundaire replica voor elke database van de beschikbaarheidsgroep met behulp van de geconfigureerde eindpunten. Deze nieuwe functie kan worden gebruikt tijdens het maken van een beschikbaarheidsgroep of wanneer een database aan een database wordt toegevoegd. Automatische seeding bevindt zich in alle edities van SQL Server die AlwaysOn-beschikbaarheidsgroepen ondersteunen en kunnen worden gebruikt met zowel traditionele beschikbaarheidsgroepen als gedistribueerde beschikbaarheidsgroepen.

Security

Beveiligingsmachtigingen variëren, afhankelijk van het type replica dat wordt geïnitialiseerd:

• Voor een traditionele beschikbaarheidsgroep moeten machtigingen worden verleend voor de beschikbaarheidsgroep op de secundaire replica wanneer deze wordt toegevoegd aan de beschikbaarheidsgroep. Gebruik de opdracht ALTER AVAILABILITY GROUP [<AGName>] GRANT CREATE ANY DATABASEin Transact-SQL.
• Voor een gedistribueerde beschikbaarheidsgroep waarin de databases van de replica die worden gemaakt zich op de primaire replica van de tweede beschikbaarheidsgroep bevinden, zijn er geen extra machtigingen vereist omdat deze al een primaire replica is. Als er echter slechts één replica in de tweede beschikbaarheidsgroep is, verleent u de machtiging CREATE ANY DATABASE aan de naam van de secundaire beschikbaarheidsgroep, anders kan automatische seeding mislukken.
• Voor een secundaire replica op de tweede beschikbaarheidsgroep van een gedistribueerde beschikbaarheidsgroep moet u de opdracht ALTER AVAILABILITY GROUP [<2ndAGName>] GRANT CREATE ANY DATABASEgebruiken. Deze secundaire replica wordt geseed van de primaire van de tweede beschikbaarheidsgroep.

Invloed op prestaties en het transactielogboek op de primaire replica

Automatische seeding kan al dan niet praktisch zijn om een secundaire replica te initialiseren, afhankelijk van de grootte van de database, netwerksnelheid en afstand tussen de primaire en secundaire replica's. Bijvoorbeeld:

• De databasegrootte is 5 TB
• De netwerksnelheid is 1 Gb per seconde
• De afstand tussen de twee locaties is 1000 mijl

Als de volledige bandbreedte beschikbaar is, kan een netwerk van 1 Gb per seconde een duurzame doorvoer van 125 MB per seconde bieden. In dit voorbeeld duurt automatische seeding iets meer dan 11 uur. In de praktijk is het automatische seedingproces langzamer, omdat netwerksignalen afnemen over langere afstanden en de koppeling wordt gedeeld met andere resources in het netwerk. Tijdens het seeden blijft het transactielogboek op de database op de primaire replica groeien en kan deze pas worden afgekapt als het automatisch seeden van die database is voltooid. Het transactielogboek kan vervolgens worden afgekapt met behulp van een back-up van het transactielogboek.

Automatische seeding is een proces met één thread dat maximaal vijf databases kan verwerken. De enkelvoudige threading is van invloed op de prestaties, met name als de beschikbaarheidsgroep meer dan één database heeft.

Compressie kan worden gebruikt voor automatisch seeden, maar is standaard uitgeschakeld. Het inschakelen van compressie vermindert de netwerkbandbreedte en versnelt mogelijk het proces, maar het nadeel is extra processoroverhead. Als u compressie wilt gebruiken tijdens automatische seeding, schakelt u traceringsvlag 9567 in. Zie Compressie afstemmen voor beschikbaarheidsgroep.

Schijfindeling

In SQL Server 2016 en eerder moet de map waarin de database wordt gemaakt door automatische seeding al bestaan en hetzelfde zijn als het pad op de primaire replica.

In SQL Server 2017 raadt Microsoft aan hetzelfde gegevens- en logboekbestandspad te gebruiken voor alle replica's die deelnemen aan een beschikbaarheidsgroep, maar u kunt indien nodig verschillende paden gebruiken. In een platformoverschrijdende beschikbaarheidsgroep bevindt één exemplaar van SQL Server zich bijvoorbeeld op Windows en een ander exemplaar van SQL Server op Linux. De verschillende platforms hebben verschillende standaardpaden. SQL Server 2017 ondersteunt replica's van beschikbaarheidsgroepen op exemplaren van SQL Server met verschillende standaardpaden.

De volgende tabel bevat voorbeelden van ondersteunde indelingen voor gegevensschijven die ondersteuning kunnen bieden voor automatische seeding:

Scenario's waarbij de locatie van de primaire en secundaire replicadatabase niet de standaardpaden van het exemplaar zijn, worden niet beïnvloed door deze wijziging. Vereisten voor secundaire replicabestandspaden die overeenkomen met de primaire replicabestandspaden blijven hetzelfde.

Als u standaard- en niet-standaardpaden op de primaire en secundaire replica's combineert, gedraagt SQL Server 2017 zich anders dan eerdere releases. In de volgende tabel ziet u het gedrag SQL Server 2017.

Als u wilt terugkeren naar het gedrag voor SQL Server 2016 en eerder, schakelt u traceringsvlag 9571 in. Zie DBCC TRACEON (Transact-SQL) voor meer informatie over het inschakelen van traceringsvlagmen.

Een beschikbaarheidsgroep maken met automatische seeding

U maakt een beschikbaarheidsgroep met behulp van automatische seeding met Transact-SQL of SQL Server Management Studio (SSMS, versie 17 of hoger). Als u de wizard Beschikbaarheidsgroep in SSMS wilt gebruiken, volgt u deze instructies : wanneer u bij stap 9 bent, ziet u dat automatische seeding de eerste en standaardoptie is.

In het volgende voorbeeld wordt een beschikbaarheidsgroep met automatische seeding gemaakt met behulp van Transact-SQL. Zie ook het onderwerp Een beschikbaarheidsgroep maken (Transact-SQL). Seeding is ingeschakeld op een secundaire replica door de SEEDING_MODE optie in te stellen op AUTOMATIC. Het standaardgedrag isMANUAL, wat het pre-SQL Server 2016-gedrag is, waarbij een back-up van de database moet worden gemaakt op de primaire replica, een kopie van het back-upbestand naar de secundaire replica en een herstel van de back-upWITH NORECOVERY.

CREATE AVAILABILITY GROUP [<AGName>]
  FOR DATABASE db1
  REPLICA ON N'Primary_Replica'
WITH (
  ENDPOINT_URL = N'TCP://Primary_Replica.Contoso.com:5022', 
  FAILOVER_MODE = AUTOMATIC, 
  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT
),
  N'Secondary_Replica' WITH (
    ENDPOINT_URL = N'TCP://Secondary_Replica.Contoso.com:5022', 
    FAILOVER_MODE = AUTOMATIC, 
    SEEDING_MODE = AUTOMATIC);
 GO

Het instellen SEEDING_MODE van een primaire replica tijdens een CREATE AVAILABILITY GROUP instructie heeft geen effect omdat de primaire replica al de hoofdkopie lezen/schrijven van de database bevat. SEEDING_MODE is alleen van toepassing wanneer een andere replica de primaire replica heeft gemaakt en er een database is toegevoegd. De seedingmodus kan later worden gewijzigd. Zie De seedingmodus van een replica wijzigen.

Op een exemplaar dat een secundaire replica wordt, wordt het volgende bericht toegevoegd aan het SQL Server-logboek zodra het exemplaar is toegevoegd:

Lokale beschikbaarheidsreplica voor beschikbaarheidsgroep 'AGName' is niet gemachtigd om databases te maken, maar heeft een SEEDING_MODE van AUTOMATIC. Gebruik ALTER AVAILABILITY GROUP ... GRANT CREATE ANY DATABASE dit om het maken van databases toe te staan die worden geseed door de primaire beschikbaarheidsreplica.

Machtiging voor het maken van een database op de secundaire replica aan de beschikbaarheidsgroep verlenen

Nadat u bent toegevoegd, verleent u de beschikbaarheidsgroep toestemming om databases te maken op het secundaire replica-exemplaar van SQL Server. Om automatische seeding te laten werken, heeft de beschikbaarheidsgroep toestemming nodig om een database te maken.

In het volgende voorbeeld wordt deze machtiging verleend aan een beschikbaarheidsgroep met de naam AGName.

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

Stel indien nodig de eigenaar van de database in op de secundaire replica.

Automatisch zaaien controleren

Als dit is gelukt, worden de database(s) automatisch aangemaakt op de secundaire replica in een van de volgende statussen:

• GESYNCHRONISEERD als de secundaire replica is geconfigureerd om synchroon te zijn en de gegevens worden gesynchroniseerd.
• SYNCHRONISEERT als de secundaire replica is geconfigureerd voor asynchrone gegevensverplaatsing, of wanneer deze is geconfigureerd voor synchrone gegevensverplaatsing maar nog niet met de primaire replica is gesynchroniseerd.

Naast de dynamische beheerweergaven die hieronder worden beschreven, kunt u de start en voltooiing van automatische seeding bekijken in het SQL Server logboek:

Back-up en herstel combineren met automatische initialisatie

Het is mogelijk om het traditionele back-up maken, kopiëren en herstellen te combineren met automatische seeding. In dit geval herstelt u eerst de database op een secundaire replica, inclusief alle beschikbare transactielogboeken. Schakel vervolgens automatisch seeding in bij het maken van de beschikbaarheidsgroep om de database van de secundaire replica 'in te halen', alsof een back-up van het tail-logboek is hersteld (zie Tail-Log Back-ups (SQL Server)).

Een database toevoegen aan een beschikbaarheidsgroep met automatische seeding

U kunt een database toevoegen aan een beschikbaarheidsgroep met behulp van automatische seeding met behulp van Transact-SQL of SQL Server Management Studio (SSMS, versie 17 of hoger). Als de secundaire replica automatische seeding heeft gebruikt toen deze aan de beschikbaarheidsgroep werd toegevoegd, hoeft er niets extra te worden gedaan. Als de secundaire replica back-up, kopiëren en herstellen heeft gebruikt, moet u eerst de seedingmodus wijzigen (zie de volgende sectie) en vervolgens bij het toevoegen van de database de instructie GRANT gebruiken - zie Beschikbaarheidsgroep - Een database toevoegen.

De seedingmodus van een replica wijzigen

De seedingmodus van een replica kan worden gewijzigd nadat de beschikbaarheidsgroep is gemaakt, zodat automatisch seeding kan worden ingeschakeld of uitgeschakeld. Als u automatische seeding inschakelt nadat deze is gemaakt, kan een database worden toegevoegd aan de beschikbaarheidsgroep met behulp van automatische seeding als deze is gemaakt met back-up, kopiëren en herstellen. Voorbeeld:

ALTER AVAILABILITY GROUP [AGName]
  MODIFY REPLICA ON 'Replica_Name'
  WITH (SEEDING_MODE = AUTOMATIC)

Als u automatische seeding wilt uitschakelen, gebruikt u een waarde van MANUAL.

Automatische seeding voorkomen nadat een beschikbaarheidsgroep is gemaakt

Als u automatische seeding niet volledig wilt uitschakelen voor een secundaire replica, maar tijdelijk wilt voorkomen dat de secundaire replica automatisch databases kan maken, weigert u de machtiging CREATE voor de beschikbaarheidsgroep. Dit is het geval wanneer een nieuwe database wordt toegevoegd aan de beschikbaarheidsgroep, maar de beschikbaarheidsgroep mag de database niet maken op een secundaire replica.

ALTER AVAILABILITY GROUP [AGName] 
    DENY CREATE ANY DATABASE
GO

Automatisch seeden bewaken

Er zijn vier manieren om automatische seeding te controleren en problemen op te lossen:

• SQL Server logboek zoals al is beschreven
• Dynamische beheerweergaven
• Tabellen met back-upgeschiedenis
• Uitgebreide gebeurtenissen

Dynamische beheerweergaven

Er zijn twee dynamische beheerweergaven (DMV's) om het seedingproces te bewaken: sys.dm_hadr_automatic_seeding en sys.dm_hadr_physical_seeding_stats.

• sys.dm_hadr_automatic_seeding bevat de algemene status van automatische seeding en behoudt de geschiedenis voor elke keer dat deze wordt uitgevoerd (al dan niet geslaagd). De kolom current_state heeft de waarde VOLTOOID of MISLUKT. Als de waarde FAILED is, gebruikt u de waarde in failure_state_desc om het probleem te helpen diagnosticeren. Mogelijk moet u dat combineren met wat er in het SQL Server-logboek staat om te zien wat er fout is gegaan. Deze DMV wordt gevuld op de primaire replica en op alle secundaire replica's.

• sys.dm_hadr_physical_seeding_stats geeft de status van de automatische seeding-bewerking weer terwijl deze wordt uitgevoerd. Net als bij sys.dm_hadr_automatic_seeding, retourneert dit waarden voor zowel de primaire als secundaire replica's, maar deze geschiedenis wordt niet opgeslagen. De waarden zijn alleen voor de huidige uitvoering en worden niet bewaard. Kolommen met interesse zijn onder anderestart_time_utc, , end_time_utcestimate_time_complete_utc, total_disk_io_wait_time_ms, en total_network_wait_time_msals de seeding-bewerking mislukt, failure_message.

Tabellen met back-upgeschiedenis

Automatische seeding plaatst ook vermeldingen in de msdb tabellen waarin de geschiedenis voor back-ups en herstelbewerkingen wordt opgeslagen. Op de secundaire replica waarop automatisch seeden plaatsvindt, heeft de kolom physical_device_name van de tabel backupmediafamily een GUID als waarde, en bevat de bijbehorende vermelding in backupset voor server_name en machine_name de naam van de primaire replica.

Uitgebreide gebeurtenissen

Met automatische seeding worden nieuwe uitgebreide gebeurtenissen toegevoegd voor het bijhouden van statuswijziging, fouten en prestatiestatistieken tijdens de initialisatie. Met het volgende script wordt bijvoorbeeld een uitgebreide gebeurtenissessie gemaakt waarmee gebeurtenissen worden vastgelegd die betrekking hebben op automatische 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

De volgende tabel bevat uitgebreide gebeurtenissen met betrekking tot automatische seeding.

Zie ook

ALTER AVAILABILITY GROUP (Transact-SQL)

CREATE AVAILABILITY GROUP (Transact-SQL)

Probleemoplossing en bewakingshandleiding voor AlwaysOn-beschikbaarheidsgroepen