SQL Server Always ON Availability Group er en løsning, der er beregnet til at opnå høj tilgængelighed og gendannelse efter katastrofe for SQL Server-databaser. Vi kan konfigurere denne funktionalitet mellem Windows-baserede SQL Server-installationer, Linux-baserede SQL Server-installationer og endda mellem Linux- og Windows-baserede SQL Server-installationer sammen.
Tilgængelighedsgrupper er tæt integreret med klyngeteknologier i en form for automatisk failover og databeskyttelse ved at replikere data til deres respektive sekundære replikaer. Det er dog ikke altid obligatorisk at have en cluster ressource manager til at konfigurere tilgængelighedsgrupper.
For at konfigurere SQL Server-tilgængelighedsgrupper har vi brug for WSFC – Windows Server Failover Cluster teknologi til Windows -baserede SQL Server-installationer og PACEMAKER til Linux -baserede SQL Server-installationer.
PACEMAKER er en open source-klyngressourcemanager, som vi kan bruge til at administrere ressourcer og sikre systemtilgængelighed, hvis der skulle opstå fejl på Linux-systemer.
WSFC er et Microsoft-produkt udviklet til at understøtte Windows-baserede klyngekrav.
Når du ser på de konfigurerede tilgængelighedsgrupper i SQL Server for begge typer operativsystemer, ser det ud til at være ens i SQL Server Management Studio.
Denne artikel forklarer dog tilgængelighedsgrupper mellem den Ubuntu Linux-baserede SQL Server installationer ved hjælp af PACEMAKER klyngeteknologi, så jeg vil kun overveje denne konfiguration.
Klyngetypekonfiguration
Som jeg har nævnt ovenfor, har vi tre varianter til at konfigurere tilgængelighedsgrupper til SQL Server, afhængigt af operativsystemet:
- mellem Windows-baserede SQL Server-installationer;
- mellem Linux-baserede SQL Server-installationer;
- mellem den blandede type Windows- og Linux-baserede SQL Server-installationer.
Microsoft har introduceret Cluster_type konfigurationsindstilling for at identificere og konfigurere en passende klyngeteknologi til tilgængelighedsgrupper. Det er et konfigurationselement, der definerer, hvilken type klyngeteknologi vi bruger til Availability Groups, uanset hvilket OS SQL Server-instansen er baseret på.
Du kan hente og validere den eksisterende konfiguration af klyngetypen ved hjælp af SQL Server Dynamic Management View (DMV) sys.availability_groups . Der er to kolonner med navnet cluster_type og cluster_type_desc . Vi kan læse disse kolonner for at definere klyngetypekonfigurationen af tilgængelighedsgruppens opsætning.
Denne konfigurationsindstilling har 3 værdier for at opfylde klyngeteknologikravene for hver variant:
WSFC .Du skal bruge indstillingen WSFC (Windows server failover cluster), hvis du har Windows-baserede SQL Server-installationer. Det er ikke understøttet for Linux-baserede SQL Server-installationer.
EKSTERN . Hvis du konfigurerer tilgængelighedsgrupper mellem Linux-baserede SQL Server-installationer, skal du bruge PACEMAKER cluster manager og vælge EKSTERN klynge skriv . Failovertilstanden skal også være EKSTERN (i WSFC vil den være Automatisk).
INGEN . Hvis du ikke ønsker at bruge nogen klyngeteknologi til dine tilgængelighedsgrupper, skal du vælge INGEN . Denne mulighed er anvendelig, hvis du vil konfigurere tilgængelighedsgrupper mellem Linux- og Windows-baserede SQL Server-instanser. Selvom du har konfigureret klyngedannelse til dit system, vil tilgængelighedsgrupperne ikke bruge klyngeteknologien, når først du har indstillet klyngetypeværdien til INGEN. Failovertilstanden for klyngetypen NONE er altid Manuel .
En ny indstilling:Kræver synkroniserede sekundære for at forpligte sig
Startende med SQL Server 2017 har Microsoft introduceret en ny indstilling kaldet required_synchronized_secondaries_to_commit . Den aktiverer muligheden for automatisk failover, hvis du har konfigureret klyngetypen som EKSTERN for PACEMAKER-klyngekonfigurationen.
Denne indstillings værdi indstilles som standard, når du konfigurerer SQL Server-ressourceagenten mssql-server-ha og opret klyngekonfigurationen.
Du kan også manuelt ændre værdien til dine krav ved at køre nedenstående kommando:
--Run below commands to change value for setting required_synchronized_secondaries_to_commit
--AGResourceName is the name of the resource configured for the Availability group
sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<Value>
Bemærk:Vi kan kun ændre ovenstående indstilling via Pacemaker på Linux. Det er umuligt at ændre det ved hjælp af T-SQL-sætningen til Linux-baserede implementeringer. For Windows-baserede implementeringer kan vi dog ændre denne indstilling ved hjælp af en T-SQL-sætning.
Nedenfor er de mulige værdier for required_synchronized_secondaries_to_commit
0 – Det betyder, at sekundære replikaer ikke skal synkroniseres med den respektive primære replika. Den understøtter således ikke den automatiske failover. Du skal starte failoveren manuelt, hvis den primære replika går ned. Vigtigt:Der er risiko for datatab, når du vælger denne værdi til konfiguration.
1 – Det betyder, at mindst én sekundær replika skal være i synkroniseret tilstand for at opnå automatisk failover.
2 – Det betyder, at begge sekundære replikaer skal synkroniseres med den primære replika. Den automatiske failover er understøttet.
Replikaer til at deltage i en tilgængelighedsgruppe
Antallet af replikaer, der kan deltage i en tilgængelighedsgruppe, afhænger af den installerede SQL Server-udgave.
- SQL Server Standarden udgaven understøtter kun to-node replika for en tilgængelighedsgruppe sammen med den ekstra replika, der kun er til konfiguration.
- SQL Server Enterprise udgaven understøtter op til ni replikaer – en primær og otte sekundære replikaer.
Da SQL Server Standard Edition kun understøtter to replikaer (en primær replika og en sekundær replika), har Microsoft introduceret et nyt koncept kaldet replika kun til konfiguration i SQL Server 2017 CU1 for at opnå automatisk failover for SQL-servere, der kører på Linux-systemer.
Der er to mulige designmuligheder:
- Tre synkrone replikaer. Denne konfiguration kan kun implementeres med SQL Server Enterprise-udgaven. Der vil være 3 kopier af dine tilgængelighedsdatabaser. Denne arkitektur giver mulighed for alle 3 funktionaliteter læseskala, høj tilgængelighed og databeskyttelse.
- To synkrone replikaer og en konfigurationsreplika. Du kan også konfigurere dette design ved hjælp af SQL Server Standard-udgaven, idet du kører to synkrone replikaer på SQL Server Standard-udgaven og de 3 replikaer på SQL Server Express-udgaven, der fungerer som replikaen, der kun er til konfiguration. Det er et omkostningseffektivt design, der understøtter høj tilgængelighed med automatisk failover og databasebeskyttelse.
To-node replika
to-node replika-konfigurationer for Availability Groups er en meget populær implementeringsmulighed for at sikre den høje tilgængelighed af SQL Server-databaser. Vi opnår den automatiske failover ved hjælp af Windows Server Failover Cluster-teknologien og et fildelingsvidne i Windows-baserede SQL Server-implementeringer.
Fildelingen bruges generelt på en ekstra node i WSFC for at give kvorumkonfiguration for to-node replikakonfigurationer. WSFC synkroniserer alle konfigurationsmetadata til både replikaer og på den tredje node eller fildelingsvidne for jævn failover. Al failover-arbitration for Windows-baseret SQL Server-tilgængelighedsgruppe sker på WSFC-laget.
Hvis vi ønsker at opnå den automatiske failover for Linux-baserede SQL Server Availability Group-implementeringer, vil ovenstående konfiguration ikke fungere. Det er fordi WSFC kun kan bruges til Windows-baserede SQL Server-installationer.
For at imødegå denne begrænsning og aktivere automatisk failover for Linux-baserede to-replika-implementeringer har Microsoft introduceret et nyt koncept.
Replika kun for konfiguration
En replika, der kun er til konfiguration, er en mulighed, hvor vi installerer en ekstra forekomst af SQL Server på den tredje node. Denne node vil fungere som en vidneserver for to-node replika-konfigurationen for at understøtte automatisk failover. Vi kan oprette én konfigurationsreplika pr. tilgængelighedsgruppe .
For Linux-baserede SQL Server-forekomster, hvor vi bruger klyngetype som EKSTERN for PACEMAKER, fungerer failover-arbitreringen ikke på klyngelag som WSFC. Al failover-arbitrering sker på SQL Server-laget, fordi alle metadata for tilgængelighedsgruppekonfiguration er lagret i masterdatabaserne for hver replika.
Microsoft har introduceret replikakonceptet, der kun er til konfiguration, til at håndtere kvorum for Linux-baserede SQL Server-tilgængelighedsgrupper. Dette koncept er ikke vært for nogen brugerdatabaser til at deltage i en tilgængelighedsgruppe. Den gemmer alle konfigurationsoplysninger om tilgængelighedsgruppe i masterdatabasen for at sikre, at al failover-arbitrage foregår problemfrit.
Du kan bruge enhver udgave af SQL Server til replikaen, der kun er til konfiguration. Selv SQL Server Express-udgaven vil passe til at spare dine licensomkostninger til den tredje replika. Husk, at replikaen, der kun er til konfiguration, ikke er vært for nogen database inden for tilgængelighedsgruppen. Således vil du kun have to kopier af databaser i en tilgængelighedsgruppe.
Som standard required_synchronized_secondaries_to_commit er indstillet til 0 når vi bruger replikaen, der kun er til konfiguration. Vi kan manuelt ændre denne værdi til 1, hvis det er nødvendigt.
Tag et kig på designdiagrammet for den synkrone replika med to noder og en replika, der kun er til konfiguration, for at opnå automatisk failover og databeskyttelse.
Vi kan se, at der er 3 VM'er ved navn AOAGVM1, AOAGVM2 &AOAGVM3. De kører alle af Ubuntu Linux-systemet, og SQL Server er konfigureret på alle tre Linux-systemer. Tilgængelighedsdatabaserne er hostet på AOAGVM1 og AOAGVM2.
AOAGVM1 fungerer som en primær replika, mens AOAGVM2 er en sekundær replika. AOAGVM3 fungerer som den eneste konfigurationsreplika, som er SQL Server Express-udgaven. Ingen brugerdatabaser er hostet på denne tredje replika.
Pacemaker-klyngen er blevet konfigureret mellem alle tre noder for at understøtte klyngeteknologien til Linux-baseret tilgængelighedsgruppekonfiguration.
For at konfigurere eller implementere ovenstående design skal vi udføre følgende trin:
- Installer SQL Server på tre Ubuntu-systemer (SQL Server Express-udgaven passer til replikaer, der kun kan konfigureres).
- Konfigurer tilgængelighedsgrupper mellem tre noder.
- Konfigurer PACEMAKER-klyngen mellem tre noder.
- Tilføj eller integrer tilgængelighedsgruppe som en ressource i klyngegruppen.
Se den relaterede artikel for at fuldføre trin 1 (installation af SQL Server-forekomster på tre noder).
Hold øje med min næste artikel, hvor jeg vil forklare trin-for-trin-processen for at implementere ovenstående design. Vores mål vil være at opnå automatisk failover og databeskyttelse ved hjælp af den synkrone replika med 2 noder og en replika, der kun er til konfiguration.
Vi vil være glade for at høre dine tanker og praktiske tips om denne sag. Du er velkommen til at dele dem i kommentarsektionen.