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

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

1.2 Zašto su preduzećima potrebna uvijek dostupna rješenja

U današnjoj digitalnoj ekonomiji, prekid rada baze podataka direktno se prevodi u gubitak prihoda, narušenu reputaciju i probleme s usklađenošću s propisima. Organizacijama su potrebna rješenja visoke dostupnosti koja mogu garantirati gotovo kontinuiranu dostupnost, a istovremeno štititi od različitih scenarija kvara.

Tradicionalne procedure pravljenja sigurnosnih kopija i vraćanja podataka nisu dovoljne za moderne poslovne zahtjeve. Kada kritična baza podataka zakaže, preduzeća si ne mogu priuštiti sate potrebne za vraćanje podataka iz sigurnosnih kopija. Always On rješenja pružaju automatizirano prebacivanje u slučaju kvara koje može vratiti uslugu za nekoliko sekundi ili minuta umjesto sati, dramatično smanjujući utjecaj kvarova sistema.

Pored osnovne dostupnosti, preduzeća trebaju rasteretiti opterećenja koja zahtijevaju puno čitanja iz produkcijskih baza podataka, obavljati održavanje bez zastoja i zaštititi se od katastrofa na nivou lokacije. SQL Server Always On ispunjava sve ove zahtjeve kroz objedinjenu arhitekturu koja se skalira od malih implementacija do globalno distribuiranih sistema.

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

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

Cilj tačke oporavka (RPO) definira maksimalno prihvatljiv gubitak podataka mjeren u vremenu - koliko nedavno poslanih podataka preduzeće može priuštiti da izgubi.

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

Oporavak od katastrofe (DR) adresira katastrofalne događaje koji pogađaju 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 tokom većih incidenata.

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

1.4 Uvijek dostupna rješenja

SQL Server Always On nudi tri opcije implementacije, od kojih svaka odgovara različitim zahtjevima dostupnosti i infrastrukture. Ovaj vodič pokriva sve tri:

Grupe dostupnosti uvijek uključene (AG): Visoka dostupnost i oporavak od katastrofe na nivou baze podataka bez dijeljenog prostora za pohranu.
Instance klastera za prebacivanje u slučaju kvara koje su uvijek uključene (FCI): Visoka dostupnost na nivou instance korištenjem dijeljenog prostora za pohranu.
AG + FCI zajedno: Dvoslojna zaštita koja kombinuje failover na nivou instance i baze podataka za maksimalnu otpornost.

2. Grupe dostupnosti koje su uvijek dostupne

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

2.1 Ključne karakteristike

Prebacivanje na nivo baze podataka: pojedinačne baze podataka ili grupe mogu preći na drugi nivo nezavisno od SQL Server primjer;
do devet replika (jedna primarna, osam sekundarnih) u Enterprise izdanju;
sinhrono-commit mod za nulti gubitak podataka; asinhrono-commit za udaljene DR replike;
automatsko prebacivanje u slučaju kvara za sinhrone 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 tačku veze koja se automatski usmjerava na trenutnu primarnu tačku.

2.2 Koraci implementacije

Pripremite račune servisa Active Directory i konfigurirajte dozvole na svim čvorovima;
instalirati i validirati Windows Server Failover Clustering na svim serverima koji učestvuju;
instalirajte SQL Server kao samostalna instanca na svakom čvoru koristeći konzistentne putanje i postavke;
omogućite funkciju Grupe dostupnosti uvijek uključene putem SQL Server Upravitelj konfiguracije ili PowerShell;
postavite baze podataka na model potpunog oporavka i napravite potpune i zapisničke sigurnosne kopije;
kreirajte grupu dostupnosti, dodajte replike i konfigurirajte načine dostupnosti i prebacivanja u slučaju kvara;
postavlja sekundarne replike koristeći automatsko postavljanje ili ručno pravljenje sigurnosnih kopija i vraćanje;
kreirajte slušača grupe dostupnosti i provjerite povezanost klijenta.

Za kompletan vodič korak po korak, pogledajte naš Kompletan vodič za grupe dostupnosti Always On.

2.3 Najbolje za

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

2.4 Pros

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

2.5 Protiv

Za potpuni set funkcija potrebno je Enterprise izdanje (Standard podržava Basic AG sa značajnim ograničenjima);
sinhrono-commit mod dodaje latenciju pisanja proporcionalnu vremenu povratnog putovanja mreže;
prijave, poslovi SQL agenta i povezani serveri zahtijevaju ručnu sinhronizaciju u SQL Server 2019. i ranije;
Sve replike moraju se nalaziti na čvorovima istog Windows Server Failover klastera.

2.6 Reference

Zvanični dokument Microsofta: Šta je grupa dostupnosti "Uvijek uključeno"?
Zvanični dokument Microsofta: Početak rada s grupama dostupnosti Always On

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

Uvijek uključene instance klastera za prebacivanje u slučaju kvara (FCI) pruža visoku dostupnost na nivou 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 ponovo pokreće, što čini prelaz transparentnim za klijentske aplikacije.

3.1 Ključne karakteristike

Prebacivanje na nivo instance u slučaju kvara: sve baze podataka na instanci se prebacuju u slučaju kvara zajedno kao jedna jedinica;
dijeljena pohrana (SAN, iSCSI, Storage Spaces Direct ili SMB) dostupna svim čvorovima;
Naziv virtuelne mreže i virtuelna IP adresa pružaju stabilnu krajnju tačku veze bez obzira na to koji je čvor aktivan;
Klasterisanje za preuzimanje u slučaju kvara u sistemu Windows Server upravlja praćenjem stanja čvorova, kvorumom i orkestracijom za preuzimanje u slučaju kvara;
podržava tipove konfiguracije čvorova Aktivan/Pripravan, Aktivan/Aktivan, N+1 i N+M.

3.2 Koraci implementacije

Obezbjeđivanje i povezivanje dijeljene pohrane sa svim čvorovima klastera;
instalirajte funkciju Failover Clustering i provjerite konfiguraciju klastera;
kreirajte klaster za preuzimanje u slučaju kvara na Windows serveru i konfigurišite kvorum;
pokreni 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 preuzimanje otkaza;
Provjerite ponašanje prebacivanja u slučaju kvara testiranjem ručnog prebacivanja u slučaju kvara između čvorova.

Za kompletan vodič korak po korak, pogledajte naš SQL Server Kompletan vodič za klastere za prebacivanje u slučaju kvara.

3.3 Najbolje za

Okruženja sa postojećom infrastrukturom za dijeljeno pohranjivanje podataka (SAN ili iSCSI);
aplikacije koje zahtijevaju prebacivanje na nivo instance gdje se sve baze podataka moraju prebaciti na drugi sistem 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 nivo instance bez potrebe za rekonfiguracijom klijenta;
nema opterećenja replikacije podataka — svi čvorovi pristupaju istoj pohrani;
predvidljivo ponašanje prilikom prebacivanja na drugi sistem (failover) za sve baze podataka istovremeno;
Podržava fleksibilne konfiguracije čvorova (Aktivno/Aktivno, N+1, N+M) za optimizaciju iskorištenja hardvera.

3.5 Protiv

Dijeljeno skladištenje je potencijalna jedinstvena tačka kvara, osim ako samo skladištenje nije redundantno;
samo jedan čvor radi SQL Server istovremeno — nema balansiranja opterećenja čitanja na sekundarnim čvorovima;
nema ugrađenog oporavka od katastrofe bez uparivanja s grupom dostupnosti;
Infrastruktura za dijeljeno skladištenje podataka dodaje troškove i složenost u poređenju sa AG.

3.6 Reference

Zvanični dokument Microsofta: Instance klastera za prebacivanje u slučaju kvara koje su uvijek uključene (SQL Server)

4. Kombinujte grupe dostupnosti sa instancama klastera za preuzimanje u slučaju kvara

Za organizacije kojima je potrebna zaštita i na nivou instance i na nivou baze podataka, SQL Server podržava hostovanje replika grupa dostupnosti na instancama klastera za preuzimanje 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 nivou baze podataka na svim lokacijama. Ova kombinacija pruža najsveobuhvatniju pokrivenost visoke dostupnosti i oporavka od katastrofe dostupnu u SQL Server.

4.1 Ključne karakteristike

Dvoslojni failover: FCI obrađuje kvarove čvorova na nivou instance; AG obrađuje kvarove na nivou lokacije ili replike;
Svaki FCI se računa kao jedna replika unutar grupe dostupnosti bez obzira na to koliko čvorova FCI sadrži;
Replike hostovane od strane FCI-ja i dalje zahtijevaju dijeljeno skladištenje prema standardnim FCI zahtjevima;
AG replike hostovane na FCI-jima podržavaju samo ručno prebacivanje u slučaju kvara — automatsko prebacivanje u slučaju kvara nije dostupno za replike hostovane na FCI-ju;
Samostalne instance mogu učestvovati u istoj grupi dostupnosti zajedno s replikama hostovanim na FCI-ju.

4.2 Koraci implementacije

Implementirajte i validirajte svaki FCI nezavisno slijedeći standardne procedure postavljanja FCI-ja;
osigurati da svi FCI čvorovi i samostalni replikacijski čvorovi pripadaju istom Windows Server Failover klasteru;
omogućite funkciju Grupe dostupnosti uvijek uključene na svakoj FCI instanci;
Provjerite da nijedan WSFC čvor ne bi hostirao dvije replike iste grupe dostupnosti nakon bilo kakvog mogućeg FCI prebacivanja u slučaju kvara;
kreirajte grupu dostupnosti, označite FCI instance kao replike i konfigurirajte ručni način prebacivanja u slučaju kvara za sve replike hostovane na FCI-ju;
instalirati sekundarne replike i konfigurirati slušača grupe dostupnosti.

Za detalje o postavljanju FCI-a, pogledajte našu SQL Server Kompletan vodič za klastere za preuzimanje usluga u slučaju kvara. Za detalje o postavljanju AG-a, pogledajte naš kompletan vodič za grupe dostupnosti Always On.

4.3 Najbolje za

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

4.4 Pros

Maksimalna zaštita: kvarove čvorova rješava FCI, kvarove lokacije rješava AG;
Prelazak na FCI failover je transparentan za grupu dostupnosti — AG ne vidi promjenu replike tokom prelaska na FCI failover;
Fleksibilna topologija: miješajte replike hostovane na FCI-ju i samostalne replike u istoj grupi dostupnosti.

4.5 Protiv

Replike hostovane na FCI-ju podržavaju samo ručno prebacivanje AG-a u slučaju kvara — automatsko prebacivanje AG-a u slučaju kvara 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 kod samih AG ili FCI;
dijeljena pohrana i dalje je potrebna za svaku FCI komponentu.

4.6 Reference

Zvanični dokument Microsofta: Grupe za prebacivanje u slučaju kvara i grupe za dostupnost uvijek uključene (SQL Server)
Zvanični dokument Microsofta: Šta je grupa dostupnosti "Uvijek uključeno"?
Zvanični dokument Microsofta: Početak rada s grupama dostupnosti Always On
Zvanični dokument Microsofta: Instance klastera za prebacivanje u slučaju kvara koje su uvijek uključene (SQL Server)

5. Poređenje Always On rješenja

5.1 Tabela poređenja karakteristika

svojstvo	Grupe dostupnosti	Instance klastera za prebacivanje u slučaju kvara	Kombinovano AG + FCI
Opseg prebacivanja u slučaju kvara	Na nivou baze podataka	Na nivou instance	oba
Potrebna je dijeljena pohrana	Ne	Da	Da (za FCI komponentu)
Replikacija podataka	Na osnovu dnevnika za svaku repliku	Ništa (dijeljena pohrana)	Na osnovu dnevnika između FCI-a
Automatsko prebacivanje na grešku	Da (sinhrone replike)	Da	FCI: Da; AG: Ne
Čitljive sekundarne stavke	Da	Ne	Da (AG komponenta)
Oporavak od katastrofe	Ugrađen	Nije ugrađeno	Ugrađen
Maksimalan broj replika	9 (Preduzeće)	N / A	9 (Preduzeć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

Počnite sa svojom 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 potreban vam je failover na nivou instance, FCI je jednostavnija opcija - ali planirajte dodavanje AG kasnije 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 je da replike AG-a hostovane na FCI-ju ne podržavaju automatski AG failover, tako da ova topologija zahtijeva ručnu intervenciju za failover na nivou grupe dostupnosti.

Za većinu današnjih novih implementacija, Always On Availability Groups (Grupe dostupnosti Always On) je preporučena početna tačka: pokriva i HA i DR, ne zahtijeva dijeljeno skladištenje i podržava čitljive sekundarne resurse - mogućnosti koje FCI sam po sebi ne može dostići.

6. Najbolje prakse za SQL Server Uvijek dostupna rješenja

6.1 Planiranje i dizajn

Definišite RTO i RPO zahtjeve prije odabira Always On rješenja - ovi ciljevi direktno određuju da li je sinhroni ili asinhroni način commit-a odgovarajući i da li je automatsko prebacivanje u slučaju kvara izvodljivo.
Prilagodite sekundarne replike veličini kako bi se nosile s punim primarnim opterećenjem tokom događaja prebacivanja u slučaju kvara, uključujući scenarije vršnog opterećenja.
Za AG implementacije, postavite sinhrone replike unutar istog podatkovnog centra ili mreže s niskom latencijom kako biste smanjili utjecaj latencije pisanja. Rezervirajte asinhroni način rada za geografski udaljene DR replike.
Kvorum dizajnirajte 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 podjele mozga.
Pažljivo isplanirajte topologiju mreže za implementacije s više podmreža. Svaka podmreža zahtijeva vlastitu IP adresu slušača, a klijenti trebaju imati MultiSubnetFailover=True u svojim stringovima za povezivanje.

6.2 Smjernice za implementaciju

Koristite dosljedno SQL Server nivoi verzija, izdanja i kumulativnih ažuriranja u svim replikama. Mješoviti nivoi zakrpa mogu uzrokovati neočekivano ponašanje tokom prebacivanja u slučaju kvara.
Konfigurišite namenske mrežne interfejse za saobraćaj otkucaja srca klastera, odvojeno od saobraćaja aplikacije.
Omogući automatsko zasijavanje za početnu sinhronizaciju 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 nijedan WSFC čvor ne može hostirati dvije replike iste grupe dostupnosti.
Uvek koristite SQL Server Management Studio ili Transact-SQL za upravljanje prebacivanjem grupa dostupnosti u slučaju kvara — nikada nemojte direktno koristiti Failover Cluster Manager, jer nije svjestan stanja sinhronizacije AG-a i može uzrokovati produženi prekid rada ili gubitak podataka.

6.3 Monitoring i održavanje

Redovno pratite stanje sinhronizacije, red za slanje i red za ponavljanje pomoću kontrolne ploče grupe dostupnosti u SQL Server Management Studio ili Dynamic Management Views (DMV). Rastući red za ponavljanje na sekundarnoj liniji ukazuje na usko grlo I/O koje će odgoditi oporavak nakon kvara.
Pokrenite DBCC CHECKDB na sekundarnim replikama da biste rasteretili provjere integriteta s primarne replike. Pogledajte naše Vodič za DBCC CHECKDB za detalje.
primijeniti SQL Server Zakrpe korištenjem kontinuiranih nadogradnji: prvo zakrpite sekundarne replike, izvršite planirani ručni failover na zakrpanu sekundarnu mrežu, a zatim zakrpite prethodnu primarnu mrežu. Ovo ograničava vrijeme zastoja na trajanje jednog failovera.
Redovno testirajte prebacivanje u slučaju kvara u okruženjima koja nisu u produkciji. Automatsko prebacivanje u slučaju kvara koje nikada nije testirano nije pouzdana strategija oporavka.
Konfigurišite upozorenja za promjene stanja grupe dostupnosti, prelaze uloga replike i greške sinhronizacije pomoću SQL Server Agent ili namjenski alat za praćenje kao što je SQL Server Performance Monitor.

7. FAQ

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

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

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

A: Grupe dostupnosti funkcionišu na nivou baze podataka, repliciraju podatke na nezavisne sekundarne replike putem slanja logova i ne zahtijevaju dijeljeno skladištenje. Instance klastera za preuzimanje u slučaju kvara funkcionišu na nivou instance, zahtijevaju dijeljeno skladištenje dostupno svim čvorovima i preuzimaju sve baze podataka zajedno kao cjelinu. AG podržava čitljive sekundarne baze podataka i ugrađeni DR; FCI to ne radi.

P: Da li mi je potreban zajednički prostor za grupe dostupnosti Always On?

O: Ne. Svaka AG replika održava svoju nezavisnu kopiju baza podataka na lokalnoj pohrani. Dijeljena pohrana je potrebna samo ako koristite instance klastera za preuzimanje otkaza za hostiranje AG replika.

P: Mogu li koristiti Uvijek uključeno sa 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 podrške za čitljivu sekundarnu podršku. 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 ovo proširiti na 18 replika u dvije odvojene grupe dostupnosti.

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

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

P: Koja je razlika između sinhronog i asinhronog načina commit-a?

A: Sinhroni način commit-a zahtijeva da primarni server čeka da sekundarni server ojača zapise dnevnika prije commit-a, osiguravajući nulti gubitak podataka (RPO = 0) po cijenu dodatnog kašnjenja pisanja. Asinhroni način commit-a omogućava primarnom serveru da commit-uje 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 sinhroni server za lokalne HA replike, a asinhroni server za udaljene DR replike.

P: Koliko dugo traje SQL Server Uvijek uključeno preuzimanje rezervnog sistema?

A: Automatski failover za sinhronu AG repliku obično se završi za manje od 30 sekundi pod normalnim uslovima. FCI failover 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: Šta se dešava sa vezama klijenata tokom prebacivanja na drugi sistem 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 ponovo povezuju s novim primarnim serverom nakon što se prebacivanje u slučaju kvara završi. Dodavanje MultiSubnetFailover=True u nizove za povezivanje poboljšava brzinu ponovnog povezivanja u implementacijama s više podmreža.

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

A: Koristite kontinuirane nadogradnje: prvo zakrpite sekundarne replike, zatim izvršite planirani ručni failover na zakrpanu sekundarnu server i na kraju zakrpite prethodni primarni server. Ovo ograničava vrijeme zastoja na trajanje jednog planiranog failovera - obično manje od minute.

P: Mogu li kombinovati grupe dostupnosti Always On sa instancama klastera za preuzimanje u slučaju kvara?

O: Da. Možete hostirati AG replike na FCI instancama kako biste postigli zaštitu od kvara i na nivou instance i na nivou 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: Šta trebam učiniti ako se moja baza podataka ošteti u okruženju koje je uvijek uključeno?

A: Prvo provjerite da li je oštećenje prisutno 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. Redovno pokrenite 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 Always On porede sa starijim verzijama? SQL Server HA rješenja?

A: AG zamjenjuje starije tehnologije kao što su log shipping i replikacijaDostava 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 pružanje usluga (AG) automatski prelazak u slučaju kvara, nulti gubitak podataka sa sinhronim potvrđivanjem i čitljive sekundarne datoteke - mogućnosti s kojima se te tehnologije ne mogu mjeriti.

8. zaključak

SQL Server Always On pruža fleksibilnu platformu poslovnog nivoa za visoku dostupnost i oporavak od katastrofe. Always On Availability Groups je pravi izbor za većinu modernih implementacija: eliminiše potrebu za dijeljenom pohranom, podržava čitljive sekundarne servere i obrađuje i lokalnu HA i cross-site DR u jednoj konfiguraciji. Instance klastera za preuzimanje u slučaju kvara ostaju solidna opcija kada su prebacivanje u slučaju kvara na nivou instance i postojeća infrastruktura za dijeljeno skladištenje primarni zahtjevi. Kombinovanje obje tehnologije pruža najdublju dostupnu zaštitu - po cijenu većih ulaganja u infrastrukturu i operativne složenosti.

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

o autoru

Yuan Sheng je viši administrator baze podataka (DBA) sa preko 10 godina iskustva u SQL Server okruženja i upravljanje bazama podataka u preduzećima. Uspješno je riješio stotine scenarija oporavka baza podataka u organizacijama finansijskih usluga, zdravstva i proizvodnje.

Yuan je specijaliziran 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 za sigurnosno kopiranje i oporavak za poslovne sisteme od kritične važnosti.

Svojim tehničkim znanjem i praktičnim pristupom, Yuan se fokusira na kreiranje sveobuhvatnih vodiča koji pomažu administratorima baza podataka i IT stručnjacima da riješe složene probleme. SQL Server efikasno rješava izazove. On prati najnovije SQL Server izdanja i Microsoftove tehnologije baza podataka koje se razvijaju, redovno testirajući scenarije oporavka kako bi osigurao da njegove preporuke odražavaju najbolje prakse iz stvarnog svijeta.

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