Delen via

Problemen met SQL Server AlwaysOn oplossen

Dit artikel helpt u bij het oplossen van het veelvoorkomende probleem met de AlwaysOn-configuratie op SQL Server.

Notitie

Zie AlwaysOn-problemen met SQL Server oplossen voor stapsgewijze instructies in dit artikel.

Oorspronkelijke productversie: SQL Server 2012 Enterprise, SQL Server 2014 Enterprise, SQL Server 2016 Enterprise
Oorspronkelijk KB-nummer: 10179

Belangrijke opmerkingen

Ik heb aanwijzingen nodig voor het instellen en configureren van AlwaysOn-beschikbaarheidsgroepen

Als u documentatie zoekt over het instellen van de AlwaysOn-configuratie, raadpleegt u de volgende documenten:

Aan de slag met AlwaysOn-beschikbaarheidsgroepen (SQL Server): het document bevat antwoorden op veel vragen over beschikbaarheidsgroepen en installatie. Als u alle stappen in dit artikel volgt en vereisten, beperkingen en aanbevelingen voor AlwaysOn-beschikbaarheidsgroepen (SQL Server) bekijkt, kunt u veel problemen voorkomen die u kunt tegenkomen bij het instellen en onderhouden van beschikbaarheidsgroepen in uw omgeving.

Aanvullende bronnen

Als deze informatie niet nuttig is, raadpleegt u meer informatie over AlwaysOn-beschikbaarheidsgroepen.

Ik ondervind problemen met het configureren van AlwaysOn-beschikbaarheidsgroepen

Veelvoorkomende configuratieproblemen zijn AlwaysOn-beschikbaarheidsgroepen zijn uitgeschakeld, accounts zijn onjuist geconfigureerd, het eindpunt voor databasespiegeling bestaat niet, het eindpunt is niet toegankelijk (SQL Server-fout 1418), netwerktoegang bestaat niet en er mislukt een opdracht voor de joindatabase (SQL Server-fout 35250). Raadpleeg het volgende document voor hulp bij het oplossen van deze problemen:

Problemen met configuratie van AlwaysOn-beschikbaarheidsgroepen oplossen (SQL Server)

Aanvullende koppeling: Oplossing: Fout 41009 wanneer u meerdere beschikbaarheidsgroepen probeert te maken

Als het probleem nog steeds bestaat, raadpleegt u meer informatie over AlwaysOn-beschikbaarheidsgroepen.

Ik ondervind problemen met de listenerconfiguratie (19471, 19476 en andere fouten)

Een van de meest voorkomende configuratieproblemen die klanten ondervinden, is het maken van listener voor beschikbaarheidsgroepen. De fouten zijn vergelijkbaar met het volgende:

  • Msg 19471, Niveau 16, Status 0, Regel 2De WSFC-cluster kan de netwerknaamresource niet online brengen met DE DNS-naam '' . De DNS-naam is mogelijk genomen of heeft een conflict met bestaande naamservices, of de WSFC-clusterservice wordt mogelijk niet uitgevoerd of is mogelijk niet toegankelijk. Gebruik een andere DNS-naam om naamconflicten op te lossen of controleer het WSFC-clusterlogboek voor meer informatie.

  • Msg 19476, Niveau 16, Staat 4, Regel 2De poging om de netwerknaam en het IP-adres voor de listener te maken, is mislukt. De WSFC-service wordt mogelijk niet uitgevoerd of is mogelijk niet toegankelijk in de huidige status, of de waarden die zijn opgegeven voor de netwerknaam en het IP-adres zijn mogelijk onjuist. Controleer de status van het WSFC-cluster en valideer de netwerknaam en het IP-adres bij de netwerkbeheerder.

De meeste tijd is het maken van listeners mislukt, wat resulteert in de vorige berichten, vanwege een gebrek aan machtigingen voor het clusternaamobject (CNO) in Active Directory om het computerobject van de listener te maken en te lezen. Raadpleeg de volgende artikelen voor het oplossen van dit probleem:

Als het probleem nog steeds bestaat, raadpleegt u meer informatie over AlwaysOn-beschikbaarheidsgroepen.

Automatische failover werkt niet zoals verwacht

Als u merkt dat de automatische failover niet werkt zoals verwacht tijdens het testen of in productie, raadpleegt u: Problemen met automatische failover oplossen in SQL Server 2012 AlwaysOn-omgevingen.

Onjuiste configuratie van maximumfouten in de opgegeven periode is een van de belangrijkste oorzaken voor het niet automatisch uitvoeren van een failover naar de secundaire. De standaardwaarde voor deze instelling is N-1, waarbij N het aantal replica's is. Zie de limiet voor maximale fouten van failoverclusters (groep) voor meer informatie.

Als het probleem nog steeds bestaat, raadpleegt u meer informatie over AlwaysOn-beschikbaarheidsgroepen.

Ik ondervind problemen bij het maken van verbinding met AlwaysOn-beschikbaarheidsgroepen

Nadat u de listener voor de beschikbaarheidsgroep voor een AlwaysOn-beschikbaarheidsgroep in SQL Server 2012 hebt geconfigureerd, kunt u de listener mogelijk niet pingen of er verbinding mee maken vanuit een toepassing. Mogelijk krijgt u een foutmelding die er ongeveer als volgt uitziet:

Sqlcmd: Fout: Microsoft SQL Native Client: time-out voor aanmelding is verlopen.

Als u deze en vergelijkbare fouten wilt oplossen, raadpleegt u het volgende:

Meer informatiekoppelingen:

Als het probleem nog steeds bestaat, raadpleegt u meer informatie over AlwaysOn-beschikbaarheidsgroepen.

Ik ondervind problemen met het configureren van AlwaysOn-beschikbaarheidsgroepen in mijn Azure VM (IaaS)

  1. Veel problemen met betrekking tot AlwaysOn treden op vanwege een onjuiste configuratie van de listener. Als u verbindingsproblemen ondervindt met de listener,

    1. Zorg ervoor dat u alle beperkingen van de ILB-listener leest en alle stappen hebt gevolgd die in het volgende artikel worden beschreven, met name aandacht voor afhankelijkheidsconfiguratie, IP-adres en verschillende andere parameters in het PowerShell-script.

    2. Als u het niet zeker weet, kunt u de listener verwijderen en opnieuw maken op basis van het bovenstaande document.

  2. Als u de VM onlangs naar een andere service hebt verplaatst of als de IP-adressen zijn gewijzigd, moet u de waarde van de IP-adresresource bijwerken om het nieuwe adres weer te geven en moet u het eindpunt met gelijke taakverdeling voor uw beschikbaarheidsgroep opnieuw maken. U kunt het IP-adres als volgt bijwerken met behulp van de Get of Set opdrachten:

    Get-ClusterResource "IPResourceName" | Set-ClusterParameter -name Address -value "w.x.y.z"

Aanbevolen documenten:

Als het probleem nog steeds bestaat, raadpleegt u meer informatie over AlwaysOn-beschikbaarheidsgroepen.

Het duurt lang om een failover van primaire naar secundaire of omgekeerde failover uit te voeren

Na een automatische failover of een geplande handmatige failover zonder gegevensverlies voor een beschikbaarheidsgroep, kan het zijn dat de failovertijd langer is dan de beoogde hersteltijd (RTO). Als u problemen met de oorzaken en mogelijke oplossingen wilt oplossen, raadpleegt u Problemen oplossen: Beschikbaarheidsgroep heeft RTO overschreden.

Als het probleem nog steeds bestaat, raadpleegt u meer informatie over AlwaysOn-beschikbaarheidsgroepen.

Wijzigingen op de primaire replica worden niet weergegeven of worden traag gerepliceerd naar de secundaire replica

U ziet mogelijk dat wijzigingen op de primaire replica niet tijdig worden doorgegeven aan secundaire replica. Probeer het volgende om deze problemen op te lossen:

Als het probleem nog steeds bestaat, raadpleegt u meer informatie over AlwaysOn-beschikbaarheidsgroepen.

De grootte van het transactielogboek voor mijn AG-databases beheren

U kunt de grootte van het transactielogboek verminderen door regelmatige back-ups te configureren op primaire of secundaire servers.

Bekijk de volgende onderwerpen voor meer informatie:

Als deze informatie niet nuttig is, raadpleegt u meer informatie over AlwaysOn-beschikbaarheidsgroepen.

Primaire of secundaire servers zijn getroffen in de oplossingsstatus of u ondervindt onverwachte failovers

Als het probleem nog steeds bestaat, raadpleegt u meer informatie over AlwaysOn-beschikbaarheidsgroepen.

Kan resources niet online brengen

Controleer of het lang duurt voordat de databases zijn hersteld door de berichten in het SQL-foutenlogboek te bekijken.

Als het probleem nog steeds bestaat, raadpleegt u meer informatie over AlwaysOn-beschikbaarheidsgroepen.

Veelgestelde vragen

  1. Is het mogelijk om twee listeners voor één beschikbaarheidsgroep te hebben?

    Ja, u kunt meerdere listeners instellen voor dezelfde beschikbaarheidsgroep. Zie Hoe u meerdere listeners maakt voor dezelfde beschikbaarheidsgroep (Goden Resource).

  2. Is het mogelijk om een afzonderlijke NIC-kaart te hebben voor altijd verkeer en clientconnectiviteit?

    Ja, u kunt een speciale NIC-kaart hebben voor AlwaysOn-verkeer. Zie Beschikbaarheidsgroep configureren om te communiceren in een toegewezen netwerk.

  3. Welke edities ondersteunen AlwaysOn-failoverclusterexemplaren?

    Dit onderwerp in SQL Server Books Online bevat meer informatie: Edities en ondersteunde functies voor SQL Server 2016.

  4. Hoe herstel ik in geval van een fout op alle knooppunten van uw cluster?

    Zie herstel na noodgevallen van WSFC via geforceerd quorum (SQL Server).

  5. Waar vind ik informatie over ondersteuning voor gedistribueerde transacties in AG-configuraties?

    Zie Transacties - beschikbaarheidsgroepen en databasespiegeling.

  6. AlwaysOn-configuraties bijwerken

    Zie Instanties van AlwaysOn-beschikbaarheidsgroepreplica's upgraden.

  7. Een TDE-database (Transparent Data Encryption) toevoegen aan de AG-configuratie?

    Zie AlwaysOn configureren voor een TDE-database voor een TDE-database om db met TDE toe te voegen aan AG.

  8. Hoe configureert u waarschuwingen om te controleren of de secundaire zich achter de primaire bevindt?

    U kunt het volgende script gebruiken:

    SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
dr_state.database_id AS database_id,
is_ag_replica_local = CASE
    WHEN ar_state.is_local = 1 THEN N'LOCAL'
    ELSE 'REMOTE'
    END,
ag_replica_role = CASE
    WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
    ELSE ar_state.role_desc
    END,
dr_state.last_hardened_lsn, dr_state.last_hardened_time,
datediff(s,last_hardened_time, getdate()) AS 'seconds behind primary'
FROM (( sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
    ON ag.group_id = ar.group_id)
JOIN sys.dm_hadr_availability_replica_states AS ar_state
    ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state
    ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id

  9. Hoe wordt u gewaarschuwd als de status van de database anders is dan gesynchroniseerd?

    U kunt het volgende script gebruiken:

    SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
dr_state.database_id AS database_id,
is_ag_replica_local = CASE
    WHEN ar_state.is_local = 1 THEN N'LOCAL'
    ELSE 'REMOTE'
    END,
ag_replica_role = CASE
    WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
    ELSE ar_state.role_desc
    END,
ar_state.connected_state_desc, ar.availability_mode_desc, dr_state.synchronization_state_desc
FROM (( sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
    ON ag.group_id = ar.group_id )
JOIN sys.dm_hadr_availability_replica_states AS ar_state
    ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state
    ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id

    U kunt ook de volgende koppelingen bekijken voor aanvullende methoden om AlwaysOn-groepen te bewaken:

Meer informatie over AlwaysOn-beschikbaarheidsgroepen