SQL Server Grupe dostupnosti Always On: Potpuni vodič [2026]

1. Razumijevanje grupa dostupnosti Always On

1.1 Šta je to i kako funkcioniše

Grupe dostupnosti uvijek uključene (AG) su SQL Server preduzeće visoka dostupnost i rješenje za oporavak od katastrofe koje funkcionira na nivou baze podataka. Grupa dostupnosti grupira jednu ili više korisničkih baza podataka u jednu jedinicu za prebacivanje u slučaju kvara i replicira ih na do osam sekundarnih replika putem kontinuiranog slanja dnevnika transakcija. Kada primarna replika zakaže, određena sinhrona sekundarna replika automatski preuzima, vraćajući pristup u sekundama bez dijeljenog prostora za pohranu ili ručne intervencije.

1.2 Grupe dostupnosti koje su uvijek uključene u odnosu na instance klastera za prebacivanje u slučaju kvara

SQL Server Always On uključuje dvije različite tehnologije: Grupe dostupnosti (AG) i Instance klastera za preuzimanje u slučaju kvara (FCI):

	Grupe dostupnosti uvijek uključene	Instance klastera za prebacivanje u slučaju kvara uvijek uključene
Opseg prebacivanja u slučaju kvara	Na nivou baze podataka	Nivo instance (sve baze podataka se istovremeno prebacuju u slučaju kvara)
Replikacija podataka	Replikacija zasnovana na logovanju na svaku sekundarnu bazu	Ništa — svi čvorovi dijele istu pohranu
Zajednička pohrana	Nije potrebno	Obavezno (Mreža za pohranu podataka (SAN), iSCSI, S2D ili SMB)
Čitljive sekundarne stavke	Da	Ne
Oporavak od katastrofe	Ugrađeno (asinhrone replike na više lokacija)	Nije ugrađeno bez uparivanja s AG-om

Kada koristiti svaki od njih: Koristite FCI kada vam je potreban failover na nivou instance i već imate infrastrukturu dijeljene pohrane. Koristite AG kada vam je potrebna granularnost na nivou baze podataka, čitljive sekundarne strukture ili oporavak od katastrofe. Za najpotpuniju zaštitu, kombinujte oboje: pokrenite svaku repliku kao FCI čvor i povežite ih u AG.

1.3 Prednosti i ograničenja

prednosti:

• Automatsko prebacivanje u slučaju kvara sa ciljanim vremenom oporavka (RTO) gotovo nultim za sinhrone replike;
• nulti gubitak podataka (Ciljna tačka oporavka (RPO) = 0) u režimu sinhronog potvrđivanja;
• nije potrebna dijeljena pohrana — svaka replika koristi nezavisnu lokalnu pohranu;
• čitljive sekundarne servere rasterećuju izvještavanje i sigurnosne kopije s primarnog servera;
• podržava i lokalnu visoku dostupnost (HA) i oporavak od katastrofe (DR) na više lokacija unutar jedne konfiguracije.

ograničenja:

• Zahtijeva klasteriranje za preuzimanje usluga u slučaju kvara na Windows Serveru na svim replikama;
• Enterprise izdanje za puni skup funkcija (Standardno izdanje podržava Basic AG sa značajnim ograničenjima);
• sinhrono-commit mod dodaje latenciju operacijama pisanja proporcionalno vremenu povratnog putovanja mreže;
• prijave, poslovi SQL agenta i povezani serveri se ne sinhronizuju automatski u SQL Server 2019. i ranije (riješeno u SQL Server 2022 je sadržavao grupe dostupnosti).

2. Arhitektura grupa dostupnosti koje su uvijek dostupne

2.1 Osnovne komponente i koncepti

2.1.1 Baze podataka o dostupnosti

Baze podataka o dostupnosti su korisničke baze podataka koje učestvuju u grupi dostupnosti. Ove baze podataka moraju ispunjavati određene zahtjeve: moraju koristiti model potpunog oporavka, imati potpunu sigurnosnu kopiju i postojati na primarnoj replici prije nego što se dodaju u grupu dostupnosti.

Kada se baza podataka pridruži grupi dostupnosti, ona postaje dio sinhroniziranog skupa koji se prebacuje u slučaju kvara kao jedinica. Sve baze podataka u grupi dostupnosti dijele isto stanje prebacivanja u slučaju kvara, što znači da ako primarna replika zakaže, sve baze podataka se istovremeno prebacuju na istu sekundarnu repliku. Ovo osigurava konzistentnost za aplikacije koje se oslanjaju na više povezanih baza podataka.

2.1.2 Replike dostupnosti

Replike dostupnosti su SQL Server instance koje hostiraju kopije baza podataka o dostupnosti. Svaka replika održava vlastitu fizičku kopiju baza podataka, sinhronizovanu putem slanja zapisa dnevnika transakcija. Grupa dostupnosti može sadržavati do devet replika: jednu primarnu repliku i do osam sekundarnih replika.

2.1.3 Primarna replika

Primarna replika sadrži kopiju baza podataka o dostupnosti za čitanje i pisanje. Sve izmjene podataka (INSERT, AŽURIRANJE, DELETE) se dešavaju na primarnoj replici. Klijentske aplikacije se povezuju s primarnom replikom za sve operacije pisanja i, prema zadanim postavkama, i za operacije čitanja.

2.1.4 Sekundarne replike

Sekundarne replike sadrže kopije baza podataka o dostupnosti koje su samo za čitanje, a održavaju se kontinuiranom primjenom zapisa dnevnika transakcija primljenih od primarne replike. Svaka sekundarna replika prima, osigurava i primjenjuje zapise dnevnika kako bi kopije baze podataka bile sinhronizovane s primarnom.

2.2 Načini dostupnosti

2.2.1 Sinhroni režim potvrđivanja (commit mod)

Sinhrono potvrđivanje transakcija (sinhrono-commit mode) pruža zaštitu od gubitka podataka tako što zahtijeva da primarna replika čeka potvrdu da su zapisi dnevnika transakcija ojačani na sekundarnoj replici prije potvrđivanja transakcija. Ovaj mod je neophodan za konfiguracije visoke dostupnosti gdje je gubitak podataka neprihvatljiv.

2.2.2 Asinhroni način potvrđivanja (commit)

Asinhroni način izvršavanja daje prioritet performansama primarne replike omogućavajući transakcijama izvršavanje bez čekanja da sekundarne replike potvrde poboljšanje zapisnika. Ovaj način je prikladan za replike za oporavak od katastrofe ili kada latencija mreže čini sinhrono izvršavanje nepraktičnim.

Kompromis je potencijalni gubitak podataka tokom prebacivanja u drugi sistem. Ako primarna replika ne uspije, neke potvrđene transakcije možda neće stići do sekundarne replike. Količina potencijalnog gubitka podataka zavisi od propusnosti mreže, performansi sekundarne replike i vremena kvara. Organizacije moraju prihvatiti ovaj rizik kada koriste asinhroni način rada.

2.3 Vrste prebacivanja u slučaju kvara

2.3.1 Automatsko prebacivanje u slučaju kvara

Automatsko prebacivanje u slučaju kvara omogućava grupi za dostupnost da otkrije kvar primarne replike i automatski promovira sekundarnu repliku u primarnu bez intervencije administratora. Ova mogućnost minimizira vrijeme potrebno za vraćanje u prvobitno stanje eliminirajući potrebu za ručnim odgovorom na kvarove.

Automatsko prebacivanje u slučaju kvara zahtijeva sinhroni način potvrđivanja kako bi se osiguralo da nema gubitka podataka. Kada je omogućeno, grupa za dostupnost kontinuirano prati stanje primarne replike. Ako primarna replika prestane reagirati ili ne uspije, klaster za prebacivanje u slučaju kvara Windows Servera pokreće automatsko prebacivanje u slučaju kvara na određenu sekundarnu repliku.

2.3.2 Ručno prebacivanje u slučaju kvara

Ručno prebacivanje u slučaju kvara omogućava administratorima da namjerno prebace ulogu primarne replike na sekundarnu repliku, obično u svrhu planiranog održavanja ili testiranja. Za razliku od automatskog prebacivanja u slučaju kvara, ručno prebacivanje u slučaju kvara zahtijeva eksplicitnu akciju administratora za pokretanje.

Ručno prebacivanje u slučaju kvara bez gubitka podataka dostupno je za replike sa sinhronim potvrđivanjem. Administrator pokreće prebacivanje u slučaju kvara putem SQL Server Management Studio, Transact-SQL ili PowerShell. Primarna replika završava obradu trenutnih transakcija, šalje sve preostale zapise dnevnika ciljnom sekundarnom serveru i čeka potvrdu prije prijenosa primarne uloge.

Ručno prebacivanje u slučaju kvara može se desiti i kod asinhronih replika sa potvrdom, ali to zahtijeva prisilno prebacivanje u slučaju kvara s potencijalnim gubitkom podataka. Administratori bi trebali koristiti prisilno ručno prebacivanje u slučaju kvara samo tokom stvarnih scenarija katastrofe kada primarna replika nije dostupna i gubitak podataka je prihvatljiv u poređenju s produženim zastojem.

2.3.3 Prisilno prebacivanje u slučaju kvara

Prisilni failover omogućava prebacivanje na asinhronu sekundarnu repliku ili na sekundarnu repliku koja nije u potpunosti sinhronizovana, uz eksplicitno priznanje potencijalnog gubitka podataka. Ova opcija služi kao posljednje rješenje kada primarna replika nije dostupna i ne postoji sinhronizovana sekundarna replika.

2.4 Sinkronizacija podataka

2.4.1 Kako funkcioniše sinhronizacija podataka

Sinhronizacija podataka u grupama dostupnosti Always On vrši se putem kontinuiranog slanja zapisa dnevnika transakcija iz primarne replike u sve sekundarne replike. Ova sinhronizacija zasnovana na dnevniku osigurava konzistentnost, a istovremeno omogućava nezavisno pohranjivanje za svaku repliku.

2.4.2 Zapisi dnevnika transakcija i osiguranje

Zaštita zapisa dnevnika transakcija je ključni korak u kojem se zapisi dnevnika upisuju u trajnu pohranu na sekundarnim replikama. Zaštita osigurava da zapisi dnevnika prežive kvarove sekundarnih replika i da se mogu ponovo reproducirati tokom oporavka.

2.5 Sekundarne replike skale čitanja i čitljive sekundarne replike

2.5.1 Rasterećenje radnih opterećenja samo za čitanje

Čitljive sekundarne replike omogućavaju organizacijama da rasterete opterećenja koja zahtijevaju puno čitanja s primarne replike, poboljšavajući ukupne performanse sistema i iskorištenost resursa. Ova mogućnost skaliranja čitanja jedna je od ključnih prednosti grupa dostupnosti u odnosu na starija rješenja visoke dostupnosti.

Organizacije bi trebale uzeti u obzir zahtjeve za radno opterećenje samo za čitanje prilikom dizajniranja konfiguracija grupa dostupnosti. Višestruki sekundarni serveri koji se mogu čitati mogu distribuirati opterećenje izvještavanja na nekoliko servera. Liste usmjeravanja samo za čitanje definiraju redoslijed kojim sekundarni serveri primaju veze s namjerom čitanja, omogućavajući strategije balansiranja opterećenja.

2.5.2 Operacije pravljenja sigurnosnih kopija na sekundarnim replikama

Pokretanje sigurnosnih kopija na sekundarnim replikama smanjuje opterećenje ulazno/izlaznih operacija (I/O) i centralne procesorske jedinice (CPU) na primarnoj replici, omogućavajući joj da se fokusira na transakcijska opterećenja. Ova mogućnost pomaže organizacijama da ispune zahtjeve za sigurnosnom kopijom bez utjecaja na performanse produkcije.

SQL Server Podržava potpune sigurnosne kopije baze podataka, diferencijalne sigurnosne kopije i sigurnosne kopije dnevnika transakcija na sekundarnim replikama. Postavke sigurnosne kopije mogu se konfigurirati tako da se preferiraju sekundarne replike, preferira primarna, samo sekundarna ili bilo koja replika. Sistem sigurnosne kopije automatski odabire odgovarajuću repliku na osnovu ovih postavki i trenutne dostupnosti.

Za više detalja o SQL Server sigurnosna kopija, pogledajte našu sveobuhvatni vodič.

2.6 Slušači grupe dostupnosti

2.6.1 Šta je slušač?

Slušač grupe dostupnosti je naziv virtuelne mreže (VNN) i IP adresa koju klijentske aplikacije koriste za povezivanje sa bazama podataka grupe dostupnosti. Slušač automatski preusmjerava veze na trenutnu primarnu repliku, eliminirajući potrebu da aplikacije prate koji je server trenutno primarni.

2.6.2 Rutiranje klijentske veze

Rutiranje klijentske veze putem slušača podržava i namjere povezivanja za čitanje i pisanje i samo za čitanje. Slušač pregledava zahtjev za povezivanje i usmjerava ga do odgovarajuće replike na osnovu namjere aplikacije.

3. Preduslovi i zahtjevi

3.1 Klasterisanje za preuzimanje usluga u slučaju kvara u Windows Serveru za grupe dostupnosti

3.1.1 Osnove klasteriranja za preuzimanje u slučaju kvara na Windows Serveru

Klasteriranje za preuzimanje u slučaju kvara u sistemu Windows Server (WSFC) pruža osnovu za grupe dostupnosti koje se uvijek uključuju upravljanjem članstvom u klasteru, praćenjem ispravnosti i orkestracijom preuzimanja u slučaju kvara. Za razliku od instanci klastera za preuzimanje u slučaju kvara, grupe dostupnosti koriste WSFC samo za koordinaciju klastera, a ne za upravljanje dijeljenom pohranom.

svaki SQL Server Instanca koja učestvuje u grupi dostupnosti mora biti čvor u WSFC klasteru. Klaster upravlja glasanjem kvoruma, detekcijom zdravlja čvora i stanjem resursa grupe dostupnosti. Kada primarna replika zakaže, WSFC koordinira proces prebacivanja u drugi sistem i ažurira resurse klastera kako bi odražavali novu primarnu repliku.

3.1.2 Konfiguracija kvoruma klastera

Kvorum klastera određuje koji čvorovi mogu raditi kada se pojave problemi s mrežnom povezivošću, sprječavajući scenarije podjele mozga u kojima više čvorova nezavisno tvrdi da su primarni. Konfiguracija kvoruma definira šta predstavlja većinu glasova za odluke klastera.

Za grupe dostupnosti dostupno je nekoliko kvorumskih načina rada:

• Većina čvorova koristi samo glasove čvorova klastera i dobro funkcioniše za klastere sa neparnim brojem čvorova.
• Većina čvorova i dijeljenja datoteka dodaje glas svjedoka dijeljenja datoteka, pogodan za klastere čvorova s ​​parnim brojem.
• Node and Disk Majority koristi svjedoka diska, ali je rjeđi za grupe dostupnosti jer dijeljeno pohranjivanje nije potrebno.

3.1.3 Grupiranje više podmreža

Grupiranje u više podmreža omogućava replikama grupa dostupnosti da se protežu kroz različite mrežne podmreže, podržavajući geografski distribuirane implementacije u podatkovnim centrima. Ova mogućnost je ključna za konfiguracije oporavka od katastrofe gdje replike postoje na odvojenim lokacijama.

3.2 SQL Server Zahtjevi izdanja

3.2.1 Funkcije Enterprise izdanja

SQL Server Enterprise izdanje pruža punu funkcionalnost grupa dostupnosti bez ograničenja. Enterprise izdanje podržava do osam sekundarnih replika, čitljive sekundarne replike, automatsko zasijavanje, distribuirane grupe dostupnosti i sve napredne funkcije.

3.2.2 Funkcije standardnog izdanja (osnovne grupe dostupnosti)

SQL Server Standardno izdanje 2016 i novije podržavaju osnovne grupe dostupnosti sa značajnim ograničenjima. Osnovne grupe dostupnosti pružaju osnovnu funkcionalnost visoke dostupnosti po nižoj cijeni, pogodnu za organizacije sa jednostavnijim zahtjevima.

4. Konfigurisanje grupa dostupnosti Always On

4.1 Priprema okruženja

Prije kreiranja grupe dostupnosti, okruženje mora biti pravilno pripremljeno s Active Directory računima, konfiguracijama servera i mrežnom infrastrukturom.

4.1.1 Podešavanje kontrolera domene

Kontroler domene Active Directory mora biti konfiguriran da podržava klaster grupe dostupnosti i SQL Server servisni računi.

1. Prijavite se na kontroler domene s vjerodajnicama administratora domene.
2. otvoreno server Manager i idite do Alat -> Korisnici i računari Active Directory.
3. Kreirajte organizacijsku jedinicu za SQL Server objekte ako jedan ne postoji.
4. Provjerite da li računarski objekti za sve čvorove klastera postoje u Active Directory-ju.
5. Osigurajte da su DNS (Domain Name System) usluge ispravno konfigurirane i da se sva imena servera ispravno razrješavaju.

4.1.2 Kreiranje servisnih računa

Kreirajte namjenske račune usluge Active Directory za SQL Server usluge na svakom čvoru.

1. otvoreno Korisnici i računari Active Directory na kontroleru domene.
2. Kliknite desnim tasterom miša na odgovarajuću organizacionu jedinicu i izaberite Novi -> Korisnik.
3. Unesite naziv servisnog računa (na primjer, svc_SQLServer) i postavite Korisničko ime za prijavu.
4. kliknite sljedeći i unesite jaku lozinku.
5. izabrati Korisnik ne može promijeniti lozinku i Lozinka nikada ne ističe.
6. kliknite sljedeći i onda završiti da kreirate nalog.
7. Ponovite za sve dodatne servisne račune koji su vam potrebni (SQL Server Agent, SSRS, itd.).

4.1.3 Konfigurisanje administratorskih dozvola

Servisni računi i računi koji se koriste za konfiguraciju SQL Server mora imati odgovarajuće dozvole na svim čvorovima klastera.

1. Prijavite se na svaki server čvora klastera.
2. otvoreno Upravljanje računarima iz Start meni ili Upravitelj servera.
3. Proširiti Lokalni korisnici i grupe i izaberite Grupe.
4. Desni klik administratori i izaberite svojstva.
5. kliknite dodati i unesite naziv servisnog računa.
6. kliknite Provjerite imena da biste potvrdili račun, a zatim kliknite OK.
7. kliknite OK da biste zatvorili dijalog Svojstva administratora.
8. Ponovite na svim čvorovima klastera.

4.2 Instaliranje i konfigurisanje WSFC-a

Grupe za preuzimanje usluga u slučaju kvara u sistemu Windows Server moraju biti instalirane i konfigurirane na svim čvorovima prije omogućavanja grupa dostupnosti koje su uvijek uključene.

4.2.1 Instaliranje funkcije klasteriranja u slučaju kvara

Instalirajte funkciju Failover Clustering na svaki server koji će učestvovati u grupi dostupnosti.

1. otvoreno server Manager na prvom čvoru klastera.
2. kliknite upravljati -> Dodajte uloge i karakteristike.
3. kliknite sljedeći kroz uvodne ekrane.
4. izabrati Instalacija zasnovana na ulozi ili karakteristikama i kliknite sljedeći.
5. Odaberite lokalni server i kliknite sljedeći.
6. Preskočite ekran Uloge i kliknite sljedeći.
7. Na ekranu Funkcije odaberite Klasteriranje preusmjeravanja.
8. kliknite Dodajte funkcije kada se od vas zatraži da uključite alate za upravljanje.
9. kliknite sljedeći i onda Instaliraj.
10. Sačekajte da se instalacija završi i kliknite blizu.
11. Ponovite na svim serverima koji će učestvovati u klasteru.

4.2.2 Kreiranje klastera za prebacivanje u slučaju kvara

Nakon instaliranja funkcije Failover Clustering na sve čvorove, kreirajte klaster iz jednog čvora.

1. otvoreno Failover Cluster Manager od server Manager -> Alat.
2. kliknite Kreiraj klaster u oknu Akcije.
3. kliknite sljedeći na stranici Prije nego što počnete.
4. kliknite Pregled i dodajte sve servere koji će biti čvorovi klastera.
5. kliknite sljedeći nakon dodavanja svih čvorova.
6. ostaviti Pokreni sve testove (preporučeno) odabrano i kliknite sljedeći.
7. Pregledajte rezultate testa validacije i ispravite sve greške ili upozorenja.
8. kliknite završiti nakon uspješnog završetka validacije.
9. Unesite naziv za klaster i IP adresu.
10. Uklonite Dodajte svu odgovarajuću pohranu u klaster jer dijeljena pohrana nije potrebna.
11. kliknite sljedeći i pregledajte potvrdu.
12. kliknite završiti da se kreira klaster.

4.2.3 Validacija konfiguracije klastera

Provjerite konfiguraciju klastera kako biste osigurali da svi čvorovi mogu ispravno komunicirati i da klaster ispravno radi.

1. In Failover Cluster Manager, kliknite desnim tasterom miša na naziv klastera.
2. izabrati Validiraj klaster iz menija.
3. kliknite sljedeći na stranici Prije nego što počnete.
4. izabrati Pokreni sve testove (preporučeno) i kliknite sljedeći.
5. kliknite sljedeći za početak validacijskih testova.
6. Pregledajte izvještaj o validaciji kada testovi budu završeni.
7. Riješite sve greške ili upozorenja identifikovana u izvještaju.
8. kliknite završiti da zatvorite čarobnjaka.

4.3 Instaliranje SQL Server za grupe dostupnosti

Instaliraj SQL Server na svakom čvoru koji će učestvovati u grupi dostupnosti koristeći opciju samostalne instalacije.

1. Pokrenite SQL Server instalacijski medij na prvom čvoru.
2. izabrati Novi SQL Server samostalna instalacija.
3. Unesite ključ proizvoda ili odaberite probno izdanje.
4. Prihvatite uslove licence i kliknite sljedeći.
5. Izvršite preduvjetne provjere i riješite sve probleme.
6. Na stranici Odabir funkcija odaberite Usluge baze podataka.
7. Konfigurišite naziv instance (koristite isti naziv instance na svim čvorovima).
8. Na stranici Konfiguracija servera navedite vjerodajnice servisnog računa.
9. Konfigurišite tipove pokretanja servisa kao automatski.
10. Na stranici Konfiguracija mehanizma baze podataka odaberite način autentifikacije.
11. Dodajte administratorske račune.
12. Konfigurišite direktorijume podataka koristeći konzistentne putanje kroz sve čvorove.
13. Završite instalaciju i provjerite uspjeh.
14. Ponovite instalaciju na svim ostalim čvorovima klastera s identičnim postavkama.

4.4 Omogućavanje funkcije grupa dostupnosti koje su uvijek uključene

Nakon instalacije SQL Server Na svim čvorovima omogućite funkciju Grupe dostupnosti koje su uvijek uključene na svakoj instanci.

4.4.1 Omogućavanje putem SQL Server konfiguracijski menadžer

upotreba SQL Server Upravitelj konfiguracije za omogućavanje grupa dostupnosti Always On putem grafičkog sučelja.

1. otvoreno SQL Server konfiguracijski menadžer na prvom čvoru.
2. Proširiti SQL Server usluge u levom oknu.
3. Desni klik na SQL Server instancu i odaberite svojstva.
4. kliknite Visoka dostupnost AlwaysOn tab.
5. Check Omogući grupe dostupnosti AlwaysOn.
6. Provjerite je li naziv Windows klastera za preuzimanje u slučaju kvara ispravan.
7. kliknite OK da sačuvate promene.
8. kliknite OK na upozorenje da se usluga mora ponovo pokrenuti.
9. Desni klik na SQL Server uslugu i odaberite Ponovo pokreni.
10. Sačekajte da se servis uspješno ponovo pokrene.
11. Ponovite na svim čvorovima klastera.

4.4.2 Omogućavanje putem PowerShella

PowerShell pruža skriptiranu metodu za omogućavanje grupa dostupnosti Always On na više čvorova.

1. Otvorite PowerShell kao administrator na prvom čvoru.
2. Uvezite SQL Server PowerShell modul:

   Import-Module SQLPS -DisableNameChecking

3. Omogući grupe dostupnosti koje su uvijek uključene:

   Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force

4. Servis će se automatski ponovo pokrenuti kada se koristi parametar Force.
5. Provjerite je li funkcija omogućena:

   Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled

6. Ponovite za svaki čvor klastera, zamjenjujući odgovarajuća imena servera i instance.

4.4.3 Provjera da li je funkcija omogućena

Prije nego što nastavite s konfiguracijom, provjerite jesu li Grupe dostupnosti uvijek uključene omogućene na svim instancama.

1. Povežite se sa svakim SQL Server instanca korištenjem SQL Server ManagementStudio.
2. Otvorite novi prozor za upit i izvršite naredbu:

   SELECT SERVERPROPERTY('IsHadrEnabled')

3. Provjerite je li rezultat 1 (omogućeno).
4. Proveri to SQL Server Instanca se pojavljuje u Upravitelju klastera za preuzimanje otkaza pod ulogama klastera.
5. Provjerite postoji li krajnja tačka grupe dostupnosti izvršavanjem:

   SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'

6. Ako krajnja tačka ne postoji, biće kreirana tokom kreiranja grupe dostupnosti.

4.5 Priprema baza podataka za grupe dostupnosti

Baze podataka moraju ispunjavati određene zahtjeve prije nego što se mogu dodati u grupu dostupnosti.

4.5.1 Zahtjevi modela oporavka baze podataka

Promijenite model oporavka baze podataka na PUNI na primarnoj replici prije nego što je dodate u grupu dostupnosti.

1. Povežite se s primarnom replikom koristeći SQL Server ManagementStudio.
2. Desnim klikom miša kliknite na bazu podataka i odaberite svojstva.
3. Izaberite mogućnosti stranici.
4. promjena Model oporavka to Full.
5. kliknite OK da sačuvate promjenu.
6. Alternativno, koristite Transact-SQL:

   ALTER DATABASE DatabaseName SET RECOVERY FULL;

4.5.2 Pravljenje potpunih sigurnosnih kopija baze podataka

Napravite potpunu sigurnosnu kopiju baze podataka kako biste uspostavili lanac sigurnosnih kopija potreban za grupe dostupnosti.

1. In SQL Server Management Studio, kliknite desnim tasterom miša na bazu podataka.
2. izabrati zadaci -> Back Up.
3. provjeriti Vrsta rezervne kopije je postavljeno na Full.
4. Odaberite odredište sigurnosne kopije ili dodajte novo odredište.
5. kliknite OK da izvršite sigurnosnu kopiju.
6. Alternativno, koristite Transact-SQL:

   BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';

4.5.3 Pravljenje sigurnosnih kopija dnevnika transakcija

Napravite sigurnosnu kopiju dnevnika transakcija kako biste osigurali da je lanac dnevnika uspostavljen i smanjili vrijeme inicijalizacije.

1. In SQL Server Management Studio, kliknite desnim tasterom miša na bazu podataka.
2. izabrati zadaci -> Back Up.
3. promjena Vrsta rezervne kopije to Dnevnik transakcija.
4. Odaberite odredište sigurnosne kopije.
5. kliknite OK da izvršite sigurnosnu kopiju.
6. Alternativno, koristite Transact-SQL:

   BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';

4.6 Kreiranje grupe dostupnosti

Kreirajte grupu dostupnosti koristeći jednu od nekoliko dostupnih metoda, ovisno o vašim preferencijama i zahtjevima automatizacije.

4.6.1 Korištenje čarobnjaka za novu grupu dostupnosti

Čarobnjak za novu grupu dostupnosti pruža grafički interfejs za kreiranje grupa dostupnosti.

1. In SQL Server Management Studio, povežite se s instancom koja će hostirati primarnu repliku.
2. Proširiti Visoka dostupnost AlwaysOn u Istraživaču objekata.
3. Desni klik Grupe dostupnosti i izaberite Novi čarobnjak grupe dostupnosti.
   
4. kliknite sljedeći na Uvodnoj stranici.
5. Unesite naziv za grupu dostupnosti i kliknite sljedeći.
6. Na stranici Odabir baza podataka odaberite baze podataka koje želite uključiti.
7. Provjerite da li baze podataka ispunjavaju sve preduvjete i kliknite sljedeći.
8. Na stranici Navedite replike kliknite Dodaj repliku.
9. Povežite se sa svakom sekundarnom replikom instance.
10. Konfigurišite svojstva replike za svaku instancu (režim dostupnosti, režim prebacivanja u slučaju kvara).
11. kliknite Krajnje točke i pregledajte konfiguraciju krajnje tab-e.
12. kliknite Postavke sigurnosne kopije karticu i konfigurirajte prioritete sigurnosne kopije.
13. kliknite slušalac tabulator i opcionalno kreirajte slušača.
14. kliknite sljedeći i odaberite metodu sinhronizacije podataka.
15. Pregledajte rezultate validacije i riješite sve probleme.
16. kliknite sljedeći i pregledajte sažetak.
17. kliknite završiti da biste kreirali grupu dostupnosti.
18. Pratite napredak i provjerite uspješno kreiranje.

4.6.2 Korištenje Transact-SQL-a

Kreirajte grupe dostupnosti koristeći Transact-SQL za skriptibilne i ponovljive implementacije.

1. Kreirajte grupu dostupnosti na primarnoj replici:

   CREATE AVAILABILITY GROUP AG_Name
   FOR DATABASE DatabaseName
   REPLICA ON
     'PrimaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
     'SecondaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

2. Pridružite sekundarnu repliku grupi dostupnosti:

   ALTER AVAILABILITY GROUP AG_Name JOIN;

3. Pridružite se sekundarnoj bazi podataka:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 Korištenje PowerShella

PowerShell pruža mogućnosti skriptiranja za kreiranje i upravljanje grupama dostupnosti.

1. Kreirajte objekat grupe dostupnosti:

   $AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"

2. Dodajte baze podataka:

   Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

3. Konfigurišite replike sa željenim svojstvima pomoću cmdleta New-SqlAvailabilityReplica.
4. Pridružite sekundarne replike pomoću cmdleta Join-SqlAvailabilityGroup.

4.7 Dodavanje replika u grupu dostupnosti

Konfigurišite svojstva specifična za repliku koja kontrolišu kako svaka instanca učestvuje u grupi dostupnosti.

4.7.1 Konfigurisanje svojstava replike

Postavite svojstva za svaku repliku kako biste definirali njenu ulogu i mogućnosti unutar grupe dostupnosti.

1. In SQL Server Management Studio, proširi Visoka dostupnost AlwaysOn -> Grupe dostupnosti.
2. Proširite grupu dostupnosti, a zatim proširite Replike dostupnosti.
   
3. Kliknite desnim tasterom miša na repliku i izaberite svojstva.
4. Pregledajte i izmijenite postavke veze za primarnu i sekundarnu ulogu.
5. Konfigurirajte vrijednosti vremenskog ograničenja sesije ako je potrebno.
6. kliknite OK da sačuvate promene.

4.7.2 Postavljanje načina dostupnosti

Konfigurišite režim dostupnosti da biste kontrolisali ponašanje sinhronizacije između replika.

1. Kliknite desnim tasterom miša na grupu dostupnosti i izaberite svojstva.
2. U Opšti stranicu, idite na Replike dostupnosti sekcija.
3. Za svaku repliku odaberite Sinhrono potvrđivanje (commit) or Asinhroni commit iz padajućeg mesta.
4. Koristite sinhrono potvrđivanje (commit) za lokalne replike visoke dostupnosti.
5. Koristite asinhrono potvrđivanje (commit) za geografski udaljene replike oporavka od katastrofe.
6. kliknite OK da sačuvate konfiguraciju.

4.7.3 Postavljanje režima prebacivanja u slučaju kvara

Konfigurišite režim prebacivanja u slučaju kvara da biste kontrolisali kako se prebacivanje u slučaju kvara dešava za svaku repliku.

1. Kliknite desnim tasterom miša na grupu dostupnosti i izaberite svojstva.
2. U Opšti stranicu, idite na Replike dostupnosti sekcija.
3. Za sinhrone replike potvrđivanja, odaberite automatski or priručnik režim prebacivanja u slučaju kvara.
4. Automatsko prebacivanje u slučaju kvara zahtijeva sinhroni način potvrđivanja i omogućava nenadzirano prebacivanje u slučaju kvara.
5. Za asinhrone replike potvrđivanja (commit), dostupan je samo ručni failover.
6. Konfigurišite do tri replike za automatsko prebacivanje u slučaju kvara (jednu primarnu i dvije sekundarne).
7. kliknite OK za primjenu postavki.

4.7.4 Konfigurisanje postavki sigurnosne kopije

Postavite postavke sigurnosne kopije kako biste kontrolirali gdje bi se operacije sigurnosne kopije trebale odvijati.

1. Kliknite desnim tasterom miša na grupu dostupnosti i izaberite svojstva.
2. izabrati Postavke sigurnosne kopije u levom oknu.
3. Odaberite jednu od postavki sigurnosne kopije:
   • Radije sekundarnoSigurnosne kopije na sekundarnoj ako su dostupne, inače na primarnoj
   • Samo sekundarnoSigurnosne kopije samo na sekundarnim replikama
   • osnovniSigurnosne kopije samo na primarnoj replici
   • Bilo koja replikaSigurnosne kopije na bilo kojoj dostupnoj replici
4. Postavite vrijednosti prioriteta sigurnosne kopije za svaku repliku (0-100).
5. Više vrijednosti prioriteta označavaju preferirane ciljeve sigurnosne kopije.
6. kliknite OK da sačuvate postavke.

4.8 Konfigurisanje slušača grupe dostupnosti

Kreirajte slušača koji će obezbijediti jednu tačku povezivanja koja automatski preusmjerava na trenutnu primarnu repliku.

4.8.1 Kreiranje slušača

Dodajte slušača u grupu dostupnosti za upravljanje vezama klijenata.

1. In SQL Server Management Studio, proširite grupu dostupnosti.
2. Desni klik Slušači grupe dostupnosti i izaberite Dodaj slušaoca.
   
3. Unesite DNS naziv za slušača (na primjer, AG_Listener).
4. Unesite broj porta (zadano je 1433).
5. izabrati Statička IP adresa za mrežni način rada.
6. kliknite dodati da biste dodali IP adresu za svaku podmrežu.
7. Unesite IP adresu i odaberite podmrežu.
8. kliknite OK da kreira slušaoca.
9. Provjerite da li se slušač pojavljuje u Object Exploreru i da li je online.

4.8.2 Konfigurisanje DNS i IP postavki

Provjerite DNS registraciju i konfiguraciju mreže za slušača.

1. Otvorite DNS Manager na kontroleru domene.
2. Provjerite je li ime slušača registrirano sa svim IP adresama.
3. Testiranje DNS rezolucije sa klijentskih mašina:

   nslookup ListenerName

4. Provjerite da li su vraćene sve konfigurirane IP adrese.
5. U Upravitelju klastera za preuzimanje u slučaju kvara, proširite uloge i odaberite grupu dostupnosti.
6. Provjerite jesu li resursi IP adrese dostupni na mreži.
7. Provjerite je li resurs mrežnog imena dostupan na mreži.
   

4.8.3 Testiranje povezivosti slušača

Provjerite da li se klijentske aplikacije mogu povezati putem slušača.

1. Sa klijentskog računara, otvorite SQL Server ManagementStudio.
2. Povežite se koristeći ime slušača umjesto imena servera.
3. Izvršite upit za provjeru veze s trenutnom primarnom replikom:

   SELECT @@SERVERNAME;

4. Testirajte usmjeravanje s namjerom čitanja dodavanjem ApplicationIntent=ReadOnly u niz za povezivanje.
5. Provjerite preusmjeravanje veze na čitljivu sekundarnu repliku.
6. Testirajte prebacivanje u slučaju kvara ručnim prebacivanjem grupe dostupnosti i provjerom ponovnog povezivanja.

4.9 Metode sinhronizacije podataka

Odaberite metodu sinhronizacije podataka za inicijalizaciju sekundarnih replika s kopijama baze podataka.

4.9.1 Automatsko sjetenje

Automatsko zasijavanje prenosi podatke baze podataka preko mreže bez potrebe za ručnim sigurnosnim kopijama i vraćanjima.

1. Tokom kreiranja grupe dostupnosti, odaberite Automatsko sejanje kao metoda sinhronizacije.
   
2. Osigurajte mrežnu povezanost i dovoljan propusni opseg između replika.
3. Primarna replika automatski prenosi podatke baze podataka na sekundarne replike.
4. Pratite napredak početne faze pomoću kontrolne ploče grupe dostupnosti ili DMV-ova.
5. Automatsko sjetenje zahtijeva SQL Server 2016 ili noviji.
6. Za velike baze podataka, uzmite u obzir utjecaj mreže i rasporedite rad tokom perioda niske upotrebe.

4.9.2 Ručno zasijavanje (sigurnosna kopija i vraćanje)

Ručno zasijavanje uključuje pravljenje sigurnosnih kopija na primarnoj serverskoj bazi i njihovo vraćanje na sekundarne replike.

1. Na primarnoj replici napravite potpunu sigurnosnu kopiju:

   BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';

2. Napravite sigurnosnu kopiju dnevnika transakcija:

   BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';

3. Na svakoj sekundarnoj replici, vratite potpunu sigurnosnu kopiju:

   RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;

4. Vratite sigurnosnu kopiju dnevnika:

   RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;

5. Pridružite bazu podataka grupi dostupnosti:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

6. Provjerite da li sinhronizacija počinje i da li baza podataka dostiže stanje SINHRONIZOVANO.

4.9.3 Datoteke snimaka baze podataka

Koristite datoteke snimki baze podataka za inicijalizaciju sekundarnih replika iz postojećih datoteka baze podataka.

1. Odvojite ili napravite sigurnosnu kopiju baze podataka na primarnoj replici.
2. Kopirajte datoteke baze podataka u svaku sekundarnu repliku koristeći iste putanje datoteka.
3. Na sekundarnim replikama, priložite bazu podataka ili je vratite bez oporavka.
4. Provjerite je li baza podataka u stanju OBNAVLJANJA.
5. Pridružite bazu podataka grupi dostupnosti.
6. Ova metoda je korisna za vrlo velike baze podataka gdje bi mrežni prijenos bio nepraktičan.

5. FAQ

5.1 Opšta pitanja

P: Koja je razlika između Always On FCI i Always On AG?

A: Instance klastera Always On Failover pružaju visoku dostupnost na nivou instance koristeći dijeljeno skladištenje, dok grupe dostupnosti Always On pružaju visoku dostupnost na nivou baze podataka bez dijeljenog skladištenja. AG nudi čitljive sekundarne resurse i fleksibilniju geografsku distribuciju.

P: Mogu li koristiti grupe dostupnosti Always On sa SQL Server Standardno izdanje?

O: Da, SQL Server Standardno izdanje 2016 i novije verzije podržavaju osnovne grupe dostupnosti s ograničenjima koja uključuju jednu bazu podataka po grupi dostupnosti, maksimalno dvije replike i nedostatak podrške za čitljivu sekundarnu grupu.

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

O: Ne, grupe dostupnosti ne zahtijevaju dijeljeno skladištenje. Svaka replika održava nezavisne kopije baza podataka na lokalnom skladištu, sinhronizovane putem slanja dnevnika transakcija.

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 podržati do ukupno 18 replika u dvije grupe dostupnosti.

5.2 Pitanja o konfiguraciji

P: Kako da biram između sinhronog i asinhronog načina potvrđivanja (commit)?

A: Koristite sinhrono potvrđivanje (commit) za zahtjeve bez gubitka podataka unutar istog podatkovnog centra ili mreža s niskom latencijom. Koristite asinhrono potvrđivanje (commit) za udaljene replike oporavka od katastrofe gdje bi sinhrono potvrđivanje (commit) utjecalo na performanse.

P: Mogu li miješati sinhrone i asinhrone replike u istoj grupi dostupnosti?

O: Da, grupe dostupnosti podržavaju mješovite konfiguracije sa sinhronim i asinhronim replikama. Ovo omogućava lokalnu visoku dostupnost sa sinhronim replikama i udaljeni oporavak od katastrofe sa asinhronim replikama.

P: Šta se dešava sa mojim vezama tokom prebacivanja na drugi sistem?

A: Postojeće veze se prekidaju kada dođe do prebacivanja u slučaju kvara. Aplikacije s logikom ponovnog pokušaja povezivanja automatski se ponovo povezuju s novim primarnim serverom putem slušača. Proces prebacivanja u slučaju kvara obično se završava u roku od nekoliko sekundi do nekoliko minuta.

P: Da li trebam sinhronizovati prijave i poslove između replika?

O: U SQL Server 2019 i ranije, da – prijave, poslovi SQL agenta i povezani serveri moraju se ručno sinhronizovati. SQL Server Verzija 2022 uvodi sadržane grupe dostupnosti koje automatski uključuju ove objekte.

5.3 Pitanja upravljanja

P: Mogu li pokretati sigurnosne kopije na sekundarnim replikama?

O: Da, sekundarne replike podržavaju potpune, diferencijalne i sigurnosne kopije dnevnika transakcija. Konfigurirajte postavke sigurnosne kopije kako biste rasteretili sigurnosne kopije s primarne replike i smanjili korištenje njenih resursa.

P: Kako da zakrpim SQL Server sa minimalnim zastojem?

A: Koristite postupne nadogradnje tako što ćete prvo zakrpiti sekundarne replike, zatim izvršiti ručno prebacivanje na zakrpanu sekundarnu repliku i na kraju zakrpiti prethodnu primarnu repliku. Ovo minimizira vrijeme zastoja zbog trajanja prebacivanja na drugu repliku.

P: Mogu li dodati baze podataka postojećoj grupi dostupnosti?

A: Da, baze podataka mogu se dodati aktivnim grupama dostupnosti. Baza podataka mora biti u modelu potpunog oporavka s potpunom sigurnosnom kopijom, a sekundarne replike moraju biti zasijane automatskim zasijavanjem ili ručnom sigurnosnom kopijom i vraćanjem.

P: Šta je automatsko sjetenje i da li bih ga trebao koristiti?

A: Automatsko zasijevanje prenosi podatke baze podataka preko mreže kako bi se inicijalizirale sekundarne replike bez ručnih sigurnosnih kopija. Koristite ga za manje baze podataka ili kada je propusnost mreže dovoljna. Za vrlo velike baze podataka, ručno zasijevanje može biti brže.

P: Gdje trebam pokrenuti DBCC CHECKDB u grupi dostupnosti?

A: Trebali biste pokrenuti DBCC CHECKDB na sekundarnim replikama kako biste smanjili opterećenje primarne replike. Provjere konzistentnosti baze podataka mogu se izvršiti na sekundarnim bazama podataka bez utjecaja na performanse primarne replike.

Za više detalja o DBCC CHECKDB, pogledajte našu sveobuhvatni vodič.

5.4 Pitanja o rješavanju problema

P: Zašto je moja baza podataka u stanju NIJE SINHRONIZIRANA?

A: Uobičajeni uzroci uključuju probleme s mrežnom povezivošću, obustavljeno premještanje podataka, nedovoljan prostor na disku na sekundarnim replikama ili probleme s krajnjim tačkama. Provjerite opis stanja sinhronizacije i SQL Server zapisnike grešaka za specifične detalje. Ako je sekundarna baza podataka ušla u stanje oporavka ili emisije oporavak na čekanju, pogledajte povezane vodiče za ciljane ispravke.

P: Kako da prisilim prebacivanje na drugi sistem kada primarni server nije dostupan?

A: Povežite se sa sekundarnom replikom i izvršite ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS. Ovo potvrđuje potencijalni gubitak podataka i odmah promoviše sekundarnu repliku u primarnu.

P: Zašto se klijenti ne mogu povezati s mojim slušačem?

A: Provjerite je li slušač online u Failover Cluster Manageru, DNS registracija uspješna, sve IP adrese slušača dostupne su klijentima i pravila zaštitnog zida dozvoljavaju promet na portu slušača.

P: Šta znači veliki red za ponavljanje?

A: Veliki red za ponavljanje ukazuje na to da sekundarna replika ne može primijeniti zapise dnevnika brzinom kojom stižu. To može ukazivati ​​na uska grla diska/I, ograničenja CPU-a ili blokiranje upita samo za čitanje na sekundarnoj repliki.

P: Šta trebam učiniti ako katastrofa utiče na sve replike i moje sigurnosne kopije su također oštećene?

A: Ovaj najgori scenario, iako izuzetno rijedak, može se dogoditi zbog napada ransomware-a, široko rasprostranjenih kvarova u skladištenju podataka ili kaskadnih katastrofa. Vaša primarna odbrana je prevencija: održavajte geografski distribuirane replike, pohranjujte sigurnosne kopije na odvojenim lokacijama i
Redovno testirajte svoje procedure za oporavak od katastrofe. Ako sve standardne opcije oporavka ne uspiju, specijalizirani Alat za oporavak SQL podataka može pokušati izdvojiti podatke iz oštećenih MDF datoteka kao hitnu mjeru u krajnjoj nuždi.

5.5 Pitanja o licenciranju i troškovima

P: Kako se licenciraju grupe dostupnosti Always On?

A: SQL Server Licenciranje zavisi od izdanja i modela implementacije. Grupe dostupnosti Enterprise Editiona zahtijevaju Enterprise licence na svim replikama. Pasivne sekundarne replike mogu ispunjavati uslove za besplatno licenciranje pod određenim uslovima.

P: Mogu li koristiti SQL Server Razvojno izdanje za grupe dostupnosti?

O: Da, Developer Edition uključuje sve funkcije Enterprise Edition-a, uključujući punu podršku za grupe dostupnosti. Međutim, licencirano je samo za razvoj i testiranje, a ne za produkcijsku upotrebu.

P: Da li čitljive sekundarne datoteke zahtijevaju dodatne licence?

A: Licenciranje zavisi od scenarija. Pasivni sekundarni serveri za oporavak od katastrofe obično ne zahtijevaju licence. Aktivni sekundarni serveri koji opslužuju radna opterećenja samo za čitanje obično zahtijevaju licence, iako se specifični uslovi razlikuju.

P: Postoji li besplatan način da se postigne visoka dostupnost sa SQL Server?

A: SQL Server Express Edition ne podržava grupe dostupnosti. SQL Server Standardno izdanje podržava osnovne grupe dostupnosti počevši od SQL Server 2016, pružajući osnovnu visoku dostupnost po cijenama licenciranja Standardnog izdanja.

P: Šta su distribuirane grupe dostupnosti?

A: Distribuirane grupe dostupnosti su posebna vrsta grupe dostupnosti koja obuhvata dvije odvojene grupe dostupnosti, omogućavajući scenarije koji prevazilaze mogućnosti tradicionalnih grupa dostupnosti. Predstavljeno u SQL Server 2016. godine, distribuirane grupe dostupnosti rješavaju zahtjeve skaliranja i geografske distribucije.

6. zaključak

6.1 Sažetak ključnih tačaka

SQL Server Grupe dostupnosti koje su uvijek dostupne predstavljaju Microsoftovo vodeće rješenje za visoku dostupnost i oporavak od katastrofe za kritične baze podataka. One pružaju prebacivanje na nivo baze podataka u slučaju kvara bez zahtjeva za dijeljenim skladištenjem, čitljive sekundarne replike za rasterećenje radnih opterećenja i fleksibilnu geografsku distribuciju za sveobuhvatnu zaštitu podataka. Za organizacije koje još uvijek koriste rješenja kao što su log shipping or replikacijaGrupe dostupnosti nude robusniji i operativno jednostavniji put nadogradnje.

6.2 Kada koristiti grupe dostupnosti koje su uvijek uključene

Odaberite grupe dostupnosti kada vam je potrebna visoka dostupnost na nivou baze podataka sa automatskim mogućnostima prebacivanja u slučaju kvara. Organizacije kojima je potrebna zaštita od nultog gubitka podataka za kritične baze podataka imaju koristi od sinhronih replika potvrđivanja sa automatskim prebacivanjem u slučaju kvara. Aplikacije koje zahtijevaju mogućnosti skaliranja čitanja koriste čitljive sekundarne replike za distribuciju radnih opterećenja upita.

6.3 Početak implementacije

Započnite planiranje grupe dostupnosti procjenom poslovnih zahtjeva, uključujući RTO, RPO i budžetska ograničenja. Dokumentujte trenutnu infrastrukturu baze podataka, zavisnosti aplikacija i nedostatke u visokoj dostupnosti. Dizajnirajte arhitekturu grupe dostupnosti koja zadovoljava zahtjeve, a istovremeno ostaje unutar ograničenja resursa.

reference

• 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: Distribuirane grupe dostupnosti

---

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.