Deze browser wordt niet meer ondersteund.
Upgrade naar Microsoft Edge om te profiteren van de nieuwste functies, beveiligingsupdates en technische ondersteuning.
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
Microsoft CSS-gegevens geven aan dat een aanzienlijk percentage klantproblemen vaak eerder wordt aangepakt in een uitgebrachte CU, maar niet proactief wordt toegepast en daarom wordt een doorlopende, proactieve installatie van CA's aanbevolen zodra deze beschikbaar komen. Zie Aankondiging van updates voor het SQL Server Incremental Servicing Model (ISM) voor meer informatie.
Als u de meest recente CA's wilt controleren die mogelijk beschikbaar zijn voor uw versie, raadpleegt u Hoe u de versie, editie en updateniveau van SQL Server en de bijbehorende onderdelen kunt bepalen.
U kunt nuttige hulpprogramma's voor het oplossen en bewaken van AlwaysOn-beschikbaarheidsgroepen in AlwaysOn-beschikbaarheidsgroepen voor probleemoplossing en bewakingshandleiding bekijken voor meer informatie over de hulpprogramma's die u kunt gebruiken voor het diagnosticeren van verschillende soorten problemen en voor het bewaken van beschikbaarheidsgroepen. De handleiding bevat ook aanvullende scenario's die mogelijk niet worden behandeld in deze begeleide rondleiding.
Het bovenliggende knooppunt voor documentatie over AlwaysOn-beschikbaarheidsgroepen en biedt een naslaginformatie over verschillende vragen. Zie AlwaysOn-beschikbaarheidsgroepen (SQL Server).
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.
Als deze informatie niet nuttig is, raadpleegt u meer informatie over 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.
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.
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.
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.
Veel problemen met betrekking tot AlwaysOn treden op vanwege een onjuiste configuratie van de listener. Als u verbindingsproblemen ondervindt met de listener,
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.
Als u het niet zeker weet, kunt u de listener verwijderen en opnieuw maken op basis van het bovenstaande document.
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.
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.
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:
Voor SQL Server 2012- en SQL Server 2014-omgevingen raadpleegt u FIX: Trage synchronisatie wanneer schijven verschillende sectorgrootten hebben voor primaire en secundaire replicalogboekbestanden in SQL Server AG en Logshipping-omgevingen.
Controleer of de secundaire knooppunten de status Onderbroken hebben in de clusterbeheerder.
Als het probleem nog steeds bestaat, raadpleegt u meer informatie over AlwaysOn-beschikbaarheidsgroepen.
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.
Controleer de gebeurtenislogboeken van het systeem en de toepassing op hardwareproblemen en andere fouten en werk samen met de leverancier om deze op te lossen.
Als u virtuele machines gebruikt, controleert u de knowledge base om te zien of er onlangs gemelde problemen zijn die kunnen bijdragen aan het probleem. Zo heeft groot pakketverlies op gastbesturingssysteemniveau op de VMXNET3 vNIC in ESXi (2039495) in sommige gevallen problemen met de AG-configuratie veroorzaakt.
Meer informatie:
Als het probleem nog steeds bestaat, raadpleegt u meer informatie over AlwaysOn-beschikbaarheidsgroepen.
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.
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).
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.
Welke edities ondersteunen AlwaysOn-failoverclusterexemplaren?
Dit onderwerp in SQL Server Books Online bevat meer informatie: Edities en ondersteunde functies voor SQL Server 2016.
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).
Waar vind ik informatie over ondersteuning voor gedistribueerde transacties in AG-configuraties?
Zie Transacties - beschikbaarheidsgroepen en databasespiegeling.
AlwaysOn-configuraties bijwerken
Zie Instanties van AlwaysOn-beschikbaarheidsgroepreplica's upgraden.
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.
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
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:
Op beleid gebaseerd beheer voor operationele problemen met AlwaysOn-beschikbaarheidsgroepen
Externe koppeling: Op beleid gebaseerd beheer gebruiken voor waarschuwingen voor gegevensverlies van SQL Server-beschikbaarheidsgroepen
Gedrag van dynamische witness op Windows Server 2012 R2-failoverclustering
Training
Module
IaaS- en PaaS-oplossingen verkennen voor hoge beschikbaarheid en herstel na noodgevallen - Training
IaaS- en PaaS-oplossingen verkennen voor hoge beschikbaarheid en herstel na noodgevallen
Certificering
Microsoft Certified: Azure Database Administrator Associate - Certifications
Beheer een SQL Server-databaseinfrastructuur voor cloud-, on-premises en hybride relationele databases met behulp van de relationele Microsoft PaaS-databaseaanbiedingen.