sql >> Database >  >> RDS >> Sqlserver

Inzicht in Always ON-beschikbaarheidsgroep tussen op Linux gebaseerde SQL Server-instanties. Deel 1

SQL Server Always ON Availability Group is een oplossing die bedoeld is om hoge beschikbaarheid en noodherstel voor SQL Server-databases te bereiken. We kunnen deze functionaliteit configureren tussen de Windows-gebaseerde SQL Server-installaties, Linux-gebaseerde SQL Server-installaties en zelfs tussen Linux en Windows-gebaseerde SQL Server-installaties samen.

Beschikbaarheidsgroepen zijn nauw geïntegreerd met clustertechnologieën in de vorm van automatische failover en gegevensbescherming door gegevens te repliceren naar hun respectieve secundaire replica's. Het is echter niet altijd verplicht om een ​​clusterresourcemanager te hebben om beschikbaarheidsgroepen te configureren.

Om SQL Server-beschikbaarheidsgroepen te configureren, hebben we WSFC . nodig – Windows Server Failover Cluster technologie voor Windows -gebaseerde SQL Server-installaties en PACEMAKER voor Linux -gebaseerde SQL Server-installaties.

PACEMAKER is een open-source cluster resource manager die we kunnen gebruiken om resources te beheren en systeembeschikbaarheid te garanderen, mocht er een storing op Linux-systemen plaatsvinden.

WSFC is een Microsoft-product dat is ontwikkeld om op Windows gebaseerde clustervereisten te ondersteunen.

Als je kijkt naar de geconfigureerde beschikbaarheidsgroepen binnen SQL Server voor beide typen besturingssystemen, lijkt het vergelijkbaar in SQL Server Management Studio.

In dit artikel worden echter de beschikbaarheidsgroepen tussen de Ubuntu Linux-gebaseerde SQL Server uitgelegd installaties met behulp van de PACEMAKER clustertechnologie, dus ik zal alleen deze configuratie overwegen.

Configuratie clustertype

Zoals ik hierboven heb vermeld, hebben we drie varianten voor het configureren van beschikbaarheidsgroepen voor SQL Server, afhankelijk van het besturingssysteem:

  • tussen Windows-gebaseerde SQL Server-installaties;
  • tussen Linux-gebaseerde SQL Server-installaties;
  • tussen het gemengde type Windows- en Linux-gebaseerde SQL Server-installaties.

Microsoft heeft het Cluster_type . geïntroduceerd configuratie-instelling om een ​​geschikte clustertechnologie voor beschikbaarheidsgroepen te identificeren en configureren. Het is een configuratie-item dat definieert welk type clustertechnologie we gebruiken voor beschikbaarheidsgroepen, ongeacht op welk besturingssysteem de SQL Server-instantie is gebaseerd.

U kunt de bestaande configuratie van het type Cluster ophalen en valideren met behulp van SQL Server dynamic management view (DMV) sys.availability_groups . Er zijn twee kolommen met de naam cluster_type en cluster_type_desc . We kunnen deze kolommen lezen om de clustertypeconfiguratie van de Beschikbaarheidsgroepconfiguratie te definiëren.

Deze configuratie-instelling heeft 3 waarden om te voldoen aan de clustertechnologievereisten voor elke variant:

WSFC .U moet de WSFC-optie (Windows Server Failover Cluster) gebruiken als u op Windows gebaseerde SQL Server-installaties hebt. Het wordt niet ondersteund voor op Linux gebaseerde SQL Server-installaties.

EXTERN . Als u Beschikbaarheidsgroepen configureert tussen Linux-gebaseerde SQL Server-installaties, moet u de PACEMAKER-clustermanager gebruiken en de EXTERN kiezen cluster type . De failover-modus moet ook EXTERN zijn (in WSFC zal dit automatisch zijn).

GEEN . Als u geen clustertechnologie voor uw beschikbaarheidsgroepen wilt gebruiken, selecteert u GEEN . Deze optie is van toepassing als u beschikbaarheidsgroepen wilt configureren tussen Linux- en Windows-gebaseerde SQL Server-instanties. Zelfs als u clustering voor uw systeem hebt geconfigureerd, zullen de beschikbaarheidsgroepen de clustertechnologie niet gebruiken zodra u de waarde voor het clustertype op GEEN hebt ingesteld. De failover-modus voor het clustertype NONE is altijd Handmatig .

Een nieuwe instelling:vereiste gesynchroniseerde secundairen om te committen

Vanaf SQL Server 2017 heeft Microsoft een nieuwe instelling geïntroduceerd met de naam required_synchronized_secondaries_to_commit . Het schakelt de automatische failover-optie in als u het clustertype hebt geconfigureerd als EXTERN voor de PACEMAKER-clusterconfiguratie.

De waarde van deze instelling wordt standaard ingesteld wanneer u de SQL Server-bronagent mssql-server-ha configureert en maak de clusterconfiguratie.

U kunt de waarde ook handmatig aanpassen aan uw vereisten door de onderstaande opdracht uit te voeren:

--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>

Opmerking:we kunnen de bovenstaande instelling alleen wijzigen via Pacemaker op Linux. Het is onmogelijk om het te wijzigen met behulp van de T-SQL-instructie voor op Linux gebaseerde implementaties. Voor op Windows gebaseerde implementaties kunnen we deze instelling echter wijzigen door een T-SQL-instructie.

Hieronder staan ​​de mogelijke waarden voor required_synchronized_secondaries_to_commit

0 – Dit betekent dat secundaire replica's niet hoeven te worden gesynchroniseerd met de respectieve primaire replica. Het ondersteunt dus niet de automatische failover. U moet de failover hand matig starten als de primaire replica uitvalt. Belangrijk:er is een kans op gegevensverlies wanneer u deze waarde kiest voor configuratie.

1 – Dit betekent dat ten minste één secundaire replica in de gesynchroniseerde staat moet zijn om automatische failover te bereiken.

2 – Dit betekent dat beide secundaire replica's moeten worden gesynchroniseerd met de primaire replica. De automatische failover wordt ondersteund.

Replica's om deel te nemen aan een beschikbaarheidsgroep

Het aantal replica's dat kan deelnemen aan een Beschikbaarheidsgroep hangt af van de geïnstalleerde SQL Server-editie.

  • De SQL Server Standaard editie ondersteunt alleen replica met twee knooppunten voor een beschikbaarheidsgroep samen met de aanvullende replica met alleen configuratie.
  • De SQL Server Enterprise editie ondersteunt maximaal negen replica's - één primaire en acht secundaire replica's.

Aangezien de SQL Server Standard Edition slechts twee replica's ondersteunt (een primaire replica en een secundaire replica), heeft Microsoft een nieuw concept geïntroduceerd met de naam replica met alleen configuratie in SQL Server 2017 CU1 om automatische failover te realiseren voor SQL Servers die op Linux-systemen draaien.

Er zijn twee mogelijke ontwerpopties:

  • Drie synchrone replica's. Deze configuratie kan alleen worden geïmplementeerd met de SQL Server Enterprise-editie. Er zullen 3 exemplaren van uw beschikbaarheidsdatabases zijn. Deze architectuur zorgt voor alle 3 functionaliteiten leesschaal, hoge beschikbaarheid en gegevensbescherming.
  • Twee synchrone replica's en een replica met alleen configuratie. U kunt dit ontwerp ook configureren met behulp van de SQL Server Standard-editie, waarbij twee synchrone replica's worden uitgevoerd op de SQL Server Standard-editie en de 3-replica op de SQL Server Express-editie die fungeert als de replica met alleen configuratie. Het is een kosteneffectief ontwerp dat hoge beschikbaarheid ondersteunt met automatische failover en databasebescherming.

Replica met twee knooppunten

De replicaconfiguraties met twee knooppunten voor Beschikbaarheidsgroepen is een zeer populaire implementatieoptie om de hoge beschikbaarheid van SQL Server-databases te garanderen. We bereiken de automatische failover met behulp van de Windows Server Failover Cluster-technologie en een fileshare-getuige in Windows-gebaseerde SQL Server-implementaties.

De bestandsshare wordt over het algemeen gebruikt op een extra knooppunt in WSFC om quorumconfiguratie te bieden voor replicaconfiguraties met twee knooppunten. WSFC synchroniseert alle configuratiemetadata naar beide replica's en op de derde node of filesharewitness voor een soepele failover. Alle failover-arbitrage voor de op Windows gebaseerde SQL Server-beschikbaarheidsgroep vindt plaats op de WSFC-laag.

Als we de automatische failover voor op Linux gebaseerde SQL Server-beschikbaarheidsgroepimplementaties willen bereiken, werkt de bovenstaande configuratie niet. Dit komt omdat WSFC alleen kan worden gebruikt voor op Windows gebaseerde SQL Server-installaties.

Om deze beperking aan te pakken en automatische failover mogelijk te maken voor op Linux gebaseerde implementaties met twee replica's, heeft Microsoft een nieuw concept geïntroduceerd.

Replica met alleen configuratie

Een replica met alleen configuratie is een optie waarbij we een extra exemplaar van SQL Server op het derde knooppunt installeren. Dat knooppunt werkt als een getuige-server voor de replicaconfiguratie met twee knooppunten om automatische failover te ondersteunen. We kunnen één configuratie-only replica per beschikbaarheidsgroep maken .

Voor op Linux gebaseerde SQL Server-instanties waarbij we het clustertype EXTERN gebruiken voor PACEMAKER, werkt de failoverarbitrage niet op clusterlaag zoals WSFC. Alle failover-arbitrage vindt plaats op de SQL Server-laag omdat alle metadata van de configuratie van de beschikbaarheidsgroep wordt opgeslagen in de hoofddatabases van elke replica.

Microsoft heeft het replicaconcept met alleen configuratie geïntroduceerd om het quorum voor op Linux gebaseerde SQL Server-beschikbaarheidsgroepen te verwerken. Dit concept host geen gebruikersdatabases om deel te nemen aan een beschikbaarheidsgroep. Het slaat alle configuratie-informatie van de Beschikbaarheidsgroep op in de hoofddatabase om ervoor te zorgen dat alle failover-arbitrage soepel verloopt.

U kunt elke editie van SQL Server gebruiken voor de replica met alleen configuratie. Zelfs de SQL Server Express-editie is geschikt om uw licentiekosten voor de derde replica te besparen. Houd er rekening mee dat de replica met alleen configuratie geen database host binnen de beschikbaarheidsgroep. U hebt dus slechts twee exemplaren van databases in een beschikbaarheidsgroep.

Standaard required_synchronized_secondaries_to_commit is ingesteld op 0 wanneer we de replica met alleen configuratie gebruiken. We kunnen deze waarde indien nodig handmatig wijzigen in 1.

Bekijk het ontwerpdiagram van de synchrone replica met twee knooppunten en een replica met alleen configuratie om automatische failover en gegevensbescherming te bereiken.

We kunnen zien dat er 3 VM's zijn met de naam AOAGVM1, AOAGVM2 en AOAGVM3. Ze draaien allemaal op het Ubuntu Linux-systeem en SQL Server is geconfigureerd op alle drie de Linux-systemen. De beschikbaarheidsdatabases worden gehost op AOAGVM1 en AOAGVM2.

AOAGVM1 fungeert als een primaire replica, terwijl AOAGVM2 een secundaire replica is. AOAGVM3 dient als de configuratie-only replica, de SQL Server Express-editie. Er worden geen gebruikersdatabases gehost op deze derde replica.

Het Pacemaker-cluster is geconfigureerd tussen alle drie de knooppunten om de clustertechnologie te ondersteunen voor configuratie van beschikbaarheidsgroepen op basis van Linux.

Om het bovenstaande ontwerp te configureren of te implementeren, moeten we de volgende stappen uitvoeren:

  1. Installeer SQL Server op drie Ubuntu-systemen (de SQL Server Express-editie is geschikt voor replica met alleen configuratie).
  2. Beschikbaarheidsgroepen configureren tussen drie knooppunten.
  3. Configureer het PACEMAKER-cluster tussen drie knooppunten.
  4. Beschikbaarheidsgroep toevoegen of integreren als een resource in de clustergroep.

Bekijk het gerelateerde artikel om stap 1 te voltooien (installatie van SQL Server-instanties op drie knooppunten).

Blijf op de hoogte voor mijn volgende artikel, waar ik het stapsgewijze proces zal uitleggen om het bovenstaande ontwerp te implementeren. Ons doel is om automatische failover en gegevensbescherming te bereiken met behulp van de synchrone replica met 2 knooppunten en een replica met alleen configuratie.

We horen graag uw mening en praktische tips hierover. Voel je vrij om ze te delen in het gedeelte Opmerkingen.


  1. IGNORE_DUP_KEY langzamer op geclusterde indexen

  2. PLSQL JDBC:Hoe krijg ik de laatste rij-ID?

  3. Prestatiebewaking voor TimescaleDB

  4. Een inventarisdatabase maken op Access