SQL Server Uvijek uključen: Potpuni vodič za administratore baza podataka [2026]

SQL Server Always On je Microsoftovo sveobuhvatno rješenje za visoku dostupnost i oporavak od katastrofe predstavljeno s SQL Server 2012. Predstavlja značajan napredak u odnosu na prethodne tehnologije poput zrcaljenja baze podataka i slanja logova, osiguravajući kontinuirani pristup podacima uz minimiziranje zastoja i gubitka podataka.

1.2 Zašto su tvrtkama potrebna uvijek dostupna rješenja

U današnjem digitalnom gospodarstvu, prekid rada baze podataka izravno se prevodi u gubitak prihoda, narušen ugled i probleme s usklađenošću s propisima. Organizacijama su potrebna rješenja visoke dostupnosti koja mogu jamčiti gotovo kontinuiranu dostupnost, a istovremeno štititi od raznih scenarija kvarova.

Tradicionalni postupci izrade sigurnosnih kopija i vraćanja nisu dovoljni za moderne poslovne zahtjeve. Kada kritična baza podataka zakaže, tvrtke si ne mogu priuštiti sate potrebne za vraćanje iz sigurnosnih kopija. Always On rješenja pružaju automatizirano prebacivanje u slučaju kvara koje može vratiti uslugu u sekundama ili minutama umjesto satima, dramatično smanjujući utjecaj kvarova sustava.

Osim osnovne dostupnosti, tvrtke trebaju rasteretiti produkcijske baze podataka s opterećenjima koja zahtijevaju puno čitanja, obavljati održavanje bez zastoja i zaštititi se od katastrofa na razini lokacije. SQL Server Always On rješava sve te zahtjeve putem ujedinjene arhitekture koja se skalira od malih implementacija do globalno distribuiranih sustava.

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

Ciljno vrijeme oporavka (RTO) definira maksimalno prihvatljivo trajanje zastoja nakon kvara - koliko brzo baza podataka mora biti ponovno online.

Ciljna točka oporavka (RPO) definira maksimalno prihvatljiv gubitak podataka mjeren u vremenu - koliko nedavno podijeljenih podataka tvrtka može priuštiti izgubiti.

Visoka dostupnost (HA) fokusira se na minimiziranje zastoja uzrokovanih rutinskim kvarovima poput kvarova hardvera ili softverskih padova unutar istog podatkovnog centra.

Oporavak od katastrofe (DR) rješava katastrofalne događaje koji utječu na cijele lokacije, održavajući kopije podataka na geografski odvojenim lokacijama. Dok se HA fokusira na minimiziranje zastoja, DR se fokusira na osiguranje zaštite podataka i kontinuiteta poslovanja tijekom većih incidenata.

SQL Server Always On podržava i HA i DR unutar jedne ujedinjene arhitekture. Način sinkronog commit-a pruža RPO = 0 s automatskim prebacivanjem u slučaju kvara za gotovo nulti RTO; način asinkronog commit-a prihvaća potencijalni gubitak podataka u zamjenu za manji utjecaj latencije na udaljenim lokacijama.

1.4 Uvijek dostupna rješenja

SQL Server Always On nudi tri mogućnosti implementacije, a svaka je prilagođena različitim zahtjevima dostupnosti i infrastrukture. Ovaj vodič pokriva sve tri:

Grupe dostupnosti uvijek uključene (AG): Visoka dostupnost i oporavak od katastrofe na razini baze podataka bez dijeljene pohrane.
Instance klastera za prebacivanje u slučaju kvara (FCI) koje su uvijek uključene: Visoka dostupnost na razini instance korištenjem dijeljene pohrane.
AG + FCI zajedno: Dvoslojna zaštita koja kombinira prebacivanje na razinu instance i baze podataka za maksimalnu otpornost.

2. Grupe dostupnosti Always On

Grupe dostupnosti uvijek uključene (AG) je rješenje za visoku dostupnost i oporavak od katastrofe na razini baze podataka koje replicira skup korisničkih baza podataka na do osam sekundarnih replika putem kontinuirane dostave dnevnika transakcija.

Ključne značajke 2.1-a

Prijelaz na razinu baze podataka: pojedinačne baze podataka ili grupe mogu se prebaciti na prijelaz neovisno o SQL Server primjer;
do devet replika (jedna primarna, osam sekundarnih) u Enterprise izdanju;
sinkroni način commit-a za nulti gubitak podataka; asinkroni način commit-a za udaljene DR replike;
automatsko prebacivanje u slučaju kvara za sinkrone replike kada primarna postane nedostupna;
čitljive sekundarne replike za rasterećenje opterećenja izvještavanja i sigurnosnog kopiranja;
Slušač grupe dostupnosti pruža jednu krajnju točku veze koja se automatski usmjerava na trenutni primarni server.

2.2 Koraci provedbe

Pripremite račune usluge Active Directory i konfigurirajte dozvole na svim čvorovima;
instalirati i validirati klasteriranje za preuzimanje rješenja za kvarove sustava Windows Server na svim uključenim poslužiteljima;
instalirati SQL Server kao samostalna instanca na svakom čvoru korištenjem konzistentnih putanja i postavki;
omogućite značajku Grupe dostupnosti uvijek uključene putem SQL Server Upravitelj konfiguracije ili PowerShell;
postaviti baze podataka na model potpunog oporavka i napraviti potpune i zapisničke sigurnosne kopije;
stvoriti grupu dostupnosti, dodati replike i konfigurirati načine dostupnosti i prebacivanja u slučaju kvara;
postavlja sekundarne replike automatskim postavljanjem ili ručnom izradom sigurnosnih kopija i vraćanjem;
stvorite slušatelja grupe dostupnosti i provjerite povezivost klijenta.

Za cjelovite upute korak po korak, pogledajte naš Potpuni vodič za grupe dostupnosti Always On.

2.3 Najbolje za

Kritične baze podataka koje zahtijevaju nulti gubitak podataka i automatsko prebacivanje na drugi sustav;
opterećenja kojima su potrebne čitljive sekundarne datoteke za izvještavanje ili rasterećenje sigurnosnih kopija;
implementacije koje obuhvaćaju više lokacija za oporavak od katastrofe;
okruženja bez postojeće infrastrukture za dijeljenu pohranu.

2.4 pros

Nije potrebna dijeljena pohrana — svaka replika koristi neovisnu lokalnu pohranu;
podržava i HA i DR u jednoj konfiguraciji;
čitljive sekundarne datoteke smanjuju primarno opterećenje;
Granularnost na razini baze podataka omogućuje različite politike prebacivanja na drugi sustav po grupi baza podataka.

2.5 kontra

Za puni skup značajki potrebno je Enterprise izdanje (Standard podržava Basic AG sa značajnim ograničenjima);
sinkroni način commit-a dodaje latenciju pisanja proporcionalnu vremenu povratnog putovanja mreže;
prijave, poslovi SQL agenta i povezani poslužitelji zahtijevaju ručnu sinkronizaciju u SQL Server 2019. i ranije;
Sve replike moraju se nalaziti na čvorovima istog klastera za prebacivanje u slučaju kvara sustava Windows Server.

2.6 Literatura

Službeni dokument tvrtke Microsoft: Što je grupa dostupnosti Always On?
Službeni dokument tvrtke Microsoft: Početak rada s grupama dostupnosti Always On

3. Instance klastera za prebacivanje u slučaju kvara koje su uvijek uključene

Instance klastera za prebacivanje u slučaju kvara (FCI) koje su uvijek uključene pruža visoku dostupnost na razini instance pokretanjem jednog SQL Server instancu na više fizičkih čvorova koji dijele istu pohranu. Kada aktivni čvor zakaže, SQL Server Instanca na rezervnom čvoru se automatski ponovno pokreće, što prijelaz čini transparentnim za klijentske aplikacije.

Ključne značajke 3.1-a

Prijelaz na instancu: sve baze podataka na instanci se prebacivaju zajedno kao jedna jedinica;
dijeljena pohrana (SAN, iSCSI, Storage Spaces Direct ili SMB) dostupna svim čvorovima;
naziv virtualne mreže i virtualna IP adresa pružaju stabilnu krajnju točku veze bez obzira na to koji je čvor aktivan;
Klasteriranje za prebacivanje u slučaju kvara u sustavu Windows Server upravlja praćenjem stanja čvorova, kvorumom i orkestracijom prebacivanja u slučaju kvara;
podržava konfiguracijske tipove čvorova Aktivno/Pripravno, Aktivno/Aktivno, N+1 i N+M.

3.2 Koraci provedbe

Osigurajte i priključite dijeljenu pohranu svim čvorovima klastera;
instalirajte značajku Failover Clustering i provjerite konfiguraciju klastera;
stvoriti klaster za prebacivanje u slučaju kvara sustava Windows Server i konfigurirati kvorum;
pokrenuti SQL Server instalacija odabirom opcije klastera za preuzimanje u slučaju kvara i određivanjem naziva virtualne mreže i putanja dijeljene pohrane;
dodajte dodatne čvorove u SQL Server instanca klastera za prebacivanje u sustav s greškom;
Provjerite ponašanje prebacivanja u slučaju kvara testiranjem ručnog prebacivanja u slučaju kvara između čvorova.

Za cjelovite upute korak po korak, pogledajte naš SQL Server Potpuni vodič za klastere za prebacivanje u slučaju kvara.

3.3 Najbolje za

Okruženja s postojećom infrastrukturom dijeljene pohrane (SAN ili iSCSI);
aplikacije koje zahtijevaju prebacivanje na instancu gdje se sve baze podataka moraju prebaciti na drugi sustav zajedno;
scenariji u kojima je transparentnost klijenta ključna i nisu prihvatljive nikakve promjene na strani aplikacije;
organizacije koje daju prioritet jednostavnosti modela prebacivanja u slučaju kvara s jednom instancom.

3.4 pros

Automatsko prebacivanje na instancu bez potrebe za ponovnom konfiguracijom klijenta;
nema opterećenja replikacije podataka — svi čvorovi pristupaju istoj pohrani;
predvidljivo ponašanje prebacivanja na drugi način rada za sve baze podataka istovremeno;
podržava fleksibilne konfiguracije čvorova (Aktivno/Aktivno, N+1, N+M) za optimizaciju iskorištenja hardvera.

3.5 kontra

Dijeljena pohrana je potencijalna jedinstvena točka kvara osim ako sama pohrana nije redundantna;
samo jedan čvor radi SQL Server istovremeno — nema uravnoteženja opterećenja čitanja na sekundarnim čvorovima;
nema ugrađenog oporavka od katastrofe bez uparivanja s grupom dostupnosti;
Infrastruktura dijeljene pohrane dodaje troškove i složenost u usporedbi s AG-om.

3.6 Literatura

Službeni dokument tvrtke Microsoft: Instance klastera za prebacivanje u slučaju kvara uvijek uključene (SQL Server)

4. Kombinirajte grupe dostupnosti s instancama klastera za prebacivanje u slučaju kvara

Za organizacije kojima je potrebna zaštita i na razini instance i na razini baze podataka, SQL Server podržava hosting replika grupa dostupnosti na instancama klastera za prebacivanje u slučaju kvara (FCI). U ovoj konfiguraciji, svaki FCI čvor djeluje kao jedna replika dostupnosti, tako da je prebacivanje FCI-ja transparentno za grupu dostupnosti, dok prebacivanje AG-a pruža zaštitu na razini baze podataka na svim lokacijama. Ova kombinacija pruža najopsežniju pokrivenost visoke dostupnosti i oporavka od katastrofe dostupnu u SQL Server.

Ključne značajke 4.1-a

Dvoslojni failover: FCI obrađuje kvarove čvorova na razini instance; AG obrađuje kvarove na razini web-mjesta ili replike;
svaki FCI se računa kao jedna replika unutar grupe dostupnosti bez obzira na to koliko čvorova FCI sadrži;
Replike hostane na FCI-ju i dalje zahtijevaju dijeljenu pohranu prema standardnim FCI zahtjevima;
AG replike hostirane na FCI-jima podržavaju samo ručno prebacivanje u slučaju kvara — automatsko prebacivanje u slučaju kvara nije dostupno za replike hostirane na FCI-ju;
Samostalne instance mogu sudjelovati u istoj grupi dostupnosti zajedno s replikama hostiranim na FCI-ju.

4.2 Koraci provedbe

Implementirajte i validirajte svaki FCI neovisno slijedeći standardne postupke postavljanja FCI-ja;
osigurati da svi FCI čvorovi i samostalni replikacijski čvorovi pripadaju istom klasteru za prebacivanje u slučaju kvara sustava Windows Server;
omogućite značajku Grupe dostupnosti uvijek uključene na svakoj FCI instanci;
provjeriti da niti jedan WSFC čvor ne bi hostirao dvije replike iste grupe dostupnosti nakon bilo kakvog mogućeg FCI prebacivanja u slučaju kvara;
stvoriti grupu dostupnosti, označiti FCI instance kao replike i konfigurirati ručni način prebacivanja u slučaju kvara za sve replike hostane na FCI-ju;
postaviti sekundarne replike i konfigurirati slušatelja grupe dostupnosti.

Za detalje o postavljanju FCI-a pogledajte našu SQL Server Potpuni vodič za klastere za prebacivanje u slučaju kvara. Za detalje o postavljanju AG-a pogledajte naš potpuni vodič za Grupe dostupnosti uvijek uključene.

4.3 Najbolje za

Kritična okruženja koja zahtijevaju zaštitu od kvarova pojedinačnih čvorova i katastrofa na razini lokacije;
organizacije koje već koriste FCI i trebaju dodati oporavak od katastrofe na više lokacija;
regulirane industrije u kojima su SLA-ovi za maksimalnu zaštitu podataka i dostupnost obvezni;
velike implementacije gdje politike prebacivanja na razinu instance i baze podataka moraju koegzistirati.

4.4 pros

Maksimalna zaštita: kvarove čvorova rješava FCI, kvarove lokacije rješava AG;
FCI prebacivanje u slučaju kvara je transparentno za grupu dostupnosti — AG ne vidi promjenu replike tijekom FCI prebacivanja u slučaju kvara;
fleksibilna topologija: kombinirajte replike hostane na FCI-ju i samostalne replike u istoj grupi dostupnosti.

4.5 kontra

Replike hostane na FCI-ju podržavaju samo ručno prebacivanje u slučaju kvara u AG-u — automatsko prebacivanje u slučaju kvara u AG-u nije dostupno za ove replike;
zahtijeva pažljivo planiranje WSFC čvora kako bi se spriječilo da jedan čvor hostira dvije replike iste AG nakon FCI failovera;
veći troškovi infrastrukture i operativna složenost nego samo AG ili FCI;
dijeljena pohrana i dalje je potrebna za svaku FCI komponentu.

4.6 Literatura

Službeni dokument tvrtke Microsoft: Grupe za prebacivanje u slučaju kvara i grupe dostupnosti Always On (SQL Server)
Službeni dokument tvrtke Microsoft: Što je grupa dostupnosti Always On?
Službeni dokument tvrtke Microsoft: Početak rada s grupama dostupnosti Always On
Službeni dokument tvrtke Microsoft: Instance klastera za prebacivanje u slučaju kvara uvijek uključene (SQL Server)

5. Usporedba rješenja Always On

5.1 Tablica usporedbe značajki

svojstvo	Grupe dostupnosti	Instance klastera za prebacivanje u slučaju kvara	Kombinirano AG + FCI
Opseg prebacivanja u slučaju kvara	Razina baze podataka	Na razini instance	Oboje
Potrebna je dijeljena pohrana	Ne	Da	Da (za FCI komponentu)
Replikacija podataka	Na temelju zapisnika za svaku repliku	Ništa (dijeljena pohrana)	Na temelju zapisnika između FCI-a
Automatski failover	Da (sinkrone replike)	Da	FCI: Da; AG: Ne
Čitljive sekundarne stavke	Da	Ne	Da (AG komponenta)
Oporavak od katastrofe	Ugrađen	Nije ugrađeno	Ugrađen
Maks. replika	9 (Poduzeće)	N / A	9 (Poduzeće)
Složenost infrastrukture	Srednji	Srednji	visok
Trošak	Niže (nije potrebna SAN)	Viša (potreban SAN)	Najviši

5.2 Odaberite svoje rješenje koje vam uvijek bude dostupno

Započnite s infrastrukturom za pohranu: ako nemate postojeću dijeljenu pohranu, Grupe dostupnosti (AG) su prirodan izbor i najisplativiji put do HA i DR. Ako već upravljate SAN okruženjem i trebate prebacivanje na razinu instance u slučaju kvara, FCI je jednostavnija opcija - ali planirajte kasnije dodavanje AG ako je DR na više lokacija buduća potreba.

Odaberite kombinaciju AG + FCI samo kada imate stvarnu potrebu za oba sloja zaštite i operativnu zrelost za upravljanje povećanom složenošću. Ključno ograničenje koje treba zapamtiti jest da replike AG-a hostane na FCI-ju ne podržavaju automatsko prebacivanje u slučaju kvara, pa ova topologija zahtijeva ručnu intervenciju za prebacivanje u slučaju kvara na razini grupe dostupnosti.

Za većinu današnjih implementacija u novim fazama, preporučena početna točka su Always On Availability Groups: pokrivaju i HA i DR, ne zahtijevaju dijeljenu pohranu i podržavaju čitljive sekundarne resurse - mogućnosti koje FCI sam po sebi ne može dostići.

6. Najbolji primjeri iz prakse za SQL Server Uvijek dostupna rješenja

6.1 Planiranje i dizajn

Definirajte zahtjeve za RTO i RPO prije odabira Always On rješenja - ovi ciljevi izravno određuju je li prikladan sinkroni ili asinkroni način commit-a i je li automatsko prebacivanje u slučaju kvara izvedivo.
Prilagodite sekundarne replike kako bi se nosile s punim primarnim opterećenjem tijekom događaja prebacivanja u slučaju kvara, uključujući scenarije vršnog opterećenja.
Za AG implementacije, postavite sinkrone replike unutar istog podatkovnog centra ili mreže s niskom latencijom kako biste smanjili utjecaj latencije pisanja. Rezervirajte asinkroni način rada za geografski udaljene DR replike.
Osmislite kvorum s neparnim brojem glasova. Za klastere s dva čvora, dodajte dijeljenje datoteka ili svjedoka u oblaku kao treći glas kako biste spriječili scenarije podijeljenog mozga.
Pažljivo isplanirajte topologiju mreže za implementacije s više podmreža. Svaka podmreža zahtijeva vlastitu IP adresu slušatelja, a klijenti trebaju imati MultiSubnetFailover=True u svojim nizovima za povezivanje.

6.2 Smjernice za provedbu

Koristite dosljedno SQL Server razine verzija, izdanja i kumulativnih ažuriranja u svim replikama. Mješovite razine zakrpa mogu uzrokovati neočekivano ponašanje tijekom prebacivanja u slučaju kvara.
Konfigurirajte namjenska mrežna sučelja za promet otkucaja srca klastera, odvojeno od prometa aplikacije.
Omogući automatsko zasijevanje za početnu sinkronizaciju baze podataka u SQL Server 2016 i novije verzije — eliminira potrebu za ručnim kopiranjem sigurnosnih kopija na sekundarne replike za većinu scenarija.
Za AG + FCI topologije, nakon svake promjene konfiguracije FCI čvora provjerite da niti jedan WSFC čvor ne može hostirati dvije replike iste grupe dostupnosti.
Uvijek koristite SQL Server Management Studio ili Transact-SQL za upravljanje prebacivanjem grupa dostupnosti u slučaju kvara - nikada nemojte izravno koristiti Failover Cluster Manager jer nije svjestan stanja sinkronizacije AG-a i može uzrokovati dulje vrijeme prekida rada ili gubitak podataka.

6.3 Praćenje i održavanje

Redovito pratite stanje sinkronizacije, red slanja i red ponavljanja pomoću nadzorne ploče grupe dostupnosti u SQL Server Management Studio ili Dynamic Management Views (DMV). Rastući red za ponavljanje na sekundarnoj adresi ukazuje na usko grlo I/O koje će odgoditi oporavak nakon kvara.
Pokrenite DBCC CHECKDB na sekundarnim replikama kako biste rasteretili provjere integriteta s primarne. Pogledajte naše Vodič za DBCC CHECKDB za detalje.
Korak po korak do prijave SQL Server zakrpe korištenjem kontinuiranih nadogradnji: prvo zakrpa sekundarne replike, izvrši planirani ručni failover na zakrpanu sekundarnu mrežu, a zatim zakrpa prethodnu primarnu mrežu. To ograničava vrijeme zastoja na trajanje jednog failovera.
Redovito testirajte prebacivanje u slučaju kvara u neprodukcijskim okruženjima. Automatsko prebacivanje u slučaju kvara koje nikada nije testirano nije pouzdana strategija oporavka.
Konfigurirajte upozorenja za promjene stanja grupe dostupnosti, prijelaze uloga replike i neuspjehe sinkronizacije pomoću SQL Server Agent ili namjenski alat za praćenje kao što je SQL Server Performance Monitor.

7. Pitanja

P: Što je SQL Server Uvijek uključeno?

A: SQL Server Always On je Microsoftova platforma za visoku dostupnost i oporavak od katastrofe predstavljena SQL Server 2012. Obuhvaća dvije tehnologije — Always On Availability Groups i Always On Failover Cluster Instances — koje omogućuju automatizirano prebacivanje u slučaju kvara, redundanciju podataka i kontinuirani pristup bazama podataka u slučaju kvarova hardvera, softvera ili web-mjesta.

P: Koja je razlika između grupa dostupnosti Always On i instanci klastera za prebacivanje u slučaju kvara?

A: Grupe dostupnosti rade na razini baze podataka, repliciraju podatke na neovisne sekundarne replike putem slanja dnevnika i ne zahtijevaju dijeljenu pohranu. Instance klastera za prebacivanje u slučaju kvara rade na razini instance, zahtijevaju dijeljenu pohranu kojoj mogu pristupiti svi čvorovi i prebacuju sve baze podataka zajedno kao cjelinu. AG podržava čitljive sekundarne baze podataka i ugrađeni DR; FCI ne.

P: Trebam li dijeljenu pohranu za grupe dostupnosti Always On?

O: Ne. Svaka AG replika održava vlastitu neovisnu kopiju baza podataka na lokalnoj pohrani. Dijeljena pohrana je potrebna samo ako koristite instance klastera za prebacivanje u slučaju kvara za hostiranje AG replika.

P: Mogu li koristiti Always On s SQL Server Standardno izdanje?

A: SQL Server Standardno izdanje podržava osnovne grupe dostupnosti počevši od SQL Server 2016., ali sa značajnim ograničenjima: jedna baza podataka po AG-u, maksimalno dvije replike i bez čitljive sekundarne podrške. FCI je dostupan u Standardnom izdanju bez ovih ograničenja. Enterprise izdanje je potrebno za punu funkcionalnost Always On.

P: Koji je maksimalni broj replika u grupi dostupnosti?

A: SQL Server Enterprise Edition podržava do devet replika: jednu primarnu i osam sekundarnih. Distribuirane grupe dostupnosti mogu proširiti ovo na 18 replika u dvije odvojene grupe dostupnosti.

P: Mogu li replike hostane na FCI-ju koristiti automatsko prebacivanje u slučaju kvara u slučaju kvara?

O: Ne. Kada se replika dostupnosti nalazi na instanci klastera za prebacivanje u slučaju kvara, automatsko prebacivanje grupe dostupnosti u slučaju kvara nije podržano za tu repliku. Sva prebacivanja u slučaju kvara grupe dostupnosti koja uključuju replike hostirane na FCI-ju zahtijevaju ručnu intervenciju.

P: Koja je razlika između sinkronih i asinkronih načina potvrđivanja?

A: Sinkroni način izvršavanja zahtijeva da primarni server pričeka da sekundarni server ojača zapise dnevnika prije izvršavanja, osiguravajući nulti gubitak podataka (RPO = 0) po cijenu dodatne latencije pisanja. Asinkroni način izvršavanja omogućuje primarnom serveru izvršavanje bez čekanja, smanjujući latenciju, ali riskirajući gubitak podataka ako primarni server ne uspije prije nego što sekundarni server primi sve zapise dnevnika. Koristite sinkroni način za lokalne HA replike, a asinkroni za udaljene DR replike.

P: Koliko dugo traje SQL Server Uvijek uključeno preuzimanje rezervnog načina rada?

A: Automatsko prebacivanje u slučaju kvara za sinkronu AG repliku obično se dovršava za manje od 30 sekundi u normalnim uvjetima. FCI prebacivanje u slučaju kvara obično traje 20–60 sekundi, ovisno o vremenu oporavka baze podataka. Stvarno trajanje ovisi o opterećenju, veličini baze podataka i postavkama vremenskog ograničenja provjere ispravnosti konfiguriranim u WSFC-u.

P: Što se događa s vezama klijenata tijekom prebacivanja u slučaju kvara?

A: Postojeće veze se prekidaju kada dođe do prebacivanja u slučaju kvara. Aplikacije koje koriste slušača grupe dostupnosti i uključuju logiku ponovnog pokušaja povezivanja automatski se ponovno povezuju s novim primarnim poslužiteljem nakon što se prebacivanje u slučaju kvara dovrši. Dodavanje MultiSubnetFailover=True nizovima za povezivanje poboljšava brzinu ponovnog povezivanja u implementacijama s više podmreža.

P: Kako se prijaviti SQL Server zakrpe s minimalnim zastojem u Always On okruženju?

A: Koristite nadogradnje u tijeku: prvo zakrpajte sekundarne replike, zatim izvedite planirani ručni failover na zakrpanu sekundarnu server i na kraju zakrpajte bivši primarni server. To ograničava vrijeme neaktivnosti na trajanje jednog planiranog failovera - obično manje od minute.

P: Mogu li kombinirati grupe dostupnosti Always On s instancama klastera za prebacivanje u slučaju kvara?

O: Da. Možete hostirati AG replike na FCI instancama kako biste postigli zaštitu od kvara na razini instance i baze podataka. Svaki FCI se računa kao jedna AG replika. Ova topologija zahtijeva pažljivo planiranje WSFC čvora kako bi se osiguralo da nijedan čvor ne hostira dvije replike iste AG nakon bilo kakvog mogućeg FCI kvara.

P: Što trebam učiniti ako se moja baza podataka ošteti u okruženju s uključenom funkcijom Always On?

A: Prvo provjerite postoji li oštećenje na svim replikama ili samo na primarnoj. Ako postoji ispravna sekundarna replika, odmah se prebacite na nju. Za oštećenje svih replika, vratite podatke iz čiste sigurnosne kopije. Redovito pokrećite DBCC CHECKDB na sekundarnim replikama kako biste rano otkrili oštećenje. Ako su pogođene i sigurnosne kopije, specijalizirani SQL Server alat za oporavak podataka može pokušati izdvojiti podatke iz oštećenih MDF datoteka kao krajnju mjeru.

P: Kako se Grupe dostupnosti uvijek uspoređuju sa starijim verzijama SQL Server HA rješenja?

A: AG zamjenjuje starije tehnologije kao što su otprema trupaca i odgovorDostava logova zahtijeva ručno prebacivanje u slučaju kvara i nema automatsku promjenu uloge; replikacija je dizajnirana za distribuciju podataka, a ne za visoku dostupnost. Agenti za distribuciju pružaju automatizirano prebacivanje u slučaju kvara, nulti gubitak podataka sa sinkronim potvrđivanjem i čitljive sekundarne datoteke - mogućnosti kojima se te tehnologije ne mogu usporediti.

8. Zaključak

SQL Server Always On pruža fleksibilnu platformu poslovne razine za visoku dostupnost i oporavak od katastrofe. Grupe dostupnosti Always On pravi su izbor za većinu modernih implementacija: eliminiraju potrebu za dijeljenom pohranom, podržavaju čitljive sekundarne resurse i obrađuju lokalnu visoku dostupnost i oporavak od katastrofe na više lokacija u jednoj konfiguraciji. Instance klastera za prebacivanje u slučaju kvara ostaju solidna opcija kada su prebacivanje u slučaju kvara na razini instance i postojeća infrastruktura dijeljene pohrane primarni zahtjevi. Kombiniranje obje tehnologije pruža najdublju dostupnu zaštitu - uz cijenu većih ulaganja u infrastrukturu i operativne složenosti.

Bez obzira na rješenje koje odaberete, osnove su iste: prvo definirajte svoje RTO i RPO zahtjeve, dizajnirajte topologiju oko tih ciljeva i redovito testirajte prebacivanje u slučaju kvara. Dobro implementirano Always On rješenje koje je temeljito testirano predvidljivo će se oporaviti kada dođe do kvarova u produkciji.

O Autor:

Yuan Sheng je viši administrator baze podataka (DBA) s preko 10 godina iskustva u SQL Server okruženja i upravljanje bazama podataka poduzeća. Uspješno je riješio stotine scenarija oporavka baza podataka u financijskim uslugama, zdravstvu i proizvodnim organizacijama.

Yuan se specijalizirao za SQL Server oporavak baza podataka, rješenja za visoku dostupnost i optimizaciju performansi. Njegovo opsežno praktično iskustvo uključuje upravljanje bazama podataka od više terabajta, implementaciju grupa dostupnosti Always On i razvoj automatiziranih strategija sigurnosnog kopiranja i oporavka za poslovne sustave od kritične važnosti.

Svojim tehničkim znanjem i praktičnim pristupom, Yuan se usredotočuje na stvaranje sveobuhvatnih vodiča koji pomažu administratorima baza podataka i IT stručnjacima u rješavanju složenih SQL Server učinkovito rješava izazove. Ostaje u toku s najnovijim SQL Server izdanja i Microsoftove razvojne tehnologije baza podataka, redovito testirajući scenarije oporavka kako bi osigurao da njegove preporuke odražavaju najbolje prakse iz stvarnog svijeta.

Imate pitanja o SQL Server oporavak ili trebate dodatne upute za rješavanje problema s bazom podataka? Yuan pozdravlja povratne informacije i sugestije za poboljšanje ovih tehničkih resursa.