sql >> Database teknologi >  >> RDS >> Sqlserver

Opsætning og konfiguration af Always-on Availability Group i SQL Server

SQL Server giver os en række højtilgængelige og disaster recovery-løsninger, der hjælper med at gøre de data, der betjener de kritiske systemer, tilgængelige i længst mulig tid med mindst mulig nedetid. Disse løsninger med høj tilgængelighed og katastrofegendannelse leveret af Microsoft SQL Server diskuteres i artiklen SQL Server Transaction Log and High Availability Solutions.

I denne artikel viser vi, hvordan du opsætter og konfigurerer et tilgængelighedsgruppe-websted og konfigurerer det, så det opfylder virksomhedens krav. Men lad os starte med en kort oversigt over Always-on Availability Group-funktionen for at blive fortrolig med den.

Oversigt

SQL Server Always-on Availability Group, introduceret i SQL Server 2012-versionen, er en løsning med høj tilgængelighed og katastrofegendannelse på virksomhedsniveau, der er bygget over Windows Server Failover Clustering-funktionen, hvor en eller flere databaser kan fungere som én tilgængelighedsgruppe og mislykkedes som en enkelt enhed.

Tilgængelighedsgruppen er en beholder for et sæt databaser, der er hostet i én primær replika, indeholder læse-skrive-kopien af ​​databaserne og synkroniseret med op til otte sekundære replikaer, som indeholder en skrivebeskyttet kopi af disse databaser.

Som et alternativ til databasespejlingsfunktionen kan Always on Availability Group bruges til at reducere belastningen på den primære instans ved at konfigurere de sekundære replikaer til at håndtere den skrivebeskyttede arbejdsbyrde og sikkerhedskopiering. På denne måde kan Always-on Availability Group bruges til at forbedre tilgængeligheden af ​​databaserne og forbedre SQL Server-ressourceudnyttelsen for alle replikaer.

Synkroniseringsprocessen mellem Availability Group-replikaerne kan udføres i en af ​​to understøttede tilgængelighedstilstande:

  • Synchronous-commit-tilstand :I denne tilgængelighedstilstand vil den primære replika vente på, at de sekundære replikaer, op til to synkrone sekundære replikaer, bekræfter at skrive loggen i deres databasetransaktionslogfil, før den begår den ved den primære replika. Denne tilgængelighedstilstand øger datatilgængelighedsniveauet over transaktionsforsinkelsesprisen.
  • Asynkron commit-tilstand :Denne tilgængelighedstilstand bruges hovedsageligt til at synkronisere med katastrofegendannelsesreplikaer, der er fordelt over distancerede datacentre, hvor den primære replika ikke vil vente på de sekundære replikaer, for at bekræfte hærdning af loggen for at begå transaktion på den primære side, hvilket giver færre data tilgængelighedsniveau og færre transaktionsforsinkelser.

Always-on Availability Groups failover-processen, hvor den primære rolle vil blive ændret mellem replikaerne, kan udføres manuelt af databaseadministratoren eller automatisk af SQL Serveren selv i tilfælde af fejl på serverniveau under hensyntagen til, at dette failover vil ikke ske i tilfælde af problemer på databaseniveau, såsom databasekorruption.

For hver tilgængelighedsgruppe kan der oprettes et servernavn for at give klienterne mulighed for at oprette forbindelse direkte til den primære replika eller de skrivebeskyttede replikaer uden at genkalde de underliggende SQL Server-instansnavne og -roller i tilgængelighedsgruppen. Dette servernavn kaldes Availability Group Listener .

Demo-scenarie

Efter at have givet en kort introduktion til funktionen Always-on Availability Group, er vi klar til at oprette en tilgængelighedsgruppe og konfigurere den korrekt. I denne demo vil vi oprette en tilgængelighedsgruppe til at replikere AdventureWorks2017-databasen mellem to SQL Server-instanser; SQL1 og SQL2, med SQL Server 2017 allerede installeret på disse servere.

Til test- og demoformål kører SQL Server Services i både SQL1- og SQL2-forekomster under ay\sqladmin-tjenestekontoen, der har de rigtige tilladelser til disse SQL Server-forekomster.

Kom godt i gang

Som nævnt i oversigten over denne artikel er Always-on Availability Group-funktionen bygget over Windows Server Failover Cluster-funktionen. Så vi er nødt til at oprette et failover-klyngewebsted, over hvilket vi definerer tilgængelighedsgruppens websted.

Opret en failover-klynge

Først og fremmest skal vi sikre os, at Failover Clustering-funktionen er installeret på alle replikaer, der vil deltage på Availability Group-webstedet. Dette kan udføres ved at åbne Server Manager-dashboardet på hver replika og vælge Tilføj roller og funktioner i menuen Administrer, og derefter kontrollere og installere Failover Clustering funktion fra denne guide, som vist nedenfor:

Når du har installeret funktionen Failover Cluster, skal du åbne Failover Cluster Manager vindue i en af ​​replikaerne ved hjælp af en autoriseret lokal administratorkonto med domæneadministratorrettigheder, der gør det muligt for den at oprette det klyngenavn i den aktive mappe, og klik på Opret klynge mulighed, som nedenfor:

Fra den åbnede Create Cluster Wizard , tjek de medfølgende instruktioner i Før du begynder vindue, og klik på Næste for at fortsætte:

På den næste side skal du angive navnet eller IP-adressen på de replikaer, der vil deltage i tilgængelighedsgruppen, og klik derefter på Næste for at fortsætte:

Derefter skal du angive, om du vil køre klyngevalideringstesten for at validere, at de tilgængelige ressourcer på disse servere er kompatible med funktionen Failover Clustering, før du opretter Failover Cluster eller ej. Det anbefales altid at udføre valideringstesten på dette trin, før du forsøger at oprette Failover Cluster-webstedet.

Dette fører dig til Valider en konfigurationsguide . På den første side af valideringsguiden skal du kontrollere guidens instruktioner og klikke på Næste for at fortsætte:

Derefter skal du angive, om du vil køre alle Failover Cluster-valideringer, hvilket er den anbefalede mulighed, eller vælge specifikke hurtigere tests. I denne demo vil vi gå med den Microsoft anbefalede mulighed og udføre alle valideringstests, og klik derefter på Næste for at fortsætte:

Og du kan gennemgå valideringstestene, der vil blive udført i denne valideringsguide og bekræfte for at fortsætte ved at klikke på Næste , som følger:

Når valideringsprocessen er fuldført, kan du klikke på knappen Vis rapport for at gennemgå valideringstestresultatet eller eksportere det til en anden ingeniør for at løse ethvert problem, eller klikke på Udfør direkte for at starte klyngenoprettelsesprocessen som nedenfor:

Indtil videre har vi kontrolleret, at vores servere er kompatible med funktionskravene til Failover Clustering, og vi kan fortsætte med at oprette Failover Clustering-webstedet. I Adgangspunktet til administration af klyngen vindue, angiv et unikt navn og IP-adresse for failover-klyngen, og klik derefter på Næste for at fortsætte:

Derefter skal du gennemgå de klyngenoprettelsesindstillinger, du angiver, og sørge for at fjerne markeringen ved siden af ​​Tilføj al kvalificeret lagerplads til klyngen , da Always on Availability Group-funktionen fungerer på dedikeret lagerplads til hver server og IKKE fælles opbevaring. Hvis du har det fint med indstillingerne, skal du klikke på Næste for at fortsætte:

Når Failover Clustering-webstedet er oprettet, giver guiden dig besked med en meddelelse om, at Failover Clustering-webstedet er oprettet fuldstændigt, som nedenfor:

Du kan bekræfte, at Failover Cluster-webstedet er oprettet korrekt, ved at åbne Failover Cluster Manager, som viser dig det oprettede klyngewebsted og alle komponenter i denne klynge som vist nedenfor:

For at holde Failover Cluster-webstedet i den bedste tilgængelighedstilstand skal du konfigurere klyngens kvorum, der kontrollerer, hvornår Failover Cluster skal holdes online eller slå det offline baseret på noderne og ressourceafstemningerne. For at konfigurere klyngens kvorum skal du højreklikke på klyngenavnet under Failover Cluster manager og vælge Konfigurer indstillinger for klynge kvorum mulighed fra Flere handlinger menu som nedenfor. For detaljerede oplysninger om de kvorumsindstillinger, der passer til Always on Availability Group-funktionen, skal du tjekke Windows Failover Cluster Quorum Modes i SQL Server Always On Availability Groups:

Aktiver Always on Availability Group Feature

Efter at have oprettet Failover-klyngen, som tilgængelighedsgruppen oprettes over, skal vi aktivere funktionen Always-on-tilgængelighedsgruppe og forbinde den til Failover-klyngen-webstedet, der vil blive brugt.

For at aktivere Always-on Availability Group-funktionen skal du åbne SQL Server Configuration Manager -> SQL Server Services og derefter højreklikke på SQL Server-tjenesten og vælge Egenskaber. Fra vinduet SQL Server Service-egenskaber skal du flytte til Always-on Availability siden og marker "Aktiver Altid på tilgængelighedsgrupper ” boksen under det automatisk detekterede Failover Cluster navn, som vist nedenfor:

Tag i betragtning, at denne ændring skal udføres på alle replikaer, der vil deltage i tilgængelighedsgruppen og træder i kraft efter genstart af SQL Server-tjenesten, som nedenfor:

Opret ny Always-on tilgængelighedsgruppe

Efter at have aktiveret Always-on Availability Group-funktionen, begynder vi at oprette den nye Availability Group ved at udvide Always-on High Availability noden under SSMS Object Explorer, højreklik derefter på Availability Groups noden og vælg Ny Guiden Tilgængelighedsgruppe , som vist nedenfor:

Den første side i Guiden Ny tilgængelighedsgruppe er introduktionssiden, hvor du kan finde en kort beskrivelse af de trin, der vil blive udført under denne guide for at oprette en ny tilgængelighedsgruppe. Gennemgå den medfølgende oversigt, og klik derefter på Næste for at fortsætte:

I Angiv indstillinger for tilgængelighedsgruppe vindue, skal du angive navnet på tilgængelighedsgruppen, typen af ​​klyngen, baseret på SQL Server-versionen og det operativsystem, der bruges på replikaerne, hvor du kan vælge fra Windows Server Failover Clustering , ikke-Windows EKSTERN klynge eller INGEN hvis ingen klynge bruges.

Denne side giver dig også mulighed for at aktivere sundhedsdetektion på databaseniveau mulighed, der kontrollerer, hvornår en database ikke længere er i onlinestatus, og udfører den automatiske failover af tilgængelighedsgruppen og aktiverer de distribuerede transaktioner i tilgængelighedsgrupper for hver database, som vist nedenfor:

Derefter skal du vælge den eller de databaser, der skal deltage i denne tilgængelighedsgruppe. Guiden kontrollerer forudgående anmodninger om databasen for at blive tilføjet til Availability-gruppen, inklusive den fulde gendannelsesmodel af databasen, og at der tages en fuld sikkerhedskopi fra denne database, før den tilføjes. Når du har opfyldt kravene til, at databasen/databaserne skal inkluderes, skal du opdatere databaselisten, kontrollere databasen og derefter klikke på Næste for at fortsætte:

På næste side under Replikaer fanen, skal du tilføje alle SQL Server-replikaer, der vil deltage i denne tilgængelighedsgruppe og være vært for en kopi fra de inkluderede databaser. Når du har tilføjet replikaerne, kan du vælge op til tre forekomster, der skal konfigureres med Synchronous commit-tilgængelighedstilstanden og tillade den automatiske failover mellem disse replikaer og resten af ​​replikaerne, der vil blive konfigureret med Asynkron commit-tilstand. Du kan også beslutte, om du vil konfigurere hver replika som læsbar sekundær for skrivebeskyttede forbindelser eller læse-hensigts-læsbar replika til at håndtere skrivebeskyttet arbejdsbyrde, der styres automatisk af lytteren, som vist nedenfor:

På fanen Endpoints skal du kontrollere indstillingerne for de forbindelsesendepunkter, der skal bruges til kommunikationen mellem replikaerne, hvor du skal sikre dig, at den brugte TCP-port er aktiveret i firewallreglerne for alle replikaer, og at den angivne tjenestekonto har Tilslut tilladelse til endepunktet af replikaerne, som nedenfor:

På fanen Sikkerhedskopieringsindstillinger skal du angive den placering, hvor sikkerhedskopieringsjobbene skal udføres i tilgængelighedsgruppen. Det giver dig mulighed for at udføre en automatisk backup fra den sekundære replika som en foretrukken mulighed, den sekundære som et must, den primære som et must eller på en hvilken som helst replika. Baseret på denne mulighed kan du oprette vedligeholdelsesplanen for at tage en sikkerhedskopi fra de databaser, der deltager i tilgængelighedsgruppen, som nedenfor:

Fra det samme vindue kan du også definere indstillingerne for tilgængelighedsgruppen for lyttere under Lytter-siden eller fortsætte uden at oprette lytteren for nu og udføre oprettelsen senere. I denne demo konfigurerer vi lytteren efter at have oprettet tilgængelighedsgruppen, som vist nedenfor:

Du kan også bruge siden Skrivebeskyttet routing til at definere den skrivebeskyttede routingliste, der bruges til at kontrollere skrivebeskyttet arbejdsbelastning inden for sekundærerne. For mere information, se Sådan konfigurerer du skrivebeskyttet routing for en tilgængelighedsgruppe i SQL Server 2016:

På næste side skal du specificere den mekanisme, der vil blive brugt til den indledende datasynkroniseringsproces mellem de primære og sekundære replikaer, med mulighed for at udføre synkroniseringen automatisk eller manuelt ved at slutte sig til den sekundære til tilgængelighedsgruppen og synkronisere databaserne senere manuelt.

Der er to automatiske synkroniseringsmetoder tilgængelige i denne guide, den første er at specificere en delt mappe for midlertidigt at kopiere den fulde og transaktionslog backup og udføre gendannelsen automatisk, som vi vil bruge her i denne demo, eller bruge en Direct Seeding metode uden tage backup, som beskrevet i SQL Server 2016 Always On Availability Group med Direct Seeding:

For at bruge Fuld Database og Log Backup metode, skal vi oprette en delt mappe og levere SQL Server-tjenesternes konti til replikaernes læse- og skrivetilladelser på den mappe, som vist nedenfor:

Derefter vil guiden Ny tilgængelighedsgruppe udføre en valideringskontrol for al konfiguration, før den fortsætter med oprettelse af tilgængelighedsgruppe. Hvis der er en fejl, kan du rette den direkte og derefter opdatere siden og klikke på Næste for at fortsætte:

På den sidste fase vil guiden give dig en oversigt over alle guidens konfigurationer for at gennemgå den og derefter klikke på Udfør for at begynde at oprette tilgængelighedsgruppen, som nedenfor:

Når guiden er færdig, vil den vise dig resultatet af hvert trin, og hvis der er en fejl. Ellers vil den vise en meddelelse om, at tilgængelighedsgruppen er oprettet uden problemer, som vist nedenfor:

Du kan også validere, at Always on Availability Group er oprettet og konfigureret med succes ved hjælp af SSMS Object Explorer, ved at kontrollere, at den eller de deltagende databaser er i en Synkroniseret tilstand i alle replikaer, og at replikaerne og databaserne er online under Always-on High Availability node, som vist nedenfor:

Du kan også oprette forbindelse til den primære replika med det primære ord ved siden af ​​tilgængelighedsgruppens navn og kontrollere egenskabssiden for tilgængelighedsgruppe med mulighed for at udføre de samme opgaver, som vi udførte under guiden Ny tilgængelighedsgruppe, såsom tilføjelse af nye replikaer , tilføjelse af ny database, ændring af hver replikakonfiguration, ændring af sikkerhedskopieringspræferencer og definering af en skrivebeskyttet routingliste, som vist nedenfor:

Opret Always-on Availability Group Listener

Det sidste trin i konfigurationen af ​​tilgængelighedsgruppen er at oprette den tilgængelighedsgruppelytter, der skal bruges, når der oprettes forbindelse til de primære og sekundære replikaer uden at angive replikanavnet.

For at oprette tilgængelighedsgruppelytteren skal du højreklikke på Availability Group Listener node under den oprettede tilgængelighedsgruppe node og vælge Tilføj lytter mulighed. Fra den åbnede New Availability Group Listener vindue, angiv navnet på den lytter, den TCP-port, der skal bruges til at oprette forbindelse til den lytter og den statiske IP-adresse, der vil blive tildelt lytteren, og klik derefter på OK at skabe det. Når lytteren er oprettet, lukkes vinduet automatisk, og lytterens navn vil blive vist under lytternoden, som vist nedenfor:

For at oprette forbindelse til Availability Group ved hjælp af lytterens navn skal du angive lytterens navn eller IP med TCP-portnummeret i Connect to Server, og den vil oprette forbindelse direkte til den primære node, som vist nedenfor:

Test failover-proces

Efter at have testet forbindelsen til Availability Group-lytteren og replikaerne, skal vi udføre en vigtig test for failoveren for at sikre, at den primære rolle vil blive flyttet mellem replikaerne uden problemer, og at databaserne vil være tilgængelige og i den synkroniserede tilstand efter failover.

For at udføre en manuel failover skal du højreklikke på tilgængelighedsgruppens navn og vælge Failover mulighed, som nedenfor:

Den første side i Failover Availability Group guiden er introduktionssiden, der giver en oversigt over de handlinger, der kan udføres i denne guide. Gennemgå introduktionen, og klik på Næste for at fortsætte:

På næste side skal du vælge, hvilken node der skal fungere som den nye primære replika, og sørg for, at der ikke sker noget datatab, når failover-handlingen udføres, og klik derefter på Næste for at fortsætte:

Derefter skal du oprette forbindelse til den nye primære replika, som du vælger for at sikre, at denne replika er online og tilgængelig, som vist nedenfor:

Gennemgå derefter dine valg i Failover-guiden på oversigtssiden, og klik på Udfør for at starte Failover-processen:

Når failoveren er fuldført, skal du gennemgå resultatsiden for at sikre, at der ikke er nogen problemer under failover-processen, som nedenfor:

Fra SSMS Object Explorer ændres rollen for SQL1-replikaen direkte til Sekundær, som vist nedenfor:

I denne artikel har vi beskrevet detaljeret de trin, der skal udføres for at forberede oprettelsen af ​​tilgængelighedsgruppens websted, og hvordan du opretter og konfigurerer webstedet Always-on Availability Group. I den næste artikel vil vi se, hvordan du fejlfinder de problemer, du kan komme ud for med et eksisterende tilgængelighedsgruppewebsted. Følg med.


  1. Konverter et månedsnavn til månedsnummeret i SQL Server (T-SQL)

  2. ATAN() Eksempler i SQL Server

  3. 5 grunde til at vælge Arkware

  4. Hvorfor returnerer valg af SCOPE_IDENTITY() en decimal i stedet for et heltal?