Failoveroptie voor gezondheidsdetectie op databaseniveau binnen een beschikbaarheidsgroep

Van toepassing op:SQL Server

Vanaf SQL Server 2016 is de optie statusdetectie op databaseniveau (DB_FAILOVER) beschikbaar bij het configureren van een AlwaysOn-beschikbaarheidsgroep. De statusdetectie op databaseniveau merkt wanneer een database niet langer de onlinestatus heeft, wanneer er iets misgaat en de automatische failover van de beschikbaarheidsgroep activeert. Voorbeelden die de gezondheidsdetectie kunnen activeren, zijn database in verdachte status, database is offline, database in herstel (kan niet worden hersteld). Zie de kolom State in sys.databases voor meer informatie.

De statusdetectie op databaseniveau is ingeschakeld voor de beschikbaarheidsgroep als geheel. Daarom bewaakt de statusdetectie op databaseniveau elke database in de beschikbaarheidsgroep. Het kan niet selectief worden ingeschakeld voor specifieke databases in de beschikbaarheidsgroep.

Voordelen van de optie statusdetectie op databaseniveau

De optie voor statusdetectie op databaseniveau van een beschikbaarheidsgroep wordt algemeen aanbevolen als een goede optie om de hoge beschikbaarheid voor uw databases te garanderen. U moet overwegen deze in te schakelen voor alle beschikbaarheidsgroepen. Als uw toepassing afhankelijk is van meerdere databases die maximaal beschikbaar zijn, kunt u deze groeperen in een beschikbaarheidsgroep met de optie databasestatus ingeschakeld.

Met de instelling voor het detecteren van de gezondheid op databaseniveau ingeschakeld, als SQL Server bijvoorbeeld niet kan schrijven naar het transactielogboekbestand voor een van de databases, zou de status van die database veranderen om een fout aan te geven en zou de beschikbaarheidsgroep spoedig naar een andere server overschakelen. Uw toepassing kan dan opnieuw verbinding maken en met minimale onderbreking blijven functioneren zodra de databases weer online zijn.

Gezondheidsdetectie op databaseniveau inschakelen

Hoewel het over het algemeen wordt aanbevolen, is de optie Databasestatus standaard uitgeschakeld, om compatibiliteit met eerdere versies met de standaardinstellingen te behouden.

Er zijn verschillende eenvoudige manieren om de instelling voor gezondheidsdetectie op databaseniveau in te schakelen:

1. Maak in SQL Server Management Studio verbinding met uw SQL Server-database-engine. Klik in het venster Objectverkenner met de rechtermuisknop op het knooppunt AlwaysOn Hoge beschikbaarheid en voer de wizard Nieuwe beschikbaarheidsgroep uit. Schakel het selectievakje Statusdetectie op databaseniveau in op de pagina Naam opgeven. Voltooi vervolgens de rest van de pagina's in de wizard.

   

2. Bekijk de eigenschappen van een bestaande beschikbaarheidsgroep in SQL Server Management Studio. Maak verbinding met uw SQL Server. Vouw in het venster Objectverkenner het knooppunt AlwaysOn Hoge beschikbaarheid uit. Vouw beschikbaarheidsgroepen uit. Klik met de rechtermuisknop op de beschikbaarheidsgroep en kies Eigenschappen. Schakel de optie Statusdetectie op databaseniveau in en klik vervolgens op OK of Script voor de wijziging.

   

3. Transact-SQL syntaxis voor HET MAKEN VAN BESCHIKBAARHEIDSGROEP. De parameter DB_FAILOVER accepteert waarden AAN of UIT.

   CREATE AVAILABILITY GROUP [Contoso-ag]
   WITH (DB_FAILOVER=ON)
   FOR DATABASE [AutoHa-Sample]
   REPLICA ON
       N'SQLSERVER-0' WITH (ENDPOINT_URL = N'TCP://SQLSERVER-0.DOMAIN.COM:5022',
         FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
       N'SQLSERVER-1' WITH (ENDPOINT_URL = N'TCP://SQLSERVER-1.DOMAIN.COM:5022',
        FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
   

4. Transact-SQL syntaxis voor ALTER AVAILABILITY GROUP. De parameter DB_FAILOVER accepteert waarden AAN of UIT.

   ALTER AVAILABILITY GROUP [Contoso-ag] SET (DB_FAILOVER = ON);
   
   ALTER AVAILABILITY GROUP [Contoso-ag] SET (DB_FAILOVER = OFF);
   

Waarschuwingen

Het is belangrijk om te weten dat de optie Detectie van status op databaseniveau momenteel niet tot gevolg heeft dat SQL Server de schijftijd bewaakt en SQL Server de beschikbaarheid van databasebestanden niet rechtstreeks bewaakt. Als een schijfstation uitvalt of niet meer beschikbaar is, zal de beschikbaarheidsgroep niet noodzakelijkerwijs automatisch overstappen.

Als een database bijvoorbeeld niet actief is zonder actieve transacties en er geen fysieke schrijfbewerkingen plaatsvinden, moeten sommige databasebestanden ontoegankelijk worden, kan SQL Server geen lees- of schrijf-IO uitvoeren naar de bestanden en kan de status voor die database niet onmiddellijk wijzigen, zodat er geen failover wordt geactiveerd. Wanneer een databasecontrolepunt zich later voordoet of een fysieke lees- of schrijfbewerking plaatsvindt voor het uitvoeren van een query, kan SQL Server het probleem met het bestand opmerken en reageren door de databasestatus te wijzigen, waarna de beschikbaarheidsgroep waarop de statusdetectie op databaseniveau is ingesteld, een failover zou uitvoeren vanwege de statuswijziging van de database.

Een ander voorbeeld: wanneer de SQL Server-database-engine een datapagina moet lezen om aan een query te voldoen, als de datapagina in de cache van het bufferpoolgeheugen staat, is mogelijk geen fysieke schijfleestoegang vereist om aan het queryverzoek te voldoen. Daarom kan een ontbrekend of niet beschikbaar gegevensbestand niet onmiddellijk een automatische failover activeren, zelfs niet wanneer de optie voor databasestatus is ingeschakeld, omdat de databasestatus niet onmiddellijk wordt bijgewerkt.

Databasefailover is gescheiden van flexibel failoverbeleid

Statusdetectie op databaseniveau implementeert een flexibel failoverbeleid waarmee de drempelwaarden van de SQL Server-processtatus voor failoverbeleid worden geconfigureerd. De statusdetectie op databaseniveau wordt geconfigureerd met behulp van de parameter DB_FAILOVER, terwijl de optie voor de beschikbaarheidsgroep FAILURE_CONDITION_LEVEL afzonderlijk is voor het configureren van sql Server-processtatusdetectie. De twee opties zijn onafhankelijk.

Gezondheidsdetectie op databaseniveau beheren en monitoren

Dynamische beheerweergaven

De DMV-sys.availability_groups van het systeem toont een kolom db_failover die aangeeft of de optie voor statusdetectie op databaseniveau is uitgeschakeld (0) of aan (1).

select name, db_failover from sys.availability_groups

Voorbeeld van dmv-uitvoer:

Foutenlogboek

In het SQL Server-foutenlogboek (of tekst uit sp_readerrorlog) wordt het foutbericht 41653 weergegeven wanneer een beschikbaarheidsgroep een failover heeft uitgevoerd, vanwege de controles op statusdetectie op databaseniveau.

In dit fragment van het foutenlogboek ziet u bijvoorbeeld dat het schrijven van een transactielogboek is mislukt vanwege een schijfprobleem en vervolgens de database met de naam AutoHa-Sample is afgesloten, waardoor de statusdetectie op databaseniveau is geactiveerd om een failover uit te voeren van de beschikbaarheidsgroep.

2016-04-25 12:20:21.08 spid1s Fout: 17053, Ernst: 16, Status: 1.

2016-04-25 12:20:21.08 spid1s SQLServerLogMgr::LogWriter: Besturingssysteemfout 21(Het apparaat is niet gereed.) aangetroffen. 2016-04-25 12:20:21.08 spid1s Schrijffout tijdens het leegmaken van logboeken.

2016-04-25 12:20:21.08 spid79 Fout: 9001, Ernst: 21, Status: 4.

2016-04-25 12:20:21.08 spid79 Het logboek voor database AutoHa-Sample is niet beschikbaar. Controleer het gebeurtenislogboek op gerelateerde foutberichten. Los eventuele fouten op en start de database opnieuw op.

2016-04-25 12:20:21.15 spid79 Fout: 41653, Ernst: 21, Status: 1.

2016-04-25 12:20:21.15 spid79 Database 'AutoHa-Sample' heeft een fout aangetroffen (fouttype: 2 'DB_SHUTDOWN') waardoor de beschikbaarheidsgroep Contoso-ag is mislukt. Raadpleeg het SQL Server-foutenlogboek voor informatie over de fouten die zijn opgetreden. Als deze voorwaarde zich blijft voordoen, neemt u contact op met de systeembeheerder.

2016-04-25 12:20:21.17 spid79 Statusinformatie voor database 'AutoHa-Sample' - Geharde Lsn: '(34:664:1)' Commit LSN: '(34:656:1)' Commit Tijd: 'Apr 25 2016 12:19PM'

2016-04-25 12:20:21.19 spid15s AlwaysOn-beschikbaarheids groepen-verbinding met secundaire database beëindigd voor primaire database 'AutoHa-Sample' op de beschikbaarheidsreplica 'SQLServer-0' met Replica ID: {c4ad5ea4-8a99-41fa-893e-189154c24b49}. Dit is alleen een informatief bericht. De gebruiker hoeft verder niets te doen.

2016-04-25 12:20:21.21 spid75 AlwaysOn: De lokale replica van de beschikbaarheidsgroep Contoso-ag bereidt zich voor op de overgang naar de oplossingsrol in reactie op een aanvraag van het WSFC-cluster (Windows Server Failover Clustering). Dit is alleen een informatief bericht. De gebruiker hoeft verder niets te doen.

2016-04-25 12:20:21.21 spid75 De status van de lokale beschikbaarheidsreplica in beschikbaarheidsgroep 'ag' is gewijzigd van 'PRIMARY_NORMAL' in 'RESOLVING_NORMAL'. De status is gewijzigd omdat de beschikbaarheidsgroep offline gaat. De replica gaat offline omdat de bijbehorende beschikbaarheidsgroep is verwijderd of de gebruiker de bijbehorende beschikbaarheidsgroep offline heeft gehaald in de beheerconsole van Windows Server Failover Clustering (WSFC), of de beschikbaarheidsgroep voert een failover uit naar een ander SQL Server-exemplaar. Zie het SQL Server-foutenlogboek, de WSFC-beheerconsole (Windows Server Failover Clustering) of het WSFC-logboek voor meer informatie.

Uitgebreide gebeurtenis voor sqlserver.availability_replica_database_fault_reporting

Er is een nieuwe uitgebreide gebeurtenis gedefinieerd vanaf SQL Server 2016 die wordt geactiveerd door de statusdetectie op databaseniveau. De naam van de gebeurtenis is sqlserver.availability_replica_database_fault_reporting

Deze XEvent wordt alleen geactiveerd op de primaire replica. Deze XEvent wordt geactiveerd wanneer statusprobleem op databaseniveau wordt gedetecteerd voor een database die wordt gehost in een beschikbaarheidsgroep.

Hier volgt een voorbeeld om een XEvent-sessie te maken waarmee deze gebeurtenis wordt vastgelegd. Omdat er geen pad is opgegeven, moet het XEvent-uitvoerbestand zich bevinden in het standaardpad van het SQL Server-foutenlogboek. Voer dit uit op de primaire replica van uw beschikbaarheidsgroep:

Voorbeeld van een uitgebreid gebeurtenissessiescript

CREATE EVENT SESSION [AlwaysOn_dbfault] ON SERVER
ADD EVENT sqlserver.availability_replica_database_fault_reporting
ADD TARGET package0.event_file(SET filename=N'dbfault.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_dbfault ON SERVER STATE=START
GO

Uitgebreide gebeurtenisuitvoer

Maak met behulp van SQL Server Management Studio verbinding met de primaire SQL Server, vouw vervolgens het beheerknooppunt uit, en daarna Uitgebreide Gebeurtenissen. Zoek de sessie (AlwaysOn_dbfault was de naam in het bovenstaande voorbeeld) en vouw deze uit om de uitvoerbestanden te zien. Selecteer het uitvoerbestand en het gebeurtenisbestand wordt geopend op een nieuw tabblad.

Uitleg van de velden:

In deze voorbeelduitvoer laat de fault_type zien dat er een kritieke gebeurtenis is opgetreden in de beschikbaarheidsgroep Contoso-ag, op replica met de naam SQLSERVER-1, vanwege de databasenaam AutoHa-Sample2, met fouttype 2- Afsluiten.

Verwante verwijzingen

• BESCHIKBAARHEIDSGROEP MAKEN

• BESCHIKBAARHEIDSGROEP WIJZIGEN

• Flexibel failoverbeleid voor automatische failover van een beschikbaarheidsgroep (SQL Server)

• Always On-failoverbeleid verbeteren om gegevens- en logschijven van SQL Server-databases te testen

• Uitgebreide gebeurtenissen

• Een AlwaysOn-beschikbaarheidsgroep configureren om een failover uit te voeren wanneer het databasegegevensbestand niet beschikbaar is