Problemen met failover van AlwaysOn-beschikbaarheidsgroepen oplossen

Dit artikel bevat stappen voor probleemoplossing om te bepalen waarom uw beschikbaarheidsgroep een failover heeft uitgevoerd.

Gevolgen van AlwaysOn-statusproblemen of failover

AlwaysOn implementeert robuuste statuscontrole via verschillende mechanismen om de status van het Microsoft SQL Server-exemplaar te garanderen dat als host fungeert voor de primaire replica, het onderliggende cluster en de systeemstatus. De productieworkload wordt tijdelijk onderbroken wanneer een Windows-cluster of AlwaysOn-statusprobleem wordt geïdentificeerd.

Wanneer een statusvoorwaarde wordt gedetecteerd, vindt meestal de volgende reeks gebeurtenissen plaats. In deze probleemoplosser worden status-gebeurtenissen vermeld in verwijzing naar de volgende gebeurtenissen:

• Replica's en databases van beschikbaarheidsgroep gaan over van primaire rol naar het oplossen van de rol.

• Databases van beschikbaarheidsgroepen worden offline geplaatst en zijn niet meer toegankelijk.

• Windows Cluster markeert de geclusterde resource van de beschikbaarheidsgroep als mislukt.

• Windows-cluster probeert de rol van de beschikbaarheidsgroep weer online te zetten (op de oorspronkelijke of automatische failoverpartnerreplica).

• De rol van de beschikbaarheidsgroep is online als wordt gedetecteerd dat deze in orde is door AlwaysOn en windows-clusterstatuscontrole.

Als dit lukt, worden de replica's en databases van de beschikbaarheidsgroep overgestapt op de primaire rol en zijn de beschikbaarheidsgroepdatabases online en toegankelijk voor uw toepassing.

Toepassingen hebben geen toegang tot de databases van de beschikbaarheidsgroep

Wanneer een statusvoorwaarde wordt gedetecteerd, worden de replica van de beschikbaarheidsgroep en databases overgestapt op de rol Oplossen en worden de databases van de beschikbaarheidsgroep offline gehaald. Nadat de replica online is gekomen in de primaire rol (op de oorspronkelijke replicaserver of de replicaserver van de failoverpartner), worden de replica en databases opnieuw online geplaatst. Hoewel de replica en databases worden omgezet en offline zijn, mislukken toepassingen die toegang proberen te krijgen tot die beschikbaarheidsgroepdatabases en genereren ze een bericht 'Fout 983': Unable to access availability database.... Deze fout wordt ook vastgelegd in het foutenlogboek van Microsoft SQL Server als SQL Server is geconfigureerd om mislukte aanmeldingspogingen vast te leggen:

Logon Error: 983, Severity: 14, State: 1.

Logon Unable to access availability database '<databasename>' because the database replica is not in the PRIMARY or SECONDARY role. Connections to an availability database is permitted only when the database replica is in the PRIMARY or SECONDARY role. Try the operation again later.

De periode waarin de beschikbaarheidsgroep zich in de rol Oplossen bevindt voordat deze weer online komt in de primaire rol, duurt meestal slechts een paar seconden of zelfs minder dan een seconde.

Status-gebeurtenissen of failover van AlwaysOn-beschikbaarheidsgroep identificeren en diagnosticeren

1. Trends in AlwaysOn-status identificeren

U kunt één AlwaysOn-statusgebeurtenis onderzoeken, of er is mogelijk een recente of doorlopende trend van statusproblemen die de productie af en toe onderbreken. Met de volgende vragen kunt u recente wijzigingen in uw productieomgeving beperken en correleren die mogelijk te maken hebben met deze gezondheidsproblemen:

• Wanneer is de trend van de status van AlwaysOn of het cluster begonnen?
• Vindt de status op een bepaalde dag plaats?
• Treden de status gebeurtenissen op een bepaald tijdstip van de dag op?
• Vinden de gezondheidsevenementen plaats op een bepaalde dag of week van de maand?

Als u een trend detecteert, controleert u het geplande onderhoud op het systeem (het hostsysteem in een virtuele omgeving), ETL-batches en andere taken die mogelijk correleren met deze statusgebeurtenissen. Als het systeem een virtuele machine is, onderzoekt u het hostsysteem op wijzigingen die mogelijk zijn geïntroduceerd op het moment van de storingen.

Houd rekening met actieve ad-hoc productieworkloads die kunnen correleren met de tijd van de statusproblemen (bijvoorbeeld wanneer gebruikers zich voor het eerst aanmelden bij het systeem of nadat gebruikers terugkeren na de lunch).

2. Controleer het clusterlogboek

Het Windows-clusterlogboek is het meest uitgebreide logboek dat moet worden gebruikt om het soort AlwaysOn- of clusterstatus-gebeurtenis te identificeren en ook de gedetecteerde statusvoorwaarde die de gebeurtenis heeft veroorzaakt. Voer de volgende stappen uit om het clusterlogboek te genereren en te openen:

Gebruik Windows PowerShell om het Windows-clusterlogboek te genereren op het clusterknooppunt dat als host fungeert voor de primaire replica op het moment van de status gebeurtenis. Voer bijvoorbeeld de volgende cmdlet uit in een PowerShell-venster met verhoogde bevoegdheid met behulp van sql19agn1 als de servernaam op basis van SQL Server:

get-clusterlog -Node sql19agn1 -UseLocalTime     

3. Zoek de status gebeurtenis in het clusterlogboek

AlwaysOn maakt gebruik van verschillende mechanismen voor statuscontrole om de status van de beschikbaarheidsgroep te bewaken. Naast een Windows-clusterstatusgebeurtenis (waarbij windows-cluster een statusprobleem tussen de clusterknooppunten detecteert), heeft AlwaysOn vier verschillende soorten statuscontroles:

• De SQL Server-service wordt niet uitgevoerd
• Time-out voor sql Server-lease
• Time-out van sql Server-statuscontrole
• Een probleem met de interne status van SQL Server

U kunt een van deze AlwaysOn-specifieke status gebeurtenissen vinden door in het clusterlogboek naar de tekenreeks te zoeken. [hadrag] Resource Alive result 0 Deze tekenreeks wordt opgeslagen in het clusterlogboek wanneer een van deze gebeurtenissen wordt gedetecteerd. Bijvoorbeeld:

00001334.00002ef4::2019/06/24-18:24:36.153 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0.

U kunt een hulpprogramma gebruiken om alle statusevenementen in het clusterlogboek te vinden, zodat u een overzichtsrapport van AlwaysOn-statusproblemen kunt genereren. Dit kan handig zijn om chronologische trends te identificeren en te bepalen of een bepaalde AlwaysOn-status terugkerend is. In de volgende schermafbeelding ziet u hoe u een teksteditor (Kladblok++, in dit geval) gebruikt om alle regels in het clusterlogboek te vinden die de [hadrag] Resource Alive result 0 tekenreeks bevatten:

Het statusprobleem identificeren en oplossen dat de failover heeft geactiveerd

Als u de statusproblemen in het clusterlogboek van de primaire replica wilt identificeren, vergelijkt u deze met de problemen die in de volgende secties worden beschreven. Veelvoorkomende redenen voor ag-failover zijn:

• Clusterstatus gebeurtenis
• DE SQL Server-service is niet beschikbaar (een AlwaysOn-status gebeurtenis)
• Time-out lease (een AlwaysOn-statusgebeurtenis)
• Time-out van statuscontrole (een AlwaysOn-statusgebeurtenis)
• SQL Server-status (een AlwaysOn-status-gebeurtenis)

Clusterstatus-gebeurtenissen

Microsoft Windows Cluster bewaakt de status van de lidservers in het cluster. Als er een probleem met de status wordt gedetecteerd, kan een clusterlidserver uit het cluster worden verwijderd. Ook worden de clusterresources (inclusief de rol van de beschikbaarheidsgroep die wordt gehost op de verwijderde clusterlidserver) verplaatst naar de replica van de failoverpartner van de beschikbaarheidsgroep als deze is geconfigureerd voor automatische failover.

Symptomen

Hier volgt een voorbeeld van een clusterstatus gebeurtenis in het clusterlogboek. Als u deze wilt vinden, kunt u zoeken naar Lost quorum of Cluster service has terminated omdat deze mogelijk aanwezig is tijdens de wijziging van de rol van de beschikbaarheidsgroep of failover.

00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: Lost quorum (1)
00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: goingAway: 0, core.IsServiceShutdown: 0
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925)
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [NETFT] Cluster Service preterminate succeeded.
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925), executing OnStop
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM]: Shutting down, so unloading the cluster database.
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM] Shutting down, so unloading the cluster database (waitForLock: false).
000019cc.000019d0::2022/12/15-14:26:02.654 WARN [RHS] Cluster service has terminated. Cluster.Service.Running.Event got signaled.

Een andere manier om deze gebeurtenis te identificeren, is door het Windows-systeemlogboek te doorzoeken:

Critical SQL19AGN1.CSSSQL 1135 Microsoft-Windows-FailoverClusterin Node Mgr NT AUTHORITY\SYSTEM Cluster node 'SQL19AGN2' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
Critical SQL19AGN1.CSSSQL 1177 Microsoft-Windows-FailoverClusterin Quorum Manager NT AUTHORITY\SYSTEM The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Een clusterstatus-gebeurtenis diagnosticeren

De fouten in het Windows-gebeurtenislogboek (gebeurtenissen 1135 en 1177) suggereren dat de netwerkverbinding een oorzaak van de gebeurtenis is. Dit is de meest voorkomende reden dat er een probleem met de clusterstatus wordt gedetecteerd. In het volgende voorbeeld ziet u dat andere clusterlidservers niet konden communiceren met deze server die als host fungeert voor de primaire replica van de beschikbaarheidsgroep en dat dit probleem het verwijderen van het clusterknooppunt van het cluster heeft geactiveerd:

00000fe4.00001edc::2022/12/14-22:44:36.870 INFO [NODE] Node 1: New join with n3: stage: 'Attempt Initial Connection' status (10060) reason: 'Failed to connect to remote endpoint <endpoint address>'
00000fe4.00001620::2022/12/15-14:26:02.050 INFO [IM] got event: Remote endpoint <endpoint address> unreachable from <endpoint address>
00000fe4.00001620::2022/12/15-14:26:02.050 WARN [NDP] All routes for route (virtual) local <local address> to remote <remote address> are down
00000fe4.0000179c::2022/12/15-14:26:02.053 WARN [NODE] Node 1: Connection to Node 2 is broken. Reason GracefulClose(1226)' because of 'channel to remote endpoint <endpoint address> is closed'

U kunt in het clusterlogboek zoeken naar bewijs van een verbindingsfout met het knooppunt. Zoek vanaf de locatie in het clusterlogboek waar u hebt gevonden Lost quorum, achterwaarts naar tekenreeksen zoals Failed to connect to remote endpoint, unreachableen is broken.

Oplossing

Zorg ervoor dat de clusterstatuscontrole geschikt is voor de hostomgeving. Zie het overzicht van Windows Server-failoverclusters - SQL Server op Virtuele Azure-machines voor meer informatie over SQL Server AlwaysOn-beschikbaarheidsgroepen die worden gehost in Microsoft Azure.

Als dit nodig is, kunt u contact opnemen met de ondersteuning voor hoge beschikbaarheid van Microsoft Windows om een ondersteuningsincident te openen.

De SQL Server-service is offline: een AlwaysOn-status-gebeurtenis

AlwaysOn-statuscontrole kan detecteren of de SQL Server-service die als host fungeert voor de primaire replica van de beschikbaarheidsgroep, niet meer wordt uitgevoerd.

Symptomen

Hier volgt een voorbeeld van het clusterlogboekrapport voor de beschikbaarheidsgroepsrol 'ag' die een fout aangeeft omdat QueryServiceStatusEx een proces-id 0is geretourneerd:

00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] QueryServiceStatusEx returned a process id 0
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] SQL server service is not alive
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] Resource Alive result 0.
00001898.0000185c::2023/02/27-13:27:41.121 WARN [RHS] Resource ag IsAlive has indicated failure.

Afsluitende gebeurtenissen van SQL Service diagnosticeren

Controleer het Windows-gebeurtenislogboek en het SQL Server-foutenlogboek voor een onverwacht afsluiten van SQL Server.

Als SQL Server is afgesloten door een systeemafsluiting of een administratieve afsluiting, ziet u de volgende vermelding in het FOUTENlogboek van SQL Server:

2023-03-10 09:38:46.73 spid9s SQL Server is terminating in response to a 'stop' request from Service Control Manager. This is an informational message only. No user action is required.

In het Windows-systeemlogboek wordt de volgende foutvermelding weergegeven:

Information 3/10/2023 9:41:06 AM Service Control Manager 7036 None The SQL Server (MSSQLSERVER) service entered the stopped state.

In het Windows-systeemlogboek wordt de volgende foutvermelding weergegeven als SQL Server onverwacht wordt afgesloten:

Error 3/10/2023 8:37:46 AM Service Control Manager 7034 None The SQL Server (MSSQLSERVER) service terminated unexpectedly. It has done this 1 time(s).

Controleer het einde van het SQL Server-foutenlogboek op aanwijzingen. Als het foutenlogboek plotseling eindigt, betekent dit dat het geforceerd is afgesloten. Als SQL Server bijvoorbeeld is beëindigd met behulp van Taakbeheer, zou in het foutenrapport van SQL Server geen informatie worden weergegeven over interne problemen die ertoe kunnen hebben geleid dat het proces werd afgesloten.

Oplossing

Zorg ervoor dat geautoriseerde database- en systeembeheerders toegang hebben tot het systeem om onverwachte beëindigingen van de SQL Server-service te minimaliseren. Nadat u de gebeurtenislogboeken hebt bekeken, onderzoekt u waarom een service onverwacht moest worden beëindigd.

Als een probleem met de interne sql Server-status ertoe heeft geleid dat SQL Server onverwacht werd beëindigd, kunnen er aanwijzingen zijn van een mogelijke fatale uitzondering (inclusief een diagnostisch geheugendumpbestand dat wordt gegenereerd) aan het einde van het SQL-foutenlogboek. Bekijk de aanwijzingen en voer de benodigde actie uit. Als u een dumpbestand vindt, kunt u contact opnemen met de ondersteuning van Microsoft SQL Server en het SQL Server-foutenlogboek en de inhoud van het dumpbestand opgeven voor verder onderzoek.

Time-out lease: een AlwaysOn-statusgebeurtenis

AlwaysOn maakt gebruik van een 'lease'-mechanisme om de status van de computer te bewaken waarop SQL Server is geïnstalleerd. De standaardtime-out voor lease is 20 seconden.

Symptomen

Hier volgt een voorbeelduitvoer van een Time-out van een AlwaysOn-lease vanuit het clusterlogboek. U kunt deze tekenreeksen doorzoeken om een time-out voor de lease in het clusterlogboek te vinden.

00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Availability Group lease is no longer valid 
00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0. 
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:35:57.0, 98.068572, 509227008.000000, 0.000395, 0.000350 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:7.0, 12.314941, 451817472.000000, 0.000278, 0.000266 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:17.0, 17.270742, 416096256.000000, 0.000376, 0.000292 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:27.0, 38.399895, 416301056.000000, 0.000446, 0.000304 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:37.0, 100.000000, 417517568.000000, 0.001292, 0.000666

Zie de sectie Leasemechanisme in Mechanica en richtlijnen voor time-outs voor lease-, cluster- en statuscontroletime-outs voor AlwaysOn-beschikbaarheidsgroepen voor meer informatie over time-outs voor lease.

Time-outgebeurtenissen voor AlwaysOn-lease vaststellen en oplossen

Er zijn twee belangrijke problemen die een time-out voor een lease kunnen activeren:

• SQL Server-geheugendump: wanneer SQL Server bepaalde interne status gebeurtenissen detecteert, zoals een toegangsfout, een bewering of scheduler-impasse, wordt er een diagnostisch dumpbestand (.mdmp) gegenereerd in de map SQL Server \LOG . Het proces voor het genereren van een geheugendump onderbreekt de uitvoering van SQL Server gedurende een korte periode. In die periode kan het leasemechanisme een gebrek aan servicerespons en triggeractie detecteren. Zie Impact van het genereren van dumps voor meer informatie.

• Een prestatieprobleem voor het hele systeem: een time-out voor de lease geeft niet noodzakelijkerwijs een probleem met de SQL Server-status aan. In plaats daarvan kan het duiden op een systeembreed statusprobleem dat ook van invloed is op de status van de SQL Server-server.

  • Hoog CPU-gebruik op het systeem (dicht bij 100%).
  • Onvoldoende geheugen: weinig virtueel geheugen en/of een van de processen wordt uitgepaginad.
  • WSFC offline vanwege quorumverlies
  • VM-beperking die van invloed is op de prestaties en waardoor de lease verloopt.

Oplossing

Zie MSSQLSERVER_19407 voor gedetailleerde stappen voor probleemoplossing. Dit zijn de twee meest voorkomende problemen:

diagnostische gegevens van 1. SQL serverdumpbestand

SQL Server kan een probleem met de interne status detecteren, zoals een toegangsschending, assertie of impasseplanners. In dit geval genereert het programma een minidumpbestand (.mdmp) in de map SQL Server \LOG van het SQL Server-proces voor diagnose. Het SQL Server-proces wordt enkele seconden geblokkeerd terwijl het minidumpbestand naar de schijf wordt geschreven. Gedurende deze tijd hebben alle threads binnen het SQL Server-proces een geblokkeerde status, waaronder de leasethread die wordt bewaakt door AlwaysOn-statuscontrole. Daarom kan AlwaysOn een time-out voor de lease detecteren.

**Dump thread - spid = 0, EC = 0x0000000000000000
***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\LOG\SQLDump0001.txt
* *******************************************************************************
*
* BEGIN STACK DUMP:
*   11/02/14 21:21:10 spid 1920
*
* Deadlocked Schedulers
*
* *******************************************************************************
* -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000002BA
Error: 19407, Severity: 16, State: 1.
The lease between availability group 'ag' and the Windows Server Failover Cluster has expired. A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster. To determine whether the availability group is failing over correctly, check the corresponding availability group resource in the Windows Server Failover Cluster.

Om dit probleem op te lossen, moet de diagnose van het geheugendumpbestand worden onderzocht op de hoofdoorzaak. Neem contact op met de ondersteuning van Microsoft SQL Server om het SQL Server-foutenlogboek en de inhoud van het dumpbestand te verstrekken voor verder onderzoek.

2. Hoog CPU-gebruik of ander probleem met systeemprestaties

Een time-out voor een lease geeft een prestatieprobleem aan dat van invloed is op het hele systeem, inclusief SQL Server. Om het systeemprobleem vast te stellen, rapporteert AlwaysOn-statusdiagnose prestatiemetergegevens in het clusterlogboek en bevat de time-outgebeurtenis voor leases. De prestatiegegevens duren ongeveer 50 seconden voorafgaand aan de time-outgebeurtenis van de lease, rapportage over CPU-gebruik, vrije geheugen en schijflatentie.

Hier volgt een voorbeeld van de gerapporteerde prestatiegegevens met een time-out voor de lease in het clusterlogboek. In deze voorbeelduitvoer is een hoog algemeen CPU-gebruik dat mogelijk te maken heeft met de time-out van de lease.

00000f90.000015c0::2020/08/07-14:16:41.378 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00000f90.000015c0::2020/08/07-14:16:41.382 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:20.0, 83.266073, 31700828160.000000, 0.018094, 0.015752
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:30.0, 93.653224, 31697063936.000000, 0.038590, 0.026897
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:40.0, 94.270691, 31696265216.000000, 0.166000, 0.038962
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:50.0, 90.272016, 31695409152.000000, 0.215141, 0.106084
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:16:1.0, 99.991336, 31695892480.000000, 0.046983, 0.035440

Als de prestatiegegevens een hoog CPU-gebruik, een lage geheugenconditie of een hoge schijflatentie op het moment van een time-out van de lease tonen, begint u met het verzamelen van prestatiemetergegevens voor de volledige dag op de primaire replica om deze symptomen te onderzoeken. Door prestatiemetergegevens gedurende een langere periode vast te leggen, kunt u de basislijn- en piekwaarden voor deze resources beter identificeren en wijzigingen in deze resources bewaken wanneer er een time-out optreedt voor de lease. Wanneer u deze gegevens verzamelt, moet u overwegen of er bepaalde geplande of ad-hocworkloads in SQL Server zijn die correleren met de tijd van deze resourceproblemen en statusgebeurtenissen.

U moet ook tellers vastleggen die hetzelfde systeemresourcegebruik rapporteren, waaronder het volgende:

• Processor Information::% Processor Time
• Memory::Available MBytes
• Logical Disk::Avg. Disk sec/Read
• Logical Disk::Avg. Disk sec/Write
• Logical Disk::Avg. Disk Read Queue Length
• Logical Disk::Avg. Disk Write Queue Length
• MSSQLServer:SQL Statistics::Batch Requests/sec

Time-out van statuscontrole: een AlwaysOn-statusgebeurtenis

AlwaysOn maakt gebruik van een statuscontrolemechanisme om de status van SQL Server te bewaken en de mogelijkheid voor clienttoepassingen om verbinding te maken.

Symptomen

Wanneer een replica van een beschikbaarheidsgroep overgaat naar de primaire rol, brengt AlwaysOn-statuscontrole een lokale ODBC-verbinding tot stand met het SQL Server-exemplaar. Hoewel AlwaysOn is verbonden en bewaakt, wordt er een time-out geactiveerd als SQL Server niet reageert via de ODBC-verbinding binnen de periode die is ingesteld voor de time-out van de statuscontrole van de beschikbaarheidsgroep (standaard 30 seconden), wordt er een time-outgebeurtenis voor statuscontrole geactiveerd. In dit geval gaat de beschikbaarheidsgroep over van de primaire rol naar de rol Oplossen en start de failover, als deze is geconfigureerd om dit te doen.

Zie de sectie 'Time-outs voor statuscontrole' in Mechanica en richtlijnen voor time-outs voor lease, cluster en statuscontrole voor AlwaysOn-beschikbaarheidsgroepen voor meer informatie over time-outs voor statuscontrole.

Hier volgt een time-out voor de statuscontrole van AlwaysOn, zoals gerapporteerd in het clusterlogboek:

0000211c.00002d70::2021/02/24-02:50:01.890 WARN [RES] SQL Server Availability Group: [hadrag] Failed to retrieve data column. Return code -1
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Resource Alive result 0.
0000211c.00002594::2021/02/24-02:50:02.453 WARN [RHS] Resource AG IsAlive has indicated failure.
00001278.00002ed8::2021/02/24-02:50:02.453 INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'AG', gen(0) result 1/0.

Time-outgebeurtenis van AlwaysOn-statuscontrole vaststellen en oplossen

De volgende sectie helpt u bij het controleren van de SQL Server-logboeken op 'bread crumb'-gebeurtenissen die u kunt vinden en die betrekking hebben op time-outs van AlwaysOn-statuscontroles die worden gedetecteerd en gerapporteerd. De logboeken die hier worden gecontroleerd, bevatten het clusterlogboek (waarbij de time-out van de statuscontrole wordt bevestigd), de system_health uitgebreide gebeurtenislogboeken en SQL Server-foutenlogboeken (beide gevonden in de map SQL Server \LOG ) en het Windows-systeemgebeurtenislogboek. Gebruik deze en andere logboeken om te zoeken naar correlatiegebeurtenissen die u kunnen helpen de oorzaak van de time-out van de statuscontrole te bepalen.

1. Controleren op niet-rendementende scheduler-gebeurtenissen

De time-out van de AlwaysOn-statuscontrole wordt vaak veroorzaakt door gebeurtenissen die niet opleveren in SQL Server. Wanneer SQL Server detecteert dat een thread niet heeft opgeleverd op een scheduler, wordt er een rapport weergegeven dat er een niet-rendementende scheduler-gebeurtenis is opgetreden. Als u andere taken ziet op dezelfde planner die geen CPU-tijd ontvangt, is dit het primaire teken van een niet-rendementende planner. Dit gedrag kan leiden tot een vertraagde uitvoering van deze taken en 'starve' workloads die zijn toegewezen aan een bepaalde scheduler van CPU-tijd.

Volg deze stappen om te controleren op niet-rendementende scheduler-gebeurtenissen:

1. Controleer de uitgebreide gebeurtenislogboeken van SQL Server system_health om te bepalen of een niet-opleverende scheduler-gebeurtenis van een bepaald type rond de tijd van de time-outgebeurtenis van de AlwaysOn-statuscontrole is gerapporteerd. Niet-opleverende gebeurtenissen die u kunt vinden, zijn onder andere:

   • scheduler_monitor_non_yielding_ring_buffer_recorded
   • scheduler_monitor_non_yielding_iocp_ring_buffer_recorded
   • scheduler_monitor_stalled_dispatcher_ring_buffer_recorded
   • scheduler_monitor_non_yielding_rm_ring_buffer_recorded

2. Open de uitgebreide gebeurtenislogboeken van de SQL Server-systeemstatus op de primaire replica tot het tijdstip van de time-out van de vermoedelijke statuscontrole.

3. Ga in SQL Server Management Studio (SSMS) naar Bestand > openen en selecteer Uitgebreide gebeurtenisbestanden samenvoegen.

4. Selecteer de knop Toevoegen.

5. Navigeer in het dialoogvenster Bestand openen naar de bestanden in de map SQL Server \LOG .

6. Houd Control ingedrukt en selecteer vervolgens de bestanden waarvan de namen beginnen.system_health_xxx.xel

7. Selecteer OK openen>.

8. Filter de resultaten. Klik met de rechtermuisknop op een gebeurtenis onder de naamkolom en selecteer Filteren op deze waarde.

   

9. Definieer een filter om rijen te sorteren waarin de waarden in de naamkolom staan yield, zoals wordt weergegeven in de volgende schermopname. Dit retourneert allerlei niet-resulterende gebeurtenissen die mogelijk zijn vastgelegd in de system_health logboeken.

   

10. Vergelijk de tijdstempels om te zien of er niet-opleverende gebeurtenissen waren op het moment van de time-out van de statuscontrole. Dit is de time-out voor statuscontrole, zoals gerapporteerd in het clusterlogboek:

    0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1: [hadrag] Resource Alive result 0.
    

    U kunt zien dat er niet-opleverende gebeurtenissen zijn opgetreden op het moment van de time-out van de statuscontrole.

    

Als er niet-opbrengstgebeurtenissen worden gedetecteerd, controleert u de oorzaak van de niet-opbrengstgebeurtenis. Neem contact op met het ondersteuningsteam van SQL Server om de niet-opleverende gebeurtenissen te onderzoeken.

2. Controleer het SQL Server-foutenlogboek

Controleer het SQL Server-foutenlogboek voor het correleren van gebeurtenissen op het moment van de time-out van de statuscontrole. Deze gebeurtenissen kunnen 'broodkruimels' bieden die verdere stappen voorstellen om de hoofdoorzaak van de time-outs van de statuscontrole te bepalen.

In de volgende logboekvermelding ziet u bijvoorbeeld dat er een time-out voor de statuscontrole is opgetreden in het clusterlogboek:

0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Resource Alive result 0.

In het foutenlogboek van SQL Server meldt SQL Server binnen enkele seconden na de time-out van de statuscontrole dat er ernstige I/O-latentie is gedetecteerd:

2021-02-23 20:49:54.64 spid12s SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\agdb_log.ldf] in database id 12. The OS file handle is 0x0000000000001594. The offset of the latest long I/O is: 0x000030435b0000. The duration of the long I/O is: 26728 ms.

Bekijk het systeemgebeurtenislogboek voor mogelijke systeemopwijzingsbewijzing die kan worden gerelateerd aan de time-outgebeurtenis van de statuscontrole. Wanneer u het Windows-systeemgebeurtenislogboek bekijkt, kan er een I/O-probleem optreden dat tegelijkertijd wordt gerapporteerd voor dezelfde time-out voor statuscontrole:

02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"Reset to device, \Device\<device ID>, was issued."
02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"The IO operation at logical block address <block address> for Disk 6 (PDO name: \Device\<device ID>) was retried."

SQL Server-status: een AlwaysOn-status-gebeurtenis

AlwaysOn bewaakt verschillende soorten SQL Server-statusevenementen. Hoewel sql Server als host fungeert voor een primaire replica van een beschikbaarheidsgroep, wordt SQL Server continu uitgevoerd sp_server_diagnostics die rapporteert over sql Server-status met behulp van verschillende onderdelen. Wanneer er statusproblemen worden gedetecteerd, sp_server_diagnostics rapporteert u een fout voor dat specifieke onderdeel en stuurt u de resultaten vervolgens terug naar het AlwaysOn-statusdetectieproces. Wanneer er een fout wordt gerapporteerd, geeft de rol Beschikbaarheidsgroep de status Mislukt en mogelijke failover weer als de beschikbaarheidsgroep hiervoor is geconfigureerd.

Symptomen

Hier volgt een voorbeeld van een probleem met de SQL Server-status, zoals gerapporteerd in sp_server_diagnostics het clusterlogboek. SQL Server rapporteert een foutstatus in het systeemonderdeel aan AlwaysOn-statuscontrole en de beschikbaarheidsgroep contoso-ag wordt overgezet naar een mislukte status.

INFO [RES] SQL Server Availability Group: [hadrag] SQL Server component 'system' health state has been changed from 'warning' to 'error' at 2019-06-20 15:05:52.330
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Resource Alive result 0.
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
WARN [RHS] Resource contoso-ag IsAlive has indicated failure.
INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'contoso-ag', gen(0) result 1/0.

Sql Server-statusevenementen diagnosticeren

Het type statusprobleem dat door SQL Server-status wordt gerapporteerd, moet de richting van de hoofdoorzaakanalyse dicteren.

Wanneer u een beschikbaarheidsgroep implementeert, wordt deze FAILURE_CONDITION_LEVEL standaard ingesteld als drie. Hiermee wordt bewaking van sommige, maar niet alle SQL Server-statusprofielen geactiveerd. Op het standaardniveau activeert Always On een statusgebeurtenis wanneer SQL Server te veel dumpbestanden, een schending van schrijftoegang of een zwevende spinlock produceert. Als u de beschikbaarheidsgroep instelt op niveau vier of vijf, worden de typen statusproblemen van SQL Server uitgebreid die worden bewaakt. Zie Een flexibel beleid voor automatische failover configureren voor een beschikbaarheidsgroep - SQL Server AlwaysOn voor meer informatie over de AlwaysOn-monitors van SQL Server.

Voer de volgende stappen uit om het probleem met specifieke status van AlwaysOn te identificeren:

1. Open de diagnostische uitgebreide gebeurtenislogboeken van het SQL Server-cluster op de primaire replica tot het tijdstip waarop de vermoedelijke SQL Server-statusgebeurtenis is opgetreden.

2. Ga in SSMS naar Bestand>openen en selecteer Uitgebreide gebeurtenisbestanden samenvoegen.

3. Selecteer Toevoegen.

4. Navigeer in het dialoogvenster Bestand openen naar de bestanden in de map SQL Server \LOG .

5. Druk op Control, selecteer de bestanden waarvan de namen overeenkomen <servername>_<instance>_SQLDIAG_xxx.xelen selecteer Vervolgens OK>openen.

   

   U ziet een nieuw venster met tabbladen in SSMS met de uitgebreide gebeurtenissen, zoals wordt weergegeven in de volgende schermopname.

6. Als u een probleem met de SQL Server-status wilt onderzoeken, zoekt u de waarde waarvan state_desc de component_health_result waarde iserror. Hier volgt een voorbeeld van een systeemonderdeel gebeurtenis die een fout heeft gerapporteerd aan AlwaysOn-statuscontrole:

   

7. Dubbelklik op de gegevenskolom in het onderste deelvenster. Hiermee opent u de gedetailleerde onderdeelgegevens in een nieuw venstervenster van SSMS voor revisie. De systeemonderdeelgegevens zien er als volgt uit:

   

   De gegevens 'totalDumprequests=186' geven aan dat er te veel diagnostische gebeurtenissen voor dumpbestanden zijn gegenereerd op deze SQL Server. Dit is de reden dat het systeemonderdeel een foutstatus heeft gerapporteerd. Wanneer AlwaysOn-statuscontrole deze foutstatus ontvangt, wordt een status van een beschikbaarheidsgroep geactiveerd. U kunt ook controleren of er geen schendingen van schrijftoegang of zwevende spinlocks zijn gedetecteerd op basis van de gegevens in de systeemonderdeelgegevens.

Oplossing

Afhankelijk van het type probleem dat u detecteert, moet u het dienovereenkomstig oplossen. Aangezien het artikel Over het configureren van een flexibel beleid voor automatische failover voor een beschikbaarheidsgroep - SQL Server AlwaysOn-artikel wordt besproken, kunnen er verschillende problemen zijn die dit tot gevolg hebben. Enkele voorbeelden:

• De SQL Server-service is niet beschikbaar.
• Time-out voor lease.
• De beschikbaarheidsreplica heeft de status Mislukt.
• Geheugendumps gegenereerd door zwevende spinlocks, toegangsschendingen of te veel geheugendumps die in een korte periode zijn gegenereerd.
• Permanente out-of-memoryvoorwaarde in de interne SQL Server-resourcegroep.
• Detectie van de impasse van Scheduler.
• Detectie van een onoplosbare impasse.

Als dit nodig is, neemt u contact op met de ondersteuning van SQL Server om een ondersteuningsincident te openen voor verdere hulp bij het vinden van de hoofdoorzaak voor deze interne SQL Server-statusproblemen