Activați reziliența aplicațiilor cu baza de date Azure SQL

Finalizat

Grupurile de reproducere geografică și de reluare în caz de nereușită automată sunt ambele mecanisme utilizate în baza de date SQL Azure pentru a îmbunătăți disponibilitatea și recuperarea în caz de dezastru, dar au unele diferențe cheie.

Înțelegerea reproducerii geografice active

O metodă de a crește disponibilitatea pentru o bază de date Azure SQL este să utilizați geo-replicarea activă. Geo-replicarea activă este proiectată ca soluție de continuitate a activității care vă permite să creați baze de date secundare lizibile ale bazelor de date individuale pe un server din aceeași regiune sau din altă regiune. Aceasta acceptă până la patru reproduceri secundare și este configurată pentru fiecare bază de date.

În culise, Azure utilizează Grupuri de disponibilitate pentru a furniza această funcționalitate. Cu geo-replicarea activă, clienții pot programa sau manual în caz de nereușită bazele de date principale în regiunile secundare în timpul dezastrului major.

Captură de ecran a Geo-Replication active pentru baza de date SQL Azure.

Pentru a evita supraîncărcarea de reproducere dintr-un volum mare de lucru de scriere care poate afecta performanța reproducerii, se recomandă să configurați geo-secundarul cu același nivel de serviciu și să calculați dimensiunea ca principală.

Puteți configura manual geo-replicarea pentru baza de date SQL Azure accesând pagina bazei de date și selectând Reproduceri în secțiunea Gestionare date .

Captură de ecran a noii reproduceri a bazei de date pentru baza de date SQL Azure.

După crearea reproducerii secundare, puteți iniția manual o reluare în caz de nereușită. Acest lucru comută rolurile, făcând secundar noua principală și vechea principală secundară nouă.

Captură de ecran a opțiunii de reluare forțată în caz de nereușită pentru o bază de date Azure SQL pe portalul Azure.

Reproducerea geografică este asincronă, ceea ce înseamnă că pot exista unele latențe de date între bazele de date principale și secundare. De asemenea, șirul de conexiune al aplicației trebuie actualizat după o reluare în caz de nereușită.

Configurarea geo-replicare a abonamentului încrucișat

În anumite scenarii, poate fi necesar să configurați o reproducere secundară pe un alt abonament decât baza de date principală. Aici intervine reproducerea geografică a abonamentului. Această caracteristică vă permite să configurați o reproducere secundară într-un alt abonament, oferind mai multă flexibilitate și opțiuni îmbunătățite de recuperare a dezastrelor. Utilizând reproducerea geografică a abonamentului încrucișat, vă puteți asigura că datele dvs. sunt protejate și accesibile, chiar dacă un abonament întâmpină probleme. Această configurare este utilă pentru organizațiile cu mai multe abonamente sau pentru cele care caută să implementeze un plan robust de continuitate a activității.

Pentru a afla mai multe despre pașii necesari pentru a configura o reproducere geografică între abonamente, consultați Reproducerea geografică a abonamentului încrucișat.

Activarea grupurilor de reluare în caz de nereușită automată

Un grup de reluare în caz de nereușită automată este o caracteristică de disponibilitate care poate fi utilizată atât cu baza de date Azure SQL, cât și cu instanța gestionată Azure SQL. Grupurile de reluare în caz de nereușită automată vă permit să gestionați modul în care bazele de date sunt reproduse în altă regiune și vă permit să gestionați modul în care se poate întâmpla reluarea în caz de nereușită. Numele atribuit grupului de reluare în caz de nereușită automată trebuie să fie unic în domeniul *.database.windows.net .

Grupurile de reluare în caz de nereușită automată oferă funcționalitate de tip AG printr-un ascultător, permițând atât activități de citire-scriere, cât și activități doar în citire. Această funcționalitate diferă ușor de geo-replicarea activă. Există două tipuri de ascultători: unul pentru trafic în citire-scriere și altul pentru trafic doar în citire. În timpul unei reluări în caz de nereușită, actualizările DNS permit clienților să se conecteze la numele ascultătorului fără a fi nevoie de informații suplimentare. Serverul bazei de date cu copii în citire-scriere este principal, în timp ce serverul care primește tranzacții de la principal este secundar.

Diagramă cu arhitectura grupurilor de reluare în caz de nereușită automată pentru baza de date SQL Azure și Instanța gestionată Azure SQL.

Grupurile de reluare în caz de nereușită automată au două politici diferite care pot fi configurate.

  • Gestionat de clienți (recomandat) - clienții pot iniția manual o reluare în caz de nereușită atunci când detectează o pană neașteptată care afectează una sau mai multe baze de date din grupul de reluare în caz de nereușită. Această reluare manuală în caz de nereușită poate fi efectuată utilizând instrumente de linie de comandă, cum ar fi PowerShell, Azure CLI sau Rest API.
  • Microsoft gestionat - acestea sunt inițiate automat de Microsoft în timpul unei defecțiuni extinse care afectează o regiune principală. Această reluare automată în caz de nereușită se aplică tuturor grupurilor afectate de reluare în caz de nereușită cu politica de reluare în caz de nereușită setată la Microsoft gestionat.

Reluarea în caz de nereușită neplanificată poate duce la pierderi de date dacă sunt forțate și secundare nu sunt sincronizate complet cu elementul principal. GracePeriodWithDataLossHours Configurarea controlează cât timp așteaptă Azure înainte să se reia. Valoarea implicită este de o oră. Dacă aveți un RPO strâns și nu vă permiteți pierderi mari de date, setați valoarea mai mare. Deși Azure așteaptă mai mult înainte de a trece, această abordare poate duce la mai puține pierderi de date, deoarece secundarul are mai mult timp pentru a sincroniza complet cu elementul principal.

În plus, un grup de reluare în caz de nereușită automată poate include una sau mai multe baze de date, cu aceeași dimensiune și ediție atât pe serverele principale, cât și pe cele secundare. Baza de date de pe serverul secundar este creată automat printr-un proces numit însămânțare, care poate dura un timp, în funcție de dimensiunea bazei de date. Este important să planificați în mod corespunzător și să luați în considerare factorii cum ar fi viteza rețelei.

Cum să alegeți

Geo-replicarea este potrivită pentru scenariile în care aveți nevoie de mai multe reproduceri lizibile și este acceptabilă reluarea manuală în caz de nereușită, în timp ce grupurile de reluare în caz de nereușită automată sunt ideale pentru scenarii care necesită reluare automată în caz de nereușită și reproducere sincronă pentru un grup de baze de date.

Următorul tabel compară caracteristicile grupurilor de geo-replicare și reluare în caz de nereușită automată, împreună cu alte detalii relevante.

Caracteristică Reproducere geografică Grupuri de reluare în caz de nereușită automată
Număr de reproduceri Acceptă până la patru reproduceri secundare. Acceptă o singură reproducere secundară
Nivel de configurare Configurat pentru fiecare bază de date. Configurat pentru un grup de baze de date
Tip reproducere Asincron, ceea ce înseamnă că pot exista unele latențe de date între bazele de date principale și secundare Sincronizat, asigurându-se că baza de date secundară este întotdeauna sincronizată cu baza de date principală.
Reluare în caz de nereușită Necesită reluare manuală în caz de nereușită. Șirul de conexiune al aplicației trebuie actualizat după o reluare în caz de nereușită Acceptă reluarea automată și manuală în caz de nereușită, fără a fi necesar să modificați șirurile de conexiune după o reluare în caz de nereușită
Lizibilitate Furnizează baze de date secundare lizibile. Furnizează baze de date secundare lizibile și servește drept standby-uri calde pentru reluare în caz de nereușită
Caz de utilizare Potrivit pentru scenariile care necesită mai multe reproduceri lizabile și reluare manuală în caz de nereușită Ideal pentru scenarii care necesită reluare automată în caz de nereușită și reproducere sincronă pentru un grup de baze de date