Problemen met automatische failover in omgevingen met SQL Server 2012 AlwaysOn

BUG #: 184978 (Contentbeheer)

Samenvatting

Microsoft SQL Server 2012 AlwaysOn beschikbaarheidsgroepen kunnen worden geconfigureerd voor automatische failover. Dus als een probleem voor de gezondheid op het exemplaar van SQL Server die als voor de primaire replica host fungeert wordt gevonden, kan de rol van primair apparaat worden on de automatische failover-partner (secundaire replica). De secundaire replica niet kan echter altijd overgestapt naar de primaire rol, in plaats daarvan alleen aan de rol van omzetten wordt overgestapt. Als de primaire replica wordt geretourneerd aan de orde zijn, is er geen replica in de primaire rol. Bovendien zijn de beschikbaarheid van databases niet toegankelijk.

In dit artikel worden enkele algemene oorzaken van mislukte automatische failover. Ook dit artikel worden de stappen die u uitvoeren kunt om de oorzaak van deze fouten opsporen.

Meer informatie

De symptomen bij een automatische failover met succes wordt geactiveerd

Als een automatische failover wordt gegenereerd op het exemplaar van SQL Server die als voor de primaire replica, de secundaire replica overgangen naar de rol van omzetten en vervolgens naar de primaire rol host fungeert. Bovendien foutberichten in het rapport van SQL Server logboek de volgende strekking:

De status van de beschikbaarheid van lokale replica in beschikbaarheidsgroep ' <groepsnaam>' is uit 'RESOLVING_NORMAL' gewijzigd in 'PRIMARY_PENDING'

De status van de beschikbaarheid van lokale replica in beschikbaarheidsgroep ' <groepsnaam>' is uit 'PRIMARY_PENDING' gewijzigd in 'PRIMARY_NORMAL'

Image 1

Opmerking De overgangen secundaire replica is van de status van een RESOLVING_NORMAL om de status van een PRIMARY_NORMAL .

De symptomen als automatische failover uitgevoerd worden

Als een automatische failover-gebeurtenis niet afgerond wordt, komt de secundaire replica niet met succes overgang naar de primaire rol. De beschikbaarheid van replica wordt gemeld dat deze replica oplossen status is. Bovendien hebben de beschikbaarheid van databases rapport dat ze in de status Niet synchroniseren en toepassingen geen toegang tot deze databases.

Bijvoorbeeld in de volgende afbeelding rapporteert SQL Server Management Studio dat de replica secundaire status oplossen omdat het proces voor automatische failover kan de secundaire replica overgaan op de primaire rol:
Image

In dit artikel beschrijft enkele mogelijke redenen dat automatische failover lukt dit niet, en het vaststellen van de oorzaak.

De beschikbaarheidsgroep heeft Windows cluster resource eigenschappen, zoals de eigenschap Maximum fouten in de opgegeven periode . Deze eigenschap wordt gebruikt om te voorkomen dat de onbeperkte verplaatsing van een geclusterde bron als er meerdere knooppuntfouten optreden.

Om te onderzoeken en vaststellen of dit de oorzaak van mislukte failover is, Raadpleeg het logboek van Windows cluster (Cluster.log) en controleer vervolgens de eigenschap. Ga hiervoor als volgt te werk:

Stap 1: Reeld van de gegevens in het logboek van Windows cluster (Cluster.log)

  1. Windows PowerShell gebruiken voor het genereren van het clusterlogboek van Windows op het clusterknooppunt dat als host voor de primaire replica fungeert. Voer hiervoor de volgende cmdlet in een verhoogde PowerShell-venster op het exemplaar van SQL Server die als voor de primaire replica host fungeert:

    Get-ClusterLog –Node <SQL Server node name> –TimeSpan 15


    Image 4
    Opmerkingen

    • De parameter - TimeSpan 15 in deze stap wordt gebruikt in de veronderstelling dat het probleem wordt gediagnosticeerd is opgetreden in de vorige 15 minuten.

    • Standaard wordt het logboekbestand gemaakt in % WINDIR%\cluster\reports.

  2. Open het bestand Cluster.log in Kladblok om te controleren het clusterlogboek van Windows.

  3. Klik op bewerken in Kladblok en klik op Zoekenen zoeken naar de tekenreeks "failoverCount" aan het einde van het bestand. Bekijk de resultaten en u ziet een bericht met de volgende strekking weergegeven:

    Geen failover groep <bronnaam> failoverThresholdSetting <getal> 2 computedFailoverThreshold 3 failoverCount

    Image 5



Stap 2: Controleer de eigenschap Maximum fouten in de opgegeven periode

  1. Failover-clusterbeheer starten.

  2. Klik in het navigatiedeelvenster op rollen.

  3. Klik met de rechtermuisknop op de geclusterde bron en klik vervolgens op Eigenschappenin het venster rollen .

  4. Klik op het tabblad Failover en controleert of de waarde van Maximum fouten in de opgegeven periode .Image 3
    Opmerking Standaard geeft aan dat als de geclusterde bron niet drie keer in een periode van zes uur, het in de status mislukt blijven moet. Voor een beschikbaarheidsgroep betekent dit dat de replica is links in de staat oplossen .


ConclusieNadat u de logboekbestanden hebt geanalyseerd, kunt u vinden dat de waarde 3 failoverCount groter dan de waarde van de computedFailoverThreshold van 2 is. Windows-cluster kan daarom de failover-bewerking van de resource beschikbaarheid groep aan de failover-partner niet voltooien.

OplossingVerhoog de waarde van de Maximale fouten in de opgegeven periode dit probleem op te lossen.

Opmerking Hogere waarde, kan het probleem niet oplossen. Het is mogelijk een belangrijker probleem dat ervoor zorgt de beschikbaarheidsgroep vele malen in een korte periode dat, 15 minuten, standaard is mislukt. Hogere waarde mogelijk alleen de beschikbaarheidsgroep keer voordat het resterende status mislukt mislukken. Het is raadzaam een agressieve probleemoplossing inspanning om te bepalen waarom de automatische failover blijft optreden.

De SQL Server-Database-Engine resource DLL maakt verbinding met het exemplaar van SQL Server die als host de primaire replica fungeert met behulp van ODBC gezondheid te controleren. De aanmeldingsgegevens die worden gebruikt voor deze verbinding zijn de lokale SQL Server NT AUTHORITY\SYSTEM aanmeldingsaccount. Standaard is deze lokale aanmeldingsaccount de volgende machtigingen verleend:

  • Beschikbaarheid groepen wijzigen

  • Verbinding maken met SQL

  • Status weergeven


Als de aanmeldingsaccount NT AUTHORITY\SYSTEM ontbreekt een van deze machtigingen op de automatische failover-partner (secundaire replica), kan geen SQL Server start statusdetectie wanneer een automatische failover plaatsvindt. Daarom kan niet de tweede replica overgaan tot de primaire rol. Als u wilt onderzoeken en vaststellen of dit de oorzaak is, bekijk het clusterlogboek van Windows. Ga hiervoor als volgt te werk:

  1. Windows PowerShell gebruiken voor het genereren van het clusterlogboek van Windows op het clusterknooppunt. Hiertoe de volgende cmdlet in een verhoogde PowerShell-venster worden uitgevoerd op het exemplaar van SQL Server die fungeert als host voor de secundaire replica die niet aan de primaire rol heeft:

    Get-ClusterLog –Node <SQL Server node name> –TimeSpan 15

    Image 4

  2. Open het bestand Cluster.log in Kladblok om te controleren het clusterlogboek van Windows.

  3. Hier vindt u foutberichten met de volgende strekking weergegeven:

    Kan de opdracht diagnose uitvoeren.
    De gebruiker heeft geen toestemming om deze actie te voeren.

    Image 6


ConclusieHet bestand Cluster.log wordt gemeld dat er een probleem met toestemming wanneer de opdracht diagnose door SQL Server wordt uitgevoerd. In dit voorbeeld is de storing veroorzaakt door de machtiging View server state verwijderen van de account NT AUTHORITY\SYSTEM aanmelding op het exemplaar van SQL Server die als voor de secundaire replica van een automatische failover-paar host fungeert.

OplossingDit probleem oplossen door voldoende machtigingen verlenen voor de aanmeldingsaccount voor de detectie van de gezondheid van de bron-DLL van SQL Server-Database-Engine van NT AUTHORITY\SYSTEM .

Automatisch een failover uitvoeren, zijn alle beschikbaarheid databases die zijn gedefinieerd in de beschikbaarheidsgroep in een GESYNCHRONISEERDE staat tussen de replica van de primaire en de secundaire. Wanneer een automatische failover plaatsvindt, moet deze voorwaarde synchronisatie worden voldaan om ervoor te zorgen dat er geen gegevens verloren gaan is. Daarom als een beschikbaarheid van database in de beschikbaarheid in de status synchroniseren of niet gesynchroniseerd , automatische failover niet met succes gewijzigd de secundaire replica in de primaire rol.

Ga naar de sectie 'Voorwaarden vereist voor een automatische Failover' en de sectie "synchrone commit replica's ondersteunen twee instellingen" van de volgende MSDN-webpagina voor meer informatie over de vereiste voorwaarden voor een automatische failover:

Failover- en failover-modus in AlwaysOn beschikbaarheidsgroepenAls u wilt onderzoeken en vaststellen of dit de oorzaak van mislukte failover is, bekijk het foutenlogboek van SQL Server. U ziet een foutbericht met de volgende strekking weergegeven:

Een of meer databases worden niet gesynchroniseerd of geen deel uitmaken van de beschikbaarheidsgroep

Image 8

Als u wilt controleren of de databases beschikbaar in de GESYNCHRONISEERDE -status waren, als volgt te werk:

  1. Verbinding maken met de secundaire replica.

  2. De volgende SQL-script om de waarde van de is_failover_ready voor alle beschikbaarheid databases in de beschikbaarheidsgroep die heeft geen failover worden uitgevoerd.
    Opmerking De waarde nul voor een van de databases beschikbaarheid kunt voorkomen dat automatische failover en deze waarde geeft aan dat de beschikbaarheid van database niet SYNCHRONIZED.

    Select database_name, is_failover_ready from sys.dm_hadr_database_replica_cluster_states where replica_id in (select replica_id from sys.dm_hadr_availability_replica_states)

    Image 10


ConclusieEen geslaagde automatische failover van de beschikbaarheidsgroep, moet alle beschikbaarheid databases in de GESYNCHRONISEERDE status. Ga naar de volgende MSDN-website voor meer informatie over de modi beschikbaar:

Modi van de beschikbaarheid van AlwaysOn beschikbaarheidsgroepen

Auteur: daleche
Tech Reviewer: ramakoni; cmathews; cephas.lin; luis.vargas
Redacteur: v-mordew

Meer hulp nodig?

Uw vaardigheden uitbreiden
Training verkennen
Als eerste nieuwe functies krijgen
Deelnemen aan Microsoft insiders

Was deze informatie nuttig?

Bedankt voor uw feedback.

Hartelijk dank voor uw feedback! Het lijkt ons een goed idee om u in contact te brengen met een van onze Office-ondersteuningsagenten.

×