SQL Server Grupuri de disponibilitate mereu active: Ghid complet [2026]

1. Înțelegerea grupurilor de disponibilitate Always On

1.1 Ce este și cum funcționează

Grupurile de disponibilitate (AG) mereu active sunt SQL Server Enterprise de mare disponibilitate și o soluție de recuperare în caz de dezastru care operează la nivel de bază de date. Un grup de disponibilitate grupează una sau mai multe baze de date de utilizatori într-o singură unitate de failover și le replică în până la opt replici secundare prin livrare continuă a jurnalului de tranzacții. Când replica principală eșuează, o replică secundară sincronă desemnată preia automat controlul, restaurând accesul în câteva secunde, fără stocare partajată sau intervenție manuală.

1.2 Grupuri de disponibilitate Always On vs. instanțe de cluster Failover

SQL Server Always On include două tehnologii distincte: Grupuri de disponibilitate (AG) și Instanțe de cluster Failover (FCI):

	Grupuri de disponibilitate permanent	Instanțe de cluster failover mereu active
Domeniu de aplicare pentru failover	La nivel de bază de date	La nivel de instanță (toate bazele de date se eșuează împreună)
Replicarea datelor	Replicare bazată pe jurnal către fiecare element secundar	Niciunul — toate nodurile partajează același spațiu de stocare
Spațiu de stocare partajat	Nu este necesar	Obligatoriu (Rețea de stocare (SAN), iSCSI, S2D sau SMB)
Secundare lizibile	Da	Nu
Recuperare în caz de dezastru	Integrat (replici asincrone pe site-uri)	Nu este încorporat fără asociere cu AG

Când se utilizează fiecare: Folosește FCI atunci când ai nevoie de failover la nivel de instanță și ai deja o infrastructură de stocare partajată. Folosește AG atunci când ai nevoie de granularitate la nivel de bază de date, baze de date secundare lizibile sau recuperare în caz de dezastru. Pentru cea mai completă protecție, combină ambele: rulează fiecare replică ca nod FCI și conectează-le într-un AG.

1.3 Beneficii și limitări

Beneficii:

• Failover automat cu obiectiv de timp de recuperare (RTO) aproape zero pentru replici sincrone;
• zero pierderi de date (Obiectivul Punctului de Recuperare (RPO) = 0) în modul de validare sincronă;
• nu este necesară stocare partajată — fiecare replică utilizează stocare locală independentă;
• serverele secundare lizibile descarcă rapoartele și sarcinile de backup de la serverele primare;
• suportă atât disponibilitate ridicată (HA) locală, cât și recuperare în caz de dezastru (DR) între locații într-o singură configurație.

Limitări:

• Necesită clustering Windows Server Failover pe toate replicile;
• Enterprise Edition pentru setul complet de funcții (Standard Edition acceptă Basic AG cu restricții semnificative);
• Modul de validare sincronă adaugă latență operațiunilor de scriere proporțional cu timpul de dus-întors al rețelei;
• Autentificările, joburile SQL Agent și serverele conectate nu sunt sincronizate automat în SQL Server 2019 și anterior (rezolvat în SQL Server Grupuri de disponibilitate conținute în 2022).

2. Arhitectura grupurilor de disponibilitate mereu active

2.1 Componente și concepte de bază

2.1.1 Baze de date de disponibilitate

Bazele de date de disponibilitate sunt bazele de date ale utilizatorilor care participă la un grup de disponibilitate. Aceste baze de date trebuie să îndeplinească cerințe specifice: trebuie să utilizeze modelul de recuperare completă, să aibă o copie de rezervă completă și să existe pe replica principală înainte de a fi adăugate la un grup de disponibilitate.

Când o bază de date se alătură unui grup de disponibilitate, aceasta devine parte a unui set sincronizat care se reface prin failover ca o unitate. Toate bazele de date dintr-un grup de disponibilitate au aceeași stare de failover, ceea ce înseamnă că, dacă replica principală eșuează, toate bazele de date se reface simultan în aceeași replică secundară. Acest lucru asigură consecvența pentru aplicațiile care se bazează pe mai multe baze de date corelate.

2.1.2 Replici de disponibilitate

Replicile de disponibilitate sunt SQL Server instanțe care găzduiesc copii ale bazelor de date de disponibilitate. Fiecare replică își menține propria copie fizică a bazelor de date, sincronizată prin livrarea înregistrărilor din jurnalul de tranzacții. Un grup de disponibilitate poate conține până la nouă replici: o replică principală și până la opt replici secundare.

2.1.3 Replica principală

Replica principală găzduiește copia de citire-scriere a bazelor de date de disponibilitate. Toate modificările de date (INSERT, UPDATE, DELETE) au loc pe replica principală. Aplicațiile client se conectează la replica principală pentru toate operațiunile de scriere și, în mod implicit, și pentru operațiunile de citire.

2.1.4 Replici secundare

Replicile secundare găzduiesc copii doar pentru citire ale bazelor de date de disponibilitate, menținute prin aplicarea continuă a înregistrărilor jurnalului de tranzacții primite de la replica principală. Fiecare replică secundară primește, consolidează și aplică înregistrări din jurnal pentru a menține copiile bazei de date sincronizate cu cele primare.

2.2 Moduri de disponibilitate

2.2.1 Modul de validare sincronă

Modul de validare sincronă oferă protecție zero împotriva pierderilor de date, solicitând replicii principale să aștepte confirmarea că înregistrările jurnalului de tranzacții au fost consolidate pe replica secundară înainte de validarea tranzacțiilor. Acest mod este esențial pentru configurațiile de înaltă disponibilitate în care pierderile de date sunt inacceptabile.

2.2.2 Modul de validare asincronă

Modul de validare asincronă prioritizează performanța replicii principale, permițând validarea tranzacțiilor fără a aștepta ca replicile secundare să confirme consolidarea jurnalelor. Acest mod este potrivit pentru replicile de recuperare în caz de dezastru sau atunci când latența rețelei face ca validarea sincronă să fie impracticabilă.

Compromisul este pierderea potențială de date în timpul failover-ului. Dacă replica principală eșuează, este posibil ca unele tranzacții validate să nu fi ajuns la replica secundară. Cantitatea de pierderi potențiale de date depinde de lățimea de bandă a rețelei, de performanța replicii secundare și de momentul defecțiunii. Organizațiile trebuie să accepte acest risc atunci când utilizează modul asincron.

2.3 Tipuri de failover

2.3.1 Failover automat

Failover-ul automat permite grupului de disponibilitate să detecteze erorile replicii principale și să promoveze automat o replică secundară la primară fără intervenția administratorului. Această capacitate minimizează RTO-ul eliminând necesitatea unui răspuns manual la erori.

Failover-ul automat necesită modul de validare sincronă pentru a asigura zero pierderi de date. Când este activat, grupul de disponibilitate monitorizează continuu starea de funcționare a replicii principale. Dacă replica principală nu răspunde sau se defectează, clusterul Windows Server Failover inițiază failover-ul automat către o replică secundară desemnată.

2.3.2 Failover manual

Failover-ul manual permite administratorilor să schimbe intenționat rolul replicii principale într-o replică secundară, de obicei în scopuri de întreținere planificată sau testare. Spre deosebire de failover-ul automat, failover-ul manual necesită o acțiune explicită a administratorului pentru a fi inițiat.

Failover-ul manual fără pierderi de date este disponibil pentru replicile cu validare sincronă. Administratorul inițiază failover-ul prin SQL Server Management Studio, Transact-SQL sau PowerShell. Replica principală termină procesarea tranzacțiilor curente, trimite toate înregistrările din jurnal rămase către replica secundară țintă și așteaptă confirmarea înainte de a transfera rolul principal.

Failover-ul manual poate avea loc și cu replici cu validare asincronă, dar acest lucru necesită failover forțat cu potențială pierdere de date. Administratorii ar trebui să utilizeze failover-ul manual forțat numai în timpul scenariilor de dezastru reale, când replica principală nu este disponibilă și pierderea de date este acceptabilă în comparație cu timpul de nefuncționare prelungit.

2.3.3 Failover forțat

Failover-ul forțat permite failover-ul către o replică secundară asincronă sau către o replică secundară care nu este complet sincronizată, cu confirmarea explicită a pierderii potențiale de date. Această opțiune servește ca ultimă soluție atunci când replica principală nu este disponibilă și nu există o replică secundară sincronizată.

2.4 Sincronizarea datelor

2.4.1 Cum funcționează sincronizarea datelor

Sincronizarea datelor în Grupurile de disponibilitate Always On are loc prin livrarea continuă a înregistrărilor din jurnalul de tranzacții de la replica principală la toate replicile secundare. Această sincronizare bazată pe jurnal asigură consecvența, permițând în același timp stocarea independentă pentru fiecare replică.

2.4.2 Înregistrări și consolidare a jurnalului de tranzacții

Consolidarea jurnalului de tranzacții este pasul critic în care înregistrările jurnalului sunt scrise în spațiu de stocare durabil pe replici secundare. Consolidarea asigură că înregistrările jurnalului supraviețuiesc erorilor replicilor secundare și pot fi redate în timpul recuperării.

2.5 Replici secundare lizibile și la scară de citire

2.5.1 Descărcarea sarcinilor de lucru doar pentru citire

Replicile secundare lizibile permit organizațiilor să descarce sarcinile de lucru cu citire intensivă de la replica principală, îmbunătățind performanța generală a sistemului și utilizarea resurselor. Această capacitate de scalare a citirii este unul dintre avantajele cheie ale grupurilor de disponibilitate față de soluțiile mai vechi de înaltă disponibilitate.

Organizațiile ar trebui să ia în considerare cerințele de încărcare a sarcinii de lucru doar în citire atunci când proiectează configurații de grup de disponibilitate. Mai multe servere secundare lizibile pot distribui sarcina de raportare pe mai multe servere. Listele de rutare doar în citire definesc ordinea în care serverele secundare primesc conexiuni cu intenție de citire, permițând strategii de echilibrare a încărcării.

2.5.2 Operațiuni de backup pe replici secundare

Rularea copiilor de rezervă pe replici secundare reduce încărcarea de intrare/ieșire (I/O) și a unității centrale de procesare (CPU) de pe replica principală, permițându-i să se concentreze pe sarcinile de lucru tranzacționale. Această capacitate ajută organizațiile să îndeplinească cerințele de backup fără a afecta performanța producției.

SQL Server acceptă copii de rezervă complete ale bazei de date, copii de rezervă diferențiale și copii de rezervă ale jurnalului de tranzacții pe replici secundare. Preferințele de rezervă pot fi configurate pentru a prefera replici secundare, a prefera replici primare, doar secundare sau orice replică. Sistemul de rezervă selectează automat o replică adecvată pe baza acestor preferințe și a disponibilității actuale.

Pentru mai multe detalii despre SQL Server copie de rezervă, consultați ghid cuprinzător.

2.6 Listeneri ai grupului de disponibilitate

2.6.1 Ce este un ascultător?

Un ascultător de grup de disponibilitate este un nume de rețea virtuală (VNN) și o adresă IP pe care aplicațiile client le utilizează pentru a se conecta la bazele de date ale grupurilor de disponibilitate. Ascultătorul redirecționează automat conexiunile către replica principală curentă, eliminând necesitatea ca aplicațiile să urmărească ce server este principalul în prezent.

2.6.2 Rutarea conexiunii clientului

Rutarea conexiunii client prin intermediul listener-ului acceptă atât intenții de conectare citire-scriere, cât și doar citire. Listener-ul examinează cererea de conectare și o direcționează către replica corespunzătoare pe baza intenției aplicației.

3. Condiții preliminare și cerințe

3.1 Clusteringul de failover Windows Server pentru grupuri de disponibilitate

3.1.1 Noțiuni fundamentale despre clustering-ul de failover pentru Windows Server

Clusteringul Windows Server Failover (WSFC) oferă fundația pentru grupurile de disponibilitate Always On prin gestionarea apartenenței la cluster, monitorizarea stării de funcționare și orchestrarea failover. Spre deosebire de instanțele de cluster Failover, grupurile de disponibilitate utilizează WSFC doar pentru coordonarea clusterului, nu și pentru gestionarea spațiului de stocare partajat.

Fiecare SQL Server O instanță care participă la un grup de disponibilitate trebuie să fie un nod dintr-un cluster WSFC. Clusterul gestionează votul în cvorum, detectarea stării de sănătate a nodului și starea resurselor grupului de disponibilitate. Când replica principală eșuează, WSFC coordonează procesul de failover și actualizează resursele clusterului pentru a reflecta noua replică principală.

3.1.2 Configurarea cvorumului clusterului

Cvorumul clusterului determină ce noduri pot funcționa atunci când apar probleme de conectivitate la rețea, prevenind scenariile de tip „split-brain” în care mai multe noduri pretind independent că sunt principale. Configurația cvorumului definește ce constituie un vot majoritar pentru deciziile clusterului.

Sunt disponibile mai multe moduri de cvorum pentru grupurile de disponibilitate:

• Node Majority folosește doar voturile nodurilor de cluster și funcționează bine pentru clustere cu un număr impar de noduri.
• Majoritatea nodurilor și a partajărilor de fișiere adaugă un vot martor pentru partajarea de fișiere, potrivit pentru clustere de noduri cu număr par.
• Node and Disk Majority utilizează un martor pe disc, dar este mai puțin comun pentru grupurile de disponibilitate, deoarece stocarea partajată nu este necesară.

3.1.3 Clustering pe mai multe subrețele

Clusterizarea cu mai multe subrețele permite replicilor grupurilor de disponibilitate să se întindă pe diferite subrețele de rețea, suportând implementări distribuite geografic în centre de date. Această capacitate este esențială pentru configurațiile de recuperare în caz de dezastru în care replicile există în locații separate.

3.2 SQL Server Cerințe de ediție

3.2.1 Caracteristici ale ediției Enterprise

SQL Server Ediția Enterprise oferă funcționalități complete ale grupurilor de disponibilitate, fără limitări. Ediția Enterprise acceptă până la opt replici secundare, replici secundare lizibile, seeding automat, grupuri de disponibilitate distribuite și toate funcțiile avansate.

3.2.2 Caracteristici ale ediției Standard (grupuri de disponibilitate de bază)

SQL Server Ediția Standard 2016 și versiunile ulterioare acceptă grupurile de disponibilitate de bază, cu limitări semnificative. Grupurile de disponibilitate de bază oferă funcționalități de bază de înaltă disponibilitate la un cost mai mic, potrivite pentru organizațiile cu cerințe mai simple.

4. Configurarea grupurilor de disponibilitate Always On

4.1 Pregătirea mediului

Înainte de a crea un grup de disponibilitate, mediul trebuie pregătit corespunzător, cu conturile Active Directory, configurațiile serverului și infrastructura de rețea implementate.

4.1.1 Configurarea controlerului de domeniu

Controlerul de domeniu Active Directory trebuie configurat să accepte clusterul de grupuri de disponibilitate și SQL Server conturi de servicii.

1. Conectați-vă la controlerul de domeniu cu acreditările de administrator de domeniu.
2. Operatii Deschise Server Manager și navigați la Instrumente -> Utilizatori și computere Active Directory.
3. Creați o unitate organizațională pentru SQL Server obiecte dacă unul nu există.
4. Verificați dacă există obiecte computer pentru toate nodurile clusterului în Active Directory.
5. Asigurați-vă că serviciile Sistemului de nume de domeniu (DNS) sunt configurate corect și că toate numele serverelor sunt rezolvate corect.

4.1.2 Crearea conturilor de serviciu

Creați conturi de serviciu Active Directory dedicate pentru SQL Server servicii pe fiecare nod.

1. Operatii Deschise Utilizatori și computere Active Directory pe controlerul de domeniu.
2. Faceți clic dreapta pe unitatea organizațională corespunzătoare și selectați Nou -> Utilizator.
3. Introduceți numele contului de serviciu (de exemplu, svc_SQLServer) și setați Nume de conectare utilizator.
4. Clic Pagina Următoare → și introduceți o parolă puternică.
5. Selectați Utilizatorul nu poate schimba parola și Parola nu expira niciodata.
6. Clic Pagina Următoare → și apoi finalizarea pentru a crea contul.
7. Repetați pentru orice conturi de servicii suplimentare necesare (SQL Server Agent, SSRS etc.).

4.1.3 Configurarea permisiunilor de administrator

Conturi de serviciu și conturi utilizate pentru configurare SQL Server trebuie să aibă permisiunile corespunzătoare pe toate nodurile clusterului.

1. Conectați-vă la fiecare server de nod de cluster.
2. Operatii Deschise Gestionarea computerelor de la acasă meniu sau Manager server.
3. Extinde Utilizatori și grupuri locale și selectați grupuri.
4. Faceți clic dreapta Administratorii și selectați Proprietăţi.
5. Clic Adăuga și introduceți numele contului de serviciu.
6. Clic Verificați numele pentru a valida contul, apoi faceți clic pe OK.
7. Clic OK pentru a închide caseta de dialog Proprietăți administratori.
8. Repetați pe toate nodurile clusterului.

4.2 Instalarea și configurarea WSFC

Clusteringul Windows Server Failover trebuie instalat și configurat pe toate nodurile înainte de a activa grupurile de disponibilitate Always On.

4.2.1 Instalarea funcției de clusterizare failover

Instalați caracteristica Failover Clustering pe fiecare server care va participa la grupul de disponibilitate.

1. Operatii Deschise Server Manager pe primul nod al clusterului.
2. Clic Administrare -> Adăugați roluri și funcții.
3. Clic Pagina Următoare → prin ecranele de introducere.
4. Selectați Instalare bazată pe roluri sau pe funcții și faceți clic Pagina Următoare →.
5. Selectați serverul local și faceți clic pe Pagina Următoare →.
6. Sari peste ecranul Roluri și dă clic pe Pagina Următoare →.
7. Pe ecranul Funcții, selectați Clusterare cu basculare.
8. Clic Adăugați funcții atunci când vi se solicită să includeți instrumente de gestionare.
9. Clic Pagina Următoare → și apoi Instalare.
10. Așteptați finalizarea instalării și faceți clic pe Închide.
11. Repetați pe toate serverele care vor participa la cluster.

4.2.2 Crearea clusterului Failover

După instalarea funcției Failover Clustering pe toate nodurile, creați clusterul dintr-un singur nod.

1. Operatii Deschise Manager de cluster de failover de la Server Manager -> Instrumente.
2. Clic Creați un cluster în panoul Acțiuni.
3. Clic Pagina Următoare → pe pagina Înainte de a începe.
4. Clic Naviga și adăugați toate serverele care vor fi noduri de cluster.
5. Clic Pagina Următoare → după adăugarea tuturor nodurilor.
6. Părăsi Executați toate testele (recomandat) selectat și faceți clic Pagina Următoare →.
7. Revizuiți rezultatele testelor de validare și remediați orice erori sau avertismente.
8. Clic finalizarea după ce validarea se finalizează cu succes.
9. Introduceți un nume pentru cluster și adresa IP.
10. Debifați Adăugați toată spațiul de stocare eligibil la cluster deoarece spațiul de stocare partajat nu este necesar.
11. Clic Pagina Următoare → și revizuiți confirmarea.
12. Clic finalizarea pentru a crea clusterul.

4.2.3 Validarea configurației clusterului

Validați configurația clusterului pentru a vă asigura că toate nodurile pot comunica corect și că clusterul funcționează corect.

1. In Manager de cluster de failover, faceți clic dreapta pe numele clusterului.
2. Selectați Validare cluster din meniu.
3. Clic Pagina Următoare → pe pagina Înainte de a începe.
4. Selectați Executați toate testele (recomandat) și faceți clic Pagina Următoare →.
5. Clic Pagina Următoare → pentru a începe testele de validare.
6. Revizuiți raportul de validare după finalizarea testelor.
7. Remediați orice defecțiuni sau avertismente identificate în raport.
8. Clic finalizarea pentru a închide expertul.

4.3 Instalare SQL Server pentru grupuri de disponibilitate

Instalare SQL Server pe fiecare nod care va participa la grupul de disponibilitate utilizând opțiunea de instalare independentă.

1. Pornește SQL Server suportul de instalare pe primul nod.
2. Selectați Nou SQL Server instalare independentă.
3. Introduceți cheia de produs sau selectați ediția de evaluare.
4. Acceptați termenii licenței și faceți clic Pagina Următoare →.
5. Finalizați verificările preliminare și remediați orice probleme.
6. Pe pagina Selectare caracteristici, selectați Servicii de motor de baze de date.
7. Configurați numele instanței (folosiți același nume de instanță pe toate nodurile).
8. Pe pagina Configurare server, specificați acreditările contului de serviciu.
9. Configurați tipurile de pornire a serviciilor ca Automat.
10. Pe pagina de configurare a motorului de baze de date, selectați modul de autentificare.
11. Adăugați conturi de administrator.
12. Configurați directoarele de date folosind căi consistente pe toate nodurile.
13. Finalizați instalarea și verificați succesul.
14. Repetați instalarea pe toate celelalte noduri ale clusterului cu setări identice.

4.4 Activarea funcției Grupuri de disponibilitate mereu active

După instalare SQL Server pe toate nodurile, activați funcția Grupuri de disponibilitate Always On pe fiecare instanță.

4.4.1 Activare prin SQL Server Manager de configurare

Utilizare SQL Server Configuration Manager pentru a activa grupurile de disponibilitate Always On prin interfața grafică.

1. Operatii Deschise SQL Server Manager de configurare pe primul nod.
2. Extinde SQL Server Servicii în panoul din stânga.
3. Faceți clic dreapta pe SQL Server instanță și selectați Proprietăţi.
4. Apasă pe AlwaysOn Disponibilitate ridicată tab.
5. Verifica Activați grupurile de disponibilitate AlwaysOn.
6. Verificați dacă numele clusterului de failover Windows este corect.
7. Clic OK pentru a salva modificările.
8. Clic OK la avertismentul că serviciul trebuie repornit.
9. Faceți clic dreapta pe SQL Server serviciu și selectați Repornire.
10. Așteptați ca serviciul să repornească cu succes.
11. Repetați pe toate nodurile clusterului.

4.4.2 Activare prin PowerShell

PowerShell oferă o metodă scriptată pentru a activa grupurile de disponibilitate Always On pe mai multe noduri.

1. Deschideți PowerShell ca administrator pe primul nod.
2. Importați fișierul SQL Server Modul PowerShell:

   Import-Module SQLPS -DisableNameChecking

3. Activați grupurile de disponibilitate mereu active:

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

4. Serviciul va reporni automat când se utilizează parametrul Force.
5. Verificați dacă funcția este activată:

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

6. Repetați pentru fiecare nod al clusterului, înlocuind numele de server și instanță corespunzătoare.

4.4.3 Verificarea dacă funcția este activată

Verificați dacă Grupurile de disponibilitate Always On sunt activate în toate instanțele înainte de a continua configurarea.

1. Conectați-vă la fiecare SQL Server instanță folosind SQL Server Studio de management.
2. Deschideți o nouă fereastră de interogare și executați:

   SELECT SERVERPROPERTY('IsHadrEnabled')

3. Verificați dacă rezultatul este 1 (activat).
4. Verificați dacă SQL Server Instanța apare în Failover Cluster Manager la rolurile clusterului.
5. Verificați existența punctului final al grupului de disponibilitate executând:

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

6. Dacă endpoint-ul nu există, acesta va fi creat în timpul creării grupului de disponibilitate.

4.5 Pregătirea bazelor de date pentru grupurile de disponibilitate

Bazele de date trebuie să îndeplinească anumite cerințe înainte de a putea fi adăugate la un grup de disponibilitate.

4.5.1 Cerințe ale modelului de recuperare a bazei de date

Modificați modelul de recuperare a bazei de date la FULL pe replica principală înainte de a o adăuga la un grup de disponibilitate.

1. Conectați-vă la replica principală folosind SQL Server Studio de management.
2. Faceți clic dreapta pe baza de date și selectați Proprietăţi.
3. selectaţi Opţiuni .
4. Schimba Model de recuperare la Complet.
5. Clic OK pentru a salva schimbarea.
6. Alternativ, utilizați Transact-SQL:

   ALTER DATABASE DatabaseName SET RECOVERY FULL;

4.5.2 Realizarea copiilor de rezervă complete ale bazei de date

Realizați o copie de rezervă completă a bazei de date pentru a stabili lanțul de copii de rezervă necesar pentru grupurile de disponibilitate.

1. In SQL Server Management Studio, faceți clic dreapta pe baza de date.
2. Selectați Sarcini -> Copii de rezervă.
3. Verifica Tip de rezervă este setat la Complet.
4. Selectați o destinație pentru backup sau adăugați o destinație nouă.
5. Clic OK pentru a efectua copia de rezervă.
6. Alternativ, utilizați Transact-SQL:

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

4.5.3 Realizarea copiilor de rezervă ale jurnalului de tranzacții

Faceți o copie de rezervă a jurnalului de tranzacții pentru a vă asigura că lanțul de jurnalizare este stabilit și pentru a minimiza timpul de inițializare.

1. In SQL Server Management Studio, faceți clic dreapta pe baza de date.
2. Selectați Sarcini -> Copii de rezervă.
3. Schimba Tip de rezervă la Jurnal de tranzacții.
4. Selectați o destinație pentru backup.
5. Clic OK pentru a efectua copia de rezervă.
6. Alternativ, utilizați Transact-SQL:

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

4.6 Crearea grupului de disponibilitate

Creați grupul de disponibilitate utilizând una dintre metodele disponibile, în funcție de preferințele și cerințele de automatizare.

4.6.1 Utilizarea expertului Grup nou de disponibilitate

Expertul pentru crearea unui grup de disponibilitate nou oferă o interfață grafică pentru crearea grupurilor de disponibilitate.

1. In SQL Server Management Studio, conectați-vă la instanța care va găzdui replica principală.
2. Extinde AlwaysOn Disponibilitate ridicată în Exploratorul de obiecte.
3. Faceți clic dreapta Grupuri de disponibilitate și selectați Expert nou grup de disponibilitate.
   
4. Clic Pagina Următoare → pe pagina Introducere.
5. Introduceți un nume pentru grupul de disponibilitate și faceți clic pe Pagina Următoare →.
6. Pe pagina Selectare baze de date, selectați bazele de date de inclus.
7. Verificați dacă bazele de date îndeplinesc toate cerințele preliminare și faceți clic pe Pagina Următoare →.
8. Pe pagina Specificați replici, faceți clic pe Adăugați o replică.
9. Conectați-vă la fiecare instanță replică secundară.
10. Configurați proprietățile replicii pentru fiecare instanță (modul de disponibilitate, modul de failover).
11. Apasă pe Puncte finale și revizuiți configurația punctului final.
12. Apasă pe Preferințe de backup și configurați prioritățile de rezervă.
13. Apasă pe ascultător tab și opțional să creați un listener.
14. Clic Pagina Următoare → și selectați metoda de sincronizare a datelor.
15. Revizuiți rezultatele validării și remediați orice probleme.
16. Clic Pagina Următoare → și revizuiți rezumatul.
17. Clic finalizarea pentru a crea grupul de disponibilitate.
18. Monitorizați progresul și verificați crearea cu succes.

4.6.2 Utilizarea Transact-SQL

Creați grupuri de disponibilitate folosind Transact-SQL pentru implementări repetabile și scriptabile.

1. Creați grupul de disponibilitate pe replica principală:

   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. Alăturați replica secundară la grupul de disponibilitate:

   ALTER AVAILABILITY GROUP AG_Name JOIN;

3. Alătură-te bazei de date secundare:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 Utilizarea PowerShell

PowerShell oferă capabilități de scripting pentru crearea și gestionarea grupurilor de disponibilitate.

1. Creați obiectul grupului de disponibilitate:

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

2. Adăugați baze de date:

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

3. Configurați replici cu proprietățile dorite utilizând cmdletul New-SqlAvailabilityReplica.
4. Alăturați replicilor secundare utilizând cmdletul Join-SqlAvailabilityGroup.

4.7 Adăugarea de replici la grupul de disponibilitate

Configurați proprietăți specifice replicii care controlează modul în care fiecare instanță participă la grupul de disponibilitate.

4.7.1 Configurarea proprietăților replicii

Setați proprietăți pentru fiecare replică pentru a defini rolul și capacitățile acesteia în cadrul grupului de disponibilitate.

1. In SQL Server Studio de management, extindere AlwaysOn Disponibilitate ridicată -> Grupuri de disponibilitate.
2. Extindeți grupul de disponibilitate, apoi extindeți Replici de disponibilitate.
   
3. Faceți clic dreapta pe o replică și selectați Proprietăţi.
4. Revizuiți și modificați setările de conexiune pentru rolurile principale și secundare.
5. Configurați valorile de expirare a sesiunii, dacă este necesar.
6. Clic OK pentru a salva modificările.

4.7.2 Setarea modurilor de disponibilitate

Configurați modul de disponibilitate pentru a controla comportamentul de sincronizare între replici.

1. Faceți clic dreapta pe grupul de disponibilitate și selectați Proprietăţi.
2. În General pagina, accesați Replici de disponibilitate secţiune.
3. Pentru fiecare replică, selectați Commitere sincronă or Commitere asincronă din picătură.
4. Folosește commit sincron pentru replici locale cu disponibilitate ridicată.
5. Folosește validarea asincronă pentru replici de recuperare în caz de dezastru aflate la distanță geografică.
6. Clic OK pentru a salva configurația.

4.7.3 Setarea modurilor de failover

Configurați modul de failover pentru a controla modul în care are loc failover-ul pentru fiecare replică.

1. Faceți clic dreapta pe grupul de disponibilitate și selectați Proprietăţi.
2. În General pagina, accesați Replici de disponibilitate secţiune.
3. Pentru replicile de commit sincrone, selectați Automat or Manual modul de reluare a erorii.
4. Failover-ul automat necesită modul de validare sincron și permite failover-ul nesupravegheat.
5. Pentru replicile de commit asincrone, este disponibilă doar failover-ul manual.
6. Configurați până la trei replici pentru failover automat (una principală și două secundare).
7. Clic OK pentru a aplica setările.

4.7.4 Configurarea preferințelor de backup

Setați preferințele de backup pentru a controla unde ar trebui să aibă loc operațiunile de backup.

1. Faceți clic dreapta pe grupul de disponibilitate și selectați Proprietăţi.
2. Selectați Preferințe de backup în panoul din stânga.
3. Alegeți una dintre preferințele de backup:
   • Prefer SecundarCopii de rezervă pe secundar dacă este disponibil, altfel pe primar
   • Doar secundarCopii de rezervă doar pe replici secundare
   • PrimarCopii de rezervă doar pe replica principală
   • Orice replicăCopii de rezervă pe orice replică disponibilă
4. Setați valorile de prioritate a copiilor de rezervă pentru fiecare replică (0-100).
5. Valorile de prioritate mai mari indică destinațiile de rezervă preferate.
6. Clic OK pentru a salva preferințele.

4.8 Configurarea listenerului grupului de disponibilitate

Creați un listener pentru a oferi un singur punct de conexiune care redirecționează automat către replica principală curentă.

4.8.1 Crearea Listener-ului

Adăugați un listener la grupul de disponibilitate pentru gestionarea conexiunilor clientului.

1. In SQL Server Management Studio, extindeți grupul de disponibilitate.
2. Faceți clic dreapta Listeneri de grup de disponibilitate și selectați Adăugați ascultător.
   
3. Introduceți un nume DNS pentru listener (de exemplu, AG_Listener).
4. Introduceți numărul portului (implicit este 1433).
5. Selectați Adresa IP statică pentru modul de rețea.
6. Clic Adăuga pentru a adăuga o adresă IP pentru fiecare subrețea.
7. Introduceți adresa IP și selectați subrețeaua.
8. Clic OK pentru a crea ascultătorul.
9. Verificați dacă listenerul apare în Object Explorer și este online.

4.8.2 Configurarea setărilor DNS și IP

Verificați înregistrarea DNS și configurația rețelei pentru listener.

1. Deschideți DNS Manager pe controlerul de domeniu.
2. Verificați dacă numele listener-ului a fost înregistrat cu toate adresele IP.
3. Testați rezoluția DNS de pe mașinile client:

   nslookup ListenerName

4. Verificați dacă sunt returnate toate adresele IP configurate.
5. În Managerul de clustere Failover, extindeți Roluri și selectați grupul de disponibilitate.
6. Verificați dacă resursele adresei IP sunt online.
7. Verificați dacă resursa numelui de rețea este online.
   

4.8.3 Testarea conectivității listenerului

Verificați dacă aplicațiile client se pot conecta prin intermediul listenerului.

1. De pe o mașină client, deschideți SQL Server Studio de management.
2. Conectați-vă folosind numele listenerului în loc de numele serverului.
3. Executați o interogare pentru a verifica conexiunea la replica principală curentă:

   SELECT @@SERVERNAME;

4. Testați rutarea cu intenție de citire adăugând ApplicationIntent=ReadOnly la șirul de conexiune.
5. Verificarea conexiunii redirecționează către o replică secundară lizibilă.
6. Testați failover-ul prin reluarea manuală a grupului de disponibilitate și verificarea reconectarii.

4.9 Metode de sincronizare a datelor

Alegeți o metodă de sincronizare a datelor pentru a inițializa replicile secundare cu copii ale bazei de date.

4.9.1 Semănare automată

Încărcarea automată transferă datele bazei de date prin rețea fără a fi necesare copii de rezervă și restaurări manuale.

1. În timpul creării grupului de disponibilitate, selectați Semănat automat ca metodă de sincronizare.
   
2. Asigurați conectivitatea la rețea și lățimea de bandă suficientă între replici.
3. Replica principală transmite automat date din baza de date către replicile secundare.
4. Monitorizați progresul seeding-ului utilizând tabloul de bord al grupului de disponibilitate sau DMV-urile.
5. Semănarea automată necesită SQL Server 2016 sau versiuni ulterioare.
6. Pentru bazele de date mari, luați în considerare impactul asupra rețelei și programați-le în perioadele cu utilizare redusă.

4.9.2 Seeding manual (copiere de rezervă și restaurare)

Însămânțarea manuală implică realizarea de copii de rezervă pe serverul principal și restaurarea lor pe replici secundare.

1. Pe replica principală, faceți o copie de rezervă completă:

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

2. Faceți o copie de rezervă a jurnalului de tranzacții:

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

3. Pe fiecare replică secundară, restaurați copia de rezervă completă:

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

4. Restaurați copia de rezervă a jurnalului:

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

5. Alăturați baza de date la grupul de disponibilitate:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

6. Verificați dacă sincronizarea începe și dacă baza de date atinge starea SYNCHRONIZED.

4.9.3 Fișiere instantanee ale bazei de date

Folosește fișiere instantanee ale bazei de date pentru a inițializa replici secundare din fișierele bazei de date existente.

1. Detașați sau faceți o copie de rezervă a bazei de date de pe replica principală.
2. Copiați fișierele bazei de date în fiecare replică secundară utilizând aceleași căi de fișiere.
3. Pe replicile secundare, atașați baza de date sau restaurați fără recuperare.
4. Asigurați-vă că baza de date este în starea RESTORING.
5. Alăturați baza de date la grupul de disponibilitate.
6. Această metodă este utilă pentru bazele de date foarte mari, unde transferul în rețea ar fi impracticabil.

5. FAQ

5.1 Întrebări generale

Î: Care este diferența dintre Always On FCI și Always On AG?

R: Instanțele de cluster Always On Failover oferă disponibilitate ridicată la nivel de instanță utilizând spațiu de stocare partajat, în timp ce grupurile de disponibilitate Always On oferă disponibilitate ridicată la nivel de bază de date fără spațiu de stocare partajat. AG oferă instanțe secundare lizibile și o distribuție geografică mai flexibilă.

Î: Pot utiliza grupurile de disponibilitate Always On cu SQL Server Ediție standard?

A: Da, SQL Server Ediția Standard 2016 și versiunile ulterioare acceptă grupuri de disponibilitate de bază, cu limitări precum o bază de date per AG, maximum două replici și nicio compatibilitate secundară lizibilă.

Î: Am nevoie de spațiu de stocare partajat pentru grupurile de disponibilitate Always On?

R: Nu, grupurile de disponibilitate nu necesită spațiu de stocare partajat. Fiecare replică menține copii independente ale bazelor de date în spațiul de stocare local, sincronizate prin livrarea jurnalului de tranzacții.

Î: Care este numărul maxim de replici într-un grup de disponibilitate?

A: SQL Server Enterprise Edition acceptă până la nouă replici (una principală și opt secundare). Grupurile de disponibilitate distribuite pot accepta până la 18 replici în total în două grupuri de disponibilitate.

5.2 Întrebări de configurare

Î: Cum aleg între modurile de validare sincronă și asincronă?

A: Folosiți comiterea sincronă pentru cerințe de zero pierderi de date în cadrul aceluiași centru de date sau în rețele cu latență redusă. Folosiți comiterea asincronă pentru replici de recuperare în caz de dezastru la distanță, unde comiterea sincronă ar avea impact asupra performanței.

Î: Pot combina replici sincrone și asincrone în același grup de disponibilitate?

R: Da, grupurile de disponibilitate acceptă configurații mixte, atât cu replici sincrone, cât și asincrone. Acest lucru permite disponibilitate ridicată locală cu replici sincrone și recuperare în caz de dezastru la distanță cu replici asincrone.

Î: Ce se întâmplă cu conexiunile mele în timpul reluării erorii?

R: Conexiunile existente sunt întrerupte atunci când are loc failover-ul. Aplicațiile cu logică de reîncercare a conexiunii se reconectează automat la noul server principal prin intermediul listener-ului. Procesul de failover se finalizează de obicei în câteva secunde sau minute.

Î: Trebuie să sincronizez datele de conectare și joburile între replici?

A: În SQL Server 2019 și versiuni anterioare, da – conectările, joburile SQL Agent și serverele conectate trebuie sincronizate manual. SQL Server Versiunea 2022 introduce grupuri de disponibilitate separate care includ automat aceste obiecte.

5.3 Întrebări de management

Î: Pot rula copii de rezervă pe replici secundare?

R: Da, replicile secundare acceptă copii de rezervă complete, diferențiale și ale jurnalelor de tranzacții. Configurați preferințele de backup pentru a descărca copiile de rezervă de la replica principală și a reduce utilizarea resurselor acesteia.

Î: Cum pot aplica un patch? SQL Server cu timp de nefuncționare minim?

A: Folosiți upgrade-uri continue prin aplicarea mai întâi a corecțiilor la replicile secundare, apoi efectuarea unui failover manual la o replică secundară aplicată și, în final, aplicarea corecturilor la fosta replică principală. Acest lucru reduce la minimum timpul de nefuncționare pentru durata failover-ului.

Î: Pot adăuga baze de date la un grup de disponibilitate existent?

R: Da, bazele de date pot fi adăugate la grupurile de disponibilitate care rulează. Baza de date trebuie să fie în modelul de recuperare completă cu o copie de rezervă completă, iar replicile secundare trebuie să fie însămânțate utilizând însămânțarea automată sau copierea de rezervă și restaurarea manuală.

Î: Ce este însămânțarea automată și ar trebui să o folosesc?

A: Însămânțarea automată transferă datele bazei de date prin rețea pentru a inițializa replici secundare fără copii de rezervă manuale. Folosiți-o pentru baze de date mai mici sau atunci când lățimea de bandă a rețelei este suficientă. Pentru bazele de date foarte mari, însămânțarea manuală poate fi mai rapidă.

Î: Unde ar trebui să execut DBCC CHECKDB într-un grup de disponibilitate?

A: Ar trebui să executați DBCC CHECKDB pe replici secundare pentru a reduce încărcarea replicii principale. Verificările de consistență ale bazei de date se pot executa pe bazele de date secundare fără a afecta performanța replicii principale.

Pentru mai multe detalii despre DBCC CHECKDB, consultați ghid cuprinzător.

5.4 Întrebări de depanare

Î: De ce este baza mea de date în starea NU SE SINCRONIZEAZĂ?

R: Cauzele frecvente includ probleme de conectivitate la rețea, mutarea datelor suspendată, spațiu insuficient pe disc pe replicile secundare sau probleme la terminale. Verificați descrierea stării de sincronizare și SQL Server jurnalele de erori pentru detalii specifice. Dacă baza de date secundară a introdus o starea de recuperare sau spectacole recuperare în așteptare, consultați ghidurile linkate pentru remedieri specifice.

Î: Cum pot forța failover-ul când serverul principal nu este disponibil?

A: Conectați-vă la o replică secundară și executați ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS. Aceasta recunoaște potențiala pierdere de date și promovează imediat replica secundară la primară.

Î: De ce nu se pot conecta clienții la listener-ul meu?

A: Verificați dacă listener-ul este online în Failover Cluster Manager, dacă înregistrarea DNS a reușit, dacă toate adresele IP ale listener-ului sunt accesibile de la clienți și dacă regulile firewall-ului permit traficul către portul listener-ului.

Î: Ce înseamnă o coadă mare de refacere?

A: O coadă de refacere mare indică faptul că replica secundară nu poate aplica înregistrările din jurnal la fel de repede cum sosesc. Acest lucru poate indica blocaje I/O pe disc, constrângeri ale procesorului sau blocarea interogărilor doar în citire pe replica secundară.

Î: Ce ar trebui să fac dacă un dezastru afectează toate replicile și, de asemenea, copiile mele de rezervă sunt corupte?

R: Acest scenariu negativ, deși extrem de rar, poate apărea din cauza atacurilor ransomware, a erorilor de stocare pe scară largă sau a dezastrelor în cascadă. Principala ta apărare este prevenirea: menține replici distribuite geografic, stochează copii de rezervă în locații separate și
testați periodic procedurile de recuperare în caz de dezastru. Dacă toate opțiunile standard de recuperare eșuează, un specialist Instrument de recuperare a datelor SQL poate încerca să extragă date din fișiere MDF deteriorate ca măsură de urgență și ultimă soluție.

5.5 Întrebări privind licențierea și costurile

Î: Cum se licențiază Grupurile de disponibilitate Always On?

A: SQL Server Licențierea depinde de ediție și de modelul de implementare. Grupurile de disponibilitate Enterprise Edition necesită licențe Enterprise pentru toate replicile. Replicile secundare pasive pot fi eligibile pentru licențiere gratuită în anumite condiții.

Î: Pot folosi SQL Server Ediția pentru dezvoltatori pentru grupuri de disponibilitate?

R: Da, Developer Edition include toate caracteristicile Enterprise Edition, inclusiv suport complet pentru grupuri de disponibilitate. Cu toate acestea, este licențiată doar pentru dezvoltare și testare, nu pentru utilizare în producție.

Î: Materialele secundare lizibile necesită licențe suplimentare?

R: Licențierea depinde de scenariu. Serverele secundare pasive pentru recuperarea în caz de dezastru nu necesită de obicei licențe. Serverele secundare active care deservesc sarcini de lucru doar în citire necesită, în general, licențe, deși termenii specifici variază.

Î: Există o modalitate gratuită de a obține disponibilitate ridicată cu SQL Server?

A: SQL Server Ediția Express nu acceptă grupuri de disponibilitate. SQL Server Ediția Standard acceptă grupuri de disponibilitate de bază care încep cu SQL Server 2016, oferind disponibilitate ridicată de bază la costurile de licențiere Standard Edition.

Î: Ce sunt grupurile de disponibilitate distribuită?

R: Grupurile de disponibilitate distribuite sunt un tip special de grup de disponibilitate care se întinde pe două grupuri de disponibilitate separate, permițând scenarii care depășesc capacitățile grupurilor de disponibilitate tradiționale. Introdus în SQL Server În 2016, grupurile de disponibilitate distribuită abordează cerințele de scalare și distribuție geografică.

6. Concluzie

6.1 Rezumatul punctelor cheie

SQL Server Grupurile Always On Availability reprezintă soluția principală de înaltă disponibilitate și recuperare în caz de dezastru de la Microsoft pentru bazele de date critice. Acestea oferă failover la nivel de bază de date fără cerințe de stocare partajată, replici secundare lizibile pentru descărcarea sarcinilor de lucru și distribuție geografică flexibilă pentru o protecție completă a datelor. Pentru organizațiile care încă utilizează soluții precum transport de bușteni or replică, grupurile de disponibilitate oferă o cale de actualizare mai robustă și mai simplă din punct de vedere operațional.

6.2 Când se utilizează grupurile de disponibilitate Always On

Alegeți grupuri de disponibilitate atunci când aveți nevoie de disponibilitate ridicată la nivel de bază de date cu capabilități de failover automat. Organizațiile care au nevoie de protecție împotriva pierderii zero de date pentru bazele de date critice beneficiază de replici sincrone cu commit cu failover automat. Aplicațiile care necesită capabilități de citire scalabilă utilizează replici secundare lizibile pentru a distribui sarcinile de lucru ale interogărilor.

6.3 Noțiuni introductive despre implementare

Începeți planificarea grupului de disponibilitate prin evaluarea cerințelor de business, inclusiv RTO, RPO și constrângerile bugetare. Documentați infrastructura actuală a bazei de date, dependențele aplicațiilor și lacunele de disponibilitate ridicată. Proiectați o arhitectură a grupului de disponibilitate care să răspundă cerințelor, rămânând în același timp în limitele resurselor.

Referinte

• Document oficial Microsoft: Ce este un grup de disponibilitate Always On?
• Document oficial Microsoft: Introducere în grupurile de disponibilitate Always On
• Document oficial Microsoft: Grupuri de disponibilitate distribuite

---

Despre autor

Yuan Sheng este un administrator senior de baze de date (DBA) cu peste 10 ani de experiență în SQL Server medii de lucru și managementul bazelor de date la nivel de întreprindere. A rezolvat cu succes sute de scenarii de recuperare a bazelor de date în cadrul unor organizații din domeniul serviciilor financiare, al sănătății și al producției.

Yuan este specializat în SQL Server recuperarea bazelor de date, soluții de înaltă disponibilitate și optimizarea performanței. Experiența sa practică vastă include gestionarea bazelor de date de mai mulți terabyți, implementarea grupurilor de disponibilitate Always On și dezvoltarea de strategii automate de backup și recuperare pentru sistemele critice ale afacerii.

Prin expertiza sa tehnică și abordarea practică, Yuan se concentrează pe crearea de ghiduri complete care ajută administratorii de baze de date și profesioniștii IT să rezolve probleme complexe. SQL Server provocări eficiente. El se menține la curent cu cele mai recente SQL Server versiunilor de software și tehnologiilor de baze de date în continuă evoluție ale Microsoft, testând periodic scenarii de recuperare pentru a se asigura că recomandările sale reflectă cele mai bune practici din lumea reală.

Ai întrebări despre SQL Server recuperare sau aveți nevoie de îndrumări suplimentare pentru depanarea bazei de date? Yuan vă urează bun venit pentru a vă ajuta. feedback și sugestii pentru îmbunătățirea acestor resurse tehnice.