I denne artikel vil vi diskutere adskillige problemer, som du kan stå over for, mens du opretter, konfigurerer eller vedligeholder et Always on Availability Group-websted.
Før du gennemgår denne artikel, anbefales det at læse den forrige artikel, Opsætning og konfiguration af Always on Availability Group i SQL Server, for at være bekendt med Always on Availability Group-konceptet og New Availability Group-guiderne vist i denne artikel.
Altid på tilgængelighed Gruppefunktion ikke aktiveret
Antag, at du, mens du forsøgte at oprette en ny Always on Availability-gruppe, fra Always On High Availability-noden, under Object Explorer i SQL Server Management Studio, stod over for fejlmeddelelsen nedenfor:
Funktionen Always On Availability Groups skal være aktiveret for serverforekomsten 'SQL1', før du kan oprette en tilgængelighedsgruppe for denne forekomst. For at aktivere denne funktion skal du åbne SQL Server Configuration Manager, vælge SQL Server Services, højreklikke på SQL Server-tjenestens navn, vælge Egenskaber og bruge fanen Always On Availability Groups i dialogboksen Server Properties. Aktivering af Always On Availability Groups kan kræve, at serverforekomsten hostes af en Windows Server Failover Cluster (WSFC) node. (Microsoft.SqlServer.Management.HadrTasks)
Det fremgår tydeligt af fejlmeddelelsen, at AlwaysOn Availability Groups-funktionen skal aktiveres på hver SQL Server-forekomst, der deltager i Always on Availability Group-webstedet, før det pågældende websted oprettes.
Du kan nemt aktivere funktionen Always on Availability Group ved at åbne SQL Server Configuration Manager-konsollen, gennemse fanen SQL Server Services og derefter højreklikke på SQL Server Database Engine-tjenesten og vælge Egenskaber.
Fra det åbnede SQL Server-egenskaber-vindue skal du flytte til fanen Altid på høj tilgængelighed og markere afkrydsningsfeltet ved siden af Aktiver Always on Availability Group under hensyntagen til, at denne ændring kræver genstart af SQL Server-tjenesten for at træde i kraft, som vist nedenfor:
Problem med validering af databasekrav
I de tidligere trin af guiden Ny tilgængelighedsgruppe bliver du bedt om at angive den eller de databaser, der skal deltage i Always on Availability Group. Før du tilføjer databasen, skal databasen bestå valideringskontrollen med forudsætninger. Ellers kan databasen ikke vælges fra databaselisterne, som vist i fejlmeddelelsen nedenfor:
For at blive tilføjet til en tilgængelighedsgruppe skal denne database indstilles til den fulde gendannelsesmodel. Indstil databaseegenskaben Recovery Model til Fuld, og udfør en fuld eller differentiel databasesikkerhedskopi på databasen. Du skal derefter planlægge log backups på databasen.
Budskabet er klart. Hvor databasen skal konfigureres med en fuld gendannelsesmodel, og en fuld eller differentiel sikkerhedskopiering skal udføres på den database.
Guiden advarer dig også om at planlægge en sikkerhedskopi af transaktionslog for den pågældende database efter at have ændret gendannelsesmodellen til Fuld, for automatisk at afkorte transaktionslogfilen og forhindre, at transaktionslogfilen kører uden ledig plads.
For at løse dette problem skal du ændre databasegendannelsesmodellen fra Simple til Fuld, fra fanen Indstillinger i vinduet med databaseegenskaber, og derefter tage en fuld sikkerhedskopi fra den database, som vist nedenfor:
Når vinduet Vælg databaser opdateres, ændres databasestatus til Opfyld forudsætninger, som vist nedenfor:
Problem med tilladelse til delt netværksplacering
Mens du forsøgte at konfigurere et Always on Availability Group-websted, mislykkedes valideringstrinnet i guiden New Availability Group med fejlmeddelelsen nedenfor:
Den primære server 'SQL1' kan ikke skrive til '\\SQL1\AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak'. (Microsoft.SqlServer.Management.HadrModel)
Sikkerhedskopiering mislykkedes for server 'SQL1'. (Microsoft.SqlServer.SmoExtended)
Kan ikke åbne backup-enheden '\\SQL1\AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak'. Operativsystemfejl 5 (Adgang nægtes.).
BACKUP DATABASE afsluttes unormalt. (.Net SqlClient Data Provider)
I den indledende synkroniseringsmetode for fuld database og logbackup kræves der en delt mappe for at opbevare den fulde backup- og transaktionslogsikkerhedskopieringsfiler midlertidigt for at gendanne den til alle sekundære replikaer. Hvis den primære replika ikke er i stand til at skrive sikkerhedskopifilerne til den, eller de sekundære replikaer ikke er i stand til at læse sikkerhedskopifilerne fra den, vil valideringsprocessen for New Availability Group mislykkes som nedenfor:
For at løse dette problem skal vi give SQL Server Service-kontoen for de primære og sekundære replikaer læse- og skrivetilladelse til den delte mappe, der vises i fejlmeddelelsen, og derefter køre valideringsprocessen igen for at sikre, at alle kontroller er gennemført , som vist nedenfor:
Windows-failover-klyngeproblem
Antag, at du kontrollerer status for et eksisterende Always on Availability Group-websted, og se, at:
- Den primære rolle flyttes fra SQL1-instans til SQL2.
- I SQL2 er databaserne i tilstanden Synkroniseret.
- I SQL1 er databaserne ikke synkroniserede.
- SQL1 er i tilstanden Løsning.
Som du tydeligt kan se fra SSMS Object Explorer nedenfor:
Ved at kontrollere SQL Server-fejllogfilerne i den problematiske node kan vi se, at Availability Group-replikaen bliver offline, og Availability Group holdt op med at fungere på grund af et problem i Windows Server Failover Cluster, som vist i fejlene nedenfor:
- Always On Availability Groups:Lokal Windows Server Failover Clustering node er ikke længere online . Dette er kun en informationsmeddelelse. Ingen brugerhandling er påkrævet.
- Altid tændt:Tilgængelighedsreplikadministratoren går offline, fordi den lokale Windows Server Failover Clustering (WSFC)-knude har mistet kvorum. Dette er kun en informationsmeddelelse. Ingen brugerhandling er påkrævet.
- Altid tændt:Den lokale replika af tilgængelighedsgruppen 'DemoGroup' stopper. Dette er kun en informationsmeddelelse. Ingen brugerhandling er påkrævet.
Det samme kan detekteres fra Windows Server Event Viewer, der gradvist viser, hvordan replikaen ændrer sin tilstand til Løsende tilstand, som nedenfor:
- Altid tændt:Den lokale replika af tilgængelighedsgruppen 'DemoGroup' forbereder sig på overgangen til den løsende rolle . Dette er kun en informationsmeddelelse. Ingen brugerhandling er påkrævet.
- Tilgængelighedsgruppen 'DemoGroup' bliver bedt om at stoppe fornyelsen af lejekontrakten, fordi tilgængelighedsgruppen er offline . Dette er kun en informationsmeddelelse. Ingen brugerhandling er påkrævet.
- Tilstanden for den lokale tilgængelighedsreplik i tilgængelighedsgruppen 'DemoGroup' er ændret fra 'PRIMARY_NORMAL' til 'RESOLVING_NORMAL'. Tilstanden er ændret, fordi tilgængelighedsgruppen er offline. Replikaen går offline, fordi den tilknyttede tilgængelighedsgruppe er blevet slettet, eller brugeren har taget den tilknyttede tilgængelighedsgruppe offline i WSFC-administrationskonsollen (Windows Server Failover Clustering), eller tilgængelighedsgruppen fejler over til en anden SQL Server-instans. Se SQL Server-fejlloggen eller klyngeloggen for at få flere oplysninger. Hvis dette er en tilgængelighedsgruppe for Windows Server Failover Clustering (WSFC), kan du også se WSFC-administrationskonsollen.
For at kontrollere status for Windows Cluster-webstedet bruger vi Failover Cluster Manager til at se, hvilken del af Windows Cluster der fejler.
Men Failover Cluster Manager viser, at hele klyngen er nede, som vist nedenfor:
Den første ting, der skal valideres her fra Windows Failover Cluster-siden, er Cluster-tjenesten, som kan kontrolleres fra Windows Services-konsollen som nedenfor:
Det fremgår tydeligt af Services-konsollen, at Cluster Service ikke kører. For at løse dette problem skal du starte tjenesten fra den konsol og derefter opdatere Failover Cluster Manager-konsollen for at sikre, at Windows Cluster-webstedet er oppe og køre, som vist nedenfor:
Hvis du tjekker Always on Availability Group igen, vil du se, at databaserne er synkroniseret igen, og Always on Availability Group-webstedet er i sundhedstilstand igen, som vist nedenfor:
Transaktionslogfilen er fuld på den primære side
Antag, at du modtager nedenstående fejlmeddelelse, når du forsøger at udføre en ny forespørgsel på en af Always on Availability Group-databaserne:
Ved at kontrollere, hvad der blokerer transaktionslogfilen og forhindrer den i at blive trunkeret, vil du se, at transaktionslogfilen i denne database afventer log backup operation for at blive trunkeret, som vist nedenfor:
Tag en transaktionslog backup for den pågældende database, hvis du glemmer at planlægge et transaktionslog backup job, som følger:
Og tjek igen, hvad der blokerer transaktionsloggen for den database, den viser i mit scenarie, at den venter på Availability_Replica. Hvilket betyder, at logfilerne venter på at blive skrevet til den sekundære replika, men ikke er i stand til at sende disse transaktionslogfiler til de sekundære replikaer på grund af et problem på Always on Availability Group-webstedet som nedenfor:
Den bedste placering til at kontrollere og fejlfinde Always on Availability Group-webstedet er Always on Dashboard, som kan åbnes ved at højreklikke på Availability Group-navnet og vælge Vis Dashboard-indstillingen.
Fra dashboardet kan du se, at den sekundære replika SQL2 ikke er synkroniseret med den primære replika på grund af forbindelsesproblem, som vist nedenfor:
Kontrollerer den sekundære replika og sikrer, at SQL Server Service er oppe og kører på den sekundære side, som følger:
Hvis du derefter opdaterer tilgængelighedsgruppens dashboard igen, vil du se, at Always on Availability Group-webstedet er sundt 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:
