Felsöka konfigureringen av AlwaysOn-tillgänglighetsgrupper (SQL Server)

Gäller för:SQL Server

Den här artikeln innehåller information som hjälper dig att felsöka vanliga problem med att konfigurera serverinstanser för AlwaysOn-tillgänglighetsgrupper. Vanliga konfigurationsproblem är att AlwaysOn-tillgänglighetsgrupper är inaktiverade, konton är felaktigt konfigurerade, databasens speglingsslutpunkt inte finns, slutpunkten är otillgänglig (SQL Server-fel 1418), nätverksåtkomsten finns inte och ett kopplingsdatabaskommando misslyckas (SQL Server-fel 35250).

I detta ämne:

AlwaysOn-tillgänglighetsgrupper är inte aktiverade

Funktionen AlwaysOn-tillgänglighetsgrupper måste vara aktiverad på var och en av instanserna av SQL Server.

Om funktionen AlwaysOn-tillgänglighetsgrupper inte är aktiverad visas det här felmeddelandet när du försöker skapa en tillgänglighetsgrupp på SQL Server.

The Always On Availability Groups feature must be enabled for server instance 'SQL1VM' before you can create an availability group on this instance. To enable this feature, open the SQL Server Configuration Manager, select SQL Server Services, right-click on the SQL Server service name, select Properties, and use the Always On Availability Groups tab of the Server Properties dialog. Enabling Always On Availability Groups may require that the server instance is hosted by a Windows Server Failover Cluster (WSFC) node. (Microsoft.SqlServer.Management.HadrTasks)

Felmeddelandet anger tydligt att tillgänglighetsgruppens funktion inte är aktiverad och även instruerar dig hur du aktiverar den. Det finns två scenarier där du kan hamna i detta konfigurationstillstånd, förutom det uppenbara där tillgänglighetsgruppen (AG) inte aktiverades initialt.

1. Om SQL Server installerades och funktionen AlwaysOn-tillgänglighetsgrupper aktiverades innan du installerade funktionen Windows-redundansklustring kan det här felet uppstå när du försöker skapa en AlwaysOn-tillgänglighetsgrupp.
2. Om du tar bort en befintlig windows-redundansklusterfunktion och återskapar den medan SQL Server fortfarande har AlwaysOn konfigurerat, kan det här felet inträffa när du försöker använda tillgänglighetsgruppen igen.

I sådana fall kan du vidta följande åtgärder för att lösa det:

1. Inaktivera ag-funktionen
2. Starta om SQL Server-tjänsten
3. Aktivera AG-funktionen igen
4. Starta om SQL-tjänsten igen

Mer information finns i Aktivera och inaktivera AlwaysOn-tillgänglighetsgrupper (SQL Server).

Accounts

De konton under vilka SQL Server körs måste vara korrekt konfigurerade.

1. Har kontona rätt behörigheter?

   1. Om partnerna körs under samma domänkonto finns rätt användarinloggningar automatiskt i båda huvuddatabaserna . Detta förenklar säkerhetskonfigurationen och rekommenderas.

   2. Om två serverinstanser körs under olika konton måste varje konto skapas i master på fjärrserverinstansen och serverprincipalen måste beviljas CONNECT-behörighet för att ansluta till databasspeglingens slutpunkt för serverinstansen. Mer information finns i Konfigurera inloggningskonton för databasspegling eller AlwaysOn-tillgänglighetsgrupper (SQL Server). Du kan använda följande fråga på varje instans för att kontrollera om inloggningarna har CONNECT-behörigheter:

   SELECT 
     perm.class_desc,
     prin.name,
     perm.permission_name,
     perm.state_desc,
     prin.type_desc as PrincipalType,
     prin.is_disabled
   FROM sys.server_permissions perm
     LEFT JOIN sys.server_principals prin ON perm.grantee_principal_id = prin.principal_id
     LEFT JOIN sys.tcp_endpoints tep ON perm.major_id = tep.endpoint_id
   WHERE 
     perm.class_desc = 'ENDPOINT'
     AND perm.permission_name = 'CONNECT'
     AND tep.type = 4    
   

2. Om SQL Server körs under ett inbyggt konto, till exempel lokalt system, lokal tjänst eller nätverkstjänst eller ett icke-domänkonto, måste du använda certifikat för slutpunktsautentisering. Om dina tjänstkonton använder domänkonton i samma domän kan du välja att bevilja CONNECT-åtkomst för varje tjänstkonto på alla replikplatser eller använda certifikat. Mer information finns i Använda certifikat för en databasspeglingsslutpunkt (Transact-SQL).

Endpoints

Slutpunkter måste vara korrekt konfigurerade.

1. Kontrollera att varje instans av SQL Server som ska vara värd för en tillgänglighetsreplik (varje replikplats) har en databasspeglingsslutpunkt. Om du vill avgöra om en databasspeglingsslutpunkt finns på en viss serverinstans använder du sys.database_mirroring_endpoints katalogvy:

   SELECT name, state_desc FROM sys.database_mirroring_endpoints  
   

   Mer information om hur du skapar slutpunkter finns i Skapa en databasspeglingsslutpunkt för Windows-autentisering (Transact-SQL) eller Tillåt att en databasspeglingsslutpunkt använder certifikat för utgående anslutningar (Transact-SQL).

2. Kontrollera att portnumren är korrekta.

   Om du vill identifiera porten som för närvarande är associerad med databasspeglingsslutpunkten för en serverinstans använder du följande Transact-SQL-instruktion:

   SELECT type_desc, port FROM sys.tcp_endpoints;  
   GO  
   

3. För installationsproblem med AlwaysOn-tillgänglighetsgrupper som är svåra att förklara rekommenderar vi att du inspekterar varje serverinstans för att avgöra om den lyssnar på rätt portar.

4. Kontrollera att slutpunkterna har startats (STATE=STARTED). Använd följande Transact-SQL-instruktion på varje serverinstans:

   SELECT state_desc FROM sys.database_mirroring_endpoints  
   

   Mer information om kolumnen state_desc finns i sys.database_mirroring_endpoints (Transact-SQL).

   Om du vill starta en slutpunkt använder du följande Transact-SQL-instruktion:

   ALTER ENDPOINT Endpoint_Mirroring   
   STATE = STARTED   
   AS TCP (LISTENER_PORT = <port_number>)  
   FOR database_mirroring (ROLE = ALL);  
   GO  
   

   Mer information finns i ALTER ENDPOINT (Transact-SQL).

   Anmärkning

   I vissa fall, om slutpunkten startas men ag-replikerna inte kommunicerar, försöker du stoppa och starta om slutpunkten. Du kan använda ALTER ENDPOINT [Endpoint_Mirroring] STATE = STOPPED följt av ALTER ENDPOINT [Endpoint_Mirroring] STATE = STARTED

5. Kontrollera att inloggningen från den andra servern har behörigheten ANSLUT. För att avgöra vem som har CONNECT-behörighet för en slutpunkt använder du följande Transact-SQL-instruktion på varje serverinstans:

   SELECT 'Metadata Check';  
   SELECT EP.name, SP.STATE,   
      CONVERT(nvarchar(38), suser_name(SP.grantor_principal_id))   
         AS GRANTOR,   
      SP.TYPE AS PERMISSION,  
      CONVERT(nvarchar(46),suser_name(SP.grantee_principal_id))   
         AS GRANTEE   
      FROM sys.server_permissions SP , sys.endpoints EP  
      WHERE SP.major_id = EP.endpoint_id  
      ORDER BY Permission,grantor, grantee;   
   

6. Kontrollera att rätt servernamn används i slutpunkts-URL:en

   För servernamn i en slutpunkts-URL rekommenderar vi att du använder fullständigt kvalificerat domännamn (FQDN), även om du kan använda alla namn som unikt identifierar datorn. Serveradressen kan vara ett Netbios-namn (om systemen finns i samma domän), ett fullständigt domännamn (FQDN) eller en IP-adress (helst en statisk IP-adress). Det rekommenderade alternativet är att använda det fullständigt kvalificerade domännamnet.

   Om du redan har definierat en slutpunkts-URL kan du fråga den med hjälp av:

   select endpoint_url from sys.availability_replicas
   

   Jämför sedan endpoint_url utdata med servernamnet (NetBIOS-namn eller FQDN). Kör följande kommandon i en PowerShell på repliken lokalt för att fråga efter servernamnet:

   $env:COMPUTERNAME
   [System.Net.Dns]::GetHostEntry([string]$env:computername).HostName
   

   Om du vill verifiera servernamnet på en fjärrdator kör du det här kommandot från PowerShell.

   $servername_from_endpoint_url = "server_from_endpoint_url_output"
   
   Test-NetConnection -ComputerName $servername_from_endpoint_url
   

   Mer information finns i Ange slutpunkts-URL när du lägger till eller ändrar en tillgänglighetsreplik (SQL Server).

Nätverksåtkomst

Varje serverinstans som är värd för en tillgänglighetsreplik måste kunna komma åt porten för var och en av de andra serverinstanserna via TCP. Detta är särskilt viktigt om serverinstanserna finns i olika domäner som inte litar på varandra (ej betrodda domäner). Kontrollera om du kan ansluta till slutpunkterna genom att följa dessa steg:

• Använd Test-NetConnection (motsvarande Telnet) för att verifiera anslutningen. Här är exempel på kommandon som du kan använda:

  $server_name = "your_server_name"
  $IP_address = "your_ip_address"
  $port_number = "your_port_number"
  
  Test-NetConnection -ComputerName $server_name -Port $port_number
  Test-NetConnection -ComputerName $IP_address -Port $port_number
  

• Om slutpunkten lyssnar och anslutningen lyckas visar meddelandet "TcpTestSucceeded : True". Om inte får du en "TcpTestSucceeded : False".

• Om Test-NetConnection (Telnet) anslutning till IP-adressen fungerar men inte till ServerName finns det troligtvis ett problem med DNS- eller namnuppslagning.

• Om anslutningen fungerar med ServerName och inte via IP-adress kan det finnas fler än en slutpunkt som definierats på servern (en annan SQL-instans kanske) som lyssnar på den porten. Även om statusen för slutpunkten på den aktuella instansen visar "STARTED", kan en annan instans faktiskt ha porten bunden och förhindra att rätt instans lyssnar och upprättar TCP-anslutningar.

• Om Test-NetConnection inte kan ansluta letar du efter brandväggs- och/eller antivirusprogram som blockerar den aktuella slutpunktsporten. Kontrollera brandväggsinställningen för att se om den tillåter slutpunktsportkommunikation mellan de serverinstanser som är värdar för den primära repliken och den sekundära repliken (port 5022 som standard). Kör följande PowerShell-skript för att undersöka inaktiverade regler för inkommande trafik

• Om du kör SQL Server på en virtuell Azure-dator måste du också se till att nätverkssäkerhetsgruppen (NSG) tillåter trafik till slutpunktsporten. Kontrollera brandväggsinställningen (och NSG för virtuell Azure-dator) för att se om den tillåter slutpunktsportkommunikation mellan de serverinstanser som är värdar för den primära repliken och den sekundära repliken (port 5022 som standard)

  Get-NetFirewallRule -Action Block -Enabled True -Direction Inbound |Format-Table
  

• Samla in utdata från Get-NetTCPConnection cmdlet (motsvarande NETSTAT -a) och kontrollera att statusen är en LISTENING eller ESTABLISHED på IP:Port för den angivna slutpunkten

  Get-NetTCPConnection 
  

Listener

Om du vill ha rätt konfiguration av en tillgänglighetsgruppslyssnare följer du "Konfigurera en lyssnare för en AlwaysOn-tillgänglighetsgrupp"

1. När lyssnaren har konfigurerats kan du verifiera IP-adressen och porten som den lyssnar på med hjälp av följande fråga:

   $server_name = $env:computername  #replace this with your sql instance "server\instance"
   
   sqlcmd -E -S$server_name -Q"SELECT dns_name AS AG_listener_name, port, ip_configuration_string_from_cluster 
   FROM sys.availability_group_listeners"
   

2. Du kan också hitta lyssnarinformationen tillsammans med SQL Server-portarna med hjälp av den här frågan:

   $server_name = $env:computername      #replace this with your sql instance "server\instance"
   
   sqlcmd -E -S($server_name) -Q("SELECT  convert(varchar(32), SERVERPROPERTY ('servername')) servername, convert(varchar(32),ip_address) ip_address, port, type_desc,state_desc, start_time 
   FROM sys.dm_tcp_listener_states 
   WHERE ip_address not in ('127.0.0.1', '::1') and type <> 2")
   

3. Om du behöver upprätta en anslutning till lyssnaren och misstänker att en port är blockerad kan du utföra ett test med powershell-cmdleten Test-NetConnection (motsvarande telnet).

   $listener_name = "your_ag_listener"
   $IP_address = "your_ip_address"
   $port_number = "your_port_number"
   
   Test-NetConnection -ComputerName $listener_name -Port $port_number
   Test-NetConnection -ComputerName $IP_address -Port $port_number
   

4. Kontrollera slutligen om lyssnaren lyssnar på den angivna porten:

   $port_number = "your_port_number"
   
   Get-NetTCPConnection -LocalPort $port_number -State Listen
   

Slutpunktsåtkomst (SQL Server-fel 1418)

Det här SQL Server-meddelandet anger att den servernätverksadress som anges i slutpunkts-URL:en inte kan nås eller inte finns, och det tyder på att du verifierar nätverksadressnamnet och kör kommandot igen.

Sammanfogningsdatabas misslyckas (SQL Server-fel 35250)

I det här avsnittet beskrivs möjliga orsaker till och lösning av ett fel vid anslutning av sekundära databaser till tillgänglighetsgruppen eftersom anslutningen till den primära repliken inte är aktiv. Det här är det fullständiga felmeddelandet:

Msg 35250 The connection to the primary replica is not active. The command cannot be processed.

Upplösning:

Sammanfattning av stegen beskrivs nedan.

Detaljerade stegvisa instruktioner finns i Motorfel MSSQLSERVER_35250

1. Kontrollera att slutpunkten har skapats och startats.
2. Kontrollera om du kan ansluta till slutpunkten via Telnet och se till att inga brandväggsregler blockerar anslutningen
3. Sök efter fel i systemet. Du kan fråga sys.dm_hadr_availability_replica_states efter last_connect_error_number som kan hjälpa dig att diagnostisera anslutningsproblemet.
4. Se till att slutpunkten är definierad så att den matchar IP/port som AG använder.
5. Kontrollera om nätverkstjänstkontot har CONNECT-behörighet till slutpunkten.
6. Sök efter möjliga problem med namnuppslagning
7. Se till att DIN SQL Server kör en ny version (helst den senaste versionen för att skydda mot att stöta på fasta problem.

Read-Only routing fungerar inte som det ska

1. Kontrollera att du har konfigurerat skrivskyddad routning genom att följa dokumentet Konfigurera skrivskyddad routning .

2. Se till att klientdrivrutiner stöds

   Klientprogrammet måste använda en klientprovider som stöder ApplicationIntent parametern. Se Stöd för drivrutin- och klientanslutning för tillgänglighetsgrupper

   Anmärkning

   Om du ansluter till en DNN-lyssnare (distribuerat nätverksnamn) måste providern också ha stöd MultiSubnetFailover för parametern

3. Kontrollera att egenskaperna för anslutningssträngen är korrekt inställda

   För att skrivskyddad routning ska fungera korrekt måste klientprogrammet använda dessa egenskaper i anslutningssträngen:

   • Ett databasnamn som tillhör AG
   • Ett lyssnarnamn för tillgänglighetsgrupp
     • Om du använder DNN måste du ange DNN-lyssnarens namn och DNN-portnummer <DNN name,DNN port>
   • ApplicationIntent inställt på ReadOnly
   • MultiSubnetFailover inställt på true krävs för distribuerat nätverksnamn (DNN)

   Exempel

   Det här exemplet illustrerar anslutningssträngen för .NET Microsoft.Data.SqlClient eller System.Data.SqlClient providern för en VNN-lyssnare (virtuellt nätverksnamn):

   Server=tcp:VNN_AgListener,1433;Database=AgDb1;ApplicationIntent=ReadOnly;MultiSubnetFailover=True
   

   Det här exemplet illustrerar anslutningssträngen för .NET Microsoft.Data.SqlClient eller System.Data.SqlClient providern för en DNN-lyssnare (distribuerat nätverksnamn):

   Server=tcp:DNN_AgListener,DNN_Port;Database=AgDb1;ApplicationIntent=ReadOnly;MultiSubnetFailover=True
   

   Anmärkning

   Om du använder kommandoradsprogram som SQLCMD kontrollerar du att du anger rätt växlar för servernamn. I SQLCMD måste du till exempel använda stora bokstäver -S flagga som anger serverns namn, inte små bokstäver -s flagga som används för kolumnavgränsare.
   Exempel: sqlcmd -S AG_Listener,port -E -d AgDb1 -K ReadOnly -M

4. Kontrollera att tillgänglighetsgruppens lyssnare är online. För att säkerställa att tillgänglighetsgruppens lyssnare är online kör du följande fråga på den primära repliken:

   SELECT * FROM sys.dm_tcp_listener_states;
   

   Om du upptäcker att lyssnaren är offline kan du försöka få den online med ett kommando som liknar detta:

   ALTER AVAILABILITY GROUP myAG RESTART LISTENER 'AG_Listener';
   

5. Kontrollera att READ_ONLY_ROUTING_LIST är korrekt ifylld. På primär replik kontrollerar du att READ_ONLY_ROUTING_LIST endast innehåller serverinstanser som är värdar för läsbara sekundära repliker.

   Om du vill visa egenskaperna för varje replik kan du köra den här frågan och undersöka anslutningsslutpunkten (URL) för den skrivskyddade repliken.

   SELECT replica_id, replica_server_name, secondary_role_allow_connections_desc, read_only_routing_url 
   FROM sys.availability_replicas;   
   

   Så här visar du en skrivskyddad routningslista och jämför med slutpunkts-URL:en:

   SELECT * FROM sys.availability_read_only_routing_lists;
   

   Om du vill ändra en skrivskyddad routningslista kan du använda en fråga som den här:

   ALTER AVAILABILITY GROUP [AG1]   
   MODIFY REPLICA ON  
   N'COMPUTER02' WITH   
   (PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER01','COMPUTER02')));  
   

   Mer information finns i Konfigurera skrivskyddad routning för en tillgänglighetsgrupp – SQL Server AlwaysOn

6. Kontrollera att READ_ONLY_ROUTING_URL porten är öppen. Kontrollera att Windows-brandväggen inte blockerar READ_ONLY_ROUTING_URL port. Konfigurera en Windows-brandvägg för databasmotoråtkomst på varje replik i read_only_routing_list och alla för klienter som ansluter till dessa repliker.

   Anmärkning

   Om du kör SQL Server på en virtuell Azure-dator måste du vidta ytterligare konfigurationssteg. Se till att nätverkssäkerhetsgruppen (NSG) för varje virtuell replikdator tillåter trafik till slutpunktsporten och DNN-porten om du använder DNN-lyssnaren. Om du använder VNN-lyssnaren måste du se till att lastbalanseraren är korrekt konfigurerad.

7. Kontrollera att READ_ONLY_ROUTING_URL (TCP://systemadress:port) innehåller rätt fullständigt domännamn (FQDN) och portnummer. See:

   • Beräkna read_only_routing_url för AlwaysOn
   • sys.availability_replicas (Transact-SQL)
   • ÄNDRA TILLGÄNGLIGHETSGRUPP (Transact-SQL)

8. Se till att SQL Server-nätverkskonfigurationen är korrekt i SQL Server Configuration Manager.

   Kontrollera på varje replik i read_only_routing_list att:

   • SQL Server-fjärranslutning är aktiverat
   • TCP/IP är aktiverat
   • IP-adresserna är korrekt konfigurerade

   Anmärkning

   Du kan snabbt kontrollera att alla dessa är korrekt konfigurerade om du kan ansluta från en fjärrdator till en sekundär målrepliks SQL Server-instansnamn med hjälp av TCP:SQL_Instance syntax.

Se: Konfigurera en server för att lyssna på en specifik TCP-port (SQL Server Configuration Manager) och Visa eller ändra serveregenskaper (SQL Server)

Relaterade uppgifter

• Skapande och konfiguration av tillgänglighetsgrupper (SQL Server)

• Skapa en databasspeglingsslutpunkt för Windows-autentisering (Transact-SQL)

• Ange slutpunkts-URL:en när du lägger till eller ändrar en tillgänglighetsreplik (SQL Server)

• Förbereda en sekundär databas för en tillgänglighetsgrupp (SQL Server) manuellt

• Felsöka en misslyckad Add-File åtgärd (Always On-tillgänglighetsgrupper)

• Hantering av inloggningar och jobb för databaser i en tillgänglighetsgrupp (SQL Server)

• Hantera metadata när du gör en databas tillgänglig på en annan serverinstans (SQL Server)

Relaterat innehåll

• Visa händelser och loggar för ett redundanskluster
• Get-ClusterLog cmdlet för redundanskluster
• SQL Server Always On Team Blog: Den officiella SQL Server Always On Team-bloggen
• Transportsäkerhet för databasspegling och Always On-tillgänglighetsgrupper (SQL Server)
• Konfiguration av klientnätverk
• krav, begränsningar och rekommendationer för AlwaysOn-tillgänglighetsgrupper (SQL Server)