Ü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 Server üzembe helyezésének egyik gyakori feladata, hogy minden kritikus fontosságú SQL Server-példány és a bennük lévő adatbázisok elérhetők legyenek, amikor a vállalatnak és a végfelhasználóknak szükségük van rájuk, akár 9–5, akár éjjel-nappal. 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) számos új funkciót vagy fejlesztést vezetett be a meglévőkhöz, amelyek közül néhány elérhető. Az SQL Server 2017 (14.x) legnagyobb kiegészítése az SQL Server linuxos disztribúciókon való támogatása volt. Az SQL Server új funkcióinak teljes listáját az alábbi cikkekben találja:

Ez a cikk az SQL Server 2017 (14.x) és újabb verzióinak rendelkezésre állási forgatókönyveit, valamint az új és továbbfejlesztett rendelkezésre állási funkciókat ismerteti. A forgatókönyvek közé tartoznak azok a hibridek, amelyek a Windows Serveren és a Linuxon egyaránt képesek átfogni az SQL Server üzemelő példányait, és amelyek növelhetik az adatbázisok olvasható példányainak számát.

Bár ez a cikk nem terjed ki az SQL Serveren kívüli rendelkezésre állási lehetőségekre, például a virtualizálás által biztosított lehetőségekre, 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.

SQL Server-forgatókönyvek a rendelkezésre állási funkciók használatával

Az Always On rendelkezésre állási csoportok, az Always On feladatátvevő fürtpéldányok és a naplószállítás különböző módokon használhatók, és nem feltétlenül csak rendelkezésre állási célokra. 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 adott forgatókönyvhöz használható releváns funkciókat ismertetik. Az egyetlen nem érintett funkció az SQL Server replikációja. Bár az Always On esernyőben hivatalosan nem jelölték ki rendelkezésre állási funkcióként, az SQL Server replikációját gyakran használják az adatok redundánssá tételéhez bizonyos helyzetekben. 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, amely 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 olyan probléma esetén, 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 a feladatban. Az összes leírt funkció elérhető Windows Serveren és Linuxon is.

Rendelkezésre állási csoportok

Az SQL Server 2012 -ben (11.x) bevezetett rendelkezésre állási csoportok (AG-k) adatbázisszintű védelmet nyújtanak azáltal, hogy az 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. Az AG 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 lenne. Bár a figyelő implementációi kissé eltérnek a Windows Server és a Linux rendszeren, a szolgáltatás és a használatuk ugyanaz. 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.

Egyszerű rendelkezésre állási csoport ábrája.

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 lesz 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. Ha a figyelőt használja, és az alkalmazás a .NET-keretrendszer egy későbbi verzióját használja (3.5 frissítéssel vagy 4.0-s vagy újabb verzióval), a feladatátvételt minimális hatással kell kezelni a végfelhasználókra, ha egy 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ésének különbségei miatt az AG-k feladatátvétele (manuális vagy automatikus) a Linuxon futó 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.
Linuxon futó SQL Server esetén az AG-k ajánlott konfigurációja legalább három replika. Ennek oka az alapul szolgáló klaszterezés működése.
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 mutatja 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 AG-k és FCI-k integrációját az SQL Server által szállított készletbarát erőforrás-DLL-ek biztosítják.

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. A DNS biztosítja a névfeloldást Linuxon.

A fürtverem különbsége miatt módosításokat kellett végrehajtani az Elérhetőségi Csoportokban (AG-k), mivel az SQL Servernek kezelnie kell a WSFC által natívan kezelt metaadatok egy részét. Ilyen jelentős változás egy rendelkezésre állási csoport fürttípusának bevezetése. Az adat a sys.availability_groups sorban, valamint a cluster_type és cluster_type_desc oszlopokban van tárolva. Három fürttípus létezik:

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. Az alapul szolgáló WSFC-t használó Windows Server-alapú AG-k esetében az alapértelmezett fürttípus a WSFC, és nem kell beállítani. Linux-alapú AG-k esetén az AG létrehozásakor a fürt típusát külsőre kell állítani. 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 azt jelenti, hogy az AG nem váltható át a Nincs értékről külsőre vagy WSFC-re, vagy fordítva.

Azok számára, akik csak olvasási jogú másolatokat szeretnének hozzáadni egy adatbázishoz, vagy kedvelik azt a támogatást, amit egy AG nyújt a migráció/fejlesztés során, de nem szeretnének kötődni a mögöttes fürt vagy akár a replikáció további bonyolultságához, a fürt nélküli AG (Availability Group) tökéletes megoldás. 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. Az alábbi 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 lett, de a másik problémába ütközött, nem lehetett szabályozni a viselkedést, hogy az elsődlegest vagy várja meg a hibásan viselkedő replikát, vagy engedélyezze a továbblépést. Ez azt jelenti, hogy az elsődleges replika egy ponton továbbra is megkapja az írási forgalmat, annak ellenére, hogy a másodlagos replika nem szinkronizált állapotban lenne, ami azt jelenti, hogy adatvesztés történt 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 és ha a fürt típusa 'Nincs', az alapértelmezett érték 0, de manuálisan beállítható 1 vagy 2.
A "Külső" fürttípus esetén a mechanizmus alapértelmezés szerint beállítja ezt az értéket, de ez manuálisan felülírható. Három szinkron replika esetén az alapértelmezett érték az lesz 1.

Linux-on az REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT értéket a fürt AG erőforrásán konfigurálják. Windows rendszeren a Transact-SQL-en keresztül van beállítva.

Az 0-nál magasabb érték biztosít magasabb szintű adatvédelmet, mert ha a szükséges számú másodlagos replika nem érhető el, a primer replika nem lesz elérhető, amíg ez meg nem oldódik. 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 a megfelelő állapotban van. Linuxon egy érték 0 nem teszi lehetővé az automatikus feladatátvételt, így Linuxon az automatikus feladatátvétellel szinkronban az értéket magasabb értékre kell állítani, 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
Több SQL Server-példányra kiterjedő vagy nem SQL Server-adatforrást tartalmazó tranzakció

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 DTC-támogatás a létrehozás után is hozzáadható az AG-hez. Az SQL Server 2016-ban (13.x) a DTC támogatása csak az AG létrehozásakor hajtható végre.

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

A fürtözött telepítések a 6.5-ös verzió óta az SQL Server egyik funkciója. Az FCI-k bizonyított módszerként biztosítják a rendelkezésre állást az SQL Server teljes telepítéséhez, más néven egy példányhoz. Ez azt jelenti, hogy a példányon belül minden, beleértve az adatbázisokat, az SQL Server Agent-feladatokat, a csatolt kiszolgálókat stb., egy másik kiszolgálóra kerül, ha a mögöttes kiszolgáló problémába ütközik. Minden FCI-hez szükség van valamilyen megosztott tárolóra, még akkor is, ha az a hálózaton keresztül érhető el. Az FCI erőforrásai egyszerre csak egy csomóponton futhatnak és birtokolhatók. Az alábbi ábrán a fürt első csomópontja az FCI-t birtokolja, ami azt is jelenti, hogy a tárolóhoz társított megosztott tárolási erőforrásokat a tárolóhoz tartozó egysoros vonal jelöli.

Feladatátvevő fürtpéldány diagramja.

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

A feladatátvételt követő feladatátvételi fürtpéldány diagramja.

Az FCI-vel nincs adatvesztés, de a mögöttes megosztott tároló egyetlen meghibásodási pont, mivel az adatok egy példánya van. Az FCI-ket gyakran kombinálják egy másik rendelkezésre állási módszerrel, például AG-vel vagy naplószállítással, hogy az adatbázisok redundáns másolatai legyenek. Az üzembe helyezett további módszernek fizikailag külön tárolót kell használnia az FCI-től. Amikor az FCI átvált egy másik csomópontra, az egyik csomóponton leáll, és egy másik csomóponton indul el, hasonlóan a kiszolgáló kikapcsolásához és bekapcsolásához. Az FCI végighalad a normál helyreállítási folyamaton, ami azt jelenti, hogy minden olyan tranzakció, amelyet előre kell vinni, előre lesznek vive, és a nem teljes tranzakciók vissza lesznek vonva. Ezért az adatbázis egy adatponttól a hiba időpontjáig vagy 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, így a helyreállítási idő számos tényezőtől függ, és általában hosszabb lesz, mint egy 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.

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; a rendszer az FCI-hez rendelt egyedi nevet használja. 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. A Linuxon futó FCI az SQL Server telepítése után van konfigurálva.
Linux csak egy SQL Server telepítést támogat gazdagépenként, így az összes FCI alapértelmezett példányként fog működni. 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 tekinthetők kritikus fontosságúnak, a naplószállítás egy másik bizonyított 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.

Naplószállítási diagram.

Elképzelhető, hogy a naplószállítás használatának legnagyobb előnye az, hogy segít figyelembe venni és mérsékelni az emberi hibákat. A tranzakciós naplók alkalmazása késleltethető. Ezért ha valaki olyan hibát ad ki, mint egy UPDATE záradék nélkül WHERE , előfordulhat, hogy a készenléti állapot nem rendelkezik a módosítással, így erre válthat az elsődleges rendszer javítása során. Bár a naplószállítás egyszerűen konfigurálható, a szerepkörváltozásnak nevezett elsődlegesről a meleg készenléti üzemmódra való váltás mindig manuális. A szerepkör-módosítást a Transact-SQL kezdeményezi, és egy AG-hez hasonlóan a tranzakciónaplóban nem rögzített összes objektumot manuálisan kell szinkronizálni. A naplószállítást adatbázisonként is konfigurálni kell, 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.