SQL Server Mindig bekapcsolva: Teljes körű útmutató adatbázis-adminisztrátoroknak [2026]

SQL Server Az Always On a Microsoft átfogó, magas rendelkezésre állású és katasztrófa utáni helyreállítási megoldása, amelyet a ...-val mutattak be. SQL Server 2012. Jelentős előrelépést jelent a korábbi technológiákhoz, például az adatbázis-tükrözéshez és a naplók küldéséhez képest, biztosítva az adatokhoz való folyamatos hozzáférést, miközben minimalizálja az állásidőt és az adatvesztést.

1.2 Miért van szükségük a vállalkozásoknak mindig elérhető megoldásokra?

A mai digitális gazdaságban az adatbázis-leállás közvetlenül a következőket jelenti:ost bevétel, sérült hírnév és szabályozási megfelelési problémák. A szervezeteknek olyan magas rendelkezésre állású megoldásokra van szükségük, amelyek garantálják a közel folyamatos üzemidőt, miközben védelmet nyújtanak a különféle meghibásodási forgatókönyvek ellen.

A hagyományos biztonsági mentési és visszaállítási eljárások nem elegendőek a modern üzleti követelményekhez. Amikor egy kritikus adatbázis meghibásodik, a vállalkozások nem engedhetik meg maguknak a biztonsági mentésekből való visszaállításhoz szükséges órákat. Az Always On megoldások automatikus feladatátvételt biztosítanak, amely másodpercek vagy percek alatt, nem pedig órák alatt képes visszaállítani a szolgáltatást, drámaian csökkentve a rendszerhibák hatását.

Az alapvető rendelkezésre álláson túl a vállalkozásoknak le kell venniük az olvasásigényes munkaterheléseket az éles adatbázisokról, leállás nélkül kell elvégezniük a karbantartást, és védekezniük kell a telephely szintű katasztrófák ellen. SQL Server Az Always On mindezen követelményeket egy egységes architektúrán keresztül elégíti ki, amely a kis telepítésektől a globálisan elosztott rendszerekig skálázható.

1.3 Kulcsfogalmak: RTO, RPO, HA és DR

Helyreállítási idő célkitűzés (RTO) meghatározza a meghibásodást követő állásidő maximálisan elfogadható időtartamát – azt, hogy milyen gyorsan kell az adatbázisnak újra online állapotba kerülnie.

Recovery Point Objective (RPO) meghatározza az időben mért maximálisan elfogadható adatvesztést – mennyi, a közelmúltban véglegesített adat elvesztését engedheti meg magának a vállalkozás.

Magas rendelkezésre állás (HA) arra összpontosít, hogy minimalizálja az olyan rutinszerű hibák, mint a hardverhibák vagy a szoftverösszeomlások okozta állásidőt ugyanazon adatközponton belül.

Katasztrófa utáni helyreállítás (DR) A HA a teljes telephelyeket érintő katasztrofális eseményeket kezeli, az adatok másolatait földrajzilag elkülönült helyeken tárolja. Míg a HA a leállások minimalizálására összpontosít, a DR a nagyobb incidensek során az adatvédelem és az üzletmenet-folytonosság biztosítására összpontosít.

SQL Server Az Always On egyetlen, egységes architektúrán belül támogatja a HA és a DR funkciókat. A szinkron véglegesítési mód RPO = 0 értéket biztosít automatikus feladatátvétellel a közel nulla RTO érdekében; az aszinkron véglegesítési mód elfogadja a potenciális adatvesztést a távoli telephelyek közötti alacsonyabb késleltetésért cserébe.

1.4 Mindig elérhető megoldások

SQL Server Az Always On három telepítési lehetőséget kínál, amelyek mindegyike eltérő rendelkezésre állási és infrastrukturális követelményekhez igazodik. Ez az útmutató mindhármat lefedi:

Mindig elérhető elérhetőségi csoportok (AG): Adatbázis-szintű magas rendelkezésre állás és katasztrófa utáni helyreállítás megosztott tárhely nélkül.
Mindig bekapcsolt feladatátvevő fürtpéldányok (FCI): Példányszintű magas rendelkezésre állás megosztott tárhely használatával.
AG + FCI együttesen: Kétrétegű védelem, amely a példányszintű és az adatbázisszintű feladatátvételt ötvözi a maximális rugalmasság érdekében.

2. Mindig elérhető elérhetőségi csoportok

Mindig elérhető elérhetőségi csoportok (AG) egy adatbázis-szintű magas rendelkezésre állású és katasztrófa utáni helyreállítási megoldás, amely folyamatos tranzakciónapló-küldésen keresztül replikálja a felhasználói adatbázisok egy halmazát akár nyolc másodlagos replikába.

2.1 Főbb jellemzők

Adatbázis-szintű feladatátvétel: az egyes adatbázisok vagy csoportok a feladatátvételtől függetlenül is elvégezhetik. SQL Server példány;
akár kilenc replika (egy elsődleges, nyolc másodlagos) az Enterprise Editionben;
szinkron véglegesítési mód a nulla adatvesztés érdekében; aszinkron véglegesítés távoli DR replikákhoz;
automatikus feladatátvétel szinkron replikák esetén, ha az elsődleges elérhetetlenné válik;
olvasható másodlagos replikák a jelentéskészítési és biztonsági mentési munkaterhelések tehermentesítéséhez;
A Availability Group Listener egyetlen kapcsolati végpontot biztosít, amely automatikusan az aktuális elsődleges szerverhez irányít.

2.2 A megvalósítás lépései

Active Directory szolgáltatásfiókok előkészítése és jogosultságok konfigurálása az összes csomóponton;
telepítse és érvényesítse a Windows Server feladatátvételi fürtözést az összes részt vevő szerveren;
telepíteni SQL Server önálló példányként minden csomóponton konzisztens elérési utakat és beállításokat használva;
engedélyezze az Always On Availability Groups funkciót a következőn keresztül: SQL Server Konfigurációkezelő vagy PowerShell;
adatbázisok teljes helyreállítási modellre állítása, valamint teljes és naplózott biztonsági mentések készítése;
létrehozza a rendelkezésre állási csoportot, hozzáadja a replikákat, és konfigurálja a rendelkezésre állási és feladatátvételi módokat;
másodlagos replikák beküldése automatikus beküldéssel vagy manuális biztonsági mentéssel és visszaállítással;
Hozza létre a rendelkezésre állási csoport figyelőjét, és ellenőrizze az ügyfélkapcsolatot.

A teljes, lépésről lépésre történő útmutatóért tekintse meg a Always On Availability Groups teljes útmutató.

2.3 Legjobb

Kritikus adatbázisok, amelyek nulla adatvesztést és automatikus feladatátvételt igényelnek;
olyan munkaterhelések, amelyekhez olvasható másodlagos adattárolókra van szükség a jelentéskészítéshez vagy a biztonsági mentések átviteléhez;
több telephelyet átfogó telepítések katasztrófa utáni helyreállításhoz;
meglévő megosztott tárolási infrastruktúra nélküli környezetekben.

2.4 Pro

Nincs szükség megosztott tárhelyre – minden replika független helyi tárhelyet használ;
egyetlen konfigurációban támogatja a HA-t és a DR-t is;
az olvasható másodlagos modulok csökkentik az elsődleges modulok terhelését;
Az adatbázis-szintű részletesség lehetővé teszi a különböző feladatátvételi szabályzatok használatát adatbázis-csoportonként.

2.5 Hátrányok

A teljes funkciókészlethez Enterprise Edition szükséges (a standard verzió támogatja az alapszintű AG-t jelentős korlátozásokkal);
A szinkron véglegesítési mód a hálózati oda-vissza úttal arányos írási késleltetést ad hozzá;
a bejelentkezésekhez, az SQL Agent feladatokhoz és a csatolt szerverekhez manuális szinkronizálás szükséges a SQL Server 2019 és korábbi;
minden replikának ugyanazon Windows Server feladatátvevő fürt csomópontjain kell lennie.

2.6 Hivatkozások

Hivatalos Microsoft dokumentum: Mi az az Always On rendelkezésre állási csoport?
Hivatalos Microsoft dokumentum: S megszerzésetarAlways On elérhetőségi csoportokkal

3. Mindig bekapcsolt feladatátvevő fürtpéldányok

Mindig bekapcsolt feladatátvevő fürtpéldányok (FCI) példányszintű magas rendelkezésre állást biztosít egyetlen futtatásával SQL Server példány több fizikai csomóponton keresztül, amelyek ugyanazt a tárolót használják. Amikor az aktív csomópont meghibásodik, a SQL Server A készenléti csomóponton lévő példány automatikusan újraindultarted, így az átmenet átlátható a kliensalkalmazások számára.

3.1 Főbb jellemzők

Példányszintű feladatátvétel: a példányon található összes adatbázis egyetlen egységként veszi át a feladatokat;
megosztott tároló (Storage Area Network (SAN), iSCSI, Storage Spaces Direct vagy SMB), amelyhez minden csomópont hozzáfér;
a virtuális hálózati név és a virtuális IP-cím stabil csatlakozási végpontot biztosít, függetlenül attól, hogy melyik csomópont aktív;
A Windows Server feladatátvételi fürtszolgáltatása kezeli a csomópontok állapotának monitorozását, a kvórumot és a feladatátvételi vezénylést;
támogatja az Aktív/Készenléti, Aktív/Aktív, N+1 és N+M csomópont-konfigurációs típusokat.

3.2 A megvalósítás lépései

Megosztott tároló kiépítése és csatlakoztatása az összes fürtcsomóponthoz;
telepítse a feladatátvételi fürtözési funkciót, és érvényesítse a fürt konfigurációját;
Hozza létre a Windows Server feladatátvevő fürtöt és konfigurálja a kvórumot;
futtassa a SQL Server telepítés a feladatátvevő fürt opció kiválasztásával, valamint a virtuális hálózat nevének és a megosztott tárolási útvonalak megadásával;
további csomópontok hozzáadása SQL Server feladatátvevő fürt példány;
ellenőrizze a feladatátvételi viselkedést a csomópontok közötti manuális feladatátvétel tesztelésével.

A teljes, lépésről lépésre történő útmutatóért tekintse meg a SQL Server Teljes körű útmutató a feladatátvevő fürthöz.

3.3 Legjobb

Meglévő megosztott tárolási infrastruktúrával (SAN vagy iSCSI) rendelkező környezetek;
olyan alkalmazások, amelyek példányszintű feladatátvételt igényelnek, ahol az összes adatbázisnak együtt kell feladatátvennie;
olyan forgatókönyvek, ahol az ügyféloldali átláthatóság kritikus fontosságú, és az alkalmazásoldali módosítások nem elfogadhatók;
olyan szervezetek, amelyek az egypéldányos feladatátvételi modell egyszerűségét helyezik előtérbe.

3.4 Pro

Automatikus feladatátvétel példányszinten, kliens újrakonfigurálása nélkül;
nincs adatreplikációs többletterhelés – minden csomópont ugyanahhoz a tárolóhoz fér hozzá;
kiszámítható feladatátvételi viselkedés az összes adatbázis esetében egyszerre;
támogatja a rugalmas csomópont-konfigurációkat (Aktív/Aktív, N+1, N+M) a hardverkihasználtság optimalizálása érdekében.

3.5 Hátrányok

A megosztott tároló egyetlen potenciális meghibásodási pont, kivéve, ha maga a tároló redundáns;
csak egy csomópont fut SQL Server egyszerre — nincs olvasási terheléselosztás a másodlagos csomópontokon;
nincs beépített katasztrófa utáni helyreállítás rendelkezésre állási csoporttal való párosítás nélkül;
megosztott tárolóinfrastruktúra hozzáadja a cost és a komplexitás az AG-hez képest.

3.6 Hivatkozások

Hivatalos Microsoft dokumentum: Mindig bekapcsolt feladatátvevő fürt példányok (SQL Server)

4. Elérhetőségi csoportok kombinálása feladatátvevő fürt példányokkal

Azoknak a szervezeteknek, amelyeknek példányszintű és adatbázisszintű védelmet is igényelnek, SQL Server támogatja a h-tostrendelkezésre állási csoport replikáinak létrehozása feladatátvevő fürt példányokon (FCI). Ebben a konfigurációban minden FCI csomópont egyetlen rendelkezésre állási replikaként működik, így az FCI feladatátvétel transzparens a rendelkezésre állási csoport számára, míg az AG feladatátvétel adatbázis-szintű védelmet nyújt a telephelyek között. Ez a kombináció biztosítja az most átfogó, magas rendelkezésre állású és katasztrófa utáni helyreállítási lefedettség elérhető SQL Server.

4.1 Főbb jellemzők

Kétrétegű feladatátvétel: az FCI kezeli a példányszintű csomóponthibákat; az AG kezeli a webhelyszintű vagy replikaszintű hibákat;
minden FCI egyetlen replikának számít a rendelkezésre állási csoporton belül, függetlenül attól, hogy hány csomópontot tartalmaz az FCI;
FCI-hostaz ed replikák továbbra is megosztott tárhelyet igényelnek a szabványos FCI-követelményeknek megfelelően;
AG replikák hostAz FCI-ken csak a manuális feladatátvételt támogatják — az automatikus feladatátvétel nem érhető el az FCI-h esetébenosted replikák;
Az önálló példányok részt vehetnek ugyanabban a rendelkezésre állási csoportban az FCI-h mellettosted replikák.

4.2 A megvalósítás lépései

Minden egyes FCI telepítése és validálása külön-külön, a szabványos FCI beállítási eljárásokat követve;
gondoskodjon arról, hogy minden FCI csomópont és önálló replika csomópont ugyanahhoz a Windows Server feladatátvevő fürthöz tartozzon;
engedélyezze az Always On Availability Groups funkciót minden FCI-példányon;
ellenőrizze, hogy egyetlen WSFC csomópont sem host ugyanazon rendelkezésre állási csoport két replikája bármilyen lehetséges FCI feladatátvétel után;
Hozza létre a rendelkezésre állási csoportot, jelölje ki az FCI-példányokat replikákként, és konfigurálja a manuális feladatátvételi módot az összes FCI-h számára.osted replikák;
másodlagos replikák kiindulási alapjainak megadása és a rendelkezésre állási csoport figyelőjének konfigurálása.

Az FCI beállításának részleteit lásd a SQL Server Feladatátvevő fürt teljes útmutatója. Az AG beállításának részleteit lásd az Always On Availability Groups teljes útmutatójában.

4.3 Legjobb

Kritikus környezetek, amelyek védelmet igényelnek mind az egyes csomópontok meghibásodása, mind a telephelyi szintű katasztrófák ellen;
olyan szervezetek, amelyek már futtatnak FCI-t, és amelyeknek telephelyek közötti katasztrófa-helyreállítást kell hozzáadniuk;
szabályozott iparágak, ahol a maximális adatvédelmet és rendelkezésre állást biztosító SLA-k kötelezőek;
nagyméretű telepítések, ahol a példányszintű és az adatbázis-szintű feladatátvételi szabályzatoknak együtt kell létezniük.

4.4 Pro

Maximális védelem: a csomóponthibákat az FCI, a helyszíni hibákat az AG kezeli;
Az FCI feladatátvétel transzparens a rendelkezésre állási csoport számára – az AG nem látja a replika változását az FCI feladatátvétel során;
rugalmas topológia: FCI-h keveréseosted és önálló replikák ugyanabban a rendelkezésre állási csoportban.

4.5 Hátrányok

FCI-hostAz ed replikák csak a manuális AG feladatátvételt támogatják – az automatikus AG feladatátvétel nem érhető el ezekhez a replikákhoz;
gondos WSFC csomópont-tervezést igényel, hogy megakadályozza az egyetlen csomópont h-játostugyanazon AG két replikájának létrehozása FCI feladatátvétel után;
magasabb szintű infrastruktúraost és működési összetettség, mint az AG vagy az FCI önmagában;
megosztott tárhely továbbra is szükséges minden FCI-összetevőhöz.

4.6 Hivatkozások

Hivatalos Microsoft dokumentum: Feladatátvételi fürtözés és Always On rendelkezésre állási csoportok (SQL Server)
Hivatalos Microsoft dokumentum: Mi az az Always On rendelkezésre állási csoport?
Hivatalos Microsoft dokumentum: S megszerzésetarAlways On elérhetőségi csoportokkal
Hivatalos Microsoft dokumentum: Mindig bekapcsolt feladatátvevő fürt példányok (SQL Server)

5. Az Always On megoldások összehasonlítása

5.1 Jellemzők összehasonlító táblázata

Funkció	Elérhetőségi csoportok	Feladatátvevő fürt példányai	AG + FCI kombinált
Hibatűrő hatókör	Adatbázis szintű	Példányszintű	Mindkét
Megosztott tárhely szükséges	Nem	Igen	Igen (FCI komponenshez)
Adatreplikáció	Naplóalapú minden replikához	Nincs (megosztott tárhely)	Log alapú az FCI-k között
Automatikus feladatátvétel	Igen (szinkron replikák)	Igen	FCI: Igen; AG: Nem
Olvasható másodlagos kódok	Igen	Nem	Igen (AG komponens)
Katasztrófa utáni helyreállítás	Beépített	Nem beépített	Beépített
Replikák maximális száma	9 (Vállalati)	N / A	9 (Vállalati)
Az infrastruktúra összetettsége	közepes	közepes	Magas
Cost	Alsóbb (nincs szükség SAN-ra)	Magasabb (SAN szükséges)	Legnagyobb

5.2 Válassza ki az Ön Always On megoldását

Stara tárolási infrastruktúrájával: ha nincs meglévő megosztott tárolója, az Availability Groups a természetes választás, és az most cost-hatékony elérési út mind a HA, mind a DR eléréséhez. Ha már üzemeltet SAN környezetet, és példányszintű feladatátvételre van szüksége, az FCI az egyszerűbb megoldás – de tervezze meg az AG későbbi hozzáadását, ha a telephelyek közötti DR a jövőbeni követelmény.

Csak akkor válassza az AG + FCI kombinációt, ha valóban szüksége van mindkét védelmi rétegre, és a megnövekedett komplexitás kezeléséhez szükséges működési érettségre. A legfontosabb megjegyezendő korlát az, hogy az FCI-hostAz ED AG-replikák nem támogatják az automatikus AG-feladatátvételt, ezért ez a topológia manuális beavatkozást igényel a rendelkezésre állási csoport szintű feladatátvételekhez.

A most A mai zöldmezős telepítéseknél az Always On Availability Groups az ajánlott megoldás.tarLényeges: lefedi mind a HA, mind a DR megoldásokat, nem igényel megosztott tárhelyet, és támogatja az olvasható másodlagos tárolókat – olyan képességeket, amelyekkel az FCI önmagában nem tud versenyezni.

6. A legjobb gyakorlatok a SQL Server Mindig elérhető megoldások

6.1 Tervezés és tervezés

Az Always On megoldás kiválasztása előtt határozza meg az RTO és RPO követelményeket – ezeket tarközvetlenül megállapítja, hogy a szinkron vagy aszinkron véglegesítési mód megfelelő-e, és hogy az automatikus feladatátvétel megvalósítható-e.
Méretezze a másodlagos replikákat úgy, hogy a teljes elsődleges munkaterhelést kezelni tudják feladatátvételi esemény során, beleértve a csúcsterhelési forgatókönyveket is.
AG telepítések esetén a szinkron replikákat ugyanabban az adatközpontban vagy alacsony késleltetésű hálózaton belül helyezze el az írási késleltetés hatásának minimalizálása érdekében. Az aszinkron módot a földrajzilag távoli DR-replikák számára tartsa fenn.
Páratlan számú szavazattal rendelkező kvórumot tervezzünk. Két csomópontos klaszterek esetén adjunk hozzá egy fájlmegosztást vagy felhőalapú tanúkat harmadik szavazatként az agyfelosztásos forgatókönyvek elkerülése érdekében.
Több alhálózatos telepítések esetén gondosan tervezze meg hálózati topológiáját. Minden alhálózathoz saját figyelő IP-cím szükséges, és a klienseknek a MultiSubnetFailover=True értéket kell megadniuk a kapcsolati karakterláncukban.

6.2 Végrehajtási irányelvek

Használjon következetes SQL Server verzió, kiadás és összesített frissítési szintek az összes replikán. A vegyes javítási szintek váratlan viselkedést okozhatnak feladatátvétel során.
Konfiguráljon dedikált hálózati interfészeket a fürt szívverés-forgalmához, az alkalmazásforgalomtól elkülönítve.
Automatikus szintaxis engedélyezése a kezdeti adatbázis-szinkronizációhoz itt: SQL Server 2016-os és újabb verziók – kiküszöböli a biztonsági mentések manuális másolásának szükségességét másodlagos replikákba m eseténost forgatókönyveket.
AG + FCI topológiák esetén minden FCI csomópont konfigurációs módosítása után ellenőrizze, hogy egyetlen WSFC csomópont sem végződhet-e h-val.ostugyanazon rendelkezésre állási csoport két replikájának létrehozása.
Mindig használja SQL Server Management Studio vagy Transact-SQL a rendelkezésre állási csoportok feladatátvételeinek kezeléséhez – soha ne használja közvetlenül a Failover Cluster Managert, mivel az nem ismeri az AG szinkronizációs állapotát, és hosszabb állásidőt vagy adatvesztést okozhat.

6.3 Felügyelet és karbantartás

A rendelkezésre állási csoport irányítópultjának segítségével rendszeresen figyelje a szinkronizáció állapotát, küldje el a várólistát, és ismételje meg a várólistát. SQL Server Management Studio vagy dinamikus felügyeleti nézetek (DMV-k). A másodlagos szerveren növekvő újraindítási sor I/O szűk keresztmetszetet jelez, amely késlelteti a feladatátvétellel történő helyreállítást.
Futtassa a DBCC CHECKDB parancsot a másodlagos replikákon, hogy átvegye a terhelést az integritási ellenőrzések terén az elsődleges replikákról. Tekintse meg a következőt: DBCC CHECKDB útmutató a részletekért.
Jelentkezem SQL Server Javítások gördülő frissítésekkel: először a másodlagos replikákat javítsa, hajtson végre egy tervezett manuális feladatátvételt egy javított másodlagos replikára, majd javítsa ki a korábbi elsődleges replikát. Ez egyetlen feladatátvétel időtartamára korlátozza az állásidőt.
Rendszeresen tesztelje a feladatátvételt nem termelési környezetekben. A soha nem tesztelt automatikus feladatátvétel nem megbízható helyreállítási stratégia.
Riasztások konfigurálása a rendelkezésre állási csoport állapotváltozásaihoz, a replika szerepkör-átmenetekhez és a szinkronizálási hibákhoz a következő használatával: SQL Server Ügynök vagy egy erre a célra szolgáló felügyeleti eszköz, például SQL Server teljesítmény monitor.

7. GYIK

K: Mi az SQL Server Mindig bekapcsolva?

A: SQL Server Az Always On a Microsoft magas rendelkezésre állású és katasztrófa utáni helyreállítási platformja, amelyet 2016-ban vezettek be. SQL Server 2012. Két technológiát foglal magában – az Always On Availability Groups-ot és az Always On Failover Cluster Instances-t –, amelyek automatizált feladatátvételt, adatredundanciát és folyamatos hozzáférést biztosítanak az adatbázisokhoz hardver-, szoftver- vagy webhelyhibák esetén.

K: Mi a különbség az Always On Availability Groups és a Failover Cluster Instances között?

V: Az elérhetőségi csoportok (Available Groups) adatbázis-szinten működnek, naplók küldésével replikálják az adatokat független másodlagos replikákra, és nem igényelnek megosztott tárhelyet. A feladatátvevő fürt példányai példányszinten működnek, minden csomópont által elérhető megosztott tárhelyet igényelnek, és egységként végzik az összes adatbázis feladatátvételét. Az AG támogatja az olvasható másodlagos replikákat és a beépített DR-t; az FCI nem.

K: Szükségem van megosztott tárhelyre az Always On Availability Groups szolgáltatáshoz?

V: Nem. Minden egyes AG-replika a helyi tárolóban tartja fenn az adatbázisok saját, független másolatát. Megosztott tárolóra csak akkor van szükség, ha feladatátvevő fürt példányokat használ a h...ost AG replikák.

K: Használhatom az Always On funkciót a következővel: SQL Server Standard kiadás?

A: SQL Server A Standard Edition támogatja az alapvető elérhetőségi csoportokat (Basic Availability Groups).tarting vele SQL Server 2016, de jelentős korlátozásokkal: egy adatbázis AG-nként, maximum két replika, és nincs olvasható másodlagos támogatás. Az FCI a Standard Editionben érhető el ezen korlátozások nélkül. A teljes Always On funkcióhoz Enterprise Edition szükséges.

K: Mi a replikák maximális száma egy rendelkezésre állási csoportban?

A: SQL Server Az Enterprise Edition akár kilenc replikát is támogat: egy elsődleges és nyolc másodlagos. Az elosztott rendelkezésre állási csoportok ezt 18 replikára bővíthetik két különálló rendelkezésre állási csoportban.

K: Elérhető az FCI-h?ostAz ed replikák automatikus AG feladatátvételt használnak?

V: Nem. Amikor egy rendelkezésre állási replika hostEgy feladatátvevő fürt példányán telepítve, az automatikus rendelkezésre állási csoport feladatátvétele nem támogatott az adott replika esetében. Az összes FCI-h-t érintő AG feladatátvételostAz ed replikák manuális beavatkozást igényelnek.

K: Mi a különbség a szinkron és az aszinkron commit módok között?

A: A szinkron véglegesítési mód megköveteli, hogy az elsődleges szerver megvárja, amíg a másodlagos szerver rögzíti a naplórekordokat a véglegesítés előtt, biztosítva ezzel a nulla adatvesztést (RPO = 0) a c-nél.ost a megnövelt írási késleltetés miatt. Az aszinkron véglegesítési mód lehetővé teszi az elsődleges szerver számára a várakozás nélküli véglegesítést, csökkentve a késleltetést, de kockáztatva az adatvesztést, ha az elsődleges szerver meghibásodik, mielőtt a másodlagos szerver megkapná az összes naplórekordot. Használjon szinkron módot a helyi HA replikákhoz, és aszinkron módot a távoli DR replikákhoz.

K: Mennyi ideig tart egy SQL Server Mindig bekapcsolva a feladatátvétel?

V: Normál körülmények között egy szinkron AG-replika automatikus feladatátvétele jellemzően 30 másodperc alatt befejeződik. Az FCI feladatátvétele általában 20–60 másodpercet vesz igénybe az adatbázis-helyreállítási időtől függően. A tényleges időtartam a munkaterheléstől, az adatbázis méretétől és a WSFC-ben konfigurált állapotellenőrzési időtúllépési beállításoktól függ.

K: Mi történik a klienskapcsolatokkal feladatátvétel során?

V: A meglévő kapcsolatok megszakadnak feladatátvételkor. Azok az alkalmazások, amelyek a rendelkezésre állási csoport figyelőjét használják, és tartalmazzák a kapcsolat újrapróbálkozási logikáját, automatikusan újracsatlakoznak az új elsődleges hálózathoz a feladatátvétel befejezése után. A MultiSubnetFailover=True érték hozzáadása a kapcsolati karakterláncokhoz javítja az újracsatlakozási sebességet több alhálózatos telepítések esetén.

K: Hogyan jelentkezhetek? SQL Server minimális állásidővel rendelkező javítások Always On környezetben?

V: Használjon gördülő frissítéseket: először a másodlagos replikákat javítsa ki, majd hajtson végre tervezett manuális feladatátvételt egy javított másodlagos replikára, végül pedig javítsa ki a korábbi elsődleges replikát. Ez egyetlen tervezett feladatátvétel időtartamára korlátozza az állásidőt – jellemzően egy perc alatt.

K: Kombinálhatom az Always On Availability Groups-ot a Failover Cluster Instances-szel?

V: Igen. Megtehetiost AG-replikák FCI-példányokon a példányszintű és az adatbázisszintű feladatátvételi védelem megvalósításához. Minden FCI egyetlen AG-replikának számít. Ez a topológia gondos WSFC-csomópont-tervezést igényel annak biztosítása érdekében, hogy egyetlen csomópont se legyen hostugyanazon AG két replikája egy esetleges FCI feladatátvétel után.

K: Mit tegyek, ha az adatbázisom megsérül egy Always On környezetben?

V: Először ellenőrizze, hogy a sérülés minden replikán fennáll-e, vagy csak az elsődlegesen. Ha van egy egészséges másodlagos, azonnal vegye át a feladatot arra. Ha az összes replika sérült, akkor tiszta biztonsági mentésből állítsa vissza a rendszert. Rendszeresen futtassa a DBCC CHECKDB parancsot a másodlagos replikákon a sérülés korai észlelése érdekében. Ha a biztonsági mentések is érintettek, egy speciális... SQL Server adat-helyreállítási eszköz végső megoldásként megpróbálhatja kinyerni az adatokat a sérült MDF fájlokból.

K: Hogyan viszonyul az Always On Availability Groups a régebbiekhez? SQL Server HA megoldások?

A: Az AG felülírja a régebbi technológiákat, mint például rönkszállítás és a replikációA naplók szállítása manuális feladatátvételt igényel, és nincs automatikus szerepkörátadás; a replikáció az adatelosztásra, nem pedig a HA-ra lett tervezve. Az AG automatikus feladatátvételt, nulla adatvesztést szinkron véglegesítéssel és olvasható másodlagos naplókat biztosít – olyan képességeket, amelyekkel ezek a technológiák nem tudnak versenyezni.

8. Következtetés

SQL Server Az Always On rugalmas, vállalati szintű platformot biztosít a magas rendelkezésre álláshoz és a katasztrófa utáni helyreállításhoz. Az Always On Availability Groups a megfelelő választás m számára.ost modern telepítések: kiküszöböli a megosztott tárolóhely szükségességét, támogatja az olvasható másodlagos tárolóhelyeket, és egyetlen konfigurációban kezeli mind a helyi HA-t, mind a telephelyek közötti DR-t. A feladatátvevő fürt példányok továbbra is szilárd megoldást jelentenek, ha a példányszintű feladatátvétel és a meglévő megosztott tárolóinfrastruktúra az elsődleges követelmény. A két technológia kombinálása a lehető legmélyebb védelmet nyújtja – a cost a nagyobb infrastrukturális beruházások és a működési komplexitás miatt.

Bármelyik megoldást is választja, az alapok ugyanazok: először határozza meg az RTO és RPO követelményeit, majd ezek köré tervezze a topológiát. tarrendszeresen tesztelje a feladatátvételt. Egy jól megvalósított, alaposan tesztelt Always On megoldás kiszámíthatóan helyreáll, ha termelési hibák történnek.

A szerzőről

Yuan Sheng több mint 10 éves tapasztalattal rendelkező vezető adatbázis-adminisztrátor (DBA) SQL Server környezetekben és vállalati adatbázis-kezelésben. Több száz adatbázis-helyreállítási forgatókönyvet oldott meg sikeresen pénzügyi szolgáltatások, egészségügyi ellátás és gyártási szervezetek számára.

Yuan specializálódott SQL Server adatbázis-helyreállítás, magas rendelkezésre állású megoldások és teljesítményoptimalizálás. Kiterjedt gyakorlati tapasztalata magában foglalja a több terabájtos adatbázisok kezelését, az Always On Availability Groups megvalósítását, valamint az automatizált biztonsági mentési és helyreállítási stratégiák kidolgozását kritikus fontosságú üzleti rendszerekhez.

Yuan műszaki szakértelmének és gyakorlatias megközelítésének köszönhetően átfogó útmutatók készítésére összpontosít, amelyek segítik az adatbázis-adminisztrátorokat és az informatikai szakembereket a komplex problémák megoldásában SQL Server hatékonyan kihívásokat intéz. Folyamatosan naprakész a legújabb információkkal. SQL Server kiadásait és a Microsoft fejlődő adatbázis-technológiáit, rendszeresen tesztelve a helyreállítási forgatókönyveket annak érdekében, hogy ajánlásai a valós legjobb gyakorlatokat tükrözzék.

Kérdései vannak a SQL Server helyreállításra vagy további adatbázis-hibaelhárítási útmutatásra van szüksége? Yuan örömmel fogadja visszajelzéseket és javaslatokat ezen technikai erőforrások fejlesztéséért.