SQL Server Always On: täielik juhend andmebaasiadministraatorile [2026]

SQL Server Always On on Microsofti terviklik kõrge kättesaadavuse ja katastroofide taastamise lahendus, mis tutvustati koos SQL Server 2012. See kujutab endast olulist edasiminekut varasemate tehnoloogiate, näiteks andmebaaside peegeldamise ja logide saatmise ees, tagades pideva juurdepääsu andmetele, minimeerides samal ajal seisakuid ja andmete kadu.

1.2 Miks ettevõtted vajavad alati kättesaadavaid lahendusi

Tänapäeva digitaalmajanduses tähendab andmebaaside seisakud otseselt saamata jäänud tulu, kahjustatud mainet ja vastavusprobleeme regulatiivsetele nõuetele. Organisatsioonid vajavad kõrge käideldavusega lahendusi, mis suudavad garanteerida peaaegu pideva tööaja, kaitstes samal ajal mitmesuguste rikete eest.

Traditsioonilised varundus- ja taastamisprotseduurid ei ole tänapäevaste ärivajaduste rahuldamiseks piisavad. Kui kriitiline andmebaas rikki läheb, ei saa ettevõtted endale lubada varukoopiatest taastamiseks kuluvaid tunde. Always On lahendused pakuvad automaatset tõrkesiirdeteenust, mis suudab teenuse taastada sekundite või minutite, mitte tundide jooksul, vähendades oluliselt süsteemirikete mõju.

Lisaks põhilisele kättesaadavusele peavad ettevõtted tootmisandmebaasidest maha võtma lugemismahuka töökoormuse, teostama hooldust ilma seisakuteta ja kaitsma end saiditasandi katastroofide eest. SQL Server Always On vastab kõigile neile nõuetele ühtse arhitektuuri kaudu, mis skaleerub nii väikestest juurutustest kui ka globaalselt hajutatud süsteemideni.

1.3 Põhimõisted: RTO, RPO, HA ja DR

Taastumisaja eesmärk (RTO) määratleb rikke järgse seisaku maksimaalse vastuvõetava kestuse – kui kiiresti peab andmebaas uuesti võrku olema.

Taastumispunkti eesmärk (RPO) määratleb ajas mõõdetud maksimaalse vastuvõetava andmekao – kui palju hiljuti lisatud andmeid ettevõte saab endale lubada kaotada.

Kõrge saadavus (HA) keskendub samas andmekeskuses tavapäraste rikete, näiteks riistvara talitlushäirete või tarkvarakrahhide põhjustatud seisakute minimeerimisele.

Katastroofitaaste (DR) Tegeleb katastroofiliste sündmustega, mis mõjutavad terveid saite, säilitades andmete koopiaid geograafiliselt eraldi asukohtades. Kui HA keskendub seisakuaja minimeerimisele, siis DR keskendub andmekaitse ja äritegevuse järjepidevuse tagamisele suuremate intsidentide ajal.

SQL Server Always On toetab nii HA-d kui ka DR-i ühe ühtse arhitektuuri raames. Sünkroonse kinnitamise režiim pakub RPO = 0 automaatse tõrkesiirdega peaaegu nullilähedase RTO jaoks; asünkroonse kinnitamise režiim aktsepteerib võimalikku andmekadu vastutasuks väiksema latentsusaja eest kaugemates asukohtades.

1.4 Alati lahendused

SQL Server Always On pakub kolme juurutamisvõimalust, millest igaüks sobib erinevate kättesaadavuse ja taristunõuetega. See juhend hõlmab kõiki kolme:

Alati sisse lülitatud kättesaadavusrühmad (AG): Andmebaasi tasemel kõrge käideldavus ja katastroofidejärgne taastamine ilma jagatud salvestusruumita.
Alati sisse lülitatud tõrkesiirde klastri eksemplarid (FCI): Eksemplari tasemel kõrge käideldavus jagatud salvestusruumi abil.
AG + FCI kokku: Kahekihiline kaitse, mis ühendab maksimaalse vastupidavuse tagamiseks eksemplari tasemel ja andmebaasi tasemel tõrkesiirde.

2. Alati sisse lülitatud kättesaadavuse rühmad

Alati sisse lülitatud kättesaadavusrühmad (AG) on andmebaasi tasemel kõrge käideldavuse ja katastroofide taastamise lahendus, mis replikeerib kasutajaandmebaaside komplekti kuni kaheksasse sekundaarsesse koopiasse pideva tehingulogi saatmise kaudu.

2.1 Põhijooned

Andmebaasi tasemel tõrkesiire: üksikud andmebaasid või rühmad saavad tõrkesiire teha sõltumatult SQL Server näiteks;
kuni üheksa koopiat (üks primaarne, kaheksa sekundaarset) Enterprise Editionis;
sünkroonse kinnitamise režiim andmekao nullimiseks; asünkroonne kinnitamine kaugete DR-koopiate jaoks;
automaatne tõrkesiire sünkroonsete koopiate jaoks, kui peamine koopia pole saadaval;
loetavad teisesed koopiad aruandluse ja varundustöökoormuste mahakandmiseks;
Kättesaadavusrühma kuulaja pakub ühte ühenduse lõpp-punkti, mis marsruutib automaatselt praegusele peamisele võrgule.

2.2 Rakendusetapid

Valmistage ette Active Directory teenuse kontod ja konfigureerige õigused kõigil sõlmedel;
installida ja valideerida Windows Serveri tõrkesiirdeklaster kõigil osalevatel serveritel;
paigaldama SQL Server igal sõlmel eraldiseisva eksemplarina, kasutades ühtseid teid ja sätteid;
lubage alati sisse lülitatud kättesaadavusrühmade funktsioon kaudu SQL Server Konfiguratsioonihaldur või PowerShell;
seadista andmebaasid täieliku taastemudeli peale ning tee täielikud ja logide varukoopiad;
looge kättesaadavusrühm, lisage koopiad ning konfigureerige kättesaadavus- ja tõrkesiirderežiimid;
teiseseid koopiaid saab külvata automaatse külvamise või käsitsi varundamise ja taastamise abil;
Looge kättesaadavusrühma kuulaja ja kontrollige kliendi ühenduvust.

Täieliku samm-sammult juhendi leiate meie Alati sisse lülitatud kättesaadavusgruppide täielik juhend.

2.3 Parim valik

Kriitilised andmebaasid, mis ei nõua andmete kadu ja automaatset tõrkesiirde funktsiooni;
töökoormused, mis vajavad aruandluseks või varukoopiate mahalaadimiseks loetavaid teiseseid andmeid;
juurutused, mis hõlmavad mitut asukohta katastroofidejärgseks taastamiseks;
keskkonnad ilma olemasoleva jagatud salvestusinfrastruktuurita.

2.4 Plussi

Jagatud salvestusruumi pole vaja – iga koopia kasutab sõltumatut kohalikku salvestusruumi;
toetab nii HA-d kui ka DR-i ühes konfiguratsioonis;
loetavad sekundaarkoodid vähendavad primaarkoodide töökoormust;
Andmebaasi tasemel detailsus võimaldab andmebaasirühma kohta erinevaid tõrkesiirdepoliitikaid.

2.5 miinust

Kõigi funktsioonide jaoks on vaja Enterprise Editionit (standardversioon toetab Basic AG-d oluliste piirangutega);
sünkroonse kinnitamise režiim lisab kirjutamise latentsuse proportsionaalselt võrgu edasi-tagasi ajaga;
sisselogimised, SQL-agendi tööd ja lingitud serverid vajavad käsitsi sünkroonimist SQL Server 2019 ja varem;
Kõik koopiad peavad asuma sama Windows Serveri tõrkesiirdeklastri sõlmedes.

2.6 viidet

Microsofti ametlik dokument: Mis on alati sisse lülitatud kättesaadavusrühm?
Microsofti ametlik dokument: Alustamine alati sisse lülitatud kättesaadavusgruppidega

3. Alati sisse lülitatud tõrkesiirde klastri eksemplarid

Alati sisse lülitatud tõrkesiirde klastri eksemplarid (FCI) pakub eksemplari tasemel kõrget käideldavust ühe käitamise teel SQL Server eksemplari mitmes füüsilises sõlmes, mis jagavad sama salvestusruumi. Kui aktiivne sõlm rikki läheb, siis SQL Server ooterežiimis oleval sõlmel olev eksemplar taaskäivitatakse automaatselt, muutes ülemineku kliendirakenduste jaoks läbipaistvaks.

3.1 Põhijooned

Eksemplari tasemel tõrkesiire: kõik eksemplari andmebaasid toimivad tõrkesiire kaudu ühe üksusena;
jagatud salvestusruum (Storage Area Network (SAN), iSCSI, Storage Spaces Direct või SMB), millele pääsevad ligi kõik sõlmed;
virtuaalse võrgu nimi ja virtuaalne IP-aadress pakuvad stabiilset ühenduse lõpp-punkti olenemata sellest, milline sõlm on aktiivne;
Windows Serveri tõrkesiirde klasterdamine haldab sõlme tervise jälgimist, kvoorumit ja tõrkesiirde orkestreerimist;
toetab aktiivse/ooterežiimi, aktiivse/aktiivse, N+1 ja N+M sõlme konfiguratsioonitüüpe.

3.2 Rakendusetapid

Jagatud salvestusruumi ette valmistamine ja ühendamine kõigi klastri sõlmedega;
installige tõrkesiirde klastri funktsioon ja valideerige klastri konfiguratsioon;
looge Windows Serveri tõrkesiirdeklaster ja konfigureerige kvoorum;
käivitage SQL Server installimisel valitakse tõrkesiirdeklastri suvand ning määratakse virtuaalse võrgu nimi ja jagatud salvestusradad;
lisage täiendavaid sõlmi SQL Server tõrkesiirde klastri eksemplar;
Kontrollige tõrkesiirde käitumist, testides sõlmede vahelist käsitsi tõrkesiiret.

Täieliku samm-sammult juhendi leiate meie SQL Server Failover klastri täielik juhend.

3.3 Parim valik

Keskkonnad olemasoleva jagatud salvestusinfrastruktuuriga (SAN või iSCSI);
rakendused, mis nõuavad eksemplari tasemel tõrkesiiret, kus kõik andmebaasid peavad tõrkesiirde tegema koos;
stsenaariumid, kus kliendi läbipaistvus on kriitilise tähtsusega ja rakendusepoolsed muudatused pole vastuvõetavad;
organisatsioonid, mis seavad esikohale ühe eksemplari tõrkesiirde mudeli lihtsuse.

3.4 Plussi

Automaatne tõrkesiire eksemplari tasandil ilma kliendi ümberkonfigureerimist vajamata;
andmete replikatsiooni üldkulu puudub – kõik sõlmed pääsevad juurde samale salvestusruumile;
kõigi andmebaaside samaaegne prognoositav tõrkesiirde käitumine;
toetab riistvara kasutamise optimeerimiseks paindlikke sõlmekonfiguratsioone (aktiivne/aktiivne, N+1, N+M).

3.5 miinust

Jagatud salvestusruum on potentsiaalne rikkeallikas, välja arvatud juhul, kui salvestusruum ise on varundatud;
ainult üks sõlm töötab SQL Server korraga — lugemiskoormuse tasakaalustamist teisestel sõlmedel ei toimu;
sisseehitatud katastroofidejärgset taastamist pole ilma kättesaadavusrühmaga sidumiseta;
Jagatud salvestusinfrastruktuur lisab võrreldes AG-ga kulusid ja keerukust.

3.6 viidet

Microsofti ametlik dokument: Alati sisse lülitatud tõrkesiirde klastri eksemplarid (SQL Server)

4. Kombineerige kättesaadavusrühmad tõrkesiirde klastri eksemplaridega

Organisatsioonide jaoks, mis vajavad nii eksemplari kui ka andmebaasi tasemel kaitset, SQL Server toetab kättesaadavusrühma koopiate majutamist tõrkesiirdeklastri eksemplaridel (FCI). Selles konfiguratsioonis toimib iga FCI sõlm ühe kättesaadavuskoopiana, seega on FCI tõrkesiire kättesaadavusrühma jaoks läbipaistev, samas kui AG tõrkesiire pakub andmebaasi tasemel kaitset kõigis saitides. See kombinatsioon pakub kõige ulatuslikumat kõrget kättesaadavust ja katastroofidejärgset taastamist. SQL Server.

4.1 Põhijooned

Kahekihiline tõrkesiire: FCI tegeleb eksemplari tasemel sõlme riketega; AG tegeleb saidi tasemel või replika tasemel riketega;
Iga FCI loetakse kättesaadavusrühmas üheks koopiaks olenemata sellest, mitu sõlme FCI sisaldab;
FCI-s majutatud koopiad vajavad endiselt jagatud salvestusruumi vastavalt FCI standardsetele nõuetele;
FCI-del majutatud AG-koopiad toetavad ainult käsitsi tõrkesiirde funktsiooni – automaatne tõrkesiire pole FCI-del majutatud koopiate puhul saadaval;
Eraldiseisvad eksemplarid saavad osaleda samas kättesaadavusrühmas koos FCI-s majutatud koopiatega.

4.2 Rakendusetapid

Juurutage ja valideerige iga FCI eraldi, järgides standardseid FCI seadistamise protseduure;
tagama, et kõik FCI sõlmed ja eraldiseisvad replika sõlmed kuuluvad samasse Windows Serveri tõrkesiirdeklastrisse;
lubage igal FCI eksemplaril funktsioon „Always On Availability Groups”;
kontrollige, et ükski WSFC sõlm ei majutaks pärast võimalikku FCI tõrkesiirde tekkimist sama kättesaadavusrühma kahte koopiat;
looge kättesaadavusrühm, määrates FCI eksemplarid koopiateks ja konfigureerides kõigi FCI-s hostitud koopiate jaoks käsitsi tõrkesiirde režiimi;
teiseseid koopiaid seemendada ja kättesaadavusrühma kuulaja konfigureerida.

FCI seadistamise üksikasjade kohta vaadake meie SQL Server Failover klastri täielik juhend. AG seadistamise üksikasjade saamiseks vaadake meie Always On kättesaadavusgruppide täielikku juhendit.

4.3 Parim valik

Missioonikriitilised keskkonnad, mis vajavad kaitset nii üksikute sõlmede rikete kui ka saidi tasemel katastroofide eest;
organisatsioonid, mis juba haldavad FCI-d ja vajavad saidiülest katastroofidejärgset taastamist;
reguleeritud tööstusharud, kus maksimaalse andmekaitse ja käideldavuse teenusetaseme lepingud on kohustuslikud;
suuremahulised juurutused, kus eksemplari tasemel ja andmebaasi tasemel tõrkesiirdepoliitikad peavad koos eksisteerima.

4.4 Plussi

Maksimaalne kaitse: sõlme rikkeid haldab FCI, saidi rikkeid haldab AG;
FCI tõrkesiire on kättesaadavusrühma jaoks läbipaistev – AG ei näe FCI tõrkesiire ajal koopia muutust;
Paindlik topoloogia: kasutage samas kättesaadavusrühmas nii FCI-s majutatud kui ka eraldiseisvaid koopiaid.

4.5 miinust

FCI-s majutatud koopiad toetavad ainult käsitsi AG tõrkesiirdeid – automaatne AG tõrkesiire pole nende koopiate puhul saadaval;
nõuab hoolikat WSFC sõlme planeerimist, et vältida ühe sõlme majutamist kahe sama AG koopiaga pärast FCI tõrkesiirde tekkimist;
suuremad taristukulud ja tegevusalane keerukus kui kas ainult AG-l või FCI-l;
Iga FCI komponendi jaoks on endiselt vaja jagatud salvestusruumi.

4.6 viidet

Microsofti ametlik dokument: Tõrkesiirde klasterdamine ja alati sisse lülitatud kättesaadavusrühmad (SQL Server)
Microsofti ametlik dokument: Mis on alati sisse lülitatud kättesaadavusrühm?
Microsofti ametlik dokument: Alustamine alati sisse lülitatud kättesaadavusgruppidega
Microsofti ametlik dokument: Alati sisse lülitatud tõrkesiirde klastri eksemplarid (SQL Server)

5. Always On lahenduste võrdlus

5.1 Funktsioonide võrdlustabel

tunnusjoon	Saadavusgrupid	Tõrkesümberlülitusklastri eksemplarid	AG + FCI kombineeritud
Tõrkesiirde ulatus	Andmebaasi tasemel	Eksemplari tasemel	Mõlemad
Vajalik on jagatud salvestusruum	Ei	Jah	Jah (FCI komponendi jaoks)
Andmete replikatsioon	Logipõhine iga koopia jaoks	Puudub (jagatud salvestusruum)	Logipõhine FCI-de vahel
Automaatne tõrkesiirde	Jah (sünkroonsed koopiad)	Jah	FCI: Jah; AG: Ei
Loetavad sekundaarsed väärtused	Jah	Ei	Jah (AG komponent)
Katastroofiabi	Sisseehitatud	Ei ole sisseehitatud	Sisseehitatud
Maksimaalne koopiate arv	9 (ettevõte)	N / A	9 (ettevõte)
Infrastruktuuri keerukus	Keskmine	Keskmine	Kõrge
Maksma	Madalam (SAN-i pole vaja)	Kõrgem (nõutav SAN)	Suurim

5.2 Valige endale alati saadaval olev lahendus

Alustage oma salvestusinfrastruktuurist: kui teil pole olemasolevat jagatud salvestusruumi, on kättesaadavusrühmad loomulik valik ja kõige kulutõhusam viis nii HA kui ka DR jaoks. Kui teil on juba SAN-keskkond ja vajate eksemplari tasemel tõrkesiiret, on FCI lihtsam variant – aga planeerige AG lisamist hiljem, kui saidiülene DR on tulevikus nõutav.

Valige AG + FCI kombinatsioon ainult siis, kui teil on tõeline vajadus mõlema kaitsekihi järele ja suurenenud keerukuse haldamiseks on olemas operatiivne küpsus. Peamine piirang, mida meeles pidada, on see, et FCI-s majutatud AG koopiad ei toeta automaatset AG tõrkesiirdet, seega nõuab see topoloogia kättesaadavusrühma tasemel tõrkesiirde jaoks käsitsi sekkumist.

Enamiku tänapäeval uute juurutuste puhul on soovitatav alguspunkt Always On Availability Groups: see hõlmab nii HA-d kui ka DR-i, ei vaja jagatud salvestusruumi ja toetab loetavaid teiseseid ressursse – võimalusi, millele FCI üksi ei suuda vastu astuda.

6. Parimad tavad SQL Server Alati lahendused

6.1 Planeerimine ja projekteerimine

Enne alati sisselülitatud lahenduse valimist määrake RTO ja RPO nõuded – need eesmärgid määravad otseselt, kas sünkroonne või asünkroonne kinnitusrežiim on sobiv ja kas automaatne tõrkesiire on teostatav.
Teiseste koopiate suurust saab kohandada nii, et need suudaksid tõrkesiirde ajal (sh tippkoormuse korral) täielikult esmase töökoormusega hakkama saada.
AG juurutuste puhul paiguta sünkroonsed koopiad samasse andmekeskusesse või madala latentsusega võrku, et minimeerida kirjutamise latentsuse mõju. Reserveeri asünkroonne režiim geograafiliselt kaugete DR-koopiate jaoks.
Kujundage kvoorum paaritu arvu häältega. Kahe sõlmega klastrite puhul lisage kolmanda häälena failide jagamine või pilvetunnistaja, et vältida aju lõhenemise stsenaariume.
Planeeri oma võrgu topoloogiat mitme alamvõrgu juurutuste korral hoolikalt. Igal alamvõrgul on vaja oma kuulaja IP-aadressi ja klientide ühendusstringides peab olema MultiSubnetFailover=True.

6.2 Rakendusjuhised

Kasutage järjepidevat SQL Server versiooni, väljaande ja kumulatiivsete värskenduste tasemed kõigis koopiates. Erinevad plaastrite tasemed võivad tõrkesiirde ajal põhjustada ootamatut käitumist.
Konfigureerige klastri südamelöökide liikluse jaoks spetsiaalsed võrguliidesed, mis on rakenduste liiklusest eraldi.
Luba automaatne külv esialgse andmebaasi sünkroonimise jaoks SQL Server 2016 ja hilisemad versioonid – see välistab enamiku stsenaariumide korral vajaduse varukoopiaid käsitsi teisestesse koopiatesse kopeerida.
AG + FCI topoloogiate puhul kontrollige pärast iga FCI sõlme konfiguratsiooni muutmist, et ükski WSFC sõlm ei saaks lõpuks majutada sama kättesaadavusrühma kahte koopiat.
Kasutage alati SQL Server Management Studio või Transact-SQL kättesaadavusrühma tõrkesiirde haldamiseks – ärge kunagi kasutage tõrkeklastri haldurit otse, kuna see ei ole teadlik AG sünkroonimise olekust ja võib põhjustada pikemat seisakut või andmete kadu.

6.3 Järelevalve ja hooldus

Jälgige sünkroonimise tervist, saatke järjekorda ja tehke järjekorda regulaarselt uuesti, kasutades kättesaadavusrühma armatuurlauda jaotises SQL Server Management Studio või dünaamilised haldusvaated (DMV-d). Kasvav uuestitegemise järjekord teisesel võrgul näitab sisend-/väljundpudelikaelat, mis viivitab tõrkesiirde taastamisega.
Käivitage DBCC CHECKDB teiseste koopiate peal, et vabastada terviklikkuse kontrollid primaarsetelt koopiatelt. Vaadake meie DBCC CHECKDB juhend üksikasjad.
kehtima SQL Server Parandused jooksvate uuenduste abil: paranda esmalt sekundaarsed koopiad, teosta plaaniline käsitsi tõrkesiire parandatud sekundaarsele koopiale ja seejärel paranda endine primaarne koopia. See piirab seisakuaega ühe tõrkesiire kestusega.
Testi regulaarselt tõrkesiirde funktsiooni mittetootmiskeskkondades. Automaatne tõrkesiire, mida pole kunagi testitud, ei ole usaldusväärne taastamisstrateegia.
Konfigureerige kättesaadavusrühma terviseseisundi muutuste, replikarolli üleminekute ja sünkroonimistõrgete märguandeid, kasutades järgmist: SQL Server Agent või spetsiaalne jälgimisvahend, näiteks SQL Server Performance Monitor.

7. KKK-d

K: Mis on SQL Server Alati sees?

A: SQL Server Always On on Microsofti kõrge kättesaadavuse ja katastroofide taastamise platvorm, mis võeti kasutusele 2013. aastal. SQL Server 2012. See hõlmab kahte tehnoloogiat – alati sisse lülitatud kättesaadavusrühmi ja alati sisse lülitatud tõrkesiirdeklastri eksemplare –, mis pakuvad automaatset tõrkesiirde, andmete koondamist ja pidevat juurdepääsu andmebaasidele riist-, tarkvara- või saidirikete korral.

K: Mis vahe on alati sisse lülitatud kättesaadavusgruppidel ja tõrkesiirdeklastri eksemplaridel?

A: Kättesaadavusrühmad (FAILOBUS) toimivad andmebaasi tasandil, replikeerivad andmeid sõltumatutesse sekundaarsetesse koopiatesse logide saatmise kaudu ega vaja jagatud salvestusruumi. Tõrkesirdeklastri eksemplarid toimivad eksemplari tasandil, vajavad jagatud salvestusruumi, millele pääsevad ligi kõik sõlmed, ja toimivad tõrkesiirde korras kõigis andmebaasides koos üksusena. AG toetab loetavaid sekundaarseid koopiaid ja sisseehitatud DR-i; FCI mitte.

K: Kas mul on alati sisse lülitatud kättesaadavusrühmade jaoks vaja jagatud salvestusruumi?

V: Ei. Iga AG-koopia haldab oma andmebaaside iseseisvat koopiat kohalikus salvestusruumis. Jagatud salvestusruumi on vaja ainult siis, kui kasutate AG-koopiate majutamiseks tõrkesiirdeklastri eksemplare.

K: Kas ma saan funktsiooni „Always On” kasutada koos SQL Server Standardväljaanne?

A: SQL Server Standardversioon toetab põhilisi kättesaadavusgruppe, mis algavad SQL Server 2016, kuid oluliste piirangutega: üks andmebaas AG kohta, maksimaalselt kaks koopiat ja loetava teisese toe puudumine. FCI on standardväljaandes saadaval ilma nende piiranguteta. Täieliku Always On funktsionaalsuse jaoks on vaja Enterprise Editionit.

K: Milline on kättesaadavusrühmas olevate koopiate maksimaalne arv?

A: SQL Server Enterprise Edition toetab kuni üheksat koopiat: ühte primaarset ja kaheksat sekundaarset koopiat. Hajutatud kättesaadavusrühmad saavad seda laiendada 18 koopiani kahes eraldi kättesaadavusrühmas.

K: Kas FCI-s majutatud koopiad saavad kasutada automaatset AG tõrkesiirde funktsiooni?

V: Ei. Kui kättesaadavuskoopia on majutatud tõrkesiirdeklastri eksemplaril, siis automaatset kättesaadavusrühma tõrkesiirdeid selle koopia jaoks ei toetata. Kõik FCI-s majutatud koopiaid hõlmavad AG tõrkesiirded vajavad käsitsi sekkumist.

K: Mis vahe on sünkroonsetel ja asünkroonsetel kinnitusrežiimidel?

A: Sünkroonse kinnitamise režiim nõuab, et primaarvõrk ootaks enne kinnitamist, kuni sekundaarvõrk logikirjed tugevdab, tagades nullandmete kadumise (RPO = 0) lisandunud kirjutamislatentsuse hinnaga. Asünkroonse kinnitamise režiim võimaldab primaarvõrgul kinnitada ilma ootamata, vähendades latentsust, kuid riskides andmete kaoga, kui primaarvõrk rikki läheb enne, kui sekundaarvõrk kõik logikirjed kätte saab. Kasutage sünkroonset režiimi kohalike HA koopiate ja asünkroonset režiimi kaugete DR koopiate jaoks.

K: Kui kaua kestab SQL Server Alati sees tõrkesiire?

A: Sünkroonse AG-koopia automaatne tõrkesiire toimub tavatingimustes tavaliselt alla 30 sekundiga. FCI tõrkesiire võtab tavaliselt aega 20–60 sekundit, olenevalt andmebaasi taastamisajast. Tegelik kestus sõltub töökoormusest, andmebaasi suurusest ja WSFC-s konfigureeritud tervisekontrolli ajalõpu sätetest.

K: Mis juhtub kliendiühendustega tõrkesiirde ajal?

A: Olemasolevad ühendused katkestatakse tõrkesiirde korral. Rakendused, mis kasutavad kättesaadavusrühma kuulajat ja sisaldavad ühenduse uuesti proovimise loogikat, ühenduvad pärast tõrkesiirde lõppemist automaatselt uue primaarvõrguga. Ühendusstringidele väärtuse MultiSubnetFailover=True lisamine parandab taasühendamise kiirust mitme alamvõrgu juurutustes.

K: Kuidas kandideerida SQL Server plaastrid minimaalse seisakuajaga alati sisse lülitatud keskkonnas?

A: Kasutage jooksvaid uuendusi: parandage esmalt sekundaarsed koopiad, seejärel tehke plaaniline käsitsi üleminek parandatud sekundaarsele koopiale ja lõpuks parandage endine primaarne koopia. See piirab seisakuaega ühe plaanitud ülemineku kestusega – tavaliselt alla minuti.

K: Kas ma saan alati sisse lülitatud kättesaadavusrühmi kombineerida tõrkesiirdeklastri eksemplaridega?

V: Jah. AG-koopiaid saab majutada FCI eksemplarides, et tagada nii eksemplari kui ka andmebaasi tasemel tõrkesiirde kaitse. Iga FCI loetakse üheks AG-koopiaks. See topoloogia nõuab hoolikat WSFC-sõlmede planeerimist, et tagada, et ükski sõlm ei majutaks pärast võimalikku FCI tõrkesiirde kaitset sama AG kahte koopiat.

K: Mida peaksin tegema, kui minu andmebaas rikutakse alati sisse lülitatud keskkonnas?

A: Kõigepealt kontrollige, kas riknemine esineb kõigil koopiatel või ainult primaarsel koopial. Kui on olemas terve sekundaarne koopia, tehke sellele kohe üleminek. Kui kõik koopiad on rikutud, taastage andmed puhtast varukoopiast. Käivitage sekundaarsetel koopiatel regulaarselt DBCC CHECKDB, et riknemine varakult avastada. Kui ka varukoopiad on mõjutatud, siis spetsiaalne SQL Server andmete taastamise tööriist viimase abinõuna võib proovida kahjustatud MDF-failidest andmeid hankida.

K: Kuidas Always On kättesaadavusrühmad vanematega võrreldes toimivad? SQL Server HA lahendused?

A: AG asendab vanemaid tehnoloogiaid, näiteks palkide saatmine ja replikatsioonLogide saatmine nõuab käsitsi tõrkesiirde tegemist ja automaatset rollide üleminekut ei toimu; replikatsioon on loodud andmete levitamiseks, mitte HA jaoks. AG pakub automaatset tõrkesiirdet, nullandmete kadu sünkroonse kinnitusega ja loetavaid teiseseid logisid – võimalusi, millega need tehnoloogiad ei suuda võistelda.

8. järeldus

SQL Server Always On pakub paindlikku ja ettevõttetasemel platvormi kõrge käideldavuse ja katastroofidejärgse taastamise jaoks. Always On kättesaadavusrühmad on õige valik enamiku tänapäevaste juurutuste jaoks: see välistab jagatud salvestusruumi vajaduse, toetab loetavaid teiseseid ressursse ning käsitleb nii kohalikku HA-d kui ka saidiülest DR-i ühes konfiguratsioonis. Tõrkesiirdeklastri eksemplarid jäävad kindlaks valikuks, kui esmased nõuded on eksemplari tasemel tõrkesiire ja olemasolev jagatud salvestustaristu. Mõlema tehnoloogia kombineerimine pakub sügavaimat saadaolevat kaitset – suuremate taristuinvesteeringute ja tegevuse keerukuse hinnaga.

Olenemata sellest, millise lahenduse valite, on põhitõed samad: kõigepealt määrake oma RTO ja RPO nõuded, kujundage oma topoloogia nende eesmärkide ümber ja testige regulaarselt tõrkesiirde funktsiooni. Hästi rakendatud ja põhjalikult testitud Always On lahendus taastub tootmistõrgete korral prognoositavalt.

Teave Autor

Yuan Sheng on vanem andmebaasiadministraator (DBA), kellel on üle 10 aasta kogemust SQL Server keskkonnad ja ettevõtte andmebaaside haldus. Ta on edukalt lahendanud sadu andmebaaside taastamise stsenaariume finantsteenuste, tervishoiu ja tootmisorganisatsioonides.

Yuan on spetsialiseerunud SQL Server andmebaaside taastamine, kõrge käideldavuslahendused ja jõudluse optimeerimine. Tema ulatuslik praktiline kogemus hõlmab mitme terabaidiste andmebaaside haldamist, alati sisse lülitatud käideldavusgruppide rakendamist ning automatiseeritud varundus- ja taastestrateegiate väljatöötamist missioonikriitiliste ärisüsteemide jaoks.

Oma tehnilise asjatundlikkuse ja praktilise lähenemise abil keskendub Yuan terviklike juhendite loomisele, mis aitavad andmebaasiadministraatoritel ja IT-spetsialistidel lahendada keerulisi probleeme SQL Server väljakutseid tõhusalt. Ta on kursis uusimate uudistega SQL Server väljalasete ja Microsofti arenevate andmebaasitehnoloogiate põhjal, testides regulaarselt taastestsenaariume, et tagada oma soovituste vastavus reaalsetele parimatele tavadele.

Kas teil on küsimusi SQL Server taastamist või vajate täiendavat andmebaasi tõrkeotsingu juhendamist? Yuan tervitab tagasisidet ja ettepanekuid nende tehniliste ressursside täiustamiseks.