SQL Server Vienmēr ieslēgts: Pilnīgs ceļvedis datubāzes administratoriem [2026]

SQL Server Always On ir Microsoft visaptverošais augstas pieejamības un katastrofu atkopšanas risinājums, kas tika ieviests kopā ar SQL Server 2012. gads. Tas ir ievērojams progress salīdzinājumā ar iepriekšējām tehnoloģijām, piemēram, datubāzes spoguļošanu un žurnālu nosūtīšanu, nodrošinot nepārtrauktu piekļuvi datiem, vienlaikus samazinot dīkstāves laiku un datu zudumu.

1.2 Kāpēc uzņēmumiem ir nepieciešami vienmēr pieejami risinājumi

Mūsdienu digitālajā ekonomikā datubāzes dīkstāve tieši nozīmē lost ieņēmumi, sabojāta reputācija un atbilstības normatīvajiem aktiem problēmas. Organizācijām ir nepieciešami augstas pieejamības risinājumi, kas var garantēt gandrīz nepārtrauktu darbības laiku, vienlaikus aizsargājot pret dažādiem kļūmju scenārijiem.

Tradicionālās dublēšanas un atjaunošanas procedūras mūsdienu biznesa prasībām nav pietiekamas. Kad kritiska datubāze neizdodas, uzņēmumi nevar atļauties stundas, kas nepieciešamas atjaunošanai no dublējumkopijām. Always On risinājumi nodrošina automatizētu dublēšanu, kas var atjaunot pakalpojumu sekundēs vai minūtēs, nevis stundās, ievērojami samazinot sistēmas kļūmju ietekmi.

Papildus pamata pieejamībai uzņēmumiem ir jāatbrīvojas no ražošanas datubāzēm ar lielu lasīšanas apjomu, jāveic apkope bez dīkstāves un jāaizsargājas pret vietnes līmeņa katastrofām. SQL Server “Always On” risina visas šīs prasības, izmantojot vienotu arhitektūru, kas ir piemērota gan nelielām izvietošanas vietām, gan globāli izkliedētām sistēmām.

1.3 Galvenie jēdzieni: RTO, RPO, HA un DR

Atkopšanas laika mērķis (RTO) nosaka maksimāli pieļaujamo dīkstāves ilgumu pēc kļūmes — cik ātri datubāzei jāatgriežas tiešsaistē.

Atjaunošanas punkta mērķis (RPO) nosaka maksimāli pieļaujamo datu zudumu, kas mērīts laikā — cik daudz nesen apkopotu datu uzņēmums var atļauties zaudēt.

Augsta pieejamība (HA) koncentrējas uz dīkstāves laika samazināšanu, ko izraisa ikdienas kļūmes, piemēram, aparatūras darbības traucējumi vai programmatūras avārijas, vienā datu centrā.

Katastrofu seku novēršana (DR) risina katastrofālus notikumus, kas ietekmē veselas vietnes, saglabājot datu kopijas ģeogrāfiski atsevišķās vietās. Kamēr HA koncentrējas uz dīkstāves laika samazināšanu līdz minimumam, DR koncentrējas uz datu aizsardzības un uzņēmējdarbības nepārtrauktības nodrošināšanu lielu incidentu laikā.

SQL Server Vienā vienotā arhitektūrā Always On atbalsta gan HA, gan DR. Sinhronās apstiprināšanas režīms nodrošina RPO = 0 ar automātisku dublēšanu gandrīz nulles RTO; asinhronās apstiprināšanas režīms pieņem iespējamus datu zudumus apmaiņā pret zemāku latentuma ietekmi attālās vietnēs.

1.4 Vienmēr pieejami risinājumi

SQL Server Always On piedāvā trīs izvietošanas iespējas, katra no kurām ir piemērota atšķirīgām pieejamības un infrastruktūras prasībām. Šajā rokasgrāmatā ir aplūkotas visas trīs:

Vienmēr pieejamas pieejamības grupas (AG): Datu bāzes līmeņa augsta pieejamība un atkopšana pēc avārijas bez koplietotas krātuves.
Vienmēr ieslēgtas kļūmjpārlēces klastera instances (FCI): Augsta pieejamība instances līmenī, izmantojot koplietotu krātuvi.
AG + FCI kopā: Divslāņu aizsardzība, kas apvieno instances līmeņa un datubāzes līmeņa dublēšanu, lai nodrošinātu maksimālu noturību.

2. Vienmēr pieejamas pieejamības grupas

Vienmēr pieejamas pieejamības grupas (AG) ir datubāzes līmeņa augstas pieejamības un katastrofu atkopšanas risinājums, kas replicē lietotāju datubāzu kopu uz līdz pat astoņām sekundārām kopijām, izmantojot nepārtrauktu darījumu žurnālu nosūtīšanu.

2.1 Galvenās iezīmes

Datu bāzes līmeņa dublēšana: atsevišķas datu bāzes vai grupas var veikt dublēšanu neatkarīgi no SQL Server instance;
līdz deviņām replikām (viena primārā, astoņas sekundārās) Enterprise Edition versijā;
sinhronās apstiprināšanas režīms datu zuduma novēršanai; asinhronās apstiprināšanas režīms attālām DR replikām;
automātiska sinhrono repliku pārslēgšana, kad primārā kopija kļūst nepieejama;
lasāmas sekundārās kopijas atskaišu veidošanas un dublēšanas darba slodžu atslogošanai;
Pieejamības grupas klausītājs nodrošina vienu savienojuma galapunktu, kas automātiski novirza uz pašreizējo primāro galapunktu.

2.2. Ieviešanas soļi

Sagatavot Active Directory pakalpojuma kontus un konfigurēt atļaujas visos mezglos;
instalēt un validēt Windows Server kļūmjpārlēces klasterizāciju visos iesaistītajos serveros;
uzstādīt SQL Server kā atsevišķu instanci katrā mezglā, izmantojot konsekventus ceļus un iestatījumus;
iespējojiet funkciju Vienmēr pieejamas grupas, izmantojot SQL Server Konfigurācijas pārvaldnieks vai PowerShell;
iestatīt datubāzes pilnīgas atkopšanas modelim un veikt pilnas un žurnālu dublējumkopijas;
izveidojiet pieejamības grupu, pievienojiet kopijas un konfigurējiet pieejamības un rezerves kopiju režīmus;
iesēt sekundārās kopijas, izmantojot automātisku iesēšanu vai manuālu dublēšanu un atjaunošanu;
Izveidojiet pieejamības grupas klausītāju un pārbaudiet klienta savienojamību.

Pilnīgu soli pa solim sniegto pamācību skatiet mūsu Pilnīga rokasgrāmata par vienmēr pieejamajām grupām.

2.3 Vislabāk piemērots

Misijai kritiski svarīgas datubāzes, kurām nav nepieciešams datu zudums un automātiska pārslēgšana;
darba slodzes, kurām nepieciešami nolasāmi sekundārie faili atskaišu veidošanai vai dublējumu atslodzei;
izvietošana vairākās vietās katastrofu atkopšanai;
vidēs bez esošas koplietotas krātuves infrastruktūras.

2.4 plusi

Nav nepieciešama koplietota krātuve — katra kopija izmanto neatkarīgu lokālo krātuvi;
atbalsta gan HA, gan DR vienā konfigurācijā;
nolasāmi sekundārie materiāli samazina primāro materiālu darba slodzi;
Datu bāzes līmeņa granularitāte ļauj izmantot dažādas dublēšanas politikas katrai datu bāzes grupai.

2.5 mīnusi

Pilnam funkciju komplektam nepieciešams Enterprise Edition (standarta versija atbalsta Basic AG ar ievērojamiem ierobežojumiem);
sinhronās apstiprināšanas režīmā rakstīšanas latentums ir proporcionāls tīkla aprites laikam;
pieteikšanās, SQL aģenta darbi un saistītie serveri prasa manuālu sinhronizāciju SQL Server 2019. gadā un agrāk;
Visām kopijām jāatrodas viena un tā paša Windows Server kļūmjpārlēces klastera mezglos.

2.6 Atsauces

Oficiālais Microsoft dokuments: Kas ir vienmēr ieslēgta pieejamības grupa?
Oficiālais Microsoft dokuments: Getting Starar Always On pieejamības grupām

3. Vienmēr ieslēgtas kļūmjpārlēces klastera instances

Vienmēr ieslēgtas kļūmjpārlēces klastera instances (FCI) nodrošina augstu pieejamību instances līmenī, darbinot vienu SQL Server instance vairākos fiziskajos mezglos, kas koplieto vienu un to pašu krātuvi. Kad aktīvais mezgls neizdodas, SQL Server instance gaidstāves mezglā tiek automātiski atjaunotatarted, padarot pāreju caurspīdīgu klienta lietojumprogrammām.

3.1 Galvenās iezīmes

Instances līmeņa dublēšana: visas instances datubāzes kopīgi pārslēdzas kā viena vienība;
koplietota krātuve (krātuves tīkls (SAN), iSCSI, Storage Spaces Direct vai SMB), kurai var piekļūt visi mezgli;
virtuālā tīkla nosaukums un virtuālā IP adrese nodrošina stabilu savienojuma galapunktu neatkarīgi no tā, kurš mezgls ir aktīvs;
Windows Server kļūmjpārlēces klasterizācija pārvalda mezglu veselības uzraudzību, kvorumu un kļūmjpārlēces orķestrēšanu;
atbalsta aktīvo/gaidstāves, aktīvo/aktīvo, N+1 un N+M mezglu konfigurācijas veidus.

3.2. Ieviešanas soļi

Nodrošināt un pievienot koplietoto krātuvi visiem klastera mezgliem;
instalēt kļūmjpārlēces klasterizācijas funkciju un validēt klastera konfigurāciju;
Izveidojiet Windows Server kļūmjpārlēces klasteri un konfigurējiet kvorumu;
palaist SQL Server instalēšana, izvēloties kļūmjpārlēces klastera opciju un norādot virtuālā tīkla nosaukumu un koplietotās krātuves ceļus;
pievienot papildu mezglus SQL Server kļūmjpārlēces klastera instance;
pārbaudiet kļūmjpārlēces darbību, testējot manuālu kļūmjpārlēci starp mezgliem.

Pilnīgu soli pa solim sniegto pamācību skatiet mūsu SQL Server Pilnīga rokasgrāmata par kļūmjpārlēces klastera izveidi.

3.3 Vislabāk piemērots

Vides ar esošu koplietojamu krātuves infrastruktūru (SAN vai iSCSI);
lietojumprogrammas, kurām nepieciešama instances līmeņa dublēšana, kur visām datubāzēm ir jāveic dublēšana kopā;
scenāriji, kuros klienta pārredzamība ir kritiski svarīga un nav pieņemamas izmaiņas lietojumprogrammas pusē;
organizācijas, kas prioritizē vienas instances dublēšanas modeļa vienkāršību.

3.4 plusi

Automātiska dublēšana instances līmenī bez nepieciešamības pārkonfigurēt klientu;
nav datu replikācijas papildu izmaksu — visi mezgli piekļūst vienai un tai pašai krātuvei;
paredzama visu datubāzu vienlaicīga pārslodzes darbība;
atbalsta elastīgas mezglu konfigurācijas (aktīvs/aktīvs, N+1, N+M), lai optimizētu aparatūras izmantošanu.

3.5 mīnusi

Koplietota krātuve ir potenciāls vienīgais kļūmes punkts, ja vien pati krātuve nav lieka;
darbojas tikai viens mezgls SQL Server vienlaikus — nav lasīšanas slodzes līdzsvarošanas sekundārajos mezglos;
nav iebūvētas atkopšanas pēc avārijas bez savienošanas pārī ar pieejamības grupu;
koplietota krātuves infrastruktūra pievieno cost un sarežģītība salīdzinājumā ar AG.

3.6 Atsauces

Oficiālais Microsoft dokuments: Vienmēr ieslēgtas kļūmjpārlēces klastera instances (SQL Server)

4. Apvienojiet pieejamības grupas ar kļūmjpārlēces klastera instancēm

Organizācijām, kurām nepieciešama gan instances līmeņa, gan datubāzes līmeņa aizsardzība, SQL Server atbalsta hostpieejamības grupas repliku veidošana kļūmjpārlēces klastera instancēs (FCI). Šajā konfigurācijā katrs FCI mezgls darbojas kā viena pieejamības replika, tāpēc FCI kļūmjpārlēce ir caurspīdīga pieejamības grupai, savukārt AG kļūmjpārlēce nodrošina datubāzes līmeņa aizsardzību visās vietnēs. Šī kombinācija nodrošina most visaptverošs augstas pieejamības un katastrofu atkopšanas pārklājums, kas pieejams SQL Server.

4.1 Galvenās iezīmes

Divslāņu dublēšana: FCI apstrādā mezglu kļūmes instances līmenī; AG apstrādā vietnes vai replikas līmeņa kļūmes.
katrs FCI tiek uzskatīts par vienu repliku pieejamības grupā neatkarīgi no tā, cik mezglu FCI satur;
FCI-hostEd kopijām joprojām ir nepieciešama koplietojama krātuve saskaņā ar standarta FCI prasībām;
AG replikas hostFCI atbalsta tikai manuālu pārslēgšanu — automātiskā pārslēgšana FCI-h nav pieejama.osted kopijas;
Atsevišķas instances var piedalīties tajā pašā pieejamības grupā līdzās FCI-hosted replikas.

4.2. Ieviešanas soļi

Izvietot un validēt katru FCI neatkarīgi, ievērojot standarta FCI iestatīšanas procedūras;
nodrošināt, lai visi FCI mezgli un atsevišķie replikas mezgli piederētu vienam un tam pašam Windows Server kļūmjpārlēces klasterim;
iespējojiet funkciju “Vienmēr ieslēgtas pieejamības grupas” katrā FCI instancē;
pārliecinieties, ka neviens WSFC mezgls nedarbosiesost divas vienas un tās pašas pieejamības grupas kopijas pēc jebkuras iespējamas FCI pārslēgšanas;
Izveidojiet pieejamības grupu, norādot FCI instances kā kopijas un konfigurējot manuālu kļūmjpārlēces režīmu visiem FCI-hosted kopijas;
Sēklas sekundārās kopijas un konfigurējiet pieejamības grupas klausītāju.

Lai iegūtu sīkāku informāciju par FCI iestatīšanu, skatiet mūsu SQL Server Pilnīgs ceļvedis par rezerves kopu. Sīkāku informāciju par AG iestatīšanu skatiet mūsu Always On pieejamības grupu pilnīgajā ceļvedī.

4.3 Vislabāk piemērots

Kritiski svarīgas vides, kurām nepieciešama aizsardzība gan pret atsevišķu mezglu kļūmēm, gan vietnes līmeņa katastrofām;
organizācijas, kas jau izmanto FCI un kurām jāpievieno starpvietņu atkopšana pēc katastrofām;
regulētās nozares, kurās obligāti ir noslēgti maksimālas datu aizsardzības un pieejamības SLA;
liela mēroga izvietošanas, kurās līdzās jāpastāv gan instances līmeņa, gan datubāzes līmeņa dublēšanas politikām.

4.4 plusi

Maksimāla aizsardzība: mezglu kļūmes apstrādā FCI, vietnes kļūmes apstrādā AG;
FCI dublēšana ir caurspīdīga pieejamības grupai — AG neredz nekādas replikas izmaiņas FCI dublēšanas laikā;
elastīga topoloģija: sajauciet FCI-hostgan atsevišķas kopijas vienā pieejamības grupā.

4.5 mīnusi

FCI-hosted kopijas atbalsta tikai manuālu AG pārslēgšanu — automātiska AG pārslēgšana šīm kopijām nav pieejama;
nepieciešama rūpīga WSFC mezglu plānošana, lai novērstu viena mezgla kļūmiostdivu viena un tā paša AG kopiju izveide pēc FCI pārslēgšanas;
augstāka infrastruktūra cost un darbības sarežģītību nekā tikai AG vai FCI;
Katram FCI komponentam joprojām ir nepieciešama koplietota krātuve.

4.6 Atsauces

Oficiālais Microsoft dokuments: Kļūmjpārlēces klasterizācija un vienmēr ieslēgtas pieejamības grupas (SQL Server)
Oficiālais Microsoft dokuments: Kas ir vienmēr ieslēgta pieejamības grupa?
Oficiālais Microsoft dokuments: Getting Starar Always On pieejamības grupām
Oficiālais Microsoft dokuments: Vienmēr ieslēgtas kļūmjpārlēces klastera instances (SQL Server)

5. Vienmēr ieslēgtu risinājumu salīdzinājums

5.1 Funkciju salīdzināšanas tabula

iezīme	Pieejamības grupas	Kļūmjpārlēces klastera instances	AG + FCI kombinētā
Kļūmjpārlēces darbības joma	Datubāzes līmenī	Instances līmenī	Abi
Nepieciešama koplietota krātuve	Nē	Jā	Jā (FCI komponentam)
Datu replikācija	Žurnāla pamatā ir katra replika	Nav (koplietota krātuve)	Logaritmveida starp FCI
Automātiska kļūmjpārlēce	Jā (sinhronās kopijas)	Jā	FCI: Jā; AG: Nē
Nolasāmas sekundārās vērtības	Jā	Nē	Jā (AG komponents)
Katastrofu atgūšana	Iebūvētie	Nav iebūvēts	Iebūvētie
Maksimālais repliku skaits	9 (Uzņēmums)	N / A	9 (Uzņēmums)
Infrastruktūras sarežģītība	vidējs	vidējs	augsts
Izmaksas	Zemāks (SAN nav nepieciešams)	Augstāks (nepieciešams SAN)	augstākais

5.2 Izvēlieties savu vienmēr pieejamo risinājumu

Starar jūsu krātuves infrastruktūru: ja jums nav esošas koplietotas krātuves, pieejamības grupas ir dabiska izvēle, un most cost- efektīvs ceļš gan uz HA, gan DR. Ja jūs jau pārvaldāt SAN vidi un jums ir nepieciešama instances līmeņa dublēšana, FCI ir vienkāršāka iespēja, taču plānojiet AG pievienošanu vēlāk, ja starpvietņu DR ir nākotnes prasība.

Izvēlieties AG + FCI kombināciju tikai tad, ja jums ir patiesa nepieciešamība pēc abiem aizsardzības slāņiem un operacionālā brieduma, lai pārvaldītu paaugstināto sarežģītību. Galvenais ierobežojums, kas jāatceras, ir tas, ka FCI-hostEd AG kopijas neatbalsta automātisku AG pārslēgšanu, tāpēc šai topoloģijai ir nepieciešama manuāla iejaukšanās pieejamības grupas līmeņa pārslēgšanai.

Par most Jaunizveidotām izvietošanām mūsdienās ieteicamais risinājums ir Always On Availability Groups.tarSvarīgs punkts: tas aptver gan HA, gan DR, neprasa koplietotu krātuvi un atbalsta lasāmus sekundāros failus — iespējas, kurām FCI viena pati nevar nodrošināt līdzi.

6. Paraugprakse par SQL Server Vienmēr pieejami risinājumi

6.1. Plānošana un projektēšana

Pirms Always On risinājuma izvēles definējiet RTO un RPO prasības — šīs tartieši nosaka, vai ir piemērots sinhronais vai asinhronais apstiprināšanas režīms un vai ir iespējama automātiska pārslēgšana.
Pielāgojiet sekundāro repliku izmērus, lai apstrādātu pilnu primāro darba slodzi kļūmjpārlēces notikuma laikā, tostarp maksimālās slodzes scenārijos.
AG izvietošanas gadījumā sinhronās kopijas ievietojiet vienā datu centrā vai zemas latentuma tīklā, lai samazinātu rakstīšanas latentuma ietekmi. Ģeogrāfiski attālām DR kopijām rezervējiet asinhrono režīmu.
Izveidojiet kvorumu ar nepāra balsu skaitu. Divu mezglu klasteriem pievienojiet failu koplietošanas resursu vai mākoņa liecinieku kā trešo balsi, lai novērstu smadzeņu dalīšanās scenārijus.
Rūpīgi plānojiet tīkla topoloģiju vairāku apakštīklu izvietošanai. Katram apakštīklam ir nepieciešama sava klausītāja IP adrese, un klientiem savienojuma virknēs ir jābūt MultiSubnetFailover=True.

6.2 Ieviešanas vadlīnijas

Izmantojiet konsekventu SQL Server versiju, izdevumu un kumulatīvo atjauninājumu līmeņi visās replikās. Jaukti ielāpu līmeņi var izraisīt negaidītu darbību pārslodzes laikā.
Konfigurējiet īpašas tīkla saskarnes klastera periodisko ziņojumu trafikam atsevišķi no lietojumprogrammu trafika.
Iespējot automātisko sēšanu sākotnējai datubāzes sinhronizācijai SQL Server 2016. gadā un vēlāk — tas novērš nepieciešamību manuāli kopēt dublējumkopijas uz sekundārajām kopijām most scenāriji.
AG + FCI topoloģijām pēc katras FCI mezgla konfigurācijas izmaiņas pārbaudiet, vai neviens WSFC mezgls nevar nonākt h stāvoklī.ostdivu vienas un tās pašas pieejamības grupas repliku izveide.
Vienmēr lietojiet SQL Server Management Studio vai Transact-SQL pieejamības grupu kļūmjpārlēču pārvaldībai — nekad neizmantojiet kļūmjpārlēces klastera pārvaldnieku tieši, jo tas nezina par AG sinhronizācijas stāvokli un var izraisīt ilgstošu dīkstāvi vai datu zudumu.

6.3 Uzraudzība un apkope

Regulāri uzraugiet sinhronizācijas stāvokli, nosūtiet rindu un atkārtojiet rindu, izmantojot pieejamības grupas informācijas paneli. SQL Server Management Studio vai dinamiskās pārvaldības skati (DMV). Pieaugoša atkārtošanas rinda sekundārajā ierīcē norāda uz I/O sastrēgumu, kas aizkavēs atkopšanu pēc kļūmjpārlēces.
Palaidiet DBCC CHECKDB sekundārajās replikās, lai atbrīvotu vietu integritātes pārbaudēs, kas saistītas ar primārajām replikām. Skatiet mūsu DBCC CHECKDB ceļvedis sīkāku informāciju.
Izvēlēties SQL Server Ielāpojumi, izmantojot slīdošos jauninājumus: vispirms ielāpojiet sekundāros replikas, veiciet plānotu manuālu dublēšanu uz ielāpoto sekundāro kopiju un pēc tam ielāpojiet iepriekšējo primāro kopiju. Tas ierobežo dīkstāves laiku līdz vienas dublēšanas ilgumam.
Regulāri pārbaudiet kļūmjpārlēci neražošanas vidēs. Automātiska kļūmjpārlēce, kas nekad nav pārbaudīta, nav uzticama atkopšanas stratēģija.
Konfigurējiet brīdinājumus par pieejamības grupas veselības stāvokļa izmaiņām, replikas lomu pārejām un sinhronizācijas kļūmēm, izmantojot SQL Server Aģents vai īpašs uzraudzības rīks, piemēram, SQL Server Performance Monitor.

7. Bieži uzdotie jautājumi

J: Kas ir SQL Server Vienmēr ieslēgts?

A: SQL Server Always On ir Microsoft augstas pieejamības un katastrofu atkopšanas platforma, kas tika ieviesta 2016. gadā. SQL Server 2012. gads. Tas ietver divas tehnoloģijas — Always On Availability Groups un Always On Failover Cluster Instances —, kas nodrošina automatizētu dublēšanu, datu dublēšanu un nepārtrauktu piekļuvi datubāzēm aparatūras, programmatūras vai vietnes kļūmju gadījumā.

J: Kāda ir atšķirība starp Always On pieejamības grupām un Failover Cluster instancēm?

A: Pieejamības grupas darbojas datubāzes līmenī, replicē datus uz neatkarīgām sekundārajām kopijām, izmantojot žurnālu nosūtīšanu, un tām nav nepieciešama koplietota krātuve. Kļūmjpārlēces klastera instances darbojas instances līmenī, tām ir nepieciešama koplietota krātuve, kurai var piekļūt visi mezgli, un tās veic kļūmjpārlēces darbību visās datubāzēs kopā kā vienotā vienībā. AG atbalsta lasāmus sekundāros resursus un iebūvētu DR; FCI neatbalsta.

J: Vai man ir nepieciešama koplietojama krātuve Always On pieejamības grupām?

A: Nē. Katra AG replika lokālajā krātuvē uztur savu neatkarīgu datubāzu kopiju. Koplietota krātuve ir nepieciešama tikai tad, ja izmantojat kļūmjpārlēces klastera instances, lai...ost AG replikas.

J: Vai varu lietot funkciju Always On ar SQL Server Standarta versija?

A: SQL Server Standarta versija atbalsta pamata pieejamības grupas (Basic Availability Groups).tarzvanīt ar SQL Server 2016. gadā, taču ar ievērojamiem ierobežojumiem: viena datubāze uz katru AG, ne vairāk kā divas kopijas un nav lasāma sekundārā atbalsta. FCI ir pieejams standarta versijā bez šiem ierobežojumiem. Pilnīgai Always On funkcionalitātei ir nepieciešams Enterprise izdevums.

J: Kāds ir maksimālais repliku skaits pieejamības grupā?

A: SQL Server Enterprise Edition atbalsta līdz deviņām kopijām: vienu primāro un astoņas sekundārās kopijas. Izplatītās pieejamības grupas var paplašināt šo skaitu līdz 18 kopijām divās atsevišķās pieejamības grupās.

J: Vai FCI-h varostVai ed replikas izmanto automātisku AG dublēšanu?

A: Nē. Kad pieejamības replika ir hostJa replikā ir izveidots kļūmjpārlēces klastera gadījums, automātiskā pieejamības grupas kļūmjpārlēce šai kopijai netiek atbalstīta. Visas AG kļūmjpārlēces, kas ietver FCI-hostEd kopijām nepieciešama manuāla iejaukšanās.

J: Kāda ir atšķirība starp sinhronajiem un asinhronajiem apstiprināšanas režīmiem?

A: Sinhronās apstiprināšanas režīmā primārajam serverim ir jāgaida, kamēr sekundārais serveris nostiprina žurnāla ierakstus pirms apstiprināšanas, nodrošinot nulles datu zudumu (RPO = 0) cost papildu rakstīšanas latentuma. Asinhronās apstiprināšanas režīms ļauj primārajam serverim veikt apstiprināšanu bez gaidīšanas, samazinot latentumu, bet riskējot zaudēt datus, ja primārais serveris neizdodas, pirms sekundārais serveris saņem visus žurnāla ierakstus. Izmantojiet sinhrono režīmu lokālām HA kopijām un asinhrono režīmu attālām DR kopijām.

J: Cik ilgi notiek SQL Server Vienmēr ieslēgts rezerves pārslēgšanas režīms?

A: Automātiska sinhronas AG replikas pārslēgšana parasti notiek mazāk nekā 30 sekundēs normālos apstākļos. FCI pārslēgšana parasti aizņem 20–60 sekundes atkarībā no datubāzes atkopšanas laika. Faktiskais ilgums ir atkarīgs no darba slodzes, datubāzes lieluma un WSFC konfigurētajiem veselības pārbaudes taimauta iestatījumiem.

J: Kas notiek ar klientu savienojumiem rezerves kopēšanas laikā?

A: Esošie savienojumi tiek pārtraukti, kad notiek kļūmjpārlēce. Lietojumprogrammas, kas izmanto pieejamības grupas klausītāju un ietver savienojuma atkārtotas mēģināšanas loģiku, pēc kļūmjpārlēces pabeigšanas automātiski atkārtoti izveido savienojumu ar jauno primāro tīklu. MultiSubnetFailover=True pievienošana savienojuma virknēm uzlabo atkārtotas savienošanas ātrumu vairāku apakštīklu izvietojumos.

J: Kā pieteikties? SQL Server ielāpi ar minimālu dīkstāvi Always On vidē?

A: Izmantojiet slīdošos jauninājumus: vispirms atjauniniet sekundārās kopijas, pēc tam veiciet plānotu manuālu pārslēgšanos uz atjaunināto sekundāro kopiju un visbeidzot atjauniniet iepriekšējo primāro kopiju. Tas ierobežo dīkstāves laiku līdz vienas plānotas pārslēgšanās ilgumam — parasti mazāk nekā minūtei.

J: Vai varu apvienot Always On pieejamības grupas ar kļūmjpārlēces klastera instancēm?

A: Jā. Jūs varat host AG replikas FCI instancēs, lai nodrošinātu gan instances līmeņa, gan datubāzes līmeņa dublēšanas aizsardzību. Katra FCI tiek uzskatīta par vienu AG repliku. Šī topoloģija prasa rūpīgu WSFC mezglu plānošanu, lai nodrošinātu, ka neviens mezgls nedarbojas pareizi.ostdivas viena un tā paša AG kopijas pēc jebkuras iespējamas FCI pārslēgšanas.

J: Kas jādara, ja mana datubāze tiek bojāta Always On vidē?

A: Vispirms pārbaudiet, vai bojājumi ir visās dublikātos vai tikai primārajā. Ja pastāv vesela sekundārā kopija, nekavējoties pārejiet uz to. Ja bojājumi ir visās dublikātos, atjaunojiet tos no tīras dublējuma. Regulāri palaidiet DBCC CHECKDB sekundārajās dublikātos, lai laikus atklātu bojājumus. Ja ir skartas arī dublējumkopijas, specializēta SQL Server datu atkopšanas rīks var mēģināt iegūt datus no bojātiem MDF failiem kā pēdējo līdzekli.

J: Kā Always On pieejamības grupas salīdzināmas ar vecākām versijām SQL Server HA risinājumi?

A: AG aizstāj vecākas tehnoloģijas, piemēram, baļķu piegāde un replikācijaŽurnālu nosūtīšanai ir nepieciešama manuāla pārslēgšana, un tai nav automātiskas lomu maiņas; replikācija ir paredzēta datu izplatīšanai, nevis HA. AG nodrošina automātisku pārslēgšanu, nulles datu zudumu ar sinhronu apstiprināšanu un lasāmus sekundāros resursus — iespējas, kurām šīs tehnoloģijas nevar līdzināties.

8. secinājums

SQL Server Always On nodrošina elastīgu, uzņēmuma līmeņa platformu augstai pieejamībai un atkopšanai pēc katastrofām. Always On pieejamības grupas ir pareizā izvēle most mūsdienīgas izvietošanas: tas novērš nepieciešamību pēc koplietotas krātuves, atbalsta lasāmus sekundāros resursus un apstrādā gan lokālo HA, gan starpvietņu DR vienā konfigurācijā. Kļūmjpārlēces klastera instances joprojām ir stabila izvēle, ja galvenās prasības ir instances līmeņa kļūmjpārlēce un esošā koplietotās krātuves infrastruktūra. Abu tehnoloģiju apvienošana nodrošina visdziļāko pieejamo aizsardzību — pie cost lielākas investīcijas infrastruktūrā un darbības sarežģītība.

Neatkarīgi no izvēlētā risinājuma pamatprincipi ir vienādi: vispirms definējiet RTO un RPO prasības un, ņemot vērā šīs prasības, izstrādājiet topoloģiju. tarsaņem un regulāri testē pārslodzi. Labi ieviests un rūpīgi pārbaudīts Always On risinājums atjaunosies paredzami, ja radīsies ražošanas kļūmes.

par autoru

Juaņs Šens ir vecākais datubāzes administrators (DBA) ar vairāk nekā 10 gadu pieredzi SQL Server vides un uzņēmumu datubāzu pārvaldību. Viņš ir veiksmīgi atrisinājis simtiem datubāzu atkopšanas scenāriju finanšu pakalpojumu, veselības aprūpes un ražošanas organizācijās.

Juaņa specializējas SQL Server datubāzu atjaunošana, augstas pieejamības risinājumi un veiktspējas optimizācija. Viņa plašā praktiskā pieredze ietver vairāku terabaitu datubāzu pārvaldību, Always On pieejamības grupu ieviešanu un automatizētu dublēšanas un atkopšanas stratēģiju izstrādi kritiski svarīgām biznesa sistēmām.

Izmantojot savu tehnisko pieredzi un praktisko pieeju, Juans koncentrējas uz visaptverošu rokasgrāmatu izveidi, kas palīdz datubāzu administratoriem un IT speciālistiem risināt sarežģītus jautājumus SQL Server efektīvi izaicina. Viņš seko līdzi jaunākajām tendencēm SQL Server laidieniem un Microsoft attīstītajām datubāzu tehnoloģijām, regulāri testējot atkopšanas scenārijus, lai nodrošinātu, ka viņa ieteikumi atspoguļo labāko praksi reālajā pasaulē.

Ir jautājumi par SQL Server atkopšanai vai nepieciešama papildu palīdzība datubāzes problēmu novēršanā? Juans laipni aicina atsauksmes un ieteikumi lai uzlabotu šos tehniskos resursus.