Üzletmenet-folytonosság és adatbázis-helyreállítás – SQL Server

A következőkre vonatkozik: SQL Server 2016 (13.x) és újabb verziók

Ez a cikk áttekintést nyújt a magas rendelkezésre állású és vészhelyreállítási üzletmenet-folytonossági megoldásokról az SQL Serveren, Windowson és Linuxon.

Az SQL Servert üzembe helyezőknek gondoskodniuk kell arról, hogy minden kritikus fontosságú SQL Server-példány és a bennük lévő adatbázisok elérhetők legyenek, amikor az üzleti és végfelhasználóknak szükségük van rájuk, függetlenül attól, hogy ez a rendelkezésre állás a szokásos munkaidőben vagy éjjel-nappal rendelkezésre áll-e. A cél az, hogy az üzlet minimális vagy megszakítás nélkül működjön. Ezt a koncepciót üzletmenet-folytonosságnak is nevezik.

Az SQL Server 2017 (14.x) és újabb verziói szolgáltatásokat és fejlesztéseket vezetnek be a rendelkezésre álláshoz. A legnagyobb kiegészítés az SQL Server támogatása Linux-disztribúciókon. Az SQL Server új funkcióinak teljes listáját az alábbi cikkekben találja:

verzió	Operációs rendszer
Az SQL Server 2025 újdonságai (17.x)	Windows | Linux
Az SQL Server 2022 újdonságai (16.x)	Windows | Linux
Az SQL Server 2019 újdonságai (15.x)	Windows | Linux
Az SQL Server 2017 újdonságai (14.x)	Windows | Linux

Ez a cikk az SQL Server 2017 (14.x) és újabb verzióinak rendelkezésre állási forgatókönyveivel, valamint az új és továbbfejlesztett rendelkezésre állási funkciókkal foglalkozik. A forgatókönyvek közé tartoznak azok a hibridek, amelyek a Windows Serveren és a Linuxon futó SQL Server-telepítéseket is lefedik, és amelyek növelhetik az adatbázisok olvasható példányainak számát.

Bár ez a cikk nem foglalkozik az SQL Serveren kívüli rendelkezésre állási lehetőségekkel (például virtualizálással), az itt tárgyaltak a vendég virtuális gépen belüli SQL Server-telepítésekre vonatkoznak, akár a nyilvános felhőben, akár egy helyszíni hipervizor-kiszolgálón.

Rendelkezésre állási funkciókat használó SQL Server-forgatókönyvek

Az Always On rendelkezésre állási csoportokat, a feladatátvevő fürtpéldányokat és a naplóütemezést különböző módokon használhatja, és nem csak a rendelkezésre állás érdekében. A rendelkezésre állási funkciók négy fő módon használhatók:

• Magas szintű rendelkezésre állás
• Katasztrófa utáni helyreállítás
• Migrálások és frissítések
• Egy vagy több adatbázis olvasható másolatainak skálázása

A következő szakaszok az egyes forgatókönyvek releváns funkcióit ismertetik. Az egyik nem érintett funkció az SQL Server replikációja. Bár az SQL Server replikációja hivatalosan nem az Always On esernyő alatt van kijelölve rendelkezésre állási funkcióként, bizonyos esetekben gyakran használják az adatok redundánssá tételéhez. Az egyesítési replikáció linuxos SQL Server esetén nem támogatott. További információ: SQL Server-replikáció Linuxon.

Fontos

Az SQL Server rendelkezésre állási funkciói nem helyettesítik azt a követelményt, hogy robusztus, jól tesztelt biztonsági mentési és visszaállítási stratégiával rendelkezzenek. A biztonsági mentési és visszaállítási stratégia a rendelkezésre állási megoldások legalapvetőbb építőeleme.

Magas szintű rendelkezésre állás

Fontos gondoskodni arról, hogy az SQL Server-példányok vagy -adatbázisok elérhetők legyenek, ha olyan probléma merül fel, amely a felhő egy adatközpontjában vagy egyetlen régiójában található. Ez a szakasz bemutatja, hogyan segíthetnek az SQL Server rendelkezésre állási funkciói. Az összes leírt funkció elérhető Windows Serveren és Linuxon is.

Rendelkezésre állási csoportok

A rendelkezésre állási csoportok (AG-k) úgy biztosítják az adatbázisszintű védelmet, hogy egy adatbázis minden tranzakcióját egy másik példánynak vagy replikának küldik, amely az adatbázis egy példányát speciális állapotban tartalmazza. AG-t Standard vagy Enterprise kiadásokban is üzembe helyezhet. Az AG-ben részt vevő példányok lehetnek önálló vagy feladatátvevő fürtpéldányok (FCI-k, a következő szakaszban leírtak szerint). Mivel a rendszer azonnal egy replikába küldi a tranzakciókat, az AG-k használata ajánlott azokban az esetekben, ahol alacsonyabb helyreállítási pont (RPO) és helyreállítási idő (RTO) célkitűzésekre van szükség. A replikák közötti adatáthelyezés szinkron vagy aszinkron lehet, mivel az Enterprise kiadás legfeljebb három replikát (beleértve az elsődlegeset) is szinkronként engedélyez. Az AG rendelkezik az elsődleges replikán található adatbázis egy teljes olvasási/írási másolatával, míg az összes másodlagos replika közvetlenül nem fogadhat tranzakciókat a végfelhasználóktól vagy alkalmazásoktól.

Megjegyzés:

Az Always On az SQL Server rendelkezésre állási funkcióinak gyűjtőkifejezése, amely az AG-kre és az FCI-kre is kiterjed. Az Always On nem az AG-szolgáltatás neve.

Az SQL Server 2022 (16.x) előtt az AG-k csak adatbázisszintű védelmet biztosítanak, példányszintű védelmet nem. A tranzakciónaplóban nem rögzített vagy az adatbázisban konfigurált elemeket manuálisan kell szinkronizálni minden másodlagos replikához. Néhány olyan objektum, amelyet manuálisan kell szinkronizálni, a példány szintjén történő bejelentkezések, a csatolt kiszolgálók és az SQL Server Agent-feladatok.

Az SQL Server 2022 (16.x) és újabb verzióiban a példányszinten kívül kezelheti a metaadat-objektumokat, köztük a felhasználókat, a bejelentkezéseket, az engedélyeket és az SQL Server Agent-feladatokat. További információért tekintse meg: Mi az a korlátozott rendelkezésre állási csoport?

Az AG egy másik, figyelő nevű összetevővel is rendelkezik, amely lehetővé teszi, hogy az alkalmazások és a végfelhasználók anélkül csatlakozzanak, hogy nem kell tudniuk, hogy melyik SQL Server-példány üzemelteti az elsődleges replikát. Minden AG-nek saját figyelője van. Bár a figyelő implementációi némileg eltérnek a Windows Server és a Linux rendszeren, mindkettő ugyanazt a funkciót és használhatóságot biztosítja. Az alábbi ábra egy Windows Server-alapú AG-t mutat be, amely Windows Server feladatátvevő fürtöt (WSFC) használ. Az operációs rendszer rétegében egy mögöttes fürtre van szükség a rendelkezésre álláshoz, függetlenül attól, hogy Linuxon vagy Windows Serveren van. A példa egy egyszerű konfigurációt mutat be két kiszolgálóval, vagy csomóponttal, amelynél a WSFC szolgál alapfürtként.

A Standard és az Enterprise kiadás különböző maximális értékekkel rendelkezik a replikák esetében. Az alapszintű rendelkezésre állási csoportként ismert Standard kiadású AG két replikát (egy elsődleges és egy másodlagos) támogat, amelyekben csak egyetlen adatbázis található az AG-ben. A Nagyvállalati kiadás nem csak több adatbázis konfigurálását teszi lehetővé egyetlen AG-ben, hanem akár kilenc teljes replikával is rendelkezhet (egy elsődleges, nyolc másodlagos). A Nagyvállalati kiadás egyéb választható előnyöket is kínál, például olvasható másodlagos replikákat, a másodlagos replikák biztonsági mentésének lehetőségét és egyebeket.

Megjegyzés:

Az SQL Server 2012-ben (11.x) elavult adatbázis-tükrözés nem érhető el az SQL Server Linux-verziójában, és nem is lett hozzáadva. Az adatbázis-tükrözést továbbra is használó ügyfeleknek az AG-kbe kell migrálniuk, ami az adatbázis-tükrözés helyettesítője.

A rendelkezésre állás szempontjából az AG-k automatikus vagy manuális átkapcsolást is biztosíthatnak. Automatikus feladatátvétel akkor fordulhat elő, ha a szinkron adatáthelyezés konfigurálva van, és az elsődleges és másodlagos replika adatbázisa szinkronizált állapotban van. Mindaddig, amíg a figyelőt használja, és az alkalmazás a .NET-keretrendszer támogatott verzióját használja (3.5 Service Pack 1 vagy 4.6.2 és újabb verzióval), a feladatátvételt minimális hatással kell kezelni a végfelhasználókra, ha figyelőt használnak. Átkapcsolás egy másodlagos replikára, hogy az új elsődleges replikává váljon, beállítható automatikusra vagy manuálisra, és az időtartam általában másodpercekben mérhető.

Az alábbi lista néhány különbséget mutat a Windows Server és a Linux rendszeren futó AG-k között:

A mögöttes fürt Linuxon és Windows Serveren való működése miatt az összes AG-feladatátvétel (manuális vagy automatikus) a linuxos fürtön keresztül történik. Windows Server-alapú AG-környezetekben a manuális átvételt SQL Serveren keresztül kell végrehajtani. Az automatikus feladatátvételeket az alatti fürt kezeli Windows Serveren és Linuxon egyaránt.

• Az SQL Server Linuxon való futtatásához egy AG-t legalább három replikával szükséges konfigurálni az alapul szolgáló fürtözés működése miatt.

• Linuxon az egyes figyelők által használt köznapi név a DNS-ben van definiálva, és nem a fürtben, mint a Windows Serveren.

Az SQL Server 2017 (14.x) a következő funkciókat és fejlesztéseket vezette be az AG-k számára:

• Fürttípusok
• REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
• A Microsoft Distributor Transaction Coordinator (DTC) továbbfejlesztett támogatása Windows Server-alapú konfigurációkhoz
• További horizontális felskálázási esetek írásvédett adatbázisokhoz (amelyekről a cikk későbbi részében lesz szó)

Rendelkezésre állási csoport fürttípusai

A Windows Serveren a fürtözés beépített rendelkezésre állási formája a Feladatátvételi fürtözés funkcióval van engedélyezve. Lehetővé teszi, hogy WSFC-t hozzon létre, amelyet AG-vel vagy FCI-vel lehet használni. Az SQL Server olyan fürtbarát erőforrás-DLL-eket szállít, amelyek integrációt biztosítanak az AG-k és FCI-k számára.

A Linuxon futó SQL Server több fürtözési technológiát is támogat. A Microsoft támogatja az SQL Server-összetevőket, míg partnereink támogatják a megfelelő klaszterezési technológiát. A Pacemaker mellett például a Linuxon futó SQL Server a HPE Serviceguardot és a DH2i DxEnterprise-t támogatja fürtmegoldásként.

A Windows-alapú feladatátvevő fürt és a Linux-fürtmegoldás több hasonlóságot mutat, mint különbözőséget. Mindkettő lehetővé teszi, hogy egyesítse az egyes kiszolgálókat, és egy konfigurációban kombinálja őket a rendelkezésre állás biztosításához, és olyan fogalmakkal rendelkezzen, mint az erőforrások, a korlátozások (még ha eltérően is implementálva vannak), a feladatátvétel és így tovább.

Ha például támogatni szeretné a Pacemakert az AG- és FCI-konfigurációkhoz, például az automatikus feladatátvételhez, a Microsoft biztosítja a mssql-server-ha csomagot, amely hasonló, de nem pontosan ugyanaz, mint a Pacemaker esetében a WSFC-ben található erőforrás-DLL-ek. A WSFC és a Pacemaker között az egyik különbség az, hogy a Pacemakerben nincs hálózatinév-erőforrás, amely az a komponens, amely segít elkülöníteni a figyelő nevét (vagy az FCI nevét) egy WSFC-n. Névfeloldáshoz használja a DNS-t Linuxon.

A fürtverem különbsége miatt az SQL Server 2017-es (14.x) és újabb verzióiban az AG-knek részben azokat a metaadatokat is kezelniük kell, amelyeket a WSFC natív módon kezel. Egy rendelkezésre állási csoportnak például három fürttípusa van, amelyek a cluster_type és a cluster_type_desc oszlopban sys.availability_groups tárolódnak.

• WSFC
• Külső
• Egyik sem

Minden magas rendelkezésre állást igénylő elérhetőségi csoportnak egy háttérben futó fürtöt kell használni, amely az SQL Server 2017 (14.x) és újabb verziók esetében WSFC-t vagy Linux fürtkezelő ügynököt jelent. Azoknál az Windows Server rendszerű AG-knál, amelyek WSFC-t használnak, az alapértelmezett fürttípus a WSFC, ezért nincs szükség annak beállítására. Linux-alapú AG-k esetén a klaszter típusát külsőre kell beállítani az AG létrehozása során. A linuxos külső fürtmegoldással való integráció az AG létrehozása után van konfigurálva, míg egy WSFC-n a létrehozáskor történik.

A Nincs típusú fürt használható Windows Server és Linux AG-kkel is. A fürttípus Nincs értékre állítása azt jelenti, hogy az AG-nek nincs szüksége mögöttes fürtre. Ez azt jelenti, hogy az SQL Server 2017 (14.x) az SQL Server első verziója, amely fürt nélkül támogatja a rendelkezésre állási csoportokat (AG-k), viszont ennek a kompromisszumnak az ára, hogy ez a konfiguráció nem minősül magas rendelkezésre állású megoldásnak.

Fontos

Az SQL Server 2017 (14.x) és újabb verzióiban a létrehozás után nem módosíthatja az AG fürttípusát. Ez a korlátozás azt jelenti, hogy egy AG (Availabilitási Csoport) nem váltható át a „Nincs” beállításról „Külső” vagy „WSFC” beállításra, és fordítva.

Ha csak további írásvédett másolatokat szeretne hozzáadni egy adatbázishoz, vagy ha azt szeretné, hogy az AG mit biztosít az áttelepítéshez és a frissítésekhez, de nem szeretne foglalkozni az alapul szolgáló fürt vagy akár a replikáció összetettségével, fontolja meg egy AG beállítását a Nincs fürttípussal. További információkért tekintse meg a Migrálások és frissítések, valamint az olvasási skálázás című szakaszt.

Az alábbi képernyőképen az SQL Server Management Studio (SSMS) különböző fürttípusainak támogatása látható. A 17.1-es vagy újabb verziót kell futtatnia. A következő képernyőkép a 17.2-es verzióból származik:

KÖVETELMÉNYEK_A_SZINKRONIZÁLT_MÁSODLAGOSOK_ELKÖTELEZÉSÉHEZ

Az SQL Server 2016 (13.x) az Enterprise kiadásban kettőről háromra növelte a szinkron replikák számát. Ha azonban az egyik másodlagos replika szinkronizálva van, de a másik replika problémába ütközik, nem lehet szabályozni azt a viselkedést, amely azt jelzi az elsődlegesnek, hogy várja meg a hibásan viselkedő replikát, vagy engedélyezze a továbblépést. Ebben az esetben az elsődleges replika akkor is képes írási forgalmat fogadni, ha a másodlagos replika nem szinkronizált állapotban van, ami adatvesztést okoz a másodlagos replikán.

Az SQL Server 2017 (14.x) és újabb verzióiban szabályozhatja a szinkron replikák REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMITviselkedését. Ez a beállítás a következőképpen működik:

• Három lehetséges érték létezik: 0, 1és 2.
• Az érték a szinkronizálandó másodlagos replikák száma, ami hatással van az adatvesztésre, az AG rendelkezésre állására és a feladatátvételre.
• A WSFC-k esetében, amikor a fürt típusa 'Nincs', az alapértelmezett érték 0, és manuálisan beállíthatja 1 vagy 2 értékre.
• Külső fürttípus esetén a fürt mechanizmusa alapértelmezés szerint beállítja ezt az értéket, és manuálisan módosíthatja, ha szükséges. Három szinkron replika esetében az alapértelmezett érték az 1.

A Linux rendszeren konfigurálja a fürt AG-erőforrásának értékét REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Windows rendszeren a Transact-SQL-en keresztül állíthatja be.

Egy olyan érték, amely magasabb 0, biztosít nagyobb adatvédelmet, mert ha a szükséges számú másodlagos replika nem áll rendelkezésre, az elsődleges addig nem érhető el, amíg a feltétel meg nem szűnik. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT a feladatátvételi viselkedésre is hatással van, mivel az automatikus feladatátvétel nem fordulhat elő, ha a másodlagos replikák megfelelő száma nem megfelelő állapotban van. Linux rendszeren az érték 0 nem teszi lehetővé az automatikus feladatátvételt, ezért ha szinkront használ az automatikus feladatátvétellel Linuxon, az értéket magasabbra kell állítania, mint 0 az automatikus feladatátvétel eléréséhez. 0 Windows Serveren az SQL Server 2016 (13.x) és a korábbi verziók viselkedése.

A Microsoft Distributed Transaction Coordinator továbbfejlesztett támogatása

Az SQL Server 2016 (13.x) előtt az egyetlen módja annak, hogy elérhető legyen az SQL Serverben az elosztott tranzakciókat igénylő alkalmazások számára, amelyek a fedelek alatt DTC-t használnak, az FCI-k üzembe helyezése volt. Az elosztott tranzakciók kétféleképpen végezhetők el:

• Egy tranzakció, amely egynél több adatbázisra terjed ki ugyanabban az SQL Server-példányban.
• Egy olyan tranzakció, amely egynél több SQL Server-példányra terjed ki, vagy egy nem SQL Server-adatforrást is magában foglal.

Az SQL Server 2016 (13.x) részleges támogatást nyújtott a DTC-hez az utóbbi forgatókönyvet lefedő AG-kkel. Az SQL Server 2017 (14.x) mindkét forgatókönyvet támogatja a DTC-vel.

Az SQL Server 2017 (14.x) és újabb verzióiban a létrehozás után DTC-támogatást adhat hozzá egy AG-hez. Az SQL Server 2016-ban (13.x) csak AG létrehozásakor engedélyezheti a DTC-támogatást.

Átállási fürtpéldányok

A feladatátvevő fürtpéldányok (FCI-k) rendelkezésre állnak az SQL Server teljes telepítéséhez, más néven példányhoz. Az FCI-k esetében, ha a mögöttes kiszolgáló problémába ütközik, a rendszer a példányon belül mindent áthelyez egy másik kiszolgálóra, beleértve az adatbázisokat, az SQL Server Agent-feladatokat, a csatolt kiszolgálókat stb. Minden FCI-hez szükség van némi megosztott tárolóra, még akkor is, ha hálózat van meghatározva. Egy csomópont bármikor futtathatja és birtokolhatja az FCI erőforrásait. Az alábbi ábrán a fürt első csomópontja az FCI tulajdonosa. Emellett a hozzá társított megosztott tárolási erőforrásokat is birtokolja, amelyet a tárterület szilárd sora jelöl.

A feladatátvétel után a tulajdonjog megváltozik, ahogyan az alábbi ábrán látható:

Az FCI-k nulla adatvesztéssel járnak, de a mögöttes megosztott tároló egyetlen meghibásodási pont, mivel az adatok egy példánya van. Az adatbázisok redundáns másolatainak használatához kombinálja az FCI-ket egy másik rendelkezésre állási módszerrel, például AG-vel vagy naplószállítással. A másik módszernek fizikailag külön tárolót kell használnia az FCI-től. Amikor az FCI egy másik csomópontra omlik át, az egyik csomóponton leáll, és egy másik csomóponton indul el. Ez a folyamat hasonló a kiszolgáló kikapcsolásához és bekapcsolásához.

Az FCI a normál helyreállítási folyamaton megy keresztül. Minden olyan tranzakciót továbbít, amelyet elő kell állítani, és visszaállítja a nem teljes tranzakciókat. Ezért az adatbázis egy adatponttól a hiba időpontjáig vagy a manuális feladatátvételig konzisztens, így nincs adatvesztés. Az adatbázisok csak a helyreállítás befejezése után érhetők el. A helyreállítási idő számos tényezőtől függ, és általában hosszabb, mint egy rendelkezésre állási csoport (AG) feladatátvétele. A kompromisszum az, hogy ha feladatátvételt hajt végre egy AG-en, előfordulhat, hogy további feladatokra van szükség az adatbázisok használhatóvá tételéhez, például egy SQL Server Agent-feladat engedélyezéséhez.

Megjegyzés:

A gyorsított adatbázis-helyreállítás (ADR) csökkentheti a helyreállítási időt. További információ: Gyorsított adatbázis-helyreállítás.

Az AG-hez hasonlóan az FCI-k is eltakarják, hogy a mögöttes fürt melyik csomópontja üzemelteti őket. Az FCI-k mindig ugyanazt a nevet őrzik meg. Az alkalmazások és a végfelhasználók soha nem csatlakoznak a csomópontokhoz. Ehelyett az FCI-hez rendelt egyedi nevet használják. Az FCI az elsődleges vagy másodlagos replikát üzemeltető példányok egyikeként részt vehet egy AG-ben.

Az alábbi lista néhány különbséget mutat a Windows Server és a Linux rendszeren futó FCI-k között:

• Windows Serveren az FCI a telepítési folyamat része. Az SQL Server telepítése után konfigurálhat egy FCI-t Linuxon.
• Linux csak egyetlen SQL Server telepítést támogat gazdagépenként, tehát az összes FCI alapértelmezett példány. A Windows Server WSFC-enként legfeljebb 25 FCI-t támogat.
• A Linuxban az FCI-k által használt köznapi név a DNS-ben van definiálva, és meg kell egyeznie az FCI-hez létrehozott erőforrással.

Naplók továbbítása

Ha a helyreállítási pont és a helyreállítási idő célkitűzései rugalmasabbak, vagy az adatbázisok nem kritikus fontosságúak, a naplószállítás egy másik bevált rendelkezésre állási funkció az SQL Serverben. Az SQL Server natív biztonsági másolatai alapján a naplók szállításának folyamata automatikusan létrehozza a tranzakciónaplók biztonsági mentéseit, átmásolja őket egy vagy több, meleg készenléti állapotnak nevezett példányra, és automatikusan alkalmazza a tranzakciónapló biztonsági mentéseit az adott készenléti állapotra. A naplószállítás SQL Server Agent-feladatokkal automatizálja a tranzakciónaplók biztonsági mentésének, másolásának és alkalmazásának folyamatát.

A naplók szállításának legnagyobb előnye, hogy emberi hibát okoz, mivel késleltetheti a tranzakciónaplók alkalmazását. Ha például valaki UPDATE záradék nélkül ad ki, előfordulhat, hogy a készenléti rendszer nem tartalmazza a módosítást, így ezt használhatja, miközben az elsődleges rendszert javítja. Bár a naplószállítás egyszerűen konfigurálható, az elsődlegesről a meleg tartalék állapotra való, szerepkör-változásnak nevezett váltás mindig manuális. A Transact-SQL-en keresztül kezdeményezhet szerepkör-módosítást, és egy AG-hez hasonlóan manuálisan kell szinkronizálnia a tranzakciónaplóban nem rögzített összes objektumot. Adatbázisonként konfigurálnia kell a naplószállítást, míg egyetlen AG több adatbázist is tartalmazhat.

Az AG-től vagy FCI-től eltérően a naplók szállításának nincs absztrakciója a szerepkörváltozáshoz, amelyet az alkalmazásoknak kezelniük kell. Az olyan technikák, mint a DNS-alias (CNAME) alkalmazhatók, de vannak előnyei és hátrányai, például az, hogy mennyi időbe telik a DNS frissítése a váltás után.

Katasztrófa utáni helyreállítás

Ha az elsődleges rendelkezésre állási hely katasztrofális eseményt, például földrengést vagy árvizet tapasztal, a vállalatnak fel kell készülnie arra, hogy a rendszerei máshol is online állapotba kerülnek. Ez a szakasz bemutatja, hogyan segíthetik az SQL Server rendelkezésre állási funkciói az üzletmenet folytonosságát.

Rendelkezésre állási csoportok

Az AG-k egyik előnye, hogy egyszerre konfigurálja a magas rendelkezésre állást és a vészhelyreállítást egyetlen funkcióval. A megosztott tárterület magas rendelkezésre állásának biztosítása nélkül sokkal egyszerűbb, ha az egyik adatközpontban helyi replikákat használ a magas rendelkezésre állás érdekében, a többi adatközpontban pedig távoli replikákat, amelyek mindegyike külön tárterülettel rendelkezik a vészhelyreállításhoz. Az adatbázis további másolatainak használata a redundancia biztosításának kompromisszuma. Az alábbi ábrán egy több adatközpontot felölelő AG-példa látható. Egy elsődleges replika felelős az összes másodlagos replika szinkronizálásáért.

A Nincs fürttípusú AG-n kívül az AG megköveteli, hogy minden replika ugyanazon mögöttes fürt része legyen, legyen az WSFC vagy külső fürtmegoldás. Az előző ábrán a WSFC két különböző adatközpontban működik, ami a platformtól (Windows Server vagy Linux) függetlenül összetettebbé teszi. A fürtök távolságra nyújtása összetettséget ad hozzá.

Az SQL Server 2016 (13.x)-ben bevezetett elosztott rendelkezésre állási csoport lehetővé teszi, hogy az AG különböző fürtökön konfigurált AG-kre terjedjen ki. Az elosztott AG-k leválasztják azt a követelményt, hogy a csomópontok mind ugyanabban a fürtben vegyenek részt, ami sokkal egyszerűbbé teszi a vészhelyreállítás konfigurálását. Az elosztott AG-kkel kapcsolatos további információkért lásd: Elosztott rendelkezésre állási csoportok.

Átállási fürtpéldányok

Az FCI-k vészhelyreállításhoz használhatók. A normál AG-hez hasonlóan minden helyre ki kell terjesztenie a mögöttes fürtmechanizmust, ami növeli a komplexitást. Az FCI-k esetében a megosztott tárterületet is figyelembe kell vennie. Az elsődleges és a másodlagos helyeknek ugyanahhoz a lemezhez kell hozzáférni. Annak érdekében, hogy az FCI által használt tároló mindkét helyen megtalálható legyen, használjon egy külső módszert, például a hardverréteg tárolószolgáltatója által biztosított funkciókat. Vagy használja a Storage Replicát a Windows Serveren.

Naplók továbbítása

A naplószállítás az SQL Server-adatbázisok vészhelyreállításának egyik legrégebbi módszere. A naplószállítást gyakran használják az AG-k és FCI-k a költséghatékony és egyszerűbb vészhelyreállítás érdekében, ahol a környezet, a felügyeleti készségek vagy a költségvetés miatt más lehetőségek is kihívást jelenthetnek. A naplószállítás magas rendelkezésre állási történetéhez hasonlóan számos környezet késlelteti a tranzakciónapló betöltését, hogy emberi hibát számoljon fel.

Migrálások és frissítések

Amikor egy szervezet új példányokat helyez üzembe, vagy frissíti a régieket, nem tolerálhatja a hosszú kimaradásokat. Ez a szakasz azt ismerteti, hogyan használhatók az SQL Server rendelkezésre állási funkciói a tervezett architektúraváltás, a kiszolgálóváltás, a platformváltás (például a Windows Server linuxos vagy fordítva) állásidejének minimalizálására, illetve a javítások során.

Megjegyzés:

Más módszereket is használhat, például biztonsági mentéseket és visszaállításokat az áttelepítésekhez és a frissítésekhez. Ez a cikk nem tárgyalja ezeket a módszereket.

Rendelkezésre állási csoportok

Frissíthet egy meglévő példányt, amely egy vagy több rendelkezésre állási csoportot (AG- t) tartalmaz az SQL Server későbbi verzióira. Bár ez a frissítés némi állásidőt igényel, megfelelő tervezéssel minimalizálható.

Ha a konfiguráció módosítása nélkül szeretne új kiszolgálókra migrálni (beleértve az operációs rendszert vagy az SQL Server-verziót), vegye fel ezeket a kiszolgálókat csomópontként a meglévő mögöttes fürtbe, majd vegye fel őket az AG-be. Miután a replikák megfelelő állapotban vannak, manuálisan át kell állni egy új szerverre. Ezután távolítsa el a régi kiszolgálókat az AG-ből, és szerelje le őket.

Az elosztott AG-k egy másik módszer az új konfigurációba való migrálásra vagy az SQL Server frissítésére is. Mivel az elosztott AG különböző architektúrákon támogatja a különböző mögöttes AG-ket, a Windows Server 2019-en futó SQL Server 2019 -ről (15.x) a Windows Server 2025-en futó SQL Server 2025-re (17.x) válthat.

Végül a "N/A" fürttípusú AG-k hasznosak migráláshoz vagy frissítéshez. A klaszter típusai nem keverhetők és nem kombinálhatók egy tipikus AG-konfigurációban, így minden replikának a "None" típusúnak kell lennie. Az elosztott AG-k használhatók különböző fürttípusokkal konfigurált AG-k összefogására. Ez a módszer a különböző operációsrendszer-platformokon is támogatott.

A migrálási és frissítési AG-k minden változata lehetővé teszi az adatszinkronizálást, amely a munka legidőigényesebb része, időben elosztva történhet. Amikor el kell indítani az új konfigurációra való váltást, az átállás rövid leállást jelent, szemben egy hosszú állásidővel, ahol minden munkát, beleértve az adatszinkronizálást is, be kell fejezni.

Az AG-k minimális állásidőt biztosíthatnak a mögöttes operációs rendszer frissítése során azáltal, hogy kézi feladatátvételt hajtanak végre egy másodlagos replikára, miközben a frissítés folyamatban van. Az operációs rendszer szempontjából ez gyakoribb a Windows Serveren, mivel a mögöttes operációs rendszer karbantartása újraindítást igényelhet. A Linux javítása néha újraindítást igényel, de ez kevésbé gyakori.

Az állásidő minimalizálásának másik módja a rendelkezésre állási csoportban részt vevő SQL Server-példányok javítása attól függően, hogy mennyire összetett az AG-architektúra. Először egy másodlagos replikát kell kijavítania. A megfelelő számú replika javítása után manuálisan adja át az elsődleges replikát egy másik csomópontnak a frissítés végrehajtásához. Frissítse az adott időpontban fennmaradó másodlagos replikákat.

Átállási fürtpéldányok

Az FCI-k önmagukban nem tudnak segíteni a hagyományos migrálásban vagy frissítésben. Konfigurálnia kell egy AG-t vagy naplószállítást az FCI-ben lévő adatbázisokhoz, és el kell számolnia az összes többi objektummal. A Windows Server alatti FCI-k azonban továbbra is népszerűek, ha ki kell javítania a mögöttes Windows-kiszolgálókat. Ha manuális feladatátvételt kezdeményez, a rövid leállás helyettesíti azt az időszakot, amikor a példány a Windows Server javításának teljes ideje alatt lenne elérhetetlen.

Az FCI-t frissítheti az SQL Server későbbi verzióira. További információ: Feladatátvevő fürtpéldány frissítése.

Naplók továbbítása

A naplószállítás továbbra is népszerű lehetőség az adatbázisok migrálásához és frissítéséhez. Az AG-hez hasonlóan, de ezúttal a tranzakciónapló szinkronizálási módszerként való használatával az adatpropagálás a kiszolgálókapcsoló előtt is elindítható. Amikor a váltás megtörténik, amint az összes forgalom leáll a forrásnál, a végleges tranzakciónaplót el kell készíteni, át kell másolni, és alkalmazni kell az új konfigurációra. Ezen a ponton az adatbázis online állapotba hozható.

A naplószállítás gyakran toleránsabb a lassabb hálózatoknál, és bár a kapcsoló kissé hosszabb lehet, mint egy AG vagy elosztott AG használatával, általában percekben, nem órákban, napokban vagy hetekben mérik.

Az AG-hez hasonlóan a naplók szállításával egy másik kiszolgálóra válthat a karbantartási időszak során.

Egyéb SQL Server-telepítési módszerek és rendelkezésre állás

A Linuxon futó SQL Serverhez két másik üzembe helyezési módszer is létezik: tárolók és az Azure (vagy egy másik nyilvános felhőszolgáltató) használata. A rendelkezésre állás általános szükséglete az SQL Server üzembe helyezésétől függetlenül fennáll. Ez a két módszer különleges szempontokat is figyelembe véve teszi magas rendelkezésre állásúvá az SQL Servert.

SQL Server-tárolók és HA/DR-beállítások

Az SQL Server tárolótelepítése leegyszerűsíti az SQL Server üzembe helyezését, méretezését és életciklus-felügyeletét a környezetek között. A tároló az SQL Server teljes használatra kész rendszerképe.

A tárolóplatformtól függően, például a Kuberneteshez hasonló tárolóvezénylő használatakor, ha a tároló elveszett, újra üzembe helyezhető, és a használt megosztott tárolóhoz csatolható. Bár ez némi rugalmasságot biztosít, van némi állásidő az adatbázis-helyreállításhoz, és nem igazán magas rendelkezésre állású, mint egy rendelkezésre állási csoport vagy FCI használata esetén.

Ha magas rendelkezésre állást szeretne konfigurálni a Kubernetesen vagy nem Kubernetes-platformokon üzembe helyezett SQL Server-tárolókhoz, akkor a DH2i DxEnterprise-t használhatja az egyik fürtözési megoldásként, amelyen felül magas rendelkezésre állású módban konfigurálhat egy AG-t. Ez a beállítás biztosítja a magas rendelkezésre állású megoldástól elvárt helyreállításipont-célkitűzést (RPO) és helyreállítási időkorlátot (RTO).

Linux-alapú virtuális gépek üzembe helyezése

Linux sql serverrel üzembe helyezhető Linux Azure-beli virtuális gépeken. A helyszíni telepítésekhez hasonlóan a támogatott telepítéshez is szükség van egy sikertelen csomópont kizárására, amely a fürtügynöktől független. A csomópontok kerítését a rendelkezésre állási ügynökök biztosítják. Egyes disztribúciók a platform részeként küldik el őket, míg mások külső hardver- és szoftvergyártókra támaszkodnak. Ellenőrizze az előnyben részesített Linux-disztribúciót, hogy lássa, milyen csomópontkerítési formák érhetők el, hogy egy támogatott megoldás üzembe helyezhető legyen a nyilvános felhőben.

Az SQL Server Linuxon való telepítésének útmutatói a következő disztribúciókhoz érhetők el:

• Rövid útmutató: Az SQL Server telepítése és adatbázis létrehozása a Red Haton
• Rövid útmutató: Az SQL Server telepítése és adatbázis létrehozása az Ubuntu-on
• Rövid útmutató: Az SQL Server telepítése és adatbázis létrehozása a SUSE Linux Enterprise Serveren

Olvasási skálázás

A másodlagos replikák írásvédett lekérdezésekhez használhatók. Az AG-vel kétféleképpen lehet elérni:

• Közvetlen hozzáférés engedélyezése a másodlagoshoz
• Csak olvasási útválasztás konfigurálása, amelyhez a figyelő használata szükséges. Az SQL Server 2016 (13.x) bevezette azt a lehetőséget, hogy egy round robin algoritmus segítségével a figyelővel terheléselosztást végezzen az olvasott kérések között, lehetővé téve ezeknek minden olvasható replika közötti elosztását.

Megjegyzés:

Az olvasható másodlagos replikák csak az Enterprise kiadásban érhetők el. Minden olvasható replikát üzemeltető példányhoz SQL Server-licenc szükséges.

Az adatbázis olvasható példányainak AG-n keresztüli skálázását először elosztott AG-kkel vezették be az SQL Server 2016-ban (13.x). Ez a funkció nem csak helyben, hanem regionálisan és globálisan is csak olvasható másolatokat kínál az adatbázisról, minimális konfigurációval. Ez a beállítás csökkenti a hálózati forgalmat és a késést azáltal, hogy a lekérdezések helyileg futnak. Az AG minden elsődleges replikája két másik AG-t is képes létrehozni, még akkor is, ha nem ez a teljes olvasási/írási másolat, és minden elosztott AG legfeljebb 27 olvasható adatpéldányt támogat.

Az SQL Server 2017 (14.x) és újabb verzióiban közel valós idejű, írásvédett megoldást hozhat létre a Nincs fürttípussal konfigurált AG-kkel. Ha a cél az AG-k használata olvasható másodlagos replikákhoz, és nem a rendelkezésre állás biztosítása, ez a megközelítés megszünteti a WSFC vagy egy külső klasztermegoldás használatának összetettségét Linuxon. Egyszerűbb üzembe helyezési módszerben nyújtja az AG olvasható előnyeit.

Ennek az egyetlen fő megjegyzése, hogy mivel nincs olyan mögöttes fürt, amelynek a fürttípusa „Nincs” lenne, az írásvédett útválasztás konfigurálása kissé eltérő. SQL Server-szempontból továbbra is figyelőre van szükség a kérések átirányításához annak ellenére, hogy nincs fürt. Hagyományos figyelő konfigurálása helyett használja az elsődleges replika IP-címét vagy nevét. Az elsődleges replika ezután átirányítja a csak olvasható kérelmeket.

A naplószállítási meleg készenléti állapot technikailag beállítható olvasható használatra az adatbázis WITH STANDBYvisszaállításával. Mivel azonban a tranzakciónaplók az adatbázis kizárólagos használatát igénylik a helyreállításhoz, ez azt jelenti, hogy a felhasználók nem férhetnek hozzá az adatbázishoz, amíg ez megtörténik. Ez a naplószállítást kevésbé ideális megoldássá teszi – különösen akkor, ha közel valós idejű adatokra van szükség.

Ellentétben a tranzakciós replikációval, ahol az összes adat élő, az olvasási skálázási forgatókönyv minden másodlagos replikája az elsődleges példány pontos másolata. A replika nem olyan állapotban van, amelyben egyedi indexek alkalmazhatók. Ha a jelentéskészítéshez indexekre van szükség, vagy ha az adatokat módosítani kell, akkor ezeket az indexeket az elsődleges replikán lévő adatbázisokon kell létrehoznia. Ha erre a rugalmasságra van szüksége, a replikáció jobb megoldás az olvasható adatokhoz.

Platformfüggetlen és Linux-elosztási együttműködés

Az SQL Server windowsos és linuxos támogatásával ez a szakasz azt ismerteti, hogyan működhetnek együtt a rendelkezésre állás érdekében más célok mellett. Emellett egynél több Linux-disztribúciót tartalmazó megoldások történetét is ismerteti.

Megjegyzés:

Nincsenek olyan forgatókönyvek, melyekben egy WSFC-alapú feladatátvevő fürtpéldány (FCI) vagy rendelkezésre állási csoport (AG) közvetlenül együttműködik Linux-alapú FCI-vel vagy AG-vel. A Windows Server-feladatátvevő fürt (WSFC) nem bővíthető Pacemaker-csomóponttal, és fordítva.

Elosztott rendelkezésre állási csoportok

Az elosztott AG-k úgy vannak kialakítva, hogy átfogják az AG konfigurációkat, függetlenül attól, hogy a két mögöttes fürt az AG-k alatt két különböző WSFC, Linux-disztribúció, vagy az egyik WSFC-n, a másik Linuxon van. A platformfüggetlen megoldások elsődleges módszere az elosztott AG. Az elosztott AG az elsődleges megoldás az olyan migrálásokhoz is, mint a Windows Server-alapú SQL Server-infrastruktúráról Linux-alapúra való konvertálás, ha a vállalat ezt szeretné. Ahogy korábban már említettük, az AG-k és különösen az elosztott AG-k minimálisra csökkentenék azt az időt, amikor egy alkalmazás nem használható. Az alábbi ábrán egy WSFC-t és Pacemakert átfogó elosztott AG látható:

Ha olyan AG-t konfigurál, amelynek fürttípusa 'Nincs', az kiterjedhet a Windows Serverre, a Linuxra, valamint többféle Linux-disztribúcióra is. Mivel ez a konfiguráció nem valódi magas rendelkezésre állást biztosító, ne használja küldetéskritikus üzemelő példányokhoz. Ehelyett használja olvasási igényekhez vagy migrálási és frissítési forgatókönyvekhez.

Naplók továbbítása

A naplószállítás a biztonsági mentésen és a visszaállításon alapul, így a Windows Serveren futó SQL Server és a Linux SQL Server adatbázisaiban, fájlstruktúráiban és egyéb elemeiben nincs különbség. Konfigurálhatja a naplószállítást egy Windows Server-alapú SQL Server-telepítés és egy Linux rendszerű telepítés között, valamint a Linux disztribúciói között. Minden más ugyanaz marad.

Az AG-hez hasonlóan a naplóküldés sem működik, ha a forráskiszolgáló magasabb SQL Server főverzióval rendelkezik, mint a célkiszolgáló alacsonyabb főverziója.

Összefoglalás

Az SQL Server 2017 (14.x) és újabb verzióinak példányait és adatbázisait magas rendelkezésre állásúvá teheti, ha ugyanazokat a funkciókat használja a Windows Serveren és a Linuxon is. A helyi magas rendelkezésre állás és vészhelyreállítás szabványos rendelkezésre állási forgatókönyvei mellett az SQL Server rendelkezésre állási funkcióinak használatával minimalizálhatja a frissítésekkel és migrálásokkal kapcsolatos állásidőt. Az AG-k emellett további másolatokat is biztosíthatnak az adatbázisokról ugyanazon architektúra részeként az olvasható példányok felskálázásához. Akár új megoldást helyez üzembe, akár frissítést fontolgat, az SQL Server rendelkezik a szükséges rendelkezésre állással és megbízhatóságsal.

Kapcsolódó tartalom

• Mi az Always On rendelkezésre állási csoport?
• Telepítse az SQL Server feladatátvevő fürtöt