1. Razumijevanje grupa dostupnosti Always On
1.1 Što je to i kako funkcionira
Grupe dostupnosti uvijek uključene (AG) su SQL Server Poduzeće visoka dostupnost i rješenje za oporavak od katastrofe koje djeluje na razini 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 kontinuirane isporuke dnevnika transakcija. Kada primarna replika zakaže, određena sinkrona sekundarna replika automatski preuzima, vraćajući pristup u sekundama bez dijeljene pohrane ili ručne intervencije.
1.2 Grupe dostupnosti Always On 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 prebacivanje u slučaju kvara (FCI):
| Grupe dostupnosti Always On | Instance klastera za prebacivanje u slučaju kvara uvijek uključene | |
|---|---|---|
| Opseg prebacivanja u slučaju kvara | Razina baze podataka | Razina instance (sve baze podataka se istovremeno prebacuju u slučaju kvara) |
| Replikacija podataka | Replikacija temeljena na zapisnicima na svaku sekundarnu | Ništa — svi čvorovi dijele istu pohranu |
| Dijeljena pohrana | Nepotrebno | Obavezno (SAN, iSCSI, S2D ili SMB) |
| Čitljive sekundarne stavke | Da | Ne |
| Oporavak od katastrofe | Ugrađeno (asinkrone replike na više web-mjesta) | Nije ugrađeno bez uparivanja s AG-om |
Kada koristiti svaki od njih: Koristite FCI kada vam je potreban failover na razini instance i već imate infrastrukturu dijeljene pohrane. Koristite AG kada vam je potrebna granularnost na razini baze podataka, čitljive sekundarne datoteke ili oporavak od katastrofe. Za najpotpuniju zaštitu kombinirajte 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 s gotovo nultim ciljem vremena oporavka (RTO) za sinkrone replike;
- nulti gubitak podataka (ciljna točka oporavka (RPO) = 0) u sinkronom načinu izvršenja;
- nije potrebna dijeljena pohrana — svaka replika koristi neovisnu lokalnu pohranu;
- čitljive sekundarne datoteke rasterećuju izvještavanje i sigurnosne kopije s primarne datoteke;
- 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 u sustavu Windows Server na svim replikama;
- Enterprise izdanje za puni skup značajki (Standardno izdanje podržava Basic AG sa značajnim ograničenjima);
- sinkroni način commit-a dodaje latenciju operacijama pisanja proporcionalno vremenu povratnog putovanja mreže;
- prijave, poslovi SQL agenta i povezani poslužitelji ne sinkroniziraju se automatski u SQL Server 2019. i ranije (riješeno u SQL Server 2022. sadržavao je grupe dostupnosti).
2. Arhitektura grupa dostupnosti Always On
2.1 Osnovne komponente i koncepti
2.1.1 Baze podataka o dostupnosti
Baze podataka dostupnosti su korisničke baze podataka koje sudjeluju 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, postaje dio sinkroniziranog 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 istovremeno se prebacuju na istu sekundarnu repliku. To osigurava dosljednost 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, sinkroniziranu 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) događaju se na primarnoj replici. Klijentske aplikacije povezuju se 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 samo za čitanje, koje se održavaju kontinuiranom primjenom zapisa dnevnika transakcija primljenih od primarne replike. Svaka sekundarna replika prima, osigurava i primjenjuje zapise dnevnika kako bi kopije baze podataka bile sinkronizirane s primarnom.
2.2 Načini dostupnosti
2.2.1 Sinkroni način potvrđivanja
Način sinkronog potvrđivanja transakcija pruža zaštitu od gubitka podataka tako što zahtijeva da primarna replika pričeka potvrdu da su zapisi dnevnika transakcija ojačani na sekundarnoj replici prije potvrđivanja transakcija. Ovaj način rada je ključan za konfiguracije visoke dostupnosti gdje je gubitak podataka neprihvatljiv.
2.2.2 Asinkroni način potvrđivanja
Asinkroni način izvršavanja daje prioritet performansama primarne replike dopuštajuć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 sinkroni prijenos nepraktičnim.
Kompromis je potencijalni gubitak podataka tijekom prebacivanja u drugi sustav. Ako primarna replika ne uspije, neke potvrđene transakcije možda neće stići do sekundarne replike. Količina potencijalnog gubitka podataka ovisi o propusnosti mreže, performansama sekundarne replike i vremenu kvara. Organizacije moraju prihvatiti ovaj rizik kada koriste asinkroni 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ćuje 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 resursa (RTO) uklanjanjem potrebe za ručnim odgovorom na kvarove.
Automatsko prebacivanje u slučaju kvara zahtijeva sinkroni 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 zakaže, klaster za prebacivanje u slučaju kvara sustava Windows Server 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ćuje administratorima da namjerno prebace ulogu primarne replike na sekundarnu repliku, obično za planirano održavanje ili testiranje. Za razliku od automatskog prebacivanja u slučaju kvara, ručno prebacivanje u slučaju kvara zahtijeva izričitu akciju administratora za pokretanje.
Ručno prebacivanje u slučaju kvara bez gubitka podataka dostupno je za replike sa sinkronim 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 ciljnoj sekundarnoj repliki i čeka potvrdu prije prijenosa primarne uloge.
Ručno prebacivanje u slučaju kvara može se dogoditi i s asinkronim replikama, 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 tijekom stvarnih scenarija katastrofe kada primarna replika nije dostupna i gubitak podataka je prihvatljiv u usporedbi s produženim zastojem.
2.3.3 Prisilno prebacivanje u slučaju kvara
Prisilno prebacivanje u slučaju kvara omogućuje prebacivanje na asinkronu sekundarnu repliku ili na sekundarnu repliku koja nije u potpunosti sinkronizirana, uz izričito priznanje potencijalnog gubitka podataka. Ova opcija služi kao krajnje rješenje kada primarna replika nije dostupna i ne postoji sinkronizirana sekundarna replika.
2.4 Sinkronizacija podataka
2.4.1 Kako funkcionira sinkronizacija podataka
Sinkronizacija podataka u grupama dostupnosti Always On događa se putem kontinuiranog slanja zapisa dnevnika transakcija iz primarne replike u sve sekundarne replike. Ova sinkronizacija temeljena na dnevniku osigurava dosljednost, a istovremeno omogućuje neovisnu pohranu za svaku repliku.
2.4.2 Zapisi dnevnika transakcija i osiguranje
Zaštita zapisnika transakcija ključni je korak u kojem se zapisi zapisnika zapisuju u trajnu pohranu na sekundarnim replikama. Zaštita osigurava da zapisi zapisnika prežive kvarove sekundarnih replika i da se mogu ponovno reproducirati tijekom 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ćuju organizacijama da rasterete opterećenja intenzivnog čitanja s primarne replike, poboljšavajući ukupne performanse sustava 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 poslužitelji s mogućnošću čitanja mogu distribuirati opterećenje izvješćivanja na nekoliko poslužitelja. Popisi usmjeravanja samo za čitanje definiraju redoslijed kojim sekundarni poslužitelji primaju veze s namjerom čitanja, omogućujući strategije uravnoteženja opterećenja.
2.5.2 Operacije sigurnosnog kopiranja na sekundarnim replikama
Izrada sigurnosnih kopija na sekundarnim replikama smanjuje opterećenje ulazno/izlaznih operacija (I/O) i središnje procesorske jedinice (CPU) na primarnoj replici, omogućujući joj da se usredotoči 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. Sustav sigurnosne kopije automatski odabire odgovarajuću repliku na temelju tih postavki i trenutne dostupnosti.
Za više detalja o SQL Server sigurnosna kopija, pogledajte našu sveobuhvatan vodič.
2.6 Slušači grupe dostupnosti
2.6.1 Što je slušač?
Slušač grupe dostupnosti je naziv virtualne mreže (VNN) i IP adresa koju klijentske aplikacije koriste za povezivanje s bazama podataka grupe dostupnosti. Slušač automatski preusmjerava veze na trenutnu primarnu repliku, eliminirajući potrebu da aplikacije prate koji je poslužitelj trenutno primarni.
2.6.2 Usmjeravanje veze klijenta
Usmjeravanje klijentske veze putem slušača podržava namjere povezivanja za čitanje i pisanje i samo za čitanje. Slušač pregledava zahtjev za povezivanje i usmjerava ga na odgovarajuću repliku na temelju namjere aplikacije.
3. Preduvjeti i zahtjevi
3.1 Klasteriranje za prebacivanje u slučaju kvara u sustavu Windows Server za grupe dostupnosti
3.1.1 Osnove klastera za prebacivanje u slučaju kvara u sustavu Windows Server
Klasteriranje za prebacivanje u slučaju kvara u sustavu Windows Server (WSFC) pruža osnovu za grupe dostupnosti Always On upravljanjem članstvom u klasteru, praćenjem ispravnosti i orkestracijom prebacivanja u slučaju kvara. Za razliku od instanci klastera za prebacivanje u slučaju kvara, grupe dostupnosti koriste WSFC samo za koordinaciju klastera, a ne za upravljanje dijeljenom pohranom.
Svaki SQL Server Instanca koja sudjeluje u grupi dostupnosti mora biti čvor u WSFC klasteru. Klaster upravlja glasanjem kvoruma, otkrivanjem zdravlja čvora i stanjem resursa grupe dostupnosti. Kada primarna replika zakaže, WSFC koordinira proces prebacivanja u slučaju kvara 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 podijeljenog mozga u kojima više čvorova neovisno tvrdi da su primarni. Konfiguracija kvoruma definira što 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 funkcionira za klastere s neparnim brojem čvorova.
- Većina čvorova i dijeljenja datoteka dodaje glas svjedoka dijeljenja datoteka, prikladan za klastere čvorova s parnim brojem.
- Većina čvorova i diskova koristi svjedoka diska, ali je rjeđa za grupe dostupnosti jer dijeljena pohrana nije potrebna.
3.1.3 Grupiranje više podmreža
Grupiranje u više podmreža omogućuje replikama grupa dostupnosti da obuhvaćaju različite mrežne podmreže, podržavajući geografski distribuirane implementacije u podatkovnim centrima. Ova je mogućnost ključna za konfiguracije oporavka od katastrofe gdje replike postoje na odvojenim lokacijama.
3.2 SQL Server Zahtjevi izdanja
3.2.1 Značajke Enterprise izdanja
SQL Server Enterprise Edition pruža potpunu funkcionalnost grupa dostupnosti bez ograničenja. Enterprise Edition podržava do osam sekundarnih replika, čitljive sekundarne replike, automatsko zasijavanje, distribuirane grupe dostupnosti i sve napredne značajke.
3.2.2 Značajke 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 osnovne funkcionalnosti visoke dostupnosti po nižoj cijeni, pogodne za organizacije s jednostavnijim zahtjevima.
4. Konfiguriranje grupa dostupnosti Always On
4.1 Priprema okoliša
Prije stvaranja grupe dostupnosti, okruženje mora biti pravilno pripremljeno s Active Directory računima, konfiguracijama poslužitelja i mrežnom infrastrukturom.
4.1.1 Postavljanje kontrolera domene
Kontroler domene Active Directoryja mora biti konfiguriran za podršku klasteru grupe dostupnosti i SQL Server računi usluga.
- Prijavite se na kontroler domene s vjerodajnicama administratora domene.
- Otvoren Server Manager i krenite u Alati -> Korisnici i računala Active Directory.
- Stvorite organizacijsku jedinicu za SQL Server objekte ako jedan ne postoji.
- Provjerite postoje li računalni objekti za sve čvorove klastera u Active Directoryju.
- Provjerite jesu li usluge sustava domenskih imena (DNS) ispravno konfigurirane i jesu li sva imena poslužitelja ispravno razrješena.
4.1.2 Izrada servisnih računa
Izradite namjenske račune usluge Active Directory za SQL Server usluge na svakom čvoru.
- Otvoren Korisnici i računala Active Directory na kontroleru domene.
- Desnom tipkom miša kliknite odgovarajuću organizacijsku jedinicu i odaberite Novo -> korisnik.
- Unesite naziv servisnog računa (na primjer, svc_SQLServer) i postavite Korisničko ime za prijavu.
- Kliknite Sljedeći i unesite jaku lozinku.
- odabrati Korisnik ne može promijeniti lozinku i Lozinka nikad ne istječe.
- Kliknite Sljedeći a zatim završiti za kreiranje računa.
- Ponovite za sve dodatne potrebne servisne račune (SQL Server Agent, SSRS itd.).
4.1.3 Konfiguriranje administratorskih dozvola
Računi usluga i računi koji se koriste za konfiguriranje SQL Server mora imati odgovarajuća dopuštenja na svim čvorovima klastera.
- Prijavite se na svaki poslužitelj čvora klastera.
- Otvoren računalo za upravljanje od Start izbornik ili Upravitelj poslužitelja.
- Proširiti Lokalni korisnici i grupe i odaberite Klanovi.
- Desnom tipkom miša Administratori i odaberite Nekretnine.
- Kliknite dodati i unesite naziv servisnog računa.
- Kliknite Provjerite imena za potvrdu računa, a zatim kliknite OK.
- Kliknite OK za zatvaranje dijaloga Svojstva administratora.
- Ponovite na svim čvorovima klastera.
4.2 Instaliranje i konfiguriranje WSFC-a
Prije omogućavanja grupa dostupnosti Always On, klasteriranje za prebacivanje u slučaju kvara u sustavu Windows Server mora biti instalirano i konfigurirano na svim čvorovima.
4.2.1 Instaliranje značajke klasteriranja za prebacivanje u slučaju kvara
Instalirajte značajku klastera za prebacivanje u slučaju kvara na svaki poslužitelj koji će sudjelovati u grupi dostupnosti.
- Otvoren Server Manager na prvom čvoru klastera.
- Kliknite upravljati -> Dodajte uloge i značajke.
- Kliknite Sljedeći kroz uvodne ekrane.
- odabrati Instalacija temeljena na ulogama ili značajkama i kliknite Sljedeći.
- Odaberite lokalni poslužitelj i kliknite Sljedeći.
- Preskočite zaslon Uloge i kliknite Sljedeći.
- Na zaslonu Značajke odaberite Klasteriranje preusmjeravanja.
- Kliknite Dodavanje značajki kada se od vas zatraži da uključite alate za upravljanje.
- Kliknite Sljedeći a zatim Instalirati.
- Pričekajte da se instalacija završi i kliknite Zatvori.
- Ponovite na svim poslužiteljima koji će sudjelovati u klasteru.
4.2.2 Stvaranje klastera za prebacivanje u slučaju kvara
Nakon instaliranja značajke Failover Clustering na sve čvorove, stvorite klaster iz jednog čvora.
- Otvoren Upravitelj klastera za prebacivanje u slučaju kvara iz Server Manager -> Alati.
- Kliknite Stvorite klaster u oknu Akcije.
- Kliknite Sljedeći na stranici Prije nego što počnete.
- Kliknite Pretraga i dodajte sve poslužitelje koji će biti čvorovi klastera.
- Kliknite Sljedeći nakon dodavanja svih čvorova.
- Napusti Pokreni sve testove (preporučeno) odabrano i kliknite Sljedeći.
- Pregledajte rezultate testa validacije i ispravite sve pogreške ili upozorenja.
- Kliknite završiti nakon uspješnog završetka validacije.
- Unesite naziv klastera i IP adresu.
- Poništite Dodajte svu odgovarajuću pohranu u klaster jer dijeljena pohrana nije potrebna.
- Kliknite Sljedeći i pregledajte potvrdu.
- Kliknite završiti za stvaranje klastera.
4.2.3 Provjera konfiguracije klastera
Provjerite konfiguraciju klastera kako biste osigurali da svi čvorovi mogu ispravno komunicirati i da klaster ispravno radi.
- In Upravitelj klastera za prebacivanje u slučaju kvara, kliknite desnom tipkom miša na naziv klastera.
- odabrati Validiraj klaster iz izbornika.
- Kliknite Sljedeći na stranici Prije nego što počnete.
- odabrati Pokreni sve testove (preporučeno) i kliknite Sljedeći.
- Kliknite Sljedeći za početak validacijskih testova.
- Pregledajte izvješće o validaciji kada testovi završe.
- Riješite sve kvarove ili upozorenja utvrđena u izvješću.
- Kliknite završiti za zatvaranje čarobnjaka.
NIKADA Instaliranje SQL Server za grupe dostupnosti
Instalirati SQL Server na svakom čvoru koji će sudjelovati u grupi dostupnosti koristeći opciju samostalne instalacije.
- Pokreni SQL Server instalacijski medij na prvom čvoru.
- odabrati Novo SQL Server samostalna instalacija.
- Unesite ključ proizvoda ili odaberite probno izdanje.
- Prihvatite licencne uvjete i kliknite Sljedeći.
- Izvršite preduvjetne provjere i riješite sve probleme.
- Na stranici Odabir značajki odaberite Usluge mehanizma baze podataka.
- Konfigurirajte naziv instance (koristite isti naziv instance na svim čvorovima).
- Na stranici Konfiguracija poslužitelja navedite vjerodajnice servisnog računa.
- Konfigurirajte vrste pokretanja usluga kao Automatski.
- Na stranici Konfiguracija mehanizma baze podataka odaberite način provjere autentičnosti.
- Dodajte administratorske račune.
- Konfigurirajte direktorije podataka koristeći dosljedne putanje kroz sve čvorove.
- Dovršite instalaciju i provjerite uspjeh.
- Ponovite instalaciju na svim ostalim čvorovima klastera s identičnim postavkama.
4.4 Omogućavanje značajke Grupe dostupnosti uvijek uključene
Nakon instaliranja SQL Server na svim čvorovima omogućite značajku Grupe dostupnosti uvijek uključene na svakoj instanci.
4.4.1 Omogućavanje putem SQL Server Upravitelj konfiguracija
Koristiti SQL Server Upravitelj konfiguracije za omogućavanje grupa dostupnosti Always On putem grafičkog sučelja.
- Otvoren SQL Server Upravitelj konfiguracija na prvom čvoru.
- Proširiti SQL Server Usluge u lijevom oknu.
- Desnom tipkom miša kliknite SQL Server instancu i odaberite Nekretnine.
- kliknite Visoka dostupnost AlwaysOn Tab.
- Provjeriti Omogući grupe dostupnosti AlwaysOn.
- Provjerite je li naziv klastera za prebacivanje u slučaju kvara sustava Windows ispravan.
- Kliknite OK Za spremanje promjena.
- Kliknite OK na upozorenje da se usluga mora ponovno pokrenuti.
- Desnom tipkom miša kliknite SQL Server uslugu i odaberite Restart.
- Pričekajte da se usluga uspješno ponovno pokrene.
- 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.
- Otvorite PowerShell kao administrator na prvom čvoru.
- Uvezite SQL Server PowerShell modul:
Import-Module SQLPS -DisableNameChecking
- Omogući grupe dostupnosti Always On:
Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force
- Usluga će se automatski ponovno pokrenuti kada se koristi parametar Force.
- Provjerite je li značajka omogućena:
Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled
- Ponovite za svaki čvor klastera, zamjenjujući odgovarajuća imena poslužitelja i instance.
4.4.3 Provjera je li značajka omogućena
Prije nego što nastavite s konfiguracijom, provjerite jesu li Grupe dostupnosti uvijek uključene omogućene na svim instancama.
- Povežite se sa svakim SQL Server instanca korištenjem SQL Server Studio za upravljanje.
- Otvorite novi prozor za upit i izvršite:
SELECT SERVERPROPERTY('IsHadrEnabled') - Provjerite je li rezultat 1 (omogućeno).
- Provjerite je li SQL Server instanca se pojavljuje u Upravitelju klastera za prebacivanje u slučaju kvara pod ulogama klastera.
- Provjerite postoji li krajnja točka grupe dostupnosti izvršavanjem:
SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'
- Ako krajnja točka ne postoji, bit će kreirana tijekom 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.
- Povežite se s primarnom replikom pomoću SQL Server Studio za upravljanje.
- Desnom tipkom miša kliknite bazu podataka i odaberite Nekretnine.
- Odaberite Opcije stranica.
- Promijeniti Model oporavka do Full.
- Kliknite OK za spremanje promjene.
- Alternativno, koristite Transact-SQL:
ALTER DATABASE DatabaseName SET RECOVERY FULL;
4.5.2 Izrada potpunih sigurnosnih kopija baze podataka
Napravite potpunu sigurnosnu kopiju baze podataka kako biste uspostavili lanac sigurnosnih kopija potreban za grupe dostupnosti.
- In SQL Server Management Studio, desnom tipkom miša kliknite bazu podataka.
- odabrati Zadaci -> Natrag Gore.
- Provjeriti Vrsta sigurnosne kopije postavljena je na Full.
- Odaberite odredište sigurnosne kopije ili dodajte novo odredište.
- Kliknite OK za izvođenje sigurnosne kopije.
- Alternativno, koristite Transact-SQL:
BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';
4.5.3 Izrada sigurnosnih kopija dnevnika transakcija
Napravite sigurnosnu kopiju dnevnika transakcija kako biste osigurali da je lanac dnevnika uspostavljen i smanjili vrijeme inicijalizacije.
- In SQL Server Management Studio, desnom tipkom miša kliknite bazu podataka.
- odabrati Zadaci -> Natrag Gore.
- Promijeniti Vrsta sigurnosne kopije do Dnevnik transakcija.
- Odaberite odredište sigurnosne kopije.
- Kliknite OK za izvođenje sigurnosne kopije.
- Alternativno, koristite Transact-SQL:
BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';
4.6 Stvaranje grupe dostupnosti
Grupu dostupnosti možete stvoriti pomoću jedne 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čko sučelje za stvaranje grupa dostupnosti.
- In SQL Server Management Studio, povežite se s instancom koja će biti domaćin primarne replike.
- Proširiti Visoka dostupnost AlwaysOn u Exploreru objekata.
- Desnom tipkom miša Grupe dostupnosti i odaberite Čarobnjak za novu grupu dostupnosti.
- Kliknite Sljedeći na stranici Uvod.
- Unesite naziv grupe dostupnosti i kliknite Sljedeći.
- Na stranici Odabir baza podataka odaberite baze podataka koje želite uključiti.
- Provjerite ispunjavaju li baze podataka sve preduvjete i kliknite Sljedeći.
- Na stranici Određivanje replika kliknite Dodaj repliku.
- Povežite se sa svakom sekundarnom replikom instance.
- Konfigurirajte svojstva replike za svaku instancu (način dostupnosti, način prebacivanja u slučaju kvara).
- kliknite Krajnje točke kartica i pregledajte konfiguraciju krajnje točke.
- kliknite Postavke sigurnosne kopije karticu i konfigurirajte prioritete sigurnosne kopije.
- kliknite slušalac tab i opcionalno stvorite slušač.
- Kliknite Sljedeći i odaberite metodu sinkronizacije podataka.
- Pregledajte rezultate validacije i riješite sve probleme.
- Kliknite Sljedeći i pregledajte sažetak.
- Kliknite završiti za stvaranje grupe dostupnosti.
- Pratite napredak i provjerite uspješno stvaranje.
4.6.2 Korištenje Transact-SQL-a
Stvorite grupe dostupnosti pomoću Transact-SQL-a za skriptibilne i ponovljive implementacije.
- Stvorite 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)); - Pridružite sekundarnu repliku grupi dostupnosti:
ALTER AVAILABILITY GROUP AG_Name JOIN;
- 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 stvaranje i upravljanje grupama dostupnosti.
- Kreirajte objekt grupe dostupnosti:
$AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"
- Dodajte baze podataka:
Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"
- Konfigurirajte replike sa željenim svojstvima pomoću cmdleta New-SqlAvailabilityReplica.
- Pridružite sekundarne replike pomoću cmdleta Join-SqlAvailabilityGroup.
4.7 Dodavanje replika u grupu dostupnosti
Konfigurirajte svojstva specifična za repliku koja kontroliraju kako svaka instanca sudjeluje u grupi dostupnosti.
4.7.1 Konfiguriranje svojstava replike
Postavite svojstva za svaku repliku kako biste definirali njezinu ulogu i mogućnosti unutar grupe dostupnosti.
- In SQL Server Management Studio, proširi Visoka dostupnost AlwaysOn -> Grupe dostupnosti.
- Proširite grupu dostupnosti, a zatim proširite Replike dostupnosti.
- Desnom tipkom miša kliknite repliku i odaberite Nekretnine.
- Pregledajte i izmijenite postavke veze za primarnu i sekundarnu ulogu.
- Po potrebi konfigurirajte vrijednosti vremenskog ograničenja sesije.
- Kliknite OK za spremanje promjena.
4.7.2 Postavljanje načina dostupnosti
Konfigurirajte način dostupnosti za kontrolu ponašanja sinkronizacije između replika.
- Desnom tipkom miša kliknite grupu dostupnosti i odaberite Nekretnine.
- u Osnovne informacije stranicu, idite na Replike dostupnosti odjeljak.
- Za svaku repliku odaberite Sinkrono potvrđivanje or Asinkroni commit iz padajućeg izbornika.
- Koristite sinkrono potvrđivanje za lokalne replike visoke dostupnosti.
- Koristite asinkrono potvrđivanje (commit) za geografski udaljene replike oporavka od katastrofe.
- Kliknite OK za spremanje konfiguracije.
4.7.3 Postavljanje načina prebacivanja u slučaju kvara
Konfigurirajte način prebacivanja u slučaju kvara kako biste kontrolirali kako se prebacivanje u slučaju kvara događa za svaku repliku.
- Desnom tipkom miša kliknite grupu dostupnosti i odaberite Nekretnine.
- u Osnovne informacije stranicu, idite na Replike dostupnosti odjeljak.
- Za sinkrone replike potvrđivanja odaberite Automatski or Priručnik način rada za prebacivanje u slučaju kvara.
- Automatsko prebacivanje u slučaju kvara zahtijeva sinkroni način potvrđivanja i omogućuje nenadzirano prebacivanje u slučaju kvara.
- Za asinhrone replike potvrđivanja dostupno je samo ručno prebacivanje u slučaju kvara.
- Konfigurirajte do tri replike za automatsko prebacivanje u slučaju kvara (jednu primarnu i dvije sekundarne).
- Kliknite OK za primjenu postavki.
4.7.4 Konfiguriranje postavki sigurnosne kopije
Postavite postavke sigurnosne kopije kako biste kontrolirali gdje bi se operacije sigurnosne kopije trebale odvijati.
- Desnom tipkom miša kliknite grupu dostupnosti i odaberite Nekretnine.
- odabrati Postavke sigurnosne kopije u lijevom oknu.
- Odaberite jednu od postavki sigurnosne kopije:
- Preferirajte sekundarnoSigurnosne kopije na sekundarnoj ako su dostupne, inače na primarnoj
- Samo sekundarniSigurnosne kopije samo na sekundarnim replikama
- osnovniSigurnosne kopije samo na primarnoj replici
- Bilo koja replikaSigurnosne kopije na bilo kojoj dostupnoj replici
- Postavite vrijednosti prioriteta sigurnosne kopije za svaku repliku (0-100).
- Više vrijednosti prioriteta označavaju preferirane ciljeve sigurnosne kopije.
- Kliknite OK za spremanje preferencija.
4.8 Konfiguriranje slušača grupe dostupnosti
Izradite slušač koji će osigurati jednu točku povezivanja koja automatski preusmjerava na trenutnu primarnu repliku.
4.8.1 Stvaranje slušača
Dodajte slušatelja u grupu dostupnosti za upravljanje vezama klijenata.
- In SQL Server Management Studio, proširite grupu dostupnosti.
- Desnom tipkom miša Slušači grupe dostupnosti i odaberite Dodaj slušatelja.
- Unesite DNS naziv za slušača (na primjer, AG_Listener).
- Unesite broj porta (zadano je 1433).
- odabrati statički IP za mrežni način rada.
- Kliknite dodati za dodavanje IP adrese za svaku podmrežu.
- Unesite IP adresu i odaberite podmrežu.
- Kliknite OK stvoriti slušatelja.
- Provjerite pojavljuje li se slušač u Object Exploreru i je li online.
4.8.2 Konfiguriranje DNS i IP postavki
Provjerite DNS registraciju i konfiguraciju mreže za slušatelja.
- Otvorite DNS Manager na kontroleru domene.
- Provjerite je li ime slušatelja registrirano sa svim IP adresama.
- Testiranje DNS razrješenja s klijentskih računala:
nslookup ListenerName
- Provjerite jesu li vraćene sve konfigurirane IP adrese.
- U Upravitelju klastera za prebacivanje u slučaju kvara proširite uloge i odaberite grupu dostupnosti.
- Provjerite jesu li resursi IP adrese online.
- Provjerite je li resurs mrežnog naziva dostupan na mreži.
4.8.3 Testiranje povezivosti slušatelja
Provjerite mogu li se klijentske aplikacije povezati putem slušača.
- S klijentskog računala otvorite SQL Server Studio za upravljanje.
- Povežite se pomoću imena slušatelja umjesto imena poslužitelja.
- Izvršite upit za provjeru veze s trenutnom primarnom replikom:
SELECT @@SERVERNAME;
- Testirajte usmjeravanje namjere čitanja dodavanjem ApplicationIntent=ReadOnly u niz za povezivanje.
- Provjerite preusmjeravanja veze na čitljivu sekundarnu repliku.
- Testirajte prebacivanje u slučaju kvara ručnim prebacivanjem grupe dostupnosti i provjerom ponovnog povezivanja.
4.9 Metode sinkronizacije podataka
Odaberite metodu sinkronizacije podataka za inicijalizaciju sekundarnih replika s kopijama baze podataka.
4.9.1 Automatsko sijanje
Automatsko zasijavanje prenosi podatke baze podataka preko mreže bez potrebe za ručnim sigurnosnim kopijama i vraćanjima.
- Tijekom stvaranja grupe dostupnosti odaberite Automatsko sjetenje kao metoda sinkronizacije.
- Osigurajte mrežnu povezivost i dovoljnu propusnost između replika.
- Primarna replika automatski prenosi podatke baze podataka na sekundarne replike.
- Pratite napredak početne faze pomoću nadzorne ploče grupe dostupnosti ili DMV-ova.
- Automatsko sjetenje zahtijeva SQL Server 2016 ili noviji.
- Za velike baze podataka, uzmite u obzir utjecaj mreže i rasporedite rad tijekom razdoblja niske upotrebe.
4.9.2 Ručno pohranjivanje (sigurnosna kopija i vraćanje)
Ručno zasijavanje uključuje izradu sigurnosnih kopija na primarnoj serverskoj bazi i njihovo vraćanje na sekundarne replike.
- Na primarnoj replici napravite potpunu sigurnosnu kopiju:
BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';
- Napravite sigurnosnu kopiju dnevnika transakcija:
BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';
- Na svakoj sekundarnoj replici vratite punu sigurnosnu kopiju:
RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;
- Vratite sigurnosnu kopiju dnevnika:
RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;
- Pridružite bazu podataka grupi dostupnosti:
ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;
- Provjerite je li započela sinkronizacija i je li baza podataka dosegla stanje SINHRONIZIRANO.
4.9.3 Datoteke snimki baze podataka
Koristite datoteke snimki baze podataka za inicijalizaciju sekundarnih replika iz postojećih datoteka baze podataka.
- Odvojite ili napravite sigurnosnu kopiju baze podataka na primarnoj replici.
- Kopirajte datoteke baze podataka u svaku sekundarnu repliku koristeći iste putanje datoteka.
- Na sekundarnim replikama priložite bazu podataka ili je vratite bez oporavka.
- Provjerite je li baza podataka u stanju OBNAVLJANJA.
- Pridružite bazu podataka grupi dostupnosti.
- Ova metoda je korisna za vrlo velike baze podataka gdje bi mrežni prijenos bio nepraktičan.
5. Pitanja
5.1 Opća 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 razini instance koristeći dijeljenu pohranu, dok grupe dostupnosti Always On pružaju visoku dostupnost na razini baze podataka bez dijeljene pohrane. AG nudi čitljive sekundarne resurse i fleksibilniju geografsku distribuciju.
P: Mogu li koristiti grupe dostupnosti Always On s SQL Server Standardno izdanje?
O: Da, SQL Server Standardno izdanje 2016 i novije podržavaju osnovne grupe dostupnosti s ograničenjima koja uključuju jednu bazu podataka po grupi dostupnosti, maksimalno dvije replike i bez podrške za čitljivu sekundarnu podršku.
P: Trebam li dijeljenu pohranu za grupe dostupnosti Always On?
O: Ne, grupe dostupnosti ne zahtijevaju dijeljenu pohranu. Svaka replika održava neovisne kopije baza podataka na lokalnoj pohrani, sinkronizirane 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 mogu odabrati između sinkronog i asinkronog načina potvrđivanja?
A: Koristite sinkrono potvrđivanje za zahtjeve bez gubitka podataka unutar istog podatkovnog centra ili mreža s niskom latencijom. Koristite asinkrono potvrđivanje za udaljene replike oporavka od katastrofe gdje bi sinkrono potvrđivanje utjecalo na performanse.
P: Mogu li miješati sinkrone i asinkrone replike u istoj grupi dostupnosti?
O: Da, grupe dostupnosti podržavaju mješovite konfiguracije sa sinkronim i asinkronim replikama. To omogućuje lokalnu visoku dostupnost sa sinkronim replikama i udaljeni oporavak od katastrofe s asinkronim replikama.
P: Što se događa s mojim vezama tijekom prebacivanja na drugi sustav?
A: Postojeće veze se prekidaju kada dođe do prebacivanja u slučaju kvara. Aplikacije s logikom ponovnog pokušaja povezivanja automatski se ponovno povezuju s novim primarnim serverom putem slušača. Proces prebacivanja u slučaju kvara obično se dovršava u roku od nekoliko sekundi do nekoliko minuta.
P: Trebam li sinkronizirati prijave i poslove između replika?
O: U SQL Server 2019 i ranije, da – prijave, poslovi SQL agenta i povezani poslužitelji moraju se ručno sinkronizirati. SQL Server Verzija 2022 uvodi sadržane grupe dostupnosti koje automatski uključuju te 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 njezinih resursa.
P: Kako mogu napraviti zakrpu SQL Server s minimalnim zastojem?
A: Koristite nadogradnje u tijeku tako da prvo zakrpate sekundarne replike, zatim izvršite ručno prebacivanje na zakrpanu sekundarnu server i na kraju zakrpate bivšu primarnu server. To minimizira vrijeme zastoja na trajanje prebacivanja na drugi server.
P: Mogu li dodati baze podataka postojećoj grupi dostupnosti?
O: 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: Što je automatsko sjetenje i trebam li ga 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 sveobuhvatan vodič.
5.4 Pitanja o rješavanju problema
P: Zašto je moja baza podataka u stanju NIJE SINHRONIZIRANO?
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 točkama. Provjerite opis stanja sinkronizacije i SQL Server zapisnike pogreš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 popravke.
P: Kako mogu prisiliti prebacivanje na drugi sustav kada primarni 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 promič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 Upravitelju klastera za prebacivanje u slučaju kvara, je li registracija DNS-a uspjela, sve IP adrese slušača dostupne su klijentima i pravila vatrozida dopuštaju promet na port slušača.
P: Što znači veliki red za ponavljanje?
A: Veliki red za ponavljanje označava da sekundarna replika ne može primijeniti zapise dnevnika jednako brzo kao što stignu. To može ukazivati na uska grla diskovnog ulazno/izlaznog sustava, ograničenja procesora ili blokiranje upita samo za čitanje na sekundarnoj repliki.
P: Što trebam učiniti ako katastrofa utječe na sve replike i moje sigurnosne kopije su također oštećene?
A: Ovaj najgori scenarij, iako izuzetno rijedak, može se dogoditi zbog napada ransomwarea, raširenih kvarova pohrane ili kaskadnih katastrofa. Vaša primarna obrana je prevencija: održavajte geografski distribuirane replike, pohranjujte sigurnosne kopije na odvojenim lokacijama i
redovito testirajte svoje postupke oporavka 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 krajnju mjeru.
5.5 Pitanja o licenciranju i troškovima
P: Kako se licenciraju grupe dostupnosti Always On?
A: SQL Server Licenciranje ovisi o izdanju i modelu implementacije. Grupe dostupnosti Enterprise Editiona zahtijevaju Enterprise licence na svim replikama. Pasivne sekundarne replike mogu se kvalificirati za besplatno licenciranje pod određenim uvjetima.
P: Mogu li koristiti SQL Server Razvojno izdanje za grupe dostupnosti?
O: Da, Developer Edition uključuje sve značajke Enterprise Editiona, uključujući punu podršku za grupe dostupnosti. Međutim, licencirano je samo za razvoj i testiranje, a ne za produkcijsku upotrebu.
P: Zahtijevaju li čitljive sekundarne datoteke dodatne licence?
A: Licenciranje ovisi o scenariju. 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 uvjeti razlikuju.
P: Postoji li besplatan način za postizanje visoke dostupnosti s 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 cijeni licenciranja Standardnog izdanja.
P: Što su distribuirane grupe dostupnosti?
A: Distribuirane grupe dostupnosti posebna su vrsta grupe dostupnosti koja obuhvaća dvije odvojene grupe dostupnosti, omogućujući scenarije koji nadilaze mogućnosti tradicionalnih grupa dostupnosti. Uvedeno u SQL Server 2016., distribuirane grupe dostupnosti rješavaju zahtjeve skaliranja i geografske distribucije.
6. Zaključak
6.1 Sažetak ključnih točaka
SQL Server Grupe dostupnosti Always On predstavljaju Microsoftovo vodeće rješenje za visoku dostupnost i oporavak od katastrofe za kritične baze podataka. One pružaju prebacivanje na razinu baze podataka bez zahtjeva za dijeljenom pohranom, čitljive sekundarne replike za rasterećenje opterećenja i fleksibilnu geografsku distribuciju za sveobuhvatnu zaštitu podataka. Za organizacije koje još uvijek koriste rješenja kao što su otprema trupaca or odgovor, grupe dostupnosti nude robusniji i operativno jednostavniji put nadogradnje.
6.2 Kada koristiti grupe dostupnosti Always On
Odaberite grupe dostupnosti kada vam je potrebna visoka dostupnost na razini baze podataka s 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 sinkronih replika potvrđivanja s automatskim prebacivanjem u slučaju kvara. Aplikacije koje zahtijevaju mogućnosti skaliranja čitanja koriste čitljive sekundarne replike za distribuciju opterećenja upita.
6.3 Početak implementacije
Započnite planiranje grupe dostupnosti procjenom poslovnih zahtjeva, uključujući RTO, RPO i ograničenja proračuna. Dokumentirajte trenutnu infrastrukturu baze podataka, ovisnosti aplikacija i nedostatke u visokoj dostupnosti. Osmislite arhitekturu grupe dostupnosti koja zadovoljava zahtjeve, a istovremeno ostaje unutar ograničenja resursa.
Reference
- 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: Distribuirane grupe dostupnosti
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.


















