I den här artikeln kommer vi att diskutera flera problem som du kan möta när du skapar, konfigurerar eller underhåller en Always on Availability Group-webbplats.
Innan du går igenom den här artikeln rekommenderar vi att du läser den tidigare artikeln, Ställa in och konfigurera alltid på tillgänglighetsgrupp i SQL Server, för att bekanta dig med konceptet för alltid på tillgänglighetsgrupp och guiderna för ny tillgänglighetsgrupp som visas i den här artikeln.
Alltid på tillgänglighet Gruppfunktion inte aktiverad
Anta att du, när du försökte skapa en ny Alltid på tillgänglighetsgrupp, från noden Alltid på hög tillgänglighet, under objektutforskaren i SQL Server Management Studio, mötte felmeddelandet nedan:
Funktionen Always On Availability Groups måste vara aktiverad för serverinstansen 'SQL1' innan du kan skapa en tillgänglighetsgrupp för denna instans. För att aktivera den här funktionen, öppna SQL Server Configuration Manager, välj SQL Server Services, högerklicka på SQL Server-tjänstens namn, välj Egenskaper och använd fliken Alltid på tillgänglighetsgrupper i dialogrutan Serveregenskaper. Aktivering av Always On Availability Groups kan kräva att serverinstansen är värd för en Windows Server Failover Cluster-nod (WSFC). (Microsoft.SqlServer.Management.HadrTasks)
Det framgår tydligt av felmeddelandet att funktionen AlwaysOn Availability Groups bör vara aktiverad på varje SQL Server-instans som deltar på Always on Availability Group-webbplatsen innan den webbplatsen skapas.
Du kan enkelt aktivera funktionen Always on Availability Group genom att öppna SQL Server Configuration Manager-konsolen, bläddra på fliken SQL Server Services och sedan högerklicka på tjänsten SQL Server Database Engine och välja alternativet Egenskaper.
Från det öppnade fönstret SQL Server Properties, flytta till fliken Alltid på hög tillgänglighet och markera kryssrutan bredvid Aktivera alltid på tillgänglighetsgrupp , med hänsyn till att denna ändring kräver att SQL Server-tjänsten startas om för att träda i kraft, enligt nedan:
Problem med validering av databaskrav
I de tidigare stegen i guiden New Availability Group kommer du att bli ombedd att ange databasen/databaserna som ska delta i Alltid på tillgänglighetsgruppen. Innan databasen läggs till bör databasen klara valideringskontrollen av förutsättningarna. Annars kan databasen inte väljas från databaslistorna, som visas i felmeddelandet nedan:
För att läggas till i en tillgänglighetsgrupp måste denna databas vara inställd på den fullständiga återställningsmodellen. Ställ in databasegenskapen för återställningsmodell till Full och utför en fullständig eller differentiell säkerhetskopiering av databasen på databasen. Du måste sedan schemalägga loggsäkerhetskopior på databasen.
Budskapet är tydligt. Där databasen ska konfigureras med en fullständig återställningsmodell och en fullständig eller differentiell säkerhetskopiering ska utföras på den databasen.
Guiden varnar dig också för att schemalägga en säkerhetskopia av transaktionsloggar för den databasen efter att ha ändrat återställningsmodellen till Full, för att automatiskt trunkera transaktionsloggfilen och förhindra att transaktionsloggfilen körs utan ledigt utrymme.
För att åtgärda det problemet, ändra databasåterställningsmodellen från Enkel till Fullständig, från fliken Alternativ i databasegenskapersfönstret och ta sedan en fullständig säkerhetskopia från den databasen, som visas nedan:
Genom att uppdatera fönstret Välj databaser ändras databasstatusen till Möt förutsättningar, som visas nedan:
Problem med behörighet för delat nätverksplats
När du försökte konfigurera en webbplats för alltid på tillgänglighetsgrupp misslyckades valideringssteget i guiden Ny tillgänglighetsgrupp med felmeddelandet nedan:
Den primära servern 'SQL1' kan inte skriva till '\\SQL1\AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak'. (Microsoft.SqlServer.Management.HadrModel)
Säkerhetskopiering misslyckades för server 'SQL1'. (Microsoft.SqlServer.SmoExtended)
Kan inte öppna säkerhetskopieringsenheten '\\SQL1\AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak'. Operativsystemfel 5 (Åtkomst nekas.).
BACKUP DATABAS avslutas onormalt. (.Net SqlClient Data Provider)
I den initiala synkroniseringsmetoden för fullständig databas och säkerhetskopiering av logg, krävs en delad mapp för att spara hela säkerhetskopian och säkerhetskopieringsfilerna för transaktionsloggen tillfälligt för att återställa den till alla sekundära repliker. Om den primära repliken inte kan skriva säkerhetskopiorna till den, eller om de sekundära replikerna inte kan läsa säkerhetskopiorna från den, kommer valideringsprocessen för New Availability Group att misslyckas enligt nedan:
För att åtgärda problemet måste vi ge SQL Server Service-kontot för de primära och sekundära replikerna läs- och skrivbehörighet för den delade mappen som visas i felmeddelandet, och sedan köra valideringsprocessen igen för att se till att alla kontroller har lyckats , som visas nedan:
Windows-failover-klusterproblem
Anta att du kontrollerar statusen för en befintlig Always on Availability Group-webbplats och se att:
- Den primära rollen flyttas från SQL1-instans till SQL2.
- I SQL2 är databaserna i synkroniserat tillstånd.
- I SQL1 är databaserna inte synkroniserade.
- SQL1 är i lösande tillstånd.
Som du tydligt kan se från SSMS Object Explorer nedan:
När vi kontrollerar SQL Server-felloggarna i den problematiska noden kan vi se att Tillgänglighetsgrupp-repliken blir offline och Tillgänglighetsgruppen slutade fungera på grund av ett problem i Windows Server Failover-klustret, som visas i felen nedan:
- Always On Availability Groups:Lokal Windows Server Failover Clustering-nod är inte längre online . Detta är endast ett informationsmeddelande. Ingen användaråtgärd krävs.
- Alltid på:Tillgänglighetsreplikhanteraren går offline eftersom den lokala Windows Server Failover Clustering (WSFC)-noden har förlorat kvorum. Detta är endast ett informationsmeddelande. Ingen användaråtgärd krävs.
- Alltid på:Den lokala repliken av tillgänglighetsgruppen 'DemoGroup' slutar. Detta är endast ett informationsmeddelande. Ingen användaråtgärd krävs.
Samma sak kan upptäckas från Windows Server Event Viewer, som gradvis visar hur repliken ändrar sitt tillstånd till Lösande tillstånd, enligt nedan:
- Alltid på:Den lokala repliken av tillgänglighetsgruppen "DemoGroup" förbereder sig på övergången till den lösa rollen . Detta är endast ett informationsmeddelande. Ingen användaråtgärd krävs.
- Tillgänglighetsgruppen 'DemoGroup' uppmanas att stoppa förnyelsen av hyresavtalet eftersom tillgänglighetsgruppen går offline . Detta är endast ett informationsmeddelande. Ingen användaråtgärd krävs.
- Tillståndet för den lokala tillgänglighetsrepliken i tillgänglighetsgruppen 'DemoGroup' har ändrats från 'PRIMARY_NORMAL' till 'RESOLVING_NORMAL'. Statusen ändrades eftersom tillgänglighetsgruppen är offline. Repliken går offline eftersom den associerade tillgänglighetsgruppen har tagits bort, eller att användaren har tagit den associerade tillgänglighetsgruppen offline i hanteringskonsolen för Windows Server Failover Clustering (WSFC), eller att tillgänglighetsgruppen misslyckas över till en annan SQL Server-instans. Mer information finns i SQL Server-felloggen eller klusterloggen. Om detta är en tillgänglighetsgrupp för Windows Server Failover Clustering (WSFC), kan du också se WSFC-hanteringskonsolen.
För att kontrollera statusen för Windows Cluster-webbplatsen använder vi Failover Cluster Manager för att se vilken del av Windows Cluster som inte fungerar.
Men Failover Cluster Manager visar att hela klustret är nere, som visas nedan:
Det första som ska valideras här från Windows Failover Cluster-sidan är Cluster Service, som kan kontrolleras från Windows Services-konsolen enligt nedan:
Det är tydligt från Services-konsolen att klustertjänsten inte körs. För att åtgärda problemet startar du tjänsten från den konsolen och uppdaterar sedan Failover Cluster Manager-konsolen för att se till att Windows Cluster-webbplatsen är igång, som visas nedan:
Om du kontrollerar gruppen Alltid på tillgänglighet igen kommer du att se att databaserna är synkroniserade igen och webbplatsen för alltid tillgänglig grupp är i hälsotillstånd igen, som visas nedan:
Transaktionsloggfilen är full på den primära sidan
Anta att du får felmeddelandet nedan när du försöker köra en ny fråga på en av databaserna för alltid tillgänglig grupp:
Om du kontrollerar vad som blockerar transaktionsloggfilen och förhindrar att den trunkeras, kommer du att se att transaktionsloggfilen för denna databas väntar på att loggsäkerhetskopieringen ska trunkeras, som visas nedan:
Ta en säkerhetskopia av transaktionsloggar för den databasen, om du glömmer att schemalägga ett säkerhetskopieringsjobb för transaktionslogg, enligt följande:
Och kolla igen vad som blockerar transaktionsloggen för den databasen, den visar i mitt scenario att den väntar på Availability_Replica. Vilket betyder att loggarna väntar på att skrivas till den sekundära repliken, men inte kan skicka dessa transaktionsloggar till de sekundära replikerna på grund av ett problem på Always on Availability Group-webbplatsen, enligt nedan:
Den bästa platsen för att kontrollera och felsöka webbplatsen Alltid på tillgänglighetsgrupp är alltid på instrumentpanelen, som kan öppnas genom att högerklicka på tillgänglighetsgruppens namn och välja alternativet Visa instrumentpanel.
Från instrumentpanelen kan du se att den sekundära repliken SQL2 inte är synkroniserad med den primära repliken på grund av anslutningsproblem, som visas nedan:
Kontrollera den sekundära repliken och se till att SQL Server Service är igång på den sekundära sidan, enligt följande:
Om du sedan uppdaterar instrumentpanelen för tillgänglighetsgruppen igen kommer du att se att webbplatsen för alltid på tillgänglighetsgruppen är frisk igen. Checking if the transaction logs file is blocked by any operation, we will see that it is pending OLDEST_PAGE, indicating that the oldest page of the database is older than the checkpoint LSN. This issue can be fixed easily by taking another transaction log backup and the transaction log file will be blocked by nothing, as shown clearly below:
Always on Availability Group Failover Misconfiguration
Assume that the Primary replica becomes offline due to an unplanned issue. As expected, the system will not be affected as an automatic failover operation will be performed and the secondary replica will act as the new Primary replica.
But in our case, this happy scenario is not valid, where the secondary replica changed to Resolving state and the system is down!
Checking the secondary replica’s error log and see why it is not acting as the new Primary as expected, you will see that it is failing due to a role synchronization issue, as shown below:
The availability group database "AdventureWorks2017" is changing roles from "SECONDARY" to "RESOLVING" because the mirroring session or availability group failed over due to role synchronization. This is an informational message only. No user action is required.
This means that there is an issue with the synchronization mode that is used in this Availability Group. The synchronization mode used, can be checked from the Always on Availability Group properties page.
From the properties page below, it is clear that the Failover mode in this Availability Group is configured to be performed Manually only. In this case, you need to manually perform a failover operation before rebooting or shutting down the server:
This can be fixed easily by changing the Failover Mode to Automatic, where an automatic failover operation will be performed in case of any unplanned shutdown or reboot:
The same issue can be faced when the Windows Failover Cluster quorum is configured with Node Majority for an even number of replicas, where any failure for one of the servers will bring the Windows Failover Cluster site offline. For more information, check Windows Failover Cluster Quorum Modes in SQL Server Always On Availability Groups:
Failover with Data Loss
Assume that you are trying to perform a manual failover between the Primary and one of the Secondary replicas, but in the Select New Primary Replica window, you see a warning message that the failover operation may end up with data loss as the Primary and the selected Secondary replica are not synchronized, as shown below:
To identify the cause of that issue, we will browse the Always on Health events using the Always on Availability Group dashboard, which shows that the Primary replica is not able to open a connection to the Secondary replica, ash shown below:
After fixing the connectivity issue between the Primary and the Secondary, refresh the replicas list and you will see that the data loss issue is fixed, as shown below. For more information about troubleshooting the connectivity issues, check Troubleshoot connecting to the SQL Server Database Engine.
Monitoring Always on Availability Group Latency
The Availability Group dashboard can be modified to include additional columns that provide information about the synchronization latency between Primary and Secondary replicas, including the Commit LSN, Sent LSN and harden LSN values, without showing why there is a latency, as shown below:
For more information about measuring the latency, check the Measuring Availability Group synchronization lag.
Starting from SSMS 17.4, the Always on Availability Group dashboard enhanced to include two new options that are used for latency information calculation, analysis and reporting, which helps in identifying the bottlenecks in the transaction logs flow between the Primary and the Secondary replicas and narrow down the cause of that latency.
For more information about the new functionality and reports, check to Use the Always on Availability Group dashboard.
To trigger using this new option, click on Collect Latency Data option from the Always on Availability Group dashboard, that will create a new SQL Agent job on the Primary and Secondary replicas to collect the latency data, As shown below:
When the created job execution has completed on all the Availability Group replicas, you will be able to view the latency statistics from the latency reports by right-clicking on the Availability Group name and choose the Primary Replica Latency or Secondary Replica Latency report, based on the replica role in the Availability Group.
After providing information about the Availability Group replicas, the latency report will show a graphical view of the transaction log commit time on the Primary replica and the remote Hardening time for the secondary replicas, aggregated as average values. Also, the report provides statistical values for the transaction logs send, receive, commit, compress, decompress and other numerical values based on the replica role in the Availability Group.
For more information about the latency report, check New in SSMS - Always On Availability Group Latency Reports.
The below report is an example of the latency reports generated from the Secondary replica, showing normal logs transport operations:
Also, the Log Block Latency report shows the amount of time, in ms, that the transaction log on the Primary replica waits for Secondary replicas to commit that transaction. After enabling it from the Availability Group Dashboard, you can browse it from the SSMS similar to the previous latency reports. Take into consideration that, the large latency time indicates that the Primary replica is waiting a long time for the Secondary replicas to commit the sent transactions, as shown below:
