Bedrijfscontinuïteit en databaseherstel - SQL Server

Van toepassing op: SQL Server 2016 (13.x) en latere versies

Dit artikel bevat een overzicht van bedrijfscontinuïteitsoplossingen voor hoge beschikbaarheid en herstel na noodgevallen in SQL Server, in Windows en Linux.

Iedereen die SQL Server implementeert, moet ervoor zorgen dat alle bedrijfskritieke SQL Server-exemplaren en de databases in deze exemplaren beschikbaar zijn wanneer het bedrijf en eindgebruikers deze nodig hebben, ongeacht of deze beschikbaarheid zich tijdens normale kantooruren of rond de klok bevindt. Het doel is om het bedrijf actief te houden met minimale of geen onderbreking. Dit concept wordt ook wel bedrijfscontinuïteit genoemd.

SQL Server 2017 (14.x) en latere versies hebben functies en verbeteringen geïntroduceerd voor beschikbaarheid. De grootste toevoeging is ondersteuning voor SQL Server op Linux-distributies. Zie de volgende artikelen voor een volledige lijst met de nieuwe functies in SQL Server:

Versie	besturingssysteem
Wat is er nieuw in SQL Server 2025 (17.x)	Windows | Linux
Wat is er nieuw in SQL Server 2022 (16.x)	Windows | Linux
Wat is er nieuw in SQL Server 2019 (15.x)	Windows | Linux
Wat is er nieuw in SQL Server 2017 (14.x)	Windows | Linux

Dit artikel is gericht op de beschikbaarheidsscenario's in SQL Server 2017 (14.x) en latere versies, evenals de nieuwe en verbeterde beschikbaarheidsfuncties. De scenario's omvatten hybride implementaties die SQL Server-implementaties kunnen omvatten op zowel Windows Server als Linux, en degenen die het aantal leesbare kopieën van een database kunnen verhogen.

Hoewel dit artikel geen betrekking heeft op beschikbaarheidsopties buiten SQL Server (zoals virtualisatie), is alles wat hier wordt besproken van toepassing op SQL Server-installaties in een virtuele gastmachine, ongeacht of deze zich in de openbare cloud bevindt of wordt gehost door een on-premises hypervisorserver.

SQL Server-scenario's die gebruikmaken van beschikbaarheidsfuncties

U kunt AlwaysOn-beschikbaarheidsgroepen, failoverclusterexemplaren en logboekverzending op verschillende manieren gebruiken, en niet alleen voor beschikbaarheid. U kunt de beschikbaarheidsfuncties op vier manieren gebruiken:

• Hoge beschikbaarheid
• Herstel na een ramp
• Migraties en upgrades
• Leesbare kopieën van een of meer databases uitschalen

In de volgende secties worden de relevante functies voor elk scenario beschreven. Eén functie die niet wordt behandeld, is SQL Server-replicatie. Hoewel SQL Server-replicatie niet officieel is aangewezen als een beschikbaarheidsfunctie onder de paraplu van AlwaysOn, wordt deze vaak gebruikt voor het redundant maken van gegevens in bepaalde scenario's. Samenvoegreplicatie wordt niet ondersteund voor SQL Server in Linux. Zie SQL Server-replicatie in Linux voor meer informatie.

Belangrijk

De sql Server-beschikbaarheidsfuncties vervangen niet de vereiste om een robuuste, goed geteste back-up- en herstelstrategie te hebben. Een strategie voor back-up en herstel is de meest fundamentele bouwsteen van elke beschikbaarheidsoplossing.

Hoge beschikbaarheid

Het is belangrijk om ervoor te zorgen dat SQL Server-exemplaren of -databases beschikbaar zijn als er een probleem optreedt dat lokaal is in een datacenter of één regio in de cloud. In deze sectie wordt uitgelegd hoe de sql Server-beschikbaarheidsfuncties u kunnen helpen. Alle beschreven functies zijn zowel beschikbaar op Windows Server als in Linux.

Beschikbaarheidsgroepen

Beschikbaarheidsgroepen (AG's) bieden beveiliging op databaseniveau door elke transactie van een database naar een ander exemplaar of replica te verzenden, die een kopie van die database in een speciale status bevat. U kunt een AG implementeren in Standard- of Enterprise-edities. De exemplaren die deelnemen aan een AG, kunnen zelfstandige exemplaren of failoverclusterexemplaren zijn (CCI's, zoals beschreven in de volgende sectie). Omdat de transacties naar een replica worden verzonden terwijl ze plaatsvinden, worden AG's aanbevolen wanneer er vereisten zijn voor lagere beoogde herstelpunten en hersteltijd. Gegevensverplaatsing tussen replica's kan synchroon of asynchroon zijn, met de Enterprise-editie wat toestaat dat maximaal drie replica's (inclusief de primaire) synchroon zijn. Een AG heeft één volledig lees-/schrijfkopie van de database die zich op de primaire replica bevindt, terwijl alle secundaire replica's geen transacties rechtstreeks van eindgebruikers of toepassingen kunnen ontvangen.

Opmerking

AlwaysOn is een overkoepelende term voor de beschikbaarheidsfuncties in SQL Server en omvat zowel AG's als FCI's. AlwaysOn is niet de naam van de ag-functie.

Vóór SQL Server 2022 (16.x) bieden AG's alleen beveiliging op databaseniveau en niet op exemplaarniveau. Alles wat niet is vastgelegd in het transactielogboek of geconfigureerd in de database, moet handmatig worden gesynchroniseerd voor elke secundaire replica. Enkele voorbeelden van objecten die handmatig moeten worden gesynchroniseerd, zijn aanmeldingen op exemplaarniveau, gekoppelde servers en SQL Server Agent-taken.

In SQL Server 2022 (16.x) en latere versies kunt u metagegevensobjecten beheren, waaronder gebruikers, aanmeldingen, machtigingen en SQL Server Agent-taken op ag-niveau, naast het exemplaarniveau. Zie Wat is een ingesloten beschikbaarheidsgroep?

Een AG heeft ook een ander onderdeel genaamd de listener, waarmee toepassingen en eindgebruikers verbinding kunnen maken zonder te hoeven weten welk SQL Server-exemplaar als host fungeert voor de primaire replica. Elke AG heeft een eigen listener. Hoewel de implementaties van de listener enigszins verschillen in Windows Server versus Linux, bieden ze beide dezelfde functionaliteit en bruikbaarheid. In het volgende diagram ziet u een Windows Server-AG met een Windows Server-failovercluster (WSFC). Een onderliggend cluster op de besturingssysteemlaag is vereist voor beschikbaarheid, ongeacht of het zich in Linux of Windows Server bevindt. In het voorbeeld ziet u een eenvoudige configuratie met twee servers of knooppunten, met een WSFC als het onderliggende cluster.

Standard en Enterprise Edition hebben verschillende maximumlimieten als het gaat om replica's. Een AG in Standard-editie, ook wel een standaard beschikbaarheidsgroep genoemd, ondersteunt twee replica's (één primaire en één secundaire) met slechts één database in de beschikbaarheidsgroep. Met de Enterprise Edition kunnen niet alleen meerdere databases in één beschikbaarheidsgroep worden geconfigureerd, maar kunnen er ook tot negen replica's (één primaire, acht secundaire) worden gebruikt. Enterprise Edition biedt ook andere optionele voordelen, zoals leesbare secundaire replica's, de mogelijkheid om back-ups te maken van een secundaire replica en meer.

Opmerking

Databasespiegeling, die is afgeschaft in SQL Server 2012 (11.x), is niet beschikbaar in de Linux-versie van SQL Server en is niet toegevoegd. Klanten die nog steeds databasespiegeling gebruiken, moeten van plan zijn om te migreren naar AG's. Dit is de vervanging voor databasespiegeling.

Als het gaat om beschikbaarheid, kunnen AG's automatische of handmatige failover bieden. Automatische failover kan optreden als synchrone gegevensverplaatsing is geconfigureerd en de database op de primaire en secundaire replica een gesynchroniseerde status heeft. Zolang de listener wordt gebruikt en de toepassing gebruikmaakt van een ondersteunde versie van .NET Framework (3.5 met Service Pack 1 of 4.6.2 en latere versies), moet de failover worden afgehandeld met minimaal tot geen effect op eindgebruikers als een listener wordt gebruikt. Als u een failover naar een secundaire replica uitvoert, kan de nieuwe primaire replica zodanig worden geconfigureerd dat deze automatisch of handmatig is en over het algemeen in seconden wordt gemeten.

In de volgende lijst ziet u enkele verschillen met AG's in Windows Server versus Linux:

Vanwege de manier waarop het onderliggende cluster werkt op Linux en Windows Server, worden alle AG-failovers (handmatig of automatisch) uitgevoerd via het cluster op Linux. In windows Server-ag-implementaties moeten handmatige failovers worden uitgevoerd via SQL Server. Automatische failovers worden verwerkt door het onderliggende cluster op zowel Windows Server als Linux.

• Voor SQL Server op Linux moet u een AG configureren met minimaal drie replica's, vanwege de manier waarop de onderliggende clustering werkt.

• In Linux wordt de algemene naam die door elke listener wordt gebruikt, gedefinieerd in DNS en niet in het cluster, zoals in Windows Server.

SQL Server 2017 (14.x) heeft de volgende functies en verbeteringen geïntroduceerd in AG's:

• Clustertypen
• REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
• Verbeterde DTC-ondersteuning (Microsoft Distributor Transaction Coordinator) voor configuraties op basis van Windows Server
• Aanvullende uitschaalscenario's voor read-only-databases (verderop in dit artikel beschreven)

Clustertypen van beschikbaarheidsgroep

De ingebouwde beschikbaarheidsvorm van clustering in Windows Server is ingeschakeld via een functie met de naam FailoverClustering. Hiermee kunt u een WSFC bouwen voor gebruik met een AG of FCI. SQL Server verzendt clusterbewuste resource-DLL's die integratie bieden voor AG's en FCI's.

SQL Server op Linux ondersteunt meerdere clusteringtechnologieën. Microsoft ondersteunt de SQL Server-onderdelen, terwijl onze partners de relevante clusteringtechnologie ondersteunen. Sql Server op Linux ondersteunt bijvoorbeeld HPE Serviceguard en DH2i DxEnterprise als clusteroplossing, samen met Pacemaker.

Een Windows-failovercluster en Linux-clusteroplossing zijn vergelijkbaarer dan anders. Beide bieden een manier om afzonderlijke servers te nemen en te combineren in een configuratie om beschikbaarheid te bieden en concepten te hebben van zaken als resources, beperkingen (zelfs als ze anders zijn geïmplementeerd), failover enzovoort.

Als u bijvoorbeeld Pacemaker wilt ondersteunen voor zowel AG- als FCI-configuraties, waaronder zaken als automatische failover, biedt Microsoft het mssql-server-ha pakket, dat vergelijkbaar is met, maar niet precies hetzelfde is als de resource-DLL's in een WSFC, voor Pacemaker. Een van de verschillen tussen een WSFC en Pacemaker is dat er geen netwerknaamresource in Pacemaker is. Dit is het onderdeel waarmee de naam van de listener (of de naam van de FCI) op een WSFC kan worden geabstraheerd. DNS gebruiken voor naamomzetting in Linux.

Vanwege het verschil in de clusterstack moeten AG's in SQL Server 2017 (14.x) en latere versies enkele metagegevens verwerken die systeemeigen worden verwerkt door een WSFC. Er zijn bijvoorbeeld drie clustertypen voor een beschikbaarheidsgroep, die zijn opgeslagen in sys.availability_groups de cluster_type en cluster_type_desc kolommen:

• WSFC
• Extern
• Geen

Alle AG's waarvoor hoge beschikbaarheid is vereist, moeten gebruikmaken van een onderliggend cluster. In het geval van SQL Server 2017 (14.x) en latere versies betekent WSFC of een Linux-clusteringagent. Voor Windows Server-AG's die gebruikmaken van een onderliggende WSFC, is het standaardclustertype WSFC en hoeft u dit niet in te stellen. Voor op Linux gebaseerde AG's moet u het clustertype instellen op Extern bij het maken van de beschikbaarheidsgroep (AG). De integratie met een externe clusteroplossing in Linux wordt geconfigureerd nadat de beschikbaarheidsgroep (AG) is gemaakt, terwijl dit bij de creatie van een Failovercluster van Windows Server (WSFC) gebeurt.

Een clustertype Geen kan worden gebruikt met zowel Windows Server als Linux AG's. Als het clustertype is ingesteld op Geen, heeft de beschikbaarheidsgroep geen onderliggend cluster nodig. Dit betekent dat SQL Server 2017 (14.x) de eerste versie van SQL Server is ter ondersteuning van AG's zonder een cluster, maar het nadeel is dat deze configuratie niet wordt ondersteund als een oplossing voor hoge beschikbaarheid.

Belangrijk

In SQL Server 2017 (14.x) en latere versies kunt u een clustertype voor een AG niet wijzigen nadat het is gemaakt. Deze beperking betekent dat een AG niet kan worden overgeschakeld van Geen naar Extern of WSFC, en omgekeerd.

Als u alleen extra alleen-lezen kopieën van een database wilt toevoegen of als u wilt wat een AG biedt voor migratie en upgrades, maar niet wilt omgaan met de complexiteit van een onderliggend cluster of zelfs replicatie, kunt u overwegen een beschikbaarheidsgroep in te stellen met het clustertype Geen. Zie de secties Migraties en upgrades enleesschaal voor meer informatie.

In de volgende schermopname ziet u de ondersteuning voor de verschillende soorten clustertypen in SQL Server Management Studio (SSMS). U moet versie 17.1 of hoger uitvoeren. De volgende schermopname is van versie 17.2:

VEREIST_GESYNCHRONISEERDE_SECONDARIES_OM_TE_COMMITTEREN

SQL Server 2016 (13.x) verbeterde ondersteuning voor het aantal synchrone replica's van twee tot drie in enterprise-editie. Als echter één secundaire replica wordt gesynchroniseerd, maar de andere replica een probleem heeft, is er geen manier om het gedrag te sturen om de primaire replica te laten wachten op de problematische replica, of om door te gaan. In dit scenario kan de primaire replica nog steeds schrijfverkeer ontvangen, ook al heeft de secundaire replica geen gesynchroniseerde status, wat resulteert in gegevensverlies op de secundaire replica.

In SQL Server 2017 (14.x) en latere versies kunt u het gedrag bepalen van wat er gebeurt wanneer er synchrone replica's zijn met REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Deze optie werkt als volgt:

• Er zijn drie mogelijke waarden: 0, 1en 2.
• De waarde is het aantal secundaire replica's dat moet worden gesynchroniseerd, wat gevolgen heeft voor gegevensverlies, beschikbaarheid van beschikbaarheidsgroepen en failover.
• Voor WSFC's en een clustertype van Geen is de standaardwaarde 0, en u kunt deze handmatig instellen op 1 of 2.
• Voor een clustertype Extern stelt het clustermechanisme deze waarde standaard in en kunt u deze handmatig overschrijven. Voor drie synchrone replica's is 1de standaardwaarde .

Op Linux configureert u de waarde voor REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT op de AG-resource in het cluster. In Windows stelt u deze in via Transact-SQL.

Een waarde die hoger is dan 0 zorgt voor een hogere gegevensbeveiliging, omdat als het vereiste aantal secundaire replica's niet beschikbaar is, de primaire waarde pas beschikbaar is als die voorwaarde wordt opgelost. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT is ook van invloed op het failovergedrag, omdat automatische failover niet kan optreden als het juiste aantal secundaire replica's niet de juiste status heeft. Op Linux is een waarde van 0 niet toegestaan voor automatische failover, dus wanneer u synchrone modus met automatische failover op Linux gebruikt, moet u de waarde hoger instellen dan 0 om automatische failover te bereiken. 0 op Windows Server is het gedrag in SQL Server 2016 (13.x) en eerdere versies.

Verbeterde ondersteuning voor Microsoft Distributed Transaction Coordinator

Vóór SQL Server 2016 (13.x) was de enige manier om beschikbaarheid in SQL Server te realiseren voor toepassingen die gedistribueerde transacties vereisen, waarbij gebruik wordt gemaakt van DTC onder de motorkap, het implementeren van FCIs. Een gedistribueerde transactie kan op twee manieren worden uitgevoerd:

• Een transactie die meer dan één database omvat in hetzelfde SQL Server-exemplaar.
• Een transactie die meer dan één SQL Server-exemplaar omvat of mogelijk een niet-SQL Server-gegevensbron omvat.

SQL Server 2016 (13.x) introduceerde gedeeltelijke ondersteuning voor DTC met AG's die het laatste scenario behandelden. SQL Server 2017 (14.x) voltooit het verhaal door beide scenario's met DTC te ondersteunen.

In SQL Server 2017 (14.x) en latere versies kunt u DTC-ondersteuning toevoegen aan een AG nadat deze is gemaakt. In SQL Server 2016 (13.x) kunt u alleen DTC-ondersteuning inschakelen bij het maken van de beschikbaarheidsgroep.

Exemplaren van failover-clusters

Failoverclusterexemplaren (CFA's) bieden beschikbaarheid voor de volledige installatie van SQL Server, ook wel een exemplaar genoemd. Met FCIs, als de onderliggende server een probleem ondervindt, wordt alles binnen de instantie verplaatst naar een andere server, waaronder databases, SQL Server Agent-taken, gekoppelde servers en meer. Voor alle FCI's is gedeelde opslag vereist, zelfs als deze via het netwerk is gedefinieerd. Eén knooppunt kan op een bepaald moment de middelen van de FCI gebruiken en bezitten. In het volgende diagram is het eerste knooppunt van het cluster eigenaar van de FCI. Het is ook eigenaar van de gedeelde opslagbronnen die eraan zijn gekoppeld, zoals de ononderbroken lijn naar de opslag aangeeft.

Na een failover verandert het eigendom, zoals wordt weergegeven in het volgende diagram:

Een FCI heeft geen gegevensverlies, maar de onderliggende gedeelde opslag vormt een enkel storingspunt omdat er slechts één kopie van de gegevens is. Als u redundante kopieën van databases wilt hebben, combineert u FCI's met een andere methode voor beschikbaarheid, zoals een beschikbaarheidsgroep of log shipping. De andere methode moet gebruikmaken van fysiek gescheiden opslagruimte ten opzichte van de FCI. Wanneer de FCI een failover naar een ander knooppunt uitvoert, stopt deze op het ene knooppunt en begint het op een ander knooppunt. Dit proces is vergelijkbaar met het uitschakelen van een server en het inschakelen ervan.

Een FCI doorloopt het normale herstelproces. Hiermee worden alle transacties die moeten worden teruggedraaid, doorgestuurd en worden onvolledige transacties teruggedraaid. Daarom is de database consistent van een gegevenspunt tot het tijdstip van de fout of handmatige failover, zodat er geen gegevensverlies is. Databases zijn alleen beschikbaar nadat het herstel is voltooid. De hersteltijd is afhankelijk van veel factoren en is over het algemeen langer dan het uitvoeren van een failover van een beschikbaarheidsgroep. Het nadeel is dat wanneer u een failover uitvoert van een beschikbaarheidsgroep, er mogelijk extra taken nodig zijn om een database bruikbaar te maken, zoals het inschakelen van een SQL Server Agent-taak.

Opmerking

Versneld databaseherstel (ADR) kan de hersteltijd beperken. Zie Versneld databaseherstel voor meer informatie.

Net als een AG abstraheren FCI's welk knooppunt van het onderliggende cluster deze host. Een FCI behoudt altijd dezelfde naam. Toepassingen en eindgebruikers maken nooit verbinding met de knooppunten. In plaats daarvan gebruiken ze de unieke naam die is toegewezen aan de FCI. Een FCI kan deelnemen aan een AG als een van de exemplaren die een primaire of secundaire replica hosten.

In de volgende lijst worden enkele verschillen met CCI's in Windows Server vergeleken met Linux:

• Op Windows Server maakt een FCI deel uit van het installatieproces. U configureert een FCI in Linux na de installatie van SQL Server.
• Linux ondersteunt alleen een enkele installatie van SQL Server per host, dus alle FCI's zijn een standaardexemplaar. Windows Server ondersteunt maximaal 25 FCI's per WSFC.
• De algemene naam die wordt gebruikt door CCI's in Linux, wordt gedefinieerd in DNS en moet dezelfde zijn als de resource die voor de FCI is gemaakt.

Logboekverzending

Als herstelpunt- en hersteltijddoelstellingen flexibeler zijn of databases niet zeer bedrijfskritiek zijn, is logboekverzending een andere bewezen beschikbaarheidsfunctie in SQL Server. Op basis van de systeemeigen back-ups van SQL Server genereert het proces voor het verzenden van logboeken automatisch back-ups van transactielogboeken, kopieert deze naar een of meer exemplaren die bekend staan als een warme stand-by. De back-ups van het transactielogboek worden automatisch op die stand-by toegepast. Logboekverzending maakt gebruik van SQL Server Agent-taken om het proces voor het maken van back-ups, het kopiëren en toepassen van de back-ups van het transactielogboek te automatiseren.

Het grootste voordeel van het gebruik van logboekverzending is dat het rekening houdt met menselijke fouten, omdat u de toepassing van transactielogboeken kunt vertragen. Als iemand bijvoorbeeld een UPDATE zonder WHERE clausule uitgeeft, is het mogelijk dat de stand-by de wijziging niet heeft, waardoor u kunt overschakelen naar die stand-by terwijl u het primaire systeem herstelt. Hoewel logboekverzending eenvoudig te configureren is, is overschakelen van de primaire naar een warme stand-by, ook wel een rolwijziging genoemd, altijd handmatig. U start een rolwijziging via Transact-SQL. Net als een AG moet u alle objecten die niet zijn vastgelegd in het transactielogboek handmatig synchroniseren. U moet logboekverzending per database configureren, terwijl één beschikbaarheidsgroep meerdere databases kan bevatten.

In tegenstelling tot een AG of FCI heeft logboekverzending geen abstractie voor een rolwijziging, die toepassingen moeten kunnen verwerken. Technieken zoals een DNS-alias (CNAME) kunnen worden gebruikt, maar er zijn voor- en nadelen, zoals de tijd die het kost om DNS na de switch te vernieuwen.

Herstel na een ramp

Wanneer uw primaire beschikbaarheidslocatie een catastrofale gebeurtenis ondervindt, zoals een aardbeving of overstroming, moet het bedrijf zijn voorbereid om zijn systemen elders online te laten komen. In deze sectie wordt beschreven hoe de sql Server-beschikbaarheidsfuncties kunnen helpen bij bedrijfscontinuïteit.

Beschikbaarheidsgroepen

Een van de voordelen van AG's is dat u zowel hoge beschikbaarheid als herstel na noodgevallen configureert met één functie. Zonder de vereiste om ervoor te zorgen dat gedeelde opslag ook maximaal beschikbaar is, is het veel eenvoudiger om replica's te hebben die lokaal zijn in één datacenter voor hoge beschikbaarheid en externe in andere datacenters voor herstel na noodgevallen, elk met afzonderlijke opslag. Het gebruik van extra kopieën van de database is de afweging om redundantie te garanderen. In het volgende diagram ziet u een voorbeeld van een beschikbaarheidsgroep die meerdere datacenters omvat. Eén primaire replica is verantwoordelijk voor het synchroniseren van alle secundaire replica's.

Buiten een AG met een clustertype Geen, vereist een AG dat alle replica's deel uitmaken van hetzelfde onderliggende cluster, ongeacht of het een WSFC- of een externe clusteroplossing is. In het vorige diagram is de WSFC uitgerekt om te werken in twee verschillende datacenters, wat complexiteit toevoegt, ongeacht het platform (Windows Server of Linux). Het uitrekken van clusters op afstand voegt complexiteit toe.

Geïntroduceerd in SQL Server 2016 (13.x), kan een gedistribueerde beschikbaarheidsgroep een AG omvatten die is geconfigureerd op verschillende clusters. Gedistribueerde AG's ontkoppelen de vereiste dat de knooppunten allemaal deelnemen aan hetzelfde cluster, waardoor het configureren van herstel na noodgevallen veel eenvoudiger wordt. Zie gedistribueerde beschikbaarheidsgroepen voor meer informatie over gedistribueerde AG's.

Exemplaren van failover-clusters

U kunt FCIS's gebruiken voor herstel na noodgevallen. Net als bij een normale beschikbaarheidsgroep moet u het onderliggende clustermechanisme uitbreiden naar alle locaties, waardoor de complexiteit toeneemt. Voor GCI's moet u ook rekening houden met de gedeelde opslag. De primaire en secundaire sites hebben toegang nodig tot dezelfde schijven. Als u ervoor wilt zorgen dat de opslag die door de FCI wordt gebruikt op beide sites bestaat, gebruikt u een externe methode, zoals de functionaliteit van de opslagleverancier op de hardwarelaag. U kunt ook Opslagreplica gebruiken in Windows Server.

Logboekverzending

Logboekverzending is een van de oudste methoden voor herstel na noodgevallen voor SQL Server-databases. Logboekverzending wordt vaak gebruikt met AG's en FCI's om kostenefficiënt en eenvoudiger herstel na noodgevallen te bieden, waarbij andere opties een uitdaging kunnen zijn vanwege omgevings-, administratieve vaardigheden of budget. Net als bij het verhaal over hoge beschikbaarheid voor logboekverzending vertragen veel omgevingen het laden van een transactielogboek om rekening te houden met menselijke fouten.

Migraties en upgrades

Wanneer een organisatie nieuwe exemplaren implementeert of oude exemplaren bijwerken, kan het geen lange storingen tolereren. In deze sectie wordt beschreven hoe de beschikbaarheidsfuncties van SQL Server kunnen worden gebruikt om de downtime in een geplande architectuurwijziging, serverswitch, platformwijziging (zoals Windows Server naar Linux of omgekeerd) of tijdens het patchen tot een minimum te beperken.

Opmerking

U kunt ook andere methoden gebruiken, zoals back-ups en herstelbewerkingen, voor migraties en upgrades. In dit artikel worden deze methoden niet besproken.

Beschikbaarheidsgroepen

U kunt een bestaand exemplaar met een of meer beschikbaarheidsgroepen (AG's) bijwerken naar latere versies van SQL Server. Hoewel voor deze upgrade enige downtime is vereist, kan deze worden geminimaliseerd met de juiste hoeveelheid planning.

Als u wilt migreren naar nieuwe servers zonder de configuratie te wijzigen (inclusief het besturingssysteem of de SQL Server-versie), voegt u deze servers toe als knooppunten aan het bestaande onderliggende cluster en voegt u deze vervolgens toe aan de beschikbaarheidsgroep. Zodra de replica of replica's in de juiste staat zijn, voert u handmatig een failover uit naar een nieuwe server. Verwijder vervolgens de oude servers uit de beschikbaarheidsgroep en neem ze buiten gebruik.

Gedistribueerde AG's zijn ook een andere methode om te migreren naar een nieuwe configuratie of SQL Server bij te werken. Omdat een gedistribueerde beschikbaarheidsgroep verschillende onderliggende AG's ondersteunt op verschillende architecturen, kunt u overstappen van SQL Server 2019 (15.x) die wordt uitgevoerd op Windows Server 2019 naar SQL Server 2025 (17.x) die wordt uitgevoerd op Windows Server 2025.

Ten slotte zijn AG's met een clustertype Geen nuttig voor migratie of upgrade. U kunt clustertypen niet combineren en vergelijken in een typische AG-configuratie, dus alle replica's moeten een type Geen zijn. Een gedistribueerde beschikbaarheidsgroep kan worden gebruikt om AG's te omvatten die zijn geconfigureerd met verschillende clustertypen. Deze methode wordt ook ondersteund op de verschillende besturingssysteemplatforms.

Alle varianten van AG's voor migraties en upgrades zorgen ervoor dat gegevenssynchronisatie, het meest tijdrovende deel van het werk, in de loop van de tijd wordt verdeeld. Wanneer het tijd is om de overstap naar de nieuwe configuratie te starten, is de cutover een korte storing, versus een lange periode waarin alle werkzaamheden, inclusief gegevenssynchronisatie, moeten worden voltooid.

AG's kunnen minimale downtime bieden tijdens het patchen van het onderliggende besturingssysteem door handmatig een failover van de primaire naar een secundaire replica uit te voeren terwijl de patches worden uitgevoerd. Vanuit het oogpunt van een besturingssysteem is dit gebruikelijker op Windows Server, omdat het onderhoud van het onderliggende besturingssysteem opnieuw kan worden opgestart. Het patchen van Linux moet soms opnieuw worden opgestart, maar dit is minder gebruikelijk.

Een andere manier om downtime te minimaliseren, is het patchen van SQL Server-exemplaren die deelnemen aan een beschikbaarheidsgroep, afhankelijk van hoe complex de AG-architectuur is. U patcht eerst een secundaire replica. Zodra het juiste aantal replica's is gepatcht, voert u handmatig een failover uit van de primaire replica naar een ander knooppunt om de upgrade uit te voeren. Werk op dat moment alle resterende secundaire replica's bij.

Exemplaren van failover-clusters

FCI's kunnen niet zelfstandig helpen bij een traditionele migratie of upgrade. U moet een beschikbaarheidsgroep of logboekverzending configureren voor de databases in de FCI en rekening houden met alle andere objecten. FCI's onder Windows Server zijn echter nog steeds een populaire optie wanneer u de onderliggende Windows-servers moet patchen. Wanneer u een handmatige failover start, zorgt de korte storing ervoor dat het exemplaar niet onbeschikbaar is gedurende de gehele tijd dat Windows Server wordt gepatcht.

U kunt een FCI upgraden naar latere versies van SQL Server. Zie Een failoverclusterexemplaar upgraden voor meer informatie.

Logboekverzending

Logboekverzending is nog steeds een populaire optie voor het migreren en upgraden van databases. Net als bij AG's, maar deze keer met behulp van het transactielogboek als synchronisatiemethode, kan de doorgifte van gegevens ruim voor de serverswitch worden gestart. Op het moment van de switch moet een definitief transactielogboek worden genomen, gekopieerd en toegepast op de nieuwe configuratie zodra al het verkeer bij de bron is gestopt. Op dat moment kan de database online worden gebracht.

Logboekverzending is vaak toleranter voor tragere netwerken en hoewel de switch mogelijk iets langer is dan één met behulp van een AG of een gedistribueerde beschikbaarheidsgroep, wordt deze meestal gemeten in minuten, niet uren, dagen of weken.

Net als bij AG's kan logboekverzending een manier bieden om tijdens een onderhoudsvenster over te schakelen naar een andere server.

Andere SQL Server-implementatiemethoden en -beschikbaarheid

Er zijn twee andere implementatiemethoden voor SQL Server in Linux: containers en het gebruik van Azure (of een andere openbare cloudprovider). De algemene behoefte aan beschikbaarheid bestaat ongeacht hoe SQL Server wordt geïmplementeerd. Deze twee methoden hebben een aantal speciale overwegingen bij het maximaal beschikbaar maken van SQL Server.

SQL Server-containers en opties voor hoge beschikbaarheid/herstel na noodgevallen

Sql Server-containerimplementatie is een manier om het inrichten, schalen en levenscyclusbeheer van SQL Server in omgevingen te vereenvoudigen. Een container is een volledige kant-en-klare image van SQL Server.

Afhankelijk van uw containerplatform, bijvoorbeeld wanneer u een containerorchestrator zoals Kubernetes gebruikt, kan de container, als deze verloren gaat, opnieuw worden gedeployed en weer worden gekoppeld aan de eerder gebruikte gedeelde opslag. Hoewel dit enige tolerantie biedt, is er enige downtime die is gekoppeld aan databaseherstel en is deze niet echt maximaal beschikbaar, zoals het zou zijn als u een beschikbaarheidsgroep of FCI gebruikt.

Als u hoge beschikbaarheid wilt configureren voor SQL Server-containers die zijn geïmplementeerd op Kubernetes- of niet-Kubernetes-platforms, kunt u DH2i DxEnterprise gebruiken als een van de clusteringoplossingen, waarboven u een AG in de modus voor hoge beschikbaarheid kunt configureren. Deze optie biedt u de beoogde herstelpuntdoelstelling (RPO) en de beoogde hersteltijd (RTO) van een oplossing voor hoge beschikbaarheid.

Vm-implementatie op basis van Linux

Linux kan worden geïmplementeerd met SQL Server op virtuele Linux Azure-machines. Net als bij lokale installaties vereist een ondersteunde installatie het gebruik van fencing voor een mislukt knooppunt dat zich buiten de clusteragent bevindt. Knooppuntafscheiding wordt geleverd via afschermingsbeschikbaarheidsagents. Sommige distributies verzenden ze als onderdeel van het platform, terwijl andere afhankelijk zijn van externe hardware- en softwareleveranciers. Neem contact op met de Linux-distributie van uw voorkeur om te zien welke vormen van knooppuntafscheiding beschikbaar zijn, zodat een ondersteunde oplossing kan worden geïmplementeerd in de openbare cloud.

Handleidingen voor het installeren van SQL Server in Linux zijn beschikbaar voor de volgende distributies:

• Quickstart: SQL Server installeren en een database maken in Red Hat
• Quickstart: SQL Server installeren en een database maken in Ubuntu
• Quickstart: SQL Server installeren en een database maken op SUSE Linux Enterprise Server

Leesschaal

Secundaire replica's hebben de mogelijkheid om te worden gebruikt voor alleen-lezenquery's. Er zijn twee manieren waarop dat kan worden bereikt met een beschikbaarheidsgroep:

• Directe toegang tot de secundaire toestaan
• Alleen-lezenroutering configureren, waarvoor het gebruik van de listener vereist is. SQL Server 2016 (13.x) heeft de mogelijkheid geïntroduceerd om alleen-lezen verbindingen via de listener te verdelen met behulp van een round robin-algoritme, waardoor alleen-lezen aanvragen over alle leesbare replica's kunnen worden verspreid.

Opmerking

Leesbare secundaire replica's zijn alleen beschikbaar in Enterprise Edition. Elk exemplaar dat als host fungeert voor een leesbare replica, heeft een SQL Server-licentie nodig.

Het schalen van leesbare kopieën van een database via AG's is voor het eerst geïntroduceerd met gedistribueerde AG's in SQL Server 2016 (13.x). Deze functie biedt alleen-lezen kopieën van de database, niet alleen lokaal, maar ook regionaal en wereldwijd, met minimale configuratie. Deze installatie vermindert het netwerkverkeer en de latentie door query's lokaal uit te voeren. Elke primaire replica van een AG kan twee andere AG's inzetten, zelfs als het niet de volledig lees-/schrijfkopie is, en elke gedistribueerde AG kan maximaal 27 leesbare kopieën van de gegevens mogelijk maken.

In SQL Server 2017 (14.x) en latere versies kunt u een bijna realtime, alleen-lezen oplossing maken met AG's die zijn geconfigureerd met een clustertype Geen. Als u AG's wilt gebruiken voor leesbare secundaire replica's en niet voor beschikbaarheid, verwijdert deze benadering de complexiteit van het gebruik van een WSFC of een externe clusteroplossing onder Linux. Het biedt de leesbare voordelen van een beschikbaarheidsgroep in een eenvoudigere implementatiemethode.

De enige belangrijke kanttekening is dat het configureren van alleen-lezenverkeer iets anders is, omdat er geen onderliggende cluster met het clustertype 'Geen' aanwezig is. Vanuit sql Server-perspectief is een listener nog steeds vereist om de aanvragen te routeren, ook al is er geen cluster. Gebruik in plaats van een traditionele listener het IP-adres of de naam van de primaire replica. De primaire replica stuurt vervolgens de aanvragen met het kenmerk Alleen-lezen.

Een warme stand-by voor logboekverzending kan technisch worden geconfigureerd voor leesbaar gebruik door de database WITH STANDBYte herstellen. Omdat de transactielogboeken echter exclusief gebruik van de database vereisen voor herstel, betekent dit dat gebruikers geen toegang hebben tot de database terwijl dat gebeurt. Hierdoor is logboekverzending een minder dan ideale oplossing, met name als bijna realtime gegevens vereist zijn.

In tegenstelling tot transactionele replicatie waarbij alle gegevens live zijn, is elke secundaire replica in een scenario met leesschaal een exacte kopie van de primaire replica. De replica heeft geen status waarin unieke indexen kunnen worden toegepast. Als er indexen nodig zijn voor rapportage of als gegevens moeten worden bewerkt, moet u deze indexen maken op de databases op de primaire replica. Als u die flexibiliteit nodig hebt, is replicatie een betere oplossing voor leesbare gegevens.

Interoperabiliteit tussen platformoverschrijdende en Linux-distributie

Met SQL Server-ondersteuning op zowel Windows Server als Linux wordt in deze sectie beschreven hoe ze naast andere doeleinden kunnen samenwerken voor beschikbaarheid. Ook wordt het verhaal behandeld voor oplossingen die meer dan één Linux-distributie bevatten.

Opmerking

Er zijn geen scenario's waarbij een op WSFC gebaseerd failoverclusterexemplaar (FCI) of beschikbaarheidsgroep (AG) rechtstreeks met een op Linux gebaseerde FCI of AG werkt. Een Windows Server-failovercluster (WSFC) kan niet worden uitgebreid door een Pacemaker-knooppunt en omgekeerd.

Gedistribueerde beschikbaarheidsgroepen

Gedistribueerde AG's zijn ontworpen om AG-configuraties te omvatten, ongeacht of deze twee onderliggende clusters onder de AG's twee verschillende WSFC's, Linux-distributies of één op een WSFC en de andere in Linux zijn. Een gedistribueerde AG is de primaire methode om een platformoverschrijdende oplossing te bieden. Een gedistribueerde AG is ook de primaire oplossing voor migraties, zoals het converteren van een SQL Server-infrastructuur op basis van Windows Server naar een op Linux gebaseerde infrastructuur, als dat is wat uw bedrijf wil doen. Zoals eerder vermeld, zouden AG's en met name gedistribueerde AG's de tijd minimaliseren dat een toepassing niet beschikbaar zou zijn voor gebruik. Een voorbeeld van een gedistribueerde beschikbaarheidsgroep die een WSFC en Pacemaker omvat, wordt weergegeven in het volgende diagram:

Als u een beschikbaarheidsgroep met een clustertype Geen configureert, kan deze zowel Windows Server als Linux en meerdere Linux-distributies omvatten. Omdat deze configuratie geen echte hoge beschikbaarheid is, moet u deze niet gebruiken voor essentiële implementaties. Gebruik het hiervoor bij situaties waarin leesschaal nodig is of voor migratie- en upgrade-scenario's.

Logboekverzending

Logboekverzending is gebaseerd op back-up en herstel, dus er zijn geen verschillen in de databases, bestandsstructuren en andere elementen voor SQL Server op Windows Server versus SQL Server op Linux. U kunt logboekverzending configureren tussen een sql Server-installatie op basis van Windows Server en een Linux-installatie, en tussen distributies van Linux. Alles anders blijft hetzelfde.

Net als bij een beschikbaarheidsgroep werkt logboekverzending niet wanneer de bronserver een hogere hoofversie van SQL Server heeft, in vergelijking met een doelserver die zich op een lagere hoofdversie bevindt.

Samenvatting

U kunt exemplaren en databases van SQL Server 2017 (14.x) en latere versies maximaal beschikbaar maken met behulp van dezelfde functies op Windows Server en Linux. Naast standaard beschikbaarheidsscenario's voor lokale hoge beschikbaarheid en herstel na noodgevallen kunt u downtime minimaliseren die is gekoppeld aan upgrades en migraties met behulp van de beschikbaarheidsfuncties in SQL Server. AG's kunnen ook extra kopieën van een database bieden als onderdeel van dezelfde architectuur om leesbare kopieën uit te schalen. Of u nu een nieuwe oplossing implementeert of een upgrade overweegt, SQL Server heeft de beschikbaarheid en betrouwbaarheid die u nodig hebt.

Verwante inhoud

• Wat is een AlwaysOn-beschikbaarheidsgroep?
• Een SQL Server-failovercluster installeren