SQL Server Vedno vključeno: Popoln vodnik za administratorje [2026]

SQL Server Always On je Microsoftova celovita rešitev za visoko razpoložljivost in obnovo po katastrofi, predstavljena z SQL Server 2012. Predstavlja pomemben napredek v primerjavi s prejšnjimi tehnologijami, kot sta zrcaljenje baz podatkov in pošiljanje dnevnikov, saj zagotavlja neprekinjen dostop do podatkov, hkrati pa zmanjšuje izpade in izgubo podatkov.

1.2 Zakaj podjetja potrebujejo vedno dostopne rešitve

V današnjem digitalnem gospodarstvu izpadi podatkovnih baz neposredno pomenijo izgubo prihodka, poškodovan ugled in težave s skladnostjo s predpisi. Organizacije potrebujejo visoko razpoložljive rešitve, ki lahko zagotovijo skoraj neprekinjeno delovanje in hkrati ščitijo pred različnimi scenariji napak.

Tradicionalni postopki varnostnega kopiranja in obnavljanja ne zadostujejo za sodobne poslovne zahteve. Ko kritična baza podatkov odpove, si podjetja ne morejo privoščiti ur, potrebnih za obnovitev iz varnostnih kopij. Rešitve Always On zagotavljajo avtomatizirano preklopno delovanje, ki lahko obnovi storitev v nekaj sekundah ali minutah namesto v urah, kar drastično zmanjša vpliv sistemskih napak.

Poleg osnovne razpoložljivosti morajo podjetja razbremeniti produkcijske baze podatkov z intenzivnim branjem, izvajati vzdrževanje brez izpadov in se zaščititi pred katastrofami na ravni lokacije. SQL Server Always On obravnava vse te zahteve z enotno arhitekturo, ki se prilagaja od majhnih uvedb do globalno porazdeljenih sistemov.

1.3 Ključni koncepti: RTO, RPO, HA in DR

Ciljni čas okrevanja (RTO) določa najdaljše sprejemljivo trajanje izpada po napaki – kako hitro se mora baza podatkov ponovno vzpostaviti.

Ciljna točka obnovitve (RPO) določa največjo sprejemljivo izgubo podatkov, merjeno v času – koliko nedavno odobrenih podatkov si podjetje lahko privošči izgubiti.

Visoka razpoložljivost (HA) osredotoča se na zmanjšanje izpadov, ki jih povzročajo rutinske napake, kot so okvare strojne opreme ali zrušitve programske opreme znotraj istega podatkovnega centra.

Obnovitev po katastrofi (DR) obravnava katastrofalne dogodke, ki prizadenejo celotne lokacije, in vzdržuje kopije podatkov na geografsko ločenih lokacijah. Medtem ko se visoka razpoložljivost osredotoča na zmanjšanje izpadov, se DR osredotoča na zagotavljanje zaščite podatkov in neprekinjenega poslovanja med večjimi incidenti.

SQL Server Always On podpira tako HA kot DR znotraj ene same poenotene arhitekture. Sinhroni način potrjevanja zagotavlja RPO = 0 z avtomatskim preklopom v primeru okvare za skoraj ničelni RTO; asinhroni način potrjevanja sprejema morebitno izgubo podatkov v zameno za manjši vpliv zakasnitve na oddaljenih lokacijah.

1.4 Rešitve, ki so vedno na voljo

SQL Server Always On ponuja tri možnosti uvajanja, od katerih je vsaka primerna za različne zahteve glede razpoložljivosti in infrastrukture. Ta priročnik zajema vse tri:

Skupine razpoložljivosti Always On (AG): Visoka razpoložljivost in obnova po katastrofi na ravni baze podatkov brez skupnega prostora za shranjevanje.
Vedno vklopljeni primerki gruče za preklop ob okvari (FCI): Visoka razpoložljivost na ravni instance z uporabo skupnega prostora za shranjevanje.
AG + FCI skupaj: Dvoslojna zaščita, ki združuje preklop na ravni instance in baze podatkov za maksimalno odpornost.

2. Skupine razpoložljivosti Always On

Skupine razpoložljivosti Always On (AG) je rešitev za visoko razpoložljivost in obnovo po katastrofi na ravni baze podatkov, ki replicira nabor uporabniških baz podatkov na do osem sekundarnih replik prek neprekinjenega pošiljanja dnevnika transakcij.

2.1 Ključne lastnosti

Preklop na ravni baze podatkov: posamezne baze podatkov ali skupine se lahko preklopijo neodvisno od SQL Server primerek;
do devet replik (ena primarna, osem sekundarnih) v izdaji Enterprise Edition;
sinhroni način potrjevanja za ničelno izgubo podatkov; asinhroni način potrjevanja za oddaljene replike DR;
samodejni preklop sinhronih replik, ko primarni strežnik ni na voljo;
berljive sekundarne replike za razbremenitev delovnih obremenitev poročanja in varnostnega kopiranja;
Poslušalnik skupine razpoložljivosti zagotavlja eno samo končno točko povezave, ki samodejno usmerja do trenutne primarne točke.

2.2 Izvedbeni koraki

Priprava računov storitve Active Directory in konfiguracija dovoljenj na vseh vozliščih;
namestite in preverite gruče za preklop sistema Windows Server na vseh sodelujočih strežnikih;
namestitev SQL Server kot samostojen primerek na vsakem vozlišču z uporabo doslednih poti in nastavitev;
omogočite funkcijo »Vedno vklopljene skupine razpoložljivosti« prek SQL Server Upravitelj konfiguracije ali PowerShell;
nastavite baze podatkov na model popolnega obnovitve in naredite popolne in dnevnikovne varnostne kopije;
ustvarite skupino razpoložljivosti, dodajte replike in konfigurirajte načine razpoložljivosti in preklopa ob okvari;
ustvarite sekundarne replike z uporabo samodejnega sejanja ali ročnega varnostnega kopiranja in obnovitve;
ustvarite poslušalnik skupine razpoložljivosti in preverite povezljivost odjemalca.

Za celoten postopek po korakih si oglejte naš Celoten vodnik za skupine razpoložljivosti Always On.

2.3 Najboljše za

Kritične podatkovne baze, ki ne zahtevajo izgube podatkov in samodejnega preklopa na drugo operacijo;
delovne obremenitve, ki potrebujejo berljive sekundarne datoteke za poročanje ali razbremenitev varnostnih kopij;
uvedbe, ki zajemajo več lokacij za obnovo po katastrofi;
okoljih brez obstoječe infrastrukture za skupno shranjevanje.

2.4 prednosti

Ni potrebe po skupnem pomnilniku – vsaka replika uporablja neodvisen lokalni pomnilnik;
podpira tako HA kot DR v eni sami konfiguraciji;
berljive sekundarne vsebine zmanjšujejo delovno obremenitev primarnih vsebin;
Granularnost na ravni baze podatkov omogoča različne politike preklopa na rezervno delovanje za vsako skupino baz podatkov.

2.5 slabosti

Za celoten nabor funkcij je potrebna izdaja Enterprise Edition (Standard podpira Basic AG z znatnimi omejitvami);
sinhroni način potrjevanja doda zakasnitev pisanja sorazmerno s časom povratnega prenosa v omrežju;
prijave, opravila agenta SQL in povezani strežniki zahtevajo ročno sinhronizacijo v SQL Server 2019 in prej;
Vse replike morajo biti na vozliščih iste gruče za preklop v primeru okvare sistema Windows Server.

2.6 Reference

Uradni dokument Microsofta: Kaj je skupina razpoložljivosti »Vedno vklopljeno«?
Uradni dokument Microsofta: Uvod v skupine razpoložljivosti Always On

3. Primerki grozda Always On Failover

Vedno vklopljeni primerki gruče za preklop ob okvari (FCI) zagotavlja visoko razpoložljivost na ravni instance z izvajanjem enega samega SQL Server primerek na več fizičnih vozliščih, ki si delijo isto shrambo. Ko aktivno vozlišče odpove, SQL Server Primerek na vozlišču v pripravljenosti se samodejno znova zažene, zaradi česar je prehod pregleden za odjemalske aplikacije.

3.1 Ključne lastnosti

Preklop na ravni instance: vse baze podatkov v instanci se preklopijo skupaj kot ena enota;
skupno shranjevanje (omrežje za shranjevanje podatkov (SAN), iSCSI, Storage Spaces Direct ali SMB), do katerega lahko dostopajo vsa vozlišča;
ime virtualnega omrežja in virtualni naslov IP zagotavljata stabilno končno točko povezave ne glede na to, katero vozlišče je aktivno;
Združevanje v gruče za preklop sistema Windows Server upravlja spremljanje zdravja vozlišč, kvorum in orkestracijo preklopa;
podpira konfiguracijske tipe vozlišč Aktivno/V stanju pripravljenosti, Aktivno/Aktivno, N+1 in N+M.

3.2 Izvedbeni koraki

Zagotovite in priključite skupno shrambo vsem vozliščem gruče;
namestite funkcijo preklopnega gručenja ob okvari in preverite konfiguracijo gruče;
ustvarite gručo za preklop sistema Windows Server ob okvari in konfigurirajte kvorum;
zaženite SQL Server namestitev z izbiro možnosti gruče za preklop v primeru okvare in določitvijo imena virtualnega omrežja ter poti za skupno shranjevanje;
dodajte dodatna vozlišča SQL Server primerek grozda za preklop ob okvari;
Preverite delovanje preklopa ob okvari s testiranjem ročnega preklopa med vozlišči.

Za celoten postopek po korakih si oglejte naš SQL Server Celoten vodnik za gručo za preklop ob okvari.

3.3 Najboljše za

Okolja z obstoječo infrastrukturo za skupno shranjevanje (SAN ali iSCSI);
aplikacije, ki zahtevajo preklop na ravni instance, kjer morajo vse baze podatkov preklopiti hkrati;
scenariji, kjer je preglednost odjemalca ključnega pomena in spremembe na strani aplikacije niso sprejemljive;
organizacije, ki dajejo prednost preprostosti modela preklopa na en sam primerek.

3.4 prednosti

Samodejni preklop na ravni instance brez potrebe po ponovni konfiguraciji odjemalca;
brez režijskih stroškov podvajanja podatkov – vsa vozlišča dostopajo do istega pomnilnika;
predvidljivo vedenje pri preklopu na drugo bazo podatkov hkrati;
podpira prilagodljive konfiguracije vozlišč (Aktivno/Aktivno, N+1, N+M) za optimizacijo izkoriščenosti strojne opreme.

3.5 slabosti

Skupno shranjevanje je potencialna enotna točka odpovedi, razen če je samo shranjevanje odveč;
deluje samo eno vozlišče SQL Server hkrati – brez uravnoteženja bralne obremenitve na sekundarnih vozliščih;
brez vgrajenega okrevanja po katastrofi brez seznanjanja s skupino razpoložljivosti;
Infrastruktura za skupno shranjevanje v primerjavi z AG povečuje stroške in kompleksnost.

3.6 Reference

Uradni dokument Microsofta: Vedno vklopljeni primerki gruče za preklop ob okvari (SQL Server)

4. Združite skupine razpoložljivosti s primerki grozdov za preklop v primeru okvare

Za organizacije, ki potrebujejo zaščito tako na ravni instance kot na ravni baze podatkov, SQL Server podpira gostovanje replik skupin razpoložljivosti na primerkih gruče za preklop ob okvari (FCI). V tej konfiguraciji vsako vozlišče FCI deluje kot ena sama replika razpoložljivosti, zato je preklop FCI transparenten za skupino razpoložljivosti, medtem ko preklop AG zagotavlja zaščito na ravni baze podatkov na vseh lokacijah. Ta kombinacija zagotavlja najobsežnejšo pokritost z visoko razpoložljivostjo in obnovitvijo po katastrofi, ki je na voljo v SQL Server.

4.1 Ključne lastnosti

Dvoslojni preklop ob okvari: FCI obravnava napake vozlišč na ravni instance; AG obravnava napake na ravni spletnega mesta ali replike;
Vsak FCI se šteje kot ena sama replika znotraj skupine razpoložljivosti, ne glede na to, koliko vozlišč FCI vsebuje;
Replike, ki jih gosti FCI, še vedno zahtevajo skupno shranjevanje v skladu s standardnimi zahtevami FCI;
Replike AG, ki gostujejo na FCI-jih, podpirajo samo ročni preklop – samodejni preklop ni na voljo za replike, ki gostujejo na FCI-jih;
Samostojni primerki lahko sodelujejo v isti skupini razpoložljivosti skupaj z replikami, ki jih gosti FCI.

4.2 Izvedbeni koraki

Vsak FCI namestite in potrdite neodvisno po standardnih postopkih nastavitve FCI;
zagotovite, da vsa vozlišča FCI in samostojna replikacijska vozlišča pripadajo isti gruči za preklop sistema Windows Server;
omogočite funkcijo skupin razpoložljivosti »Vedno vklopljeno« v vsakem primerku FCI;
preverite, da nobeno posamezno vozlišče WSFC ne bi gostilo dveh replik iste skupine razpoložljivosti po morebitnem preklopu FCI ob okvari;
ustvarite skupino razpoložljivosti, označite primerke FCI kot replike in konfigurirajte ročni način preklopa za vse replike, ki jih gosti FCI;
ustvarite sekundarne replike in konfigurirajte poslušalnik skupine razpoložljivosti.

Za podrobnosti o nastavitvi FCI glejte našo SQL Server Celoten vodnik za gručo za preklop ob okvari. Za podrobnosti o nastavitvi skupine razpoložljivosti glejte naš celoten vodnik za skupine razpoložljivosti Always On.

4.3 Najboljše za

Kritična okolja, ki zahtevajo zaščito tako pred okvarami posameznih vozlišč kot pred nesrečami na ravni lokacije;
organizacije, ki že izvajajo FCI in morajo dodati obnovo po katastrofi med lokacijami;
regulirane panoge, kjer so obvezne pogodbe o ravni storitev za maksimalno varstvo podatkov in razpoložljivost;
obsežne uvedbe, kjer morajo sočasno obstajati pravilniki za preklop na ravni instance in baze podatkov.

4.4 prednosti

Največja zaščita: okvare vozlišč obravnava FCI, okvare lokacije pa AG;
Preklop FCI ob okvari je transparenten za skupino za razpoložljivost – AG med preklopom FCI ne vidi nobene spremembe replike;
prilagodljiva topologija: v isti skupini razpoložljivosti lahko združite replike, ki jih gosti FCI, in samostojne replike.

4.5 slabosti

Replike, ki jih gosti FCI, podpirajo samo ročni preklop AG – samodejni preklop AG za te replike ni na voljo;
zahteva skrbno načrtovanje vozlišč WSFC, da se prepreči, da bi eno vozlišče po preklopu FCI gostilo dve repliki iste AG;
višji stroški infrastrukture in operativna kompleksnost kot pri samem AG ali FCI;
Za vsako komponento FCI je še vedno potrebno skupno shranjevanje.

4.6 Reference

Uradni dokument Microsofta: Grupiranje ob okvari in skupine razpoložljivosti Always On (SQL Server)
Uradni dokument Microsofta: Kaj je skupina razpoložljivosti »Vedno vklopljeno«?
Uradni dokument Microsofta: Uvod v skupine razpoložljivosti Always On
Uradni dokument Microsofta: Vedno vklopljeni primerki gruče za preklop ob okvari (SQL Server)

5. Primerjava rešitev Always On

5.1 Tabela primerjave funkcij

Feature	Skupine razpoložljivosti	Primerki grozdov za preklop ob okvari	Kombinacija AG + FCI
Obseg preklopa ob okvari	Na ravni baze podatkov	Na ravni primerka	oba
Zahtevana skupna shramba	Ne	Da	Da (za komponento FCI)
Podvajanje podatkov	Na podlagi dnevnika za vsako repliko	Brez (skupni pomnilnik)	Na podlagi dnevnikov med FCI
Samodejni preklop	Da (sinhrone replike)	Da	FCI: Da; AG: Ne
Berljive sekundarne vsebine	Da	Ne	Da (AG komponenta)
Obnovitev po nesreči	Vgrajen	Ni vgrajeno	Vgrajen
Največje število replik	9 (Podjetje)	N / A	9 (Podjetje)
Kompleksnost infrastrukture	srednje	srednje	visoka
Strošek	Nižje (SAN ni potreben)	Višja (zahteva se SAN)	Najvišji

5.2 Izberite svojo rešitev »Vedno na voljo«

Začnite z infrastrukturo za shranjevanje: če nimate obstoječega skupnega prostora za shranjevanje, so skupine razpoložljivosti naravna izbira in stroškovno najučinkovitejša pot do visoke razpoložljivosti (HA) in podeželskega vzdrževanja (DR). Če že upravljate okolje SAN in potrebujete preklop na ravni instance, je FCI enostavnejša možnost – vendar načrtujte poznejše dodajanje skupine razpoložljivosti, če bo DR na več lokacijah potreben v prihodnosti.

Kombinacijo AG + FCI izberite le, če resnično potrebujete obe plasti zaščite in operativno zrelost za obvladovanje povečane kompleksnosti. Ključna omejitev, ki si jo je treba zapomniti, je, da replike AG, ki jih gosti FCI, ne podpirajo samodejnega preklopa AG, zato ta topologija zahteva ročno posredovanje za preklope na ravni skupine razpoložljivosti.

Za večino današnjih uvedb na novo zasnovanih lokacijah so priporočene izhodiščne točke skupine razpoložljivosti Always On: zajemajo tako visoko dostopnost kot tudi zdrsnjevanje po nesreči, ne zahtevajo skupnega prostora za shranjevanje in podpirajo berljive sekundarne strežnike – zmogljivosti, ki se jim FCI sam ne more kosati.

6. Najboljše prakse za SQL Server Vedno na voljo rešitve

6.1 Načrtovanje in oblikovanje

Preden izberete rešitev Always On, določite zahteve glede časa delovanja (RTO) in razpoložljivosti (RPO) – ti cilji neposredno določajo, ali je primeren sinhroni ali asinhroni način potrjevanja in ali je izvedljiv samodejni preklop ob okvari.
Velikost sekundarnih replik se prilagodi za obvladovanje celotne primarne delovne obremenitve med dogodkom preklopa ob okvari, vključno s scenariji največje obremenitve.
Za uvedbe AG postavite sinhrone replike znotraj istega podatkovnega centra ali omrežja z nizko zakasnitvijo, da zmanjšate vpliv zakasnitve pisanja. Asinhroni način rezervirajte za geografsko oddaljene replike DR.
Kvorum zasnujte z lihim številom glasov. Za gruče z dvema vozliščema dodajte skupno rabo datotek ali pričo v oblaku kot tretji glas, da preprečite scenarije razcepljenega delovanja.
Za uvedbo z več podomrežji skrbno načrtujte omrežno topologijo. Vsako podomrežje zahteva svoj IP-naslov poslušalca, odjemalci pa morajo v svojih povezovalnih nizih imeti nastavljeno vrednost MultiSubnetFailover=True.

6.2 Smernice za izvajanje

Uporabljajte dosledno SQL Server ravni različice, izdaje in kumulativne posodobitve v vseh replikah. Mešane ravni popravkov lahko povzročijo nepričakovano vedenje med preklopom ob okvari.
Konfigurirajte namenske omrežne vmesnike za promet srčnega utripa gruče, ločeno od prometa aplikacij.
Omogoči samodejno sejanje za začetno sinhronizacijo baze podatkov v SQL Server 2016 in novejše različice – v večini scenarijev odpravlja potrebo po ročnem kopiranju varnostnih kopij v sekundarne replike.
Pri topologijah AG + FCI po vsaki spremembi konfiguracije vozlišča FCI preverite, da nobeno posamezno vozlišče WSFC ne more gostiti dveh replik iste skupine razpoložljivosti.
Vedno uporabljajte SQL Server Management Studio ali Transact-SQL za upravljanje preklopov skupin razpoložljivosti – nikoli ne uporabljajte neposredno programa Failover Cluster Manager, saj se ne zaveda stanja sinhronizacije skupine razpoložljivosti in lahko povzroči daljši izpad ali izgubo podatkov.

6.3 Nadzor in vzdrževanje

Redno spremljajte stanje sinhronizacije, čakalno vrsto za pošiljanje in čakalno vrsto za ponovitev z nadzorno ploščo skupine razpoložljivosti v SQL Server Management Studio ali dinamični pogledi za upravljanje (DMV). Naraščajoča čakalna vrsta za ponovitev na sekundarnem strežniku kaže na ozko grlo V/I, ki bo odložilo obnovitev po izpadu.
Za prenos preverjanj integritete s primarne replike na sekundarne replike zaženite ukaz DBCC CHECKDB. Glejte naše Vodnik za DBCC CHECKDB za podrobnosti.
Uporabi SQL Server Popravki z uporabo tekočih nadgradenj: najprej popravite sekundarne replike, izvedite načrtovani ročni preklop na popravljeno sekundarno različico in nato popravite prejšnjo primarno različico. To omeji čas izpada na trajanje enega samega preklopa.
Redno preizkušajte preklop v primeru okvare v neprodukcijskih okoljih. Samodejni preklop v primeru okvare, ki še ni bil preizkušen, ni zanesljiva strategija obnovitve.
Konfigurirajte opozorila za spremembe stanja skupine razpoložljivosti, prehode vlog replik in napake sinhronizacije z uporabo SQL Server Agent ali namensko orodje za spremljanje, kot je SQL Server Performance Monitor.

7. Pogosta vprašanja

V: Kaj je SQL Server Vedno vklopljeno?

A: SQL Server Always On je Microsoftova platforma za visoko razpoložljivost in obnovo po nesrečah, predstavljena leta SQL Server 2012. Zajema dve tehnologiji – skupine razpoložljivosti Always On in primerke gruče Always On Failover – ki zagotavljata avtomatiziran preklop ob okvari, redundanco podatkov in neprekinjen dostop do baz podatkov v primeru okvar strojne ali programske opreme ali spletnega mesta.

V: Kakšna je razlika med skupinami razpoložljivosti Always On in primerki grozdov Failover?

A: Skupine razpoložljivosti delujejo na ravni baze podatkov, replicirajo podatke v neodvisne sekundarne replike prek pošiljanja dnevnikov in ne potrebujejo skupnega prostora za shranjevanje. Primerki gruče za preklop v primeru okvare delujejo na ravni primerka, zahtevajo skupni prostor za shranjevanje, do katerega lahko dostopajo vsa vozlišča, in preklopijo vse baze podatkov skupaj kot enoto. AG podpira berljive sekundarne datoteke in vgrajeno DR; FCI pa ne.

V: Ali potrebujem skupno shrambo za skupine razpoložljivosti Always On?

O: Ne. Vsaka replika AG vzdržuje svojo neodvisno kopijo baz podatkov v lokalnem pomnilniku. Skupni pomnilnik je potreben le, če za gostovanje replik AG uporabljate primerke gruče Failover.

V: Ali lahko uporabljam funkcijo Vedno vklopljeno z SQL Server Standardna izdaja?

A: SQL Server Standardna izdaja podpira osnovne skupine razpoložljivosti, začenši z SQL Server 2016, vendar z znatnimi omejitvami: ena baza podatkov na AG, največ dve repliki in brez berljive sekundarne podpore. FCI je na voljo v standardni izdaji brez teh omejitev. Za polno funkcionalnost Always On je potrebna izdaja Enterprise.

V: Koliko je največje število replik v skupini razpoložljivosti?

A: SQL Server Izdaja Enterprise Edition podpira do devet replik: eno primarno in osem sekundarnih. Porazdeljene skupine razpoložljivosti lahko to razširijo na 18 replik v dveh ločenih skupinah razpoložljivosti.

V: Ali lahko replike, ki jih gosti FCI, uporabljajo samodejni preklop AG na drugo platformo?

O: Ne. Ko replika razpoložljivosti gostuje v primerku gruče za preklop ob okvari, samodejni preklop skupine razpoložljivosti za to repliko ni podprt. Vsi preklopi skupine razpoložljivosti, ki vključujejo replike, ki jih gosti FCI, zahtevajo ročni poseg.

V: Kakšna je razlika med sinhronim in asinhronim načinom potrjevanja?

A: Sinhroni način potrjevanja zahteva, da primarni strežnik počaka, da sekundarni strežnik utrdi zapise dnevnika, preden potrdi, s čimer se zagotovi ničelna izguba podatkov (RPO = 0) za ceno dodatne zakasnitve pisanja. Asinhroni način potrjevanja omogoča primarnemu strežniku, da potrdi brez čakanja, kar zmanjša zakasnitev, vendar tvega izgubo podatkov, če primarni strežnik odpove, preden sekundarni strežnik prejme vse zapise dnevnika. Za lokalne replike visoke razpoložljivosti uporabite sinhroni način, za oddaljene replike DR pa asinhroni način.

V: Kako dolgo traja SQL Server Vedno vklopljeno preklop na rezervni sistem?

A: Samodejni preklop za sinhrono repliko AG se v normalnih pogojih običajno zaključi v manj kot 30 sekundah. Preklop FCI običajno traja 20–60 sekund, odvisno od časa obnovitve baze podatkov. Dejansko trajanje je odvisno od delovne obremenitve, velikosti baze podatkov in nastavitev časovne omejitve za preverjanje zdravja, konfiguriranih v WSFC.

V: Kaj se zgodi s povezavami odjemalcev med preklopom na rezervno omrežje?

A: Obstoječe povezave se prekinejo, ko pride do preklopa. Aplikacije, ki uporabljajo poslušalnik skupine razpoložljivosti in vključujejo logiko ponovnega poskusa povezave, se po končanem preklopu samodejno ponovno povežejo z novo primarno omrežje. Dodajanje vrednosti MultiSubnetFailover=True v povezovalne nize izboljša hitrost ponovne povezave v uvedbah z več podomrežji.

V: Kako se prijavim SQL Server popravki z minimalnim izpadom v okolju Always On?

A: Uporabite tekoče nadgradnje: najprej posodobite sekundarne replike, nato izvedite načrtovani ročni preklop na posodobljeno sekundarno različico in na koncu posodobite prejšnjo primarno različico. To omeji čas izpada na trajanje enega načrtovanega preklopa – običajno manj kot minuto.

V: Ali lahko združim skupine razpoložljivosti Always On z instancami grozdov Failover?

A: Da. Replike AG lahko gostite na instancah FCI, da dosežete zaščito pred preklopom na ravni instance in baze podatkov. Vsak FCI šteje kot ena replika AG. Ta topologija zahteva skrbno načrtovanje vozlišča WSFC, da se zagotovi, da nobeno posamezno vozlišče ne gosti dveh replik iste AG po morebitnem preklopu FCI.

V: Kaj naj storim, če se moja zbirka podatkov poškoduje v okolju Always On?

A: Najprej preverite, ali je poškodba prisotna na vseh replikah ali samo na primarni. Če obstaja zdrava sekundarna kopija, jo takoj preklopite v primeru okvare. Če je poškodba prisotna na vseh replikah, obnovite iz čiste varnostne kopije. Redno izvajajte ukaz DBCC CHECKDB na sekundarnih replikah, da zgodaj odkrijete poškodbo. Če so prizadete tudi varnostne kopije, je potreben specializiran SQL Server orodje za obnovitev podatkov lahko kot zadnjo možnost poskusi izvleči podatke iz poškodovanih datotek MDF.

V: Kakšna je primerjava skupin razpoložljivosti Always On s starejšimi SQL Server Rešitve visoke razpoložljivosti?

A: AG nadomešča starejše tehnologije, kot so pošiljanje hlodov in replikacijaPošiljanje dnevnikov zahteva ročni preklop ob okvari in nima samodejnega prehoda vlog; replikacija je zasnovana za distribucijo podatkov in ne za visoko dostopno storitev (HA). Agencijska podpora zagotavlja avtomatiziran preklop ob okvari, ničelno izgubo podatkov s sinhrono potrditevjo in berljive sekundarne datoteke – zmogljivosti, s katerimi se te tehnologije ne morejo kosati.

8. Zaključek

SQL Server Always On ponuja prilagodljivo platformo poslovnega razreda za visoko razpoložljivost in obnovo po katastrofi. Skupine razpoložljivosti Always On so prava izbira za večino sodobnih uvedb: odpravljajo potrebo po skupni shrambi, podpirajo berljive sekundarne strežnike in v eni sami konfiguraciji obravnavajo tako lokalno visoko dostopnost kot tudi medspletno obnavljanje po nesreči. Primerki grozdov za preklop ob okvari ostajajo dobra možnost, kadar sta preklop na ravni primerka in obstoječa infrastruktura za skupno shranjevanje primarni zahtevi. Združevanje obeh tehnologij zagotavlja najglobljo možno zaščito – za ceno večjih naložb v infrastrukturo in operativne kompleksnosti.

Ne glede na to, katero rešitev izberete, so osnove enake: najprej definirajte zahteve glede časa obratovanja (RTO) in časa povratnega toka (RPO), zasnujte topologijo glede na te cilje in redno testirajte preklop v primeru okvare. Dobro implementirana rešitev Always On, ki je bila temeljito preizkušena, si bo predvidljivo opomogla, ko pride do napak v produkciji.

O Author

Yuan Sheng je višji administrator baz podatkov (DBA) z več kot 10 leti izkušenj na področju SQL Server okolja in upravljanje poslovnih baz podatkov. Uspešno je rešil na stotine scenarijev obnovitve baz podatkov v finančnih storitvah, zdravstvu in proizvodnih organizacijah.

Yuan je specializiran za SQL Server obnovitev baz podatkov, rešitve za visoko razpoložljivost in optimizacija delovanja. Njegove bogate praktične izkušnje vključujejo upravljanje večterabajtnih baz podatkov, implementacijo skupin razpoložljivosti Always On in razvoj avtomatiziranih strategij varnostnega kopiranja in obnovitve za ključne poslovne sisteme.

Yuan se s svojim tehničnim znanjem in praktičnim pristopom osredotoča na ustvarjanje celovitih vodnikov, ki pomagajo skrbnikom baz podatkov in IT-strokovnjakom reševati kompleksne SQL Server učinkovito se spopada z izzivi. Vedno je na tekočem z najnovejšimi SQL Server izdaje in Microsoftove razvijajoče se tehnologije baz podatkov, pri čemer redno testira scenarije obnovitve, da zagotovi, da njegova priporočila odražajo najboljše prakse iz resničnega sveta.

Imate vprašanja o SQL Server obnovitev ali potrebujete dodatna navodila za odpravljanje težav z zbirko podatkov? Yuan pozdravlja povratne informacije in predlogi za izboljšanje teh tehničnih virov.