Delen via

Hoge beschikbaarheid en gegevensbeveiliging voor configuraties van beschikbaarheidsgroepen

Van toepassing op:SQL Server - Linux

Dit artikel bevat ondersteunde implementatieconfiguraties voor SQL Server AlwaysOn-beschikbaarheidsgroepen op Linux-servers. Een beschikbaarheidsgroep ondersteunt hoge beschikbaarheid en gegevensbeveiliging. Automatische foutdetectie, automatische failover en transparante opnieuw verbinding maken na failover bieden hoge beschikbaarheid. Gesynchroniseerde replica's bieden gegevensbeveiliging.

In een Windows Server Failover Cluster (WSFC) gebruikt een algemene configuratie voor hoge beschikbaarheid twee synchrone replica's en een derde server of bestandsshare om quorum te bieden. De file-share witness valideert de configuratie van de beschikbaarheidsgroep: de synchronisatiestatus en de rol van de replica, bijvoorbeeld. Deze configuratie zorgt ervoor dat de secundaire replica die is gekozen als het failoverdoel de meest recente configuratiewijzigingen voor gegevens- en beschikbaarheidsgroepen bevat.

WSFC synchroniseert de configuratiemetagegevens voor failover-arbitrage tussen de replica's van de beschikbaarheidsgroep en de bestandsdeling-getuige. Wanneer een beschikbaarheidsgroep zich niet in een WSFC bevindt, slaan de SQL Server-exemplaren configuratiemetagegevens op in de master database.

Een beschikbaarheidsgroep op een Linux-cluster heeft CLUSTER_TYPE = EXTERNALbijvoorbeeld . Er is geen WSFC om failover te arbitreren. In dit geval worden de configuratiemetagegevens beheerd en onderhouden door de SQL Server-exemplaren. Omdat er geen witness-server in dit cluster is, is een derde SQL Server-exemplaar vereist voor het opslaan van metagegevens van de configuratiestatus. Alle drie de SQL Server-exemplaren bieden gedistribueerde metagegevensopslag voor het cluster.

De clusterbeheerder kan query's uitvoeren op de exemplaren van SQL Server in de beschikbaarheidsgroep en failover organiseren om hoge beschikbaarheid te behouden. In een Linux-cluster is Pacemaker de clusterbeheerder.

Vanaf SQL Server 2017 (14.x) CU 1 is hoge beschikbaarheid voor een beschikbaarheidsgroep ingeschakeld voor CLUSTER_TYPE = EXTERNAL twee synchrone replica's plus een configuratiereplica. De replica die alleen de configuratie bevat kan worden gehost op elke editie van SQL Server 2017 (14.x), CU 1 of hoger (inclusief de SQL Server Express-editie). De configuratie alleen replica onderhoudt configuratiegegevens over de beschikbaarheidsgroep in de master database, maar bevat niet de gebruikersdatabases in de beschikbaarheidsgroep.

Hoe de configuratie van invloed is op de standaardresource-instellingen

De REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT clusterresource-instelling garandeert dat het opgegeven aantal secundaire replica's transactiegegevens naar het logboek schrijft voordat elke transactie wordt doorgevoerd door de primaire replica. Wanneer u een extern clusterbeheer gebruikt, is deze instelling van invloed op zowel hoge beschikbaarheid als gegevensbeveiliging. De standaardwaarde voor de instelling is afhankelijk van de architectuur op het moment dat de clusterresource wordt gemaakt. Wanneer u de SQL Server-resourceagent installeert- mssql-server-ha en een clusterresource maakt voor de beschikbaarheidsgroep, detecteert de clusterbeheerder de configuratie van de beschikbaarheidsgroep en stelt deze REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT dienovereenkomstig in.

Als deze wordt ondersteund door de configuratie, wordt de parameter REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT van de resourceagent ingesteld op de waarde die hoge beschikbaarheid en gegevensbeveiliging biedt. Zie Inzicht in sql Server-resourceagent voor pacemaker voor meer informatie.

In de volgende secties wordt het standaardgedrag voor de clusterresource uitgelegd.

Kies een ontwerp voor een beschikbaarheidsgroep om te voldoen aan specifieke zakelijke vereisten voor hoge beschikbaarheid, gegevensbescherming en leesschaal.

In de volgende configuraties worden de ontwerppatronen van de beschikbaarheidsgroep en de mogelijkheden van elk patroon beschreven. Deze ontwerppatronen zijn van toepassing op beschikbaarheidsgroepen met CLUSTER_TYPE = EXTERNAL voor oplossingen voor hoge beschikbaarheid.

  • drie synchrone replica's
  • Twee synchrone replica's
  • Twee synchrone replica's en alleen een configuratiereplica

Drie synchrone replica's

Deze configuratie bestaat uit drie synchrone replica's. Het biedt standaard hoge beschikbaarheid en gegevensbeveiliging. Het kan ook leescapaciteitsschaal bieden.

Diagram met drie synchrone replica's.

Een beschikbaarheidsgroep met drie synchrone replica's kan schaalbaar lezen, hoge beschikbaarheid en gegevensbeveiliging bieden. In de volgende tabel wordt het gedrag van de beschikbaarheid beschreven.

Beschikbaarheidsgedrag leesschaal Hoge beschikbaarheid &
gegevensbeveiliging		 Gegevensbescherming
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1 2
Primaire storing Automatische failover. Kan gegevensverlies hebben. De nieuwe primaire eenheid is R/W. Automatische failover. De nieuwe primaire eenheid is R/W. Automatische failover. De nieuwe primaire server is niet beschikbaar voor lees- of schrijftransacties totdat de voormalige primaire server zich herstelt en opnieuw bij de beschikbaarheidsgroep aansluit als secundaire.
Een storing in de secundaire replica Hoofd is Lezen/Schrijven. Beschikbare secundaire gegevens zijn beschikbaar voor lezen. Hoofd is Lezen/Schrijven. Beschikbare secundaire gegevens zijn beschikbaar voor lezen. De primaire blijft ontoegankelijk voor lees- of schrijftransacties totdat de gefaalde secundaire zich heeft hersteld en opnieuw deelnemt aan de beschikbaarheidsgroep.
Storing van twee secundaire replica's De primaire is alleen beschikbaar voor leesbewerkingen en niet voor schrijfbewerkingen totdat een van de secundaire replica's herstelt en weer bij de beschikbaarheidsgroep aansluit. De primaire is alleen beschikbaar voor leesbewerkingen en niet voor schrijfbewerkingen totdat een van de secundaire replica's herstelt en weer bij de beschikbaarheidsgroep aansluit. De primaire blijft niet beschikbaar voor lees- of schrijftransacties totdat alle mislukte secundaire replica's herstellen en opnieuw deelnemen aan de beschikbaarheidsgroep.
Uitval van primaire en één secundaire replica Automatische failover. Kan gegevensverlies hebben. De nieuwe primaire versie is alleen beschikbaar voor leesbewerkingen en niet voor schrijfbewerkingen totdat een van de secundaire replica's de beschikbaarheidsgroep herstelt en opnieuw deel uitmaakt. Automatische failover. De nieuwe primaire versie is alleen beschikbaar voor lees- en schrijfbewerkingen totdat een van de secundaire replica's de beschikbaarheidsgroep herstelt en opnieuw deel uitmaakt. Automatische failover. Nieuwe primaire replica blijft niet beschikbaar voor lees- of schrijftransacties totdat de voormalige primaire replica en de secundaire replica zijn hersteld en opnieuw zijn toegevoegd aan de beschikbaarheidsgroep.

1 Standaard

Twee synchrone replicas

Met deze configuratie kunt u gegevensbeveiliging inschakelen. Net als bij de andere configuraties van de beschikbaarheidsgroep kan deze de leesschaal inschakelen. De configuratie van twee synchrone replica's biedt geen automatische hoge beschikbaarheid. Een twee replicaconfiguratie is alleen van toepassing op SQL Server 2017 (14.x) RTM en wordt niet meer ondersteund met hogere versies (CU1 en hoger) van SQL Server 2017 (14.x).

Diagram met twee synchrone replica's.

Een beschikbaarheidsgroep met twee synchrone replica's biedt leesschaal en gegevensbeveiliging. In de volgende tabel wordt het gedrag van de beschikbaarheid beschreven.

Beschikbaarheidsgedrag leesschaal Gegevensbescherming
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1
Primaire storing Automatische failover. Kan gegevensverlies hebben. De nieuwe primaire eenheid is R/W. Automatische failover. De nieuwe primaire server is niet beschikbaar voor lees- of schrijftransacties totdat de voormalige primaire server herstelt en opnieuw lid wordt van de beschikbaarheidsgroep als secundaire.
Een storing in de secundaire replica Primair is R/W en draait met risico op gegevensverlies. De primaire blijft ontoegankelijk voor lees- of schrijftransacties totdat de gefaalde secundaire zich heeft hersteld en opnieuw deelnemt aan de beschikbaarheidsgroep.

1 Standaard

Twee synchrone replica's en alleen een configuratiereplica

Een beschikbaarheidsgroep met twee (of meer) synchrone replica's en een configuratiereplica biedt alleen gegevensbeveiliging en kan ook hoge beschikbaarheid bieden. Het volgende diagram vertegenwoordigt deze architectuur:

Diagram met een beschikbaarheidsgroep alleen voor configuratie.

  1. Synchrone replicatie van gebruikersgegevens naar de secundaire replica. Het bevat ook metagegevens van de configuratie van beschikbaarheidsgroepen.
  2. Synchrone replicatie van metagegevens van de configuratie van beschikbaarheidsgroepen. Het bevat geen gebruikersgegevens.

In het diagram van de beschikbaarheidsgroep pusht een primaire replica configuratiegegevens naar zowel de secundaire replica als de enige configuratiereplica. De secundaire replica ontvangt ook gebruikersgegevens. De replica die alleen de configuratie bevat ontvangt geen gebruikersgegevens. De secundaire replica bevindt zich in de synchrone beschikbaarheidsmodus. De replica die alleen voor de configuratie is, bevat niet de databases in de beschikbaarheidsgroep, maar alleen metagegevens over de beschikbaarheidsgroep. Configuratiegegevens op de alleen-configuratiereplica worden synchroon doorgevoerd.

Opmerking

Een beschikbaarheidsgroep met alleen een configuratiereplica is nieuw voor SQL Server 2017 (14.x) CU 1. Alle exemplaren van SQL Server in de beschikbaarheidsgroep moeten SQL Server 2017 (14.x) CU 1 of hoger zijn.

De standaardwaarde voor REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT is 0. In de volgende tabel wordt het gedrag van de beschikbaarheid beschreven.

Beschikbaarheidsgedrag Hoge beschikbaarheid &
gegevensbeveiliging		 Gegevensbescherming
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1
Primaire storing Automatische failover. De nieuwe primaire eenheid is R/W. Kan gegevensverlies hebben. Automatische failover. De nieuwe primaire server is niet beschikbaar voor lees- of schrijftransacties totdat de voormalige primaire server herstelt en opnieuw lid wordt van de beschikbaarheidsgroep als secundaire.
Onderbreking van secundaire replica Primair is R/W, kwetsbaar voor gegevensverlies (als de primaire faalt en niet kan worden hersteld). Geen automatische failover als de primaire failover ook mislukt. De primaire blijft ontoegankelijk voor lees- of schrijftransacties totdat de gefaalde secundaire zich heeft hersteld en opnieuw deelnemt aan de beschikbaarheidsgroep. Er is geen replica om naar over te schakelen als de primaire ook faalt.
Replica-uitval alleen door configuratie Hoofd is Lezen/Schrijven. Geen automatische failover als de primaire failover ook mislukt. Hoofd is Lezen/Schrijven. Geen automatische failover als de primaire failover ook mislukt.
Uitval van alleen synchronische secundaire configuraties en replica's De primaire is niet beschikbaar voor lees- of schrijftransacties. Geen automatische failover. De primaire is niet beschikbaar voor lees- of schrijftransacties. Er is geen replica om naar over te schakelen als de primaire ook faalt.

1 Standaard

Opmerking

Het exemplaar van SQL Server dat als host fungeert voor de configuratiereplica, kan ook andere databases hosten. Het kan ook deelnemen als een configuratiedatabase voor meer dan één beschikbaarheidsgroep.

Behoeften

  • Alle replica's in een beschikbaarheidsgroep met alleen een configuratiereplica moeten SQL Server 2017 (14.x) CU 1 of hoger zijn.
  • Elke editie van SQL Server kan alleen een configuratiereplica hosten, inclusief SQL Server Express.
  • De beschikbaarheidsgroep heeft ten minste één secundaire replica nodig, naast de primaire replica.
  • Replica's die alleen voor configuratie zijn, tellen niet mee voor het maximum aantal replica's per SQL Server-instantie. Sql Server Standard Edition staat maximaal drie replica's toe, SQL Server Enterprise Edition biedt maximaal 9.

Overwegingen

  • Niet meer dan één configuratiereplica per beschikbaarheidsgroep.
  • Een alleen configuratiereplica kan niet een primaire replica zijn.
  • U kunt de beschikbaarheidsmodus van alleen een configuratiereplica niet wijzigen. Als u wilt overschakelen van een configuratiereplica naar een synchrone of asynchrone secundaire replica, verwijdert u de enige configuratiereplica en voegt u een secundaire replica toe met de vereiste beschikbaarheidsmodus.
  • Een alleen-configuratiereplica synchroniseert met de metagegevens van de beschikbaarheidsgroep. Er zijn geen gebruikersgegevens.
  • Een beschikbaarheidsgroep met één primaire replica en één configuratiereplica, maar zonder secundaire replica, is niet geldig.
  • U kunt geen beschikbaarheidsgroep maken op een exemplaar van sql Server Express-editie.

Begrijp de SQL Server-resourceagent voor Pacemaker

SQL Server 2017 (14.x) introduceerde sequence_number om aan te geven of een replica die als sys.availability_groups is gemarkeerd up-to-date was. sequence_number is een monotonisch toenemende BIGINT die aangeeft hoe up-to-date de lokale beschikbaarheidsgroepreplica is met betrekking tot de rest van de replica's in de beschikbaarheidsgroep. Bij het uitvoeren van failovers, het toevoegen of verwijderen van replica's en andere bewerkingen voor beschikbaarheidsgroepen wordt dit nummer bijgewerkt. Het nummer wordt bijgewerkt op het primaire systeem en vervolgens naar de secundaire replica's doorgezonden. Een secundaire replica die is up-to-date heeft dus hetzelfde sequence_number als de primaire.

Wanneer Pacemaker besluit om een replica naar een primaire replica te promoveren, wordt eerst een melding verzonden naar alle replica's om het volgnummer te extraheren en op te slaan (deze melding wordt de melding vooraf promoten genoemd). Wanneer Pacemaker vervolgens probeert een replica te promoveren naar primair, bevordert de replica zichzelf alleen als het volgnummer het hoogste is van alle reeksnummers van alle replica's, anders wordt de promotiebewerking geweigerd. Op deze manier kan alleen de replica met het hoogste reeksnummer worden gepromoveerd tot primair, waardoor er geen gegevensverlies mogelijk is.

Promotie werkt alleen zolang ten minste één replica die beschikbaar is voor promotie hetzelfde volgnummer heeft als de vorige primaire replica. Het standaardgedrag is dat de Pacemaker-resourceagent automatisch REQUIRED_COPIES_TO_COMMIT zo instelt dat ten minste één synchrone doorvoer secundaire replica up-to-date en beschikbaar is, om het doel van een automatische failover te zijn. Bij elke monitoractie wordt de waarde van REQUIRED_COPIES_TO_COMMIT berekend (en indien nodig bijgewerkt) als ('aantal synchrone commit-replica's' / 2). Tijdens een failover vereist de resourceagent dattotal number of replicas - required_copies_to_commit replica's reageren op de pre-promotie melding om een van de replica's tot primaire te kunnen promoveren. De replica met de hoogste sequence_number waarde wordt gepromoveerd tot primair.

Laten we bijvoorbeeld eens kijken naar het geval van een beschikbaarheidsgroep met drie synchrone replica's: één primaire replica en twee synchrone commit secundaire replica's.

  • REQUIRED_COPIES_TO_COMMIT is 3 ÷ 2 = 1

  • Het vereiste aantal replica's om te reageren op de actie "vooraf promoveren" is 3 - 1 = 2. Dus moeten er twee replica's operationeel zijn om de failover te activeren. Wanneer er een primaire storing optreedt, en een van de secundaire replica's niet reageert en slechts één van de replica's reageert op de actie voorafgaand aan promotie, kan de resourceagent niet garanderen dat de reagerende secundaire replica de hoogste sequence_number heeft, en wordt er geen failover geactiveerd.

Een gebruiker kan ervoor kiezen om het standaardgedrag te overschrijven en de resource van de beschikbaarheidsgroep zo te configureren dat deze niet automatisch wordt ingesteld REQUIRED_COPIES_TO_COMMIT zoals eerder wordt weergegeven.

Belangrijk

Wanneer REQUIRED_COPIES_TO_COMMIT0 is, is er risico op gegevensverlies. In het geval van een storing van de primaire resourceagent wordt er niet automatisch een failover geactiveerd. De gebruiker moet beslissen of hij of zij wil wachten tot het primaire systeem hersteld is of handmatig overschakelen.

Om REQUIRED_COPIES_TO_COMMIT in te stellen naar 0, voert u het volgende uit:

sudo pcs resource update <ag_cluster> required_copies_to_commit=0

De equivalente opdracht met crm (op SLES) is:

sudo crm resource param <ag_cluster> set required_synchronized_secondaries_to_commit 0

Als u wilt terugkeren naar de standaard berekende waarde, voert u het volgende uit:

sudo pcs resource update <ag_cluster> required_copies_to_commit=

Opmerking

Het bijwerken van resource-eigenschappen zorgt ervoor dat alle replica's worden gestopt en opnieuw worden opgestart. Dit betekent dat de primaire tijdelijk wordt gedegradeerd naar secundair en daarna opnieuw wordt opgewaardeerd, wat tijdelijke schrijf onbeschikbaarheid veroorzaakt. De nieuwe waarde voor REQUIRED_COPIES_TO_COMMIT wordt pas ingesteld zodra de replica's opnieuw worden opgestart, dus deze zal niet onmiddellijk van kracht zijn bij het uitvoeren van de pcs-opdracht.

Hoge beschikbaarheid en gegevensbescherming verdelen

Het bovenstaande standaardgedrag is ook van toepassing op het geval van twee synchrone replica's (primair + secundair). Pacemaker zorgt ervoor REQUIRED_COPIES_TO_COMMIT = 1 dat de secundaire replica altijd up-to-date is voor maximale gegevensbeveiliging.

Waarschuwing

Dit heeft een hoger risico dat de primaire replica niet beschikbaar is vanwege geplande of niet-geplande storingen op de secundaire replica. De gebruiker kan ervoor kiezen om het standaardgedrag van de resourceagent te wijzigen en de REQUIRED_COPIES_TO_COMMIT naar 0 te overschrijven.

sudo pcs resource update <ag1> required_copies_to_commit=0

Zodra deze is overschreven, gebruikt de resource-agent de nieuwe instelling voor REQUIRED_COPIES_TO_COMMIT en stopt het met berekenen. Gebruikers moeten deze handmatig bijwerken (bijvoorbeeld als ze het aantal replica's verhogen).

In de volgende tabellen wordt het resultaat van een storing voor primaire of secundaire replica's in verschillende resourceconfiguraties van de beschikbaarheidsgroep beschreven:

Beschikbaarheidsgroep - twee gesynchroniseerde replica's

Configuratie Primaire storing Een storing in de secundaire replica
REQUIRED_COPIES_TO_COMMIT = 0 De gebruiker moet een handmatige actie uitvoeren FAILOVER.
Kan gegevensverlies hebben.
Nieuw hoofdelement is R/W		 Primair is R/W en draait met risico op gegevensverlies.
REQUIRED_COPIES_TO_COMMIT = 1 1 De cluster geeft automatisch FAILOVER uit.
Geen gegevensverlies.
Nieuwe primaire groep weigert alle verbindingen totdat de voormalige primaire groep wordt hersteld en lid wordt van een beschikbaarheidsgroep als secundair.		 Primaire weigert alle verbindingen totdat de secundaire is hersteld.

1 SQL Server-resourceagent voor standaardgedrag van Pacemaker.

Beschikbaarheidsgroep - drie synchrone replica's

Configuratie Primaire storing Een storing in de secundaire replica
REQUIRED_COPIES_TO_COMMIT = 0 De gebruiker moet een handmatige actie uitvoeren FAILOVER.
Kan gegevensverlies hebben.
Nieuw hoofdelement is R/W		 De primaire modus is lezen/schrijven
REQUIRED_COPIES_TO_COMMIT = 1 1 Cluster geeft FAILOVER automatisch uit.
Geen gegevensverlies.
Nieuw primair is RW		 De primaire modus is lezen/schrijven

1 SQL Server-resourceagent voor standaardgedrag van Pacemaker.

Verwante inhoud