Elosztott rendelkezésre állási csoportok

A következőkre vonatkozik:SQL Server

Az elosztott rendelkezésre állási csoport (AG) egy speciális rendelkezésre állási csoport, amely két különálló rendelkezésre állási csoportot foglal magában. Az elosztott rendelkezésre állási csoportok az SQL Server 2016-tól érhetők el.

Ez a cikk az elosztott rendelkezésre állási csoport funkciót ismerteti. Elosztott rendelkezésre állási csoport konfigurálásához lásd: Elosztott rendelkezésre állási csoportok konfigurálása.

Áttekintés

Az elosztott rendelkezésre állási csoport egy speciális rendelkezésre állási csoporttípus, amely két különálló rendelkezésre állási csoportot foglal magában. Az elosztott rendelkezésre állási csoportban részt vevő rendelkezésre állási csoportoknak nem kell ugyanabban a helyen lenniük. Lehetnek fizikai, virtuális, helyszíni, nyilvános felhőben vagy bárhol, amely támogatja a rendelkezésre állási csoportok üzembe helyezését. Ez magában foglalja a tartományok és platformok közötti átjárást – például egy Linuxon üzemeltetett és egy Windowson üzemeltetett rendelkezésre állási csoport között. Amíg két rendelkezésre állási csoport tud kommunikálni, konfigurálhat velük egy elosztott rendelkezésre állási csoportot.

A hagyományos rendelkezésre állási csoportok erőforrásai windows serveres feladatátvevő fürtben (WSFC) vagy Linuxon a Pacemakerben vannak konfigurálva. Az elosztott rendelkezésre állási csoport nem hajt végre semmilyen konfigurációt a háttérben működő fürtben (WSFC vagy Pacemaker). Az SQL Serveren belül minden benne van. Az elosztott rendelkezésre állási csoportok információinak megtekintéséhez tekintse meg az elosztott rendelkezésre állási csoport adatainak megtekintését ismertető témakört.

Az elosztott rendelkezésre állási csoportokhoz szükség van arra, hogy az alapul szolgáló rendelkezésre állási csoportok rendelkezzenek figyelővel. Ahelyett, hogy megadná az alapul szolgáló kiszolgálónevet egy különálló példányhoz (vagy SQL Server feladatátvevő fürtpéldány esetén [FCI], a hálózati név erőforráshoz rendelt értéket), mint ahogyan egy hagyományos rendelkezésre állási csoportnál tenné, a létrehozáskor az elosztott rendelkezésre állási csoport konfigurált figyelő végpontját kell megadnia az ENDPOINT_URL paraméterrel. Bár az elosztott rendelkezésre állási csoport minden mögöttes rendelkezésre állási csoportja rendelkezik figyelővel, az elosztott rendelkezésre állási csoport nem rendelkezik figyelővel.

Az alábbi ábra egy elosztott rendelkezésre állási csoport magas szintű nézetét mutatja be, amely két rendelkezésre állási csoportot (AG 1 és AG 2) foglal magában, amelyek mindegyike saját WSFC-n van konfigurálva. Az elosztott rendelkezésre állási csoport összesen négy replikával rendelkezik, és mindegyik rendelkezésre állási csoportban kettő található. Minden rendelkezésre állási csoport legfeljebb a replikák maximális számát támogathatja, így egy elosztott rendelkezésre állási csoport legfeljebb 18 replikával rendelkezhet.

Az elosztott rendelkezésre állási csoportokban az adatáthelyezés konfigurálható szinkron vagy aszinkron módon. Az adatáthelyezés azonban kissé eltér az elosztott rendelkezésre állási csoportokon belül a hagyományos rendelkezésre állási csoporthoz képest. Bár minden rendelkezésre állási csoport rendelkezik elsődleges replikával, az elosztott rendelkezésre állási csoportban részt vevő adatbázisoknak csak egy példánya van, amely elfogadhatja a beszúrásokat, frissítéseket és törléseket. Az alábbi ábrán látható módon az AG 1 az elsődleges rendelkezésre állási csoport. Az elsődleges replika tranzakciókat küld az AG 1 másodlagos replikáinak és az AG 2 elsődleges replikáinak. Az AG 2 elsődleges replikája továbbítóként is ismert. Egy továbbító az elsődleges replika szerepét tölti be egy elosztott rendelkezésre állási csoport másodlagos rendelkezésre állási csoportjában. A továbbító az elsődleges rendelkezésre állási csoport elsődleges replikájából fogadja a tranzakciókat, és továbbítja őket a saját rendelkezésre állási csoportjában lévő másodlagos replikáknak. A továbbító ezután frissíti az AG 2 másodlagos replikáit.

Az AG 2 elsődleges replikája csak úgy fogadhatja el a beszúrásokat, frissítéseket és törléseket, ha manuálisan adja át az elosztott rendelkezésre állási csoportot az AG 1-ből. Az előző ábrán, mivel az AG 1 tartalmazza az adatbázis írható példányát, a feladatátvétel kiállításával az AG 2 rendelkezésre állási csoporttá válik, amely képes kezelni a beszúrásokat, frissítéseket és törléseket. Az egyik elosztott rendelkezésre állási csoport feladatátvételéről további információt a másodlagos rendelkezésre állási csoport feladatátvétele című témakörben talál.

Megjegyzés:

• Az SQL Server 2016 elosztott rendelkezésre állási csoportjai csak az egyik rendelkezésreállási csoportról a másikra történő feladatátvételt támogatják a beállítással FORCE_FAILOVER_ALLOW_DATA_LOSS.
• Ha elosztott rendelkezésre állási csoportokkal használ tranzakciós replikációt, a továbbító replika nem konfigurálható közzétevőként.

SQL Server 2025-módosítások

Az SQL Server 2025 (17.x) a következő módosításokat vezeti be:

Az elosztott AG-szinkronizálás fejlesztése

Az SQL Server 2025 (17.x) megváltoztatja az elosztott rendelkezésre állási csoportok belső szinkronizálási mechanizmusát a szinkronizálási teljesítmény javítása érdekében azáltal, hogy csökkenti a hálózati telítettséget, ha a továbbító replika aszinkron véglegesítési módban van. Ez a módosítás alapértelmezés szerint engedélyezve van, és nem igényel semmilyen konfigurációt.

Megjegyzés:

Az elosztott rendelkezésre állási csoport konfigurálása a két mögöttes rendelkezésreállási csoport rendelkezésreállási módjai közötti eltéréssel nem ajánlott, és szinkronizálási késést okozhat. Az optimális teljesítmény és szinkronizálás érdekében mindkét rendelkezésre állási csoportot ugyanazzal a rendelkezésreállási móddal (szinkron vagy aszinkron) kell konfigurálni.

Tartalmazott rendelkezésre állási csoport támogatása

Az SQL Server 2025 (17.x) támogatja az elosztott, tartalmazott rendelkezésre állási csoportokat. Ha egy elosztott rendelkezésre állási csoportban tartalmazott AG-t szeretne továbbítóként használni, akkor létre kell hoznia a tartalmazott AG-t a AUTOSEEDING_SYSTEM_DATABASES parancs WITH | CONTAINED záradékával a opcióhoz.

Verzió- és kiadási követelmények

Az SQL Server 2017-ben vagy újabb verzióiban az elosztott rendelkezésre állási csoportok az SQL Server fő verzióit keverhetik ugyanabban az elosztott rendelkezésre állási csoportban. Az elsődleges olvasási/írási AG lehet ugyanaz a verzió vagy alacsonyabb, mint az elosztott AG-ben részt vevő többi AG. A többi AG ugyanazzal a verzióval vagy újabb verzióval is rendelkezhet. Ez a forgatókönyv a frissítési és migrálási forgatókönyvekre irányul. Ha például az elsődleges olvasási/írási replikát tartalmazó AG az SQL Server 2016, de frissíteni/migrálni szeretné az SQL Server 2017-re vagy újabbra, az elosztott AG-ben részt vevő többi AG konfigurálható az SQL Server 2017-zel.

Mivel az elosztott rendelkezésre állási csoportok funkció nem létezik az SQL Server 2012-ben vagy 2014-ben, az ezekkel a verziókkal létrehozott rendelkezésre állási csoportok nem vehetnek részt az elosztott rendelkezésre állási csoportokban.

Megjegyzés:

Az SQL Server verziójától függően az Azure-szolgáltatásokhoz (például a felügyelt példány hivatkozásához) való csatlakozáskor konfigurálható egy elosztott rendelkezésre állási csoport a Standard kiadással, vagy a Standard és a Nagyvállalati kiadások keveréke. További információért tekintse át KB5016729 .

Mivel két különálló rendelkezésre állási csoport létezik, a szervizcsomag vagy kumulatív frissítés telepítése egy elosztott rendelkezésre állási csoportban részt vevő replikára kissé eltér a hagyományos rendelkezésre állási csoportétól:

1. Először frissítse a második rendelkezésre állási csoport replikáit az elosztott rendelkezésre állási csoportban.

2. Az elosztott rendelkezésre állási csoportban található elsődleges rendelkezésre állási csoport replikáinak javítása.

3. A standard rendelkezésre állási csoporthoz hasonlóan, hajtsa végre a feladatátvételt az elsődleges rendelkezésre állási csoport egyik saját replikájára (nem a második rendelkezésre állási csoport elsődleges példányára), és foltozza meg azt. Ha az elsődlegesen kívül nincs más replika, manuális feladatátvételre lesz szükség a második rendelkezésre állási csoportra.

Windows Server-verziók és elosztott rendelkezésre állási csoportok

Az elosztott rendelkezésre állási csoportok több rendelkezésre állási csoportra is kiterjednek, amelyek mindegyike saját mögöttes WSFC-n alapul, az elosztott rendelkezésre állási csoport pedig csak SQL Server-konstrukció. Ez azt jelenti, hogy az egyes rendelkezésre állási csoportokhoz tartozó WSFC-k a Windows Server különböző fő verzióival rendelkezhetnek. Az SQL Server fő verzióinak meg kell egyeznie az előző szakaszban ismertetett verziókkal. A kezdeti ábrához hasonlóan az alábbi ábrán az AG 1 és az AG 2 szerepel, amely egy elosztott rendelkezésre állási csoportban vesz részt, de a WSFC-k mindegyike a Windows Server egy másik verziója.

Az egyes WSFC-k és a hozzájuk tartozó rendelkezésre állási csoportok a hagyományos szabályokat követik. Vagyis csatlakoztathatók tartományhoz, vagy nem csatlakoztathatók tartományhoz (Windows Server 2016 vagy újabb). Ha két különböző rendelkezésre állási csoport egyesítése egyetlen elosztott rendelkezésre állási csoportban történik, négy forgatókönyv létezik:

• Mindkét WSFC ugyanahhoz a tartományhoz csatlakozik.
• Minden WSFC egy másik tartományhoz csatlakozik.
• Egy WSFC csatlakozik egy tartományhoz, és egy WSFC nem csatlakozik tartományhoz.
• Egyik WSFC sem csatlakozik tartományhoz.

Ha mindkét WSFC ugyanahhoz a tartományhoz csatlakozik (nem megbízható tartományokhoz), az elosztott rendelkezésre állási csoport létrehozásakor nem kell semmi különlegeset tennie. Az ugyanazon tartományhoz nem csatlakoztatott rendelkezésre állási csoportok és WSFC-k esetében használjon tanúsítványokat az elosztott rendelkezésre állási csoport működtetéséhez, hasonlóan ahhoz, ahogy tartományfüggetlen rendelkezésre állási csoport számára hozhat létre egy ilyen csoportot. Az elosztott rendelkezésre állási csoportok tanúsítványainak konfigurálásához kövesse a tartományfüggetlen rendelkezésre állási csoport létrehozása című 3–13. lépést.

Elosztott rendelkezésre állási csoport esetén az egyes mögöttes rendelkezésre állási csoportok elsődleges replikáinak rendelkezniük kell egymás tanúsítványaival. Ha már rendelkezik olyan végpontokkal, amelyek nem használnak tanúsítványokat, konfigurálja újra ezeket a végpontokat az ALTER ENDPOINT használatával, hogy tükrözze a tanúsítványok használatát.

Használati forgatókönyvek

Az elosztott rendelkezésre állási csoport három fő használati forgatókönyve:

• Vészhelyreállítás és több telephelyű konfigurációk egyszerűsítése
• Migrálás új hardverekre vagy konfigurációkra, amelyek magukban foglalhatják az új hardver használatát vagy a mögöttes operációs rendszerek módosítását
• Az olvasható replikák számának növelése egyetlen rendelkezésre állási csoportban nyolcnál többre, több rendelkezésre állási csoportra kiterjedően

Vészhelyreállítás és több helyszínű forgatókönyvek

A hagyományos rendelkezésre állási csoportok megkövetelik, hogy minden kiszolgáló ugyanabba a WSFC-hez tartozjon, ami több adatközpontra is kihívást jelenthet. Az alábbi ábra bemutatja, hogyan néz ki egy hagyományos többhelyes rendelkezésre állási csoport architektúra, beleértve az adatfolyamot is. Van egy elsődleges replika, amely tranzakciókat küld az összes másodlagos replikának. Ez a konfiguráció bizonyos szempontból kisebb, mint egy elosztott rendelkezésre állási csoport. Például olyan dolgokat kell implementálnia, mint az Active Directory (ha alkalmazható) és a tanú szerepet a kvórumhoz a WSFC-ben. Előfordulhat, hogy figyelembe kell vennie a WSFC egyéb aspektusait is, például a csomópontok szavazatainak módosítását.

Az elosztott rendelkezésre állási csoportok rugalmasabb üzembe helyezési forgatókönyvet kínálnak a több adatközpontot felölelő rendelkezésre állási csoportok számára. Olyan elosztott rendelkezésre állási csoportokat is használhat, ahol a múltban olyan funkciók voltak használatban, mint például a napló kiszállítás, például katasztrófa utáni helyreállítási forgatókönyvekhez. A naplók szállításával ellentétben azonban az elosztott rendelkezésre állási csoportok nem késleltethetik a tranzakciók alkalmazását. Ez azt jelenti, hogy a rendelkezésre állási csoportok vagy az elosztott rendelkezésre állási csoportok nem tudnak segíteni abban az esetben, ha az adatok helytelenül frissülnek vagy törlődnek.

Az elosztott rendelkezésre állási csoportok lazán vannak összekapcsolva, ami ebben az esetben azt jelenti, hogy nem igényelnek egyetlen WSFC-t, és az SQL Server kezeli őket. Mivel a WSFC-k önállóan vannak fenntartva, és a szinkronizálás elsősorban aszinkron a két rendelkezésre állási csoport között, egyszerűbb konfigurálni a vészhelyreállítást egy másik helyen. Az egyes rendelkezésre állási csoportok elsődleges replikái szinkronizálják a saját másodlagos replikáikat.

• Elosztott rendelkezésre állási csoportok esetében csak a manuális feladatátvétel támogatott. Katasztrófa-helyreállítási helyzetben, amikor adatközpontokat cserél, nem szabad automatikus failovert konfigurálni (kivéve ritka esetekben).
• Valószínűleg nem kell beállítania néhány hagyományos elemet vagy paramétert a többhelyes vagy alhálózati WSFCs-ekhez, például a CrossSubnetThresholdhoz, de továbbra is látnia kell a hálózati késést egy másik rétegben az adatátvitelhez. A különbség az, hogy minden WSFC fenntartja a saját rendelkezésre állását; a fürt nem egy négy csomópontból álló nagy entitás. Két különálló kétcsomópontos WSFC-kkel rendelkezik az előző ábrán látható módon.
• Az aszinkron adatáthelyezést javasoljuk, mert ez a megközelítés vészhelyreállítási célokra szolgálna.
• Ha szinkron adatáthelyezést konfigurál az elsődleges replika és a második rendelkezésre állási csoport legalább egy másodlagos replikája között, és szinkron mozgást konfigurál az elosztott rendelkezésre állási csoportban, az elosztott rendelkezésre állási csoport megvárja, amíg az összes szinkron példány nyugtázza, hogy rendelkeznek az adatokkal. Ha több elosztott rendelkezésre állási csoport van láncolva (AG1 -> AG2 -> AG3), és szinkron módra van állítva, az elosztott rendelkezésre állási csoport megvárja, amíg az utolsó rendelkezésre állási csoport utolsó replikája frissül.

Migrálás

Mivel az elosztott rendelkezésre állási csoportok két teljesen eltérő rendelkezésreállási csoportkonfigurációt támogatnak, nem csak a vészhelyreállítást és a többhelyes forgatókönyveket teszik lehetővé, hanem a migrálási forgatókönyveket is. Függetlenül attól, hogy új hardverre vagy virtuális gépre (helyszíni vagy nyilvános felhőbeli IaaS-re) migrál, az elosztott rendelkezésre állási csoport konfigurálása lehetővé teszi a migrálást, ahol korábban biztonsági mentést, másolást és visszaállítást vagy naplószállítást használt.

A migrálási lehetőség különösen akkor hasznos, ha a mögöttes operációs rendszert módosítja vagy frissíti, miközben ugyanazt az SQL Server-verziót használja. Bár a Windows Server 2016 lehetővé teszi a Windows Server 2012 R2 gördülő frissítését ugyanazon a hardveren, a felhasználók többsége új hardvereket vagy virtuális gépeket helyez üzembe.

Az új konfigurációra való migrálás befejezéséhez a folyamat végén állítsa le az összes adatforgalmat az eredeti rendelkezésre állási csoport felé, és módosítsa az elosztott rendelkezésre állási csoportot szinkron adatáthelyezésre. Ez a művelet biztosítja, hogy a második rendelkezésre állási csoport elsődleges replikája teljes mértékben szinkronizálva legyen, így nem lesz adatvesztés. Miután ellenőrizte a szinkronizálást, hajtsa végre a feladatátvételt az elosztott rendelkezésre állási csoportról a másodlagos rendelkezésre állási csoportra. További információkért lásd: Átváltás egy másodlagos rendelkezésre állási csoportra.

A migrálás után, ahol a második rendelkezésre állási csoport most az új elsődleges rendelkezésre állási csoport, az alábbi lépések valamelyikét kell elvégeznie:

• Nevezze át a figyelőt a másodlagos rendelkezésre állási csoportban (és esetleg törölje vagy nevezze át a régit az eredeti elsődleges rendelkezésre állási csoportban), vagy hozza létre újra a figyelővel az eredeti elsődleges rendelkezésre állási csoportból, hogy az alkalmazások és a felhasználók hozzáférhessenek az új konfigurációhoz.
• Ha az átnevezés vagy az újralétrehozás nem lehetséges, az alkalmazásokat és a felhasználókat a második rendelkezésre állási csoport figyelője felé irányíthatja.

Migrálás magasabb SQL Server-verziókra

A migrálási forgatókönyvek során ugyan konfigurálható egy elosztott AG, amely az adatbázisokat a forrásnál magasabb verziójú SQL Server-tárolóba migrálja, van néhány korlátozás.

Ha az elosztott AG-t a forrásnál magasabb verziójú SQL Server-áttelepítési célokkal konfigurálja, az automatikus inicializálás nem támogatott, ezért a inicializálási módot be kell állítani MANUAL. Ha nem tiltja le az AUTOMATIKUS MAGVETÉSt, a migrálás sikertelen lesz, és a 946-os hibaüzenet jelenik meg: "Nem nyitható meg az adatbázis "DistributionAG" xxx verziója. Frissítse az adatbázist a legújabb verzióra" a hibanaplóban. A bevetési módot manuálisra kell állítania, és manuálisan kell elvégeznie a forrásadatbázis teljes és tranzakciós naplójának biztonsági mentését az elsődleges AG-ből. Ezután manuálisan állítsa vissza a tranzakciónaplóval együtt a másodlagos AG-be. További információkért tekintse át az elosztott AG konfigurálásához szükséges manuális vetés lépéseit, valamint a szkripteket, hogy biztonsági másolatot készíthessenek és visszaállítsák az adatbázist az elsődleges AG-ből a másodlagos AG-be.

Feltételezve, hogy a másodlagos AG (AG2) az áttelepítési cél, és magasabb verziójú, mint az elsődleges AG (AG1), vegye figyelembe a következő korlátozásokat:

• Nem lesz olvasási hozzáférése a másodlagos AG replikaadatbázisaihoz, ha az elsődleges AG alacsonyabb verziójú.
• Ez idő alatt a frissítések továbbra is az elsődleges AG-ből (AG1) a másodlagos AG-be (AG2) áramlanak, de a másodlagos AG állapota részben kifogástalan állapotúként jelenik meg, a másodlagos AG (AG2) másodlagos replikáin lévő adatbázisok szinkronizálási/helyreállítási állapotként jelennek meg (még akkor is, ha az AG szinkronizálási véglegesítésben van).
• Amint az elosztott AG-t átváltják a magasabb verzióra (AG2), az AG2-nek egészségesnek kell lennie.
• Ebben az időszakban az AG1-re történő visszaállás nem lehetséges, mivel az alacsonyabb verziójú.
• Mivel az AG1 alacsonyabb verziójú, az AG2-ről az AG2-be való feladatátvétel utáni frissítések nem lesznek replikálva az AG1-be.
• Itt választhatja ki, hogy le szeretné-e szerelni az eredeti (elsődleges) AG-t, vagy frissíteni szeretné az AG1-et, és fenntartja az elosztott AG-t.
  • Ha az AG1 leszerelését választja, távolítsa el az eredeti elsődleges AG-t az elosztott AG-ből, és a folyamat befejeződött.
  • Ha úgy dönt, hogy fenntartja az elosztott AG-t, frissítse az AG1 SQL Server-verzióját az AG2-nek megfelelően. Az AG1 frissítése után az AG1 kifogástalan állapotúvá válik, az elosztott AG kifogástalan állapotúvá válik, a replikák felzárkóznak a szinkronizáláshoz, és lehetővé válik a feladat-visszavétel.

Olvasható replikák vertikális felskálázása

Egy elosztott rendelkezésre állási csoport szükség szerint legfeljebb 16 másodlagos replikával rendelkezhet. Így képes legfeljebb 18 példánnyal rendelkezni olvasáshoz, beleértve a különböző rendelkezésre állási csoportok két elsődleges példányát is. Ez a megközelítés azt jelenti, hogy több webhely közel valós idejű hozzáféréssel rendelkezhet a különböző alkalmazásoknak való jelentéskészítéshez.

Az elosztott rendelkezésre állási csoportok segíthetnek az írásvédett farmok horizontális felskálázásában, hatékonyabban, mint egyetlen rendelkezésre állási csoport. Az elosztott rendelkezésre állási csoportok kétféleképpen méretezhetik fel az olvasható replikákat:

• Az elosztott rendelkezésre állási csoport második rendelkezésre állási csoportjának elsődleges replikáját használhatja egy másik elosztott rendelkezésre állási csoport létrehozásához, annak ellenére, hogy az adatbázis nincs a RECOVERY-ben.
• Az első rendelkezésre állási csoport elsődleges replikáját is használhatja egy másik elosztott rendelkezésre állási csoport létrehozásához.

Más szóval az elsődleges replika különböző elosztott rendelkezésre állási csoportokban vehet részt. Az alábbi ábrán az AG 1 és az AG 2 is részt vesz az Elosztott AG 1-ben, míg az AG 2 és az AG 3 részt vesz az Elosztott AG 2-ben. Az AG 2 elsődleges replikája (vagy továbbítója) az Elosztott AG 1 másodlagos replikája és az Elosztott AG 2 elsődleges replikája is.

Az alábbi ábra az AG 1-et jeleníti meg elsődleges replikaként két különböző elosztott rendelkezésre állási csoport esetében: Az elosztott AG 1 (az AG 1 és az AG2) és az Elosztott AG 2 (az AG 1 és az AG 3-ból áll).

Mindkét fenti példában legfeljebb 27 replika lehet a három rendelkezésre állási csoportban, amelyek mindegyike írásvédett lekérdezésekhez használható.

Az írásvédett továbbítás nem működik teljes mértékben az elosztott hozzáférhetőségi csoportokkal. Pontosabban:

1. Read-Only Az útválasztás konfigurálható, és az elosztott rendelkezésre állási csoport elsődleges elérhetőségi csoportjára fog működni.
2. Read-Only Útválasztás konfigurálható, de nem működik az elosztott rendelkezésre állási csoport másodlagos rendelkezésre állási csoportjában. Az összes lekérdezés, amely a figyelőt használja a másodlagos rendelkezésre állási csoporthoz való csatlakozásra, a másodlagos rendelkezésre állási csoport elsődleges replikájához jut. Ellenkező esetben minden replikát úgy kell konfigurálnia, hogy az összes kapcsolatot másodlagos replikaként engedélyezze, és közvetlenül elérhesse őket. Az írásvédett útválasztás azonban akkor működik, ha a másodlagos rendelkezésre állási csoport elsődlegessé válik a feladatátvétel után. Ez a viselkedés módosulhat az SQL Server 2016-ra vagy az SQL Server egy későbbi verziójára való frissítés során.

Másodlagos rendelkezésre állási csoportok inicializálása

Az elosztott elérhetőségi csoportokat úgy tervezték, hogy az automatikus vetés legyen a fő módszer az elsődleges replika inicializálására a második rendelkezésre állási csoportban. A második rendelkezésre állási csoport elsődleges replikájában teljes adatbázis-visszaállítás lehetséges, ha az alábbiakat hajtja végre:

1. Állítsa vissza az adatbázis biztonsági mentését a NORECOVERY használatával.
2. Szükség esetén állítsa vissza a megfelelő tranzakciónapló-biztonsági mentéseket a NORECOVERY használatával.
3. Hozza létre a második rendelkezésre állási csoportot adatbázisnév megadása nélkül, és SEEDING_MODE állítsa automatikusra.
4. Automatikus vetéssel hozza létre az elosztott rendelkezésre állási csoportot.

Amikor hozzáadja a második rendelkezésre állási csoport elsődleges replikáját az elosztott rendelkezésre állási csoporthoz, a rendszert összehasonlítja az első rendelkezésre állási csoport elsődleges adatbázisaival, és az automatikus vetés szinkronizálja az adatbázist a forrással. Van néhány kikötés:

• A második rendelkezésre állási csoport elsődleges replikájában sys.dm_hadr_automatic_seeding megjelenő kimenet "A kezdő üzenet időtúllépése" okból meghiúsult értéket jelenít meg current_state .

• A második rendelkezésre állási csoport elsődleges replikáján az SQL Server aktuális hibanaplója azt mutatja, hogy az automatikus vetés működött, és hogy az LSN-k szinkronizálva lettek.

• Az első rendelkezésre állási csoport elsődleges replikájában megjelenő kimenet a sys.dm_hadr_automatic_seeding mutatja a "COMPLETED" current_state állapotot.

• Az automatikus vetés az elosztott rendelkezésre állási csoportok esetén is eltérő viselkedést vált ki. Ahhoz, hogy az automatikus vetés a második replikán kezdődjön, ki kell adnia a parancsot ALTER AVAILABILITY GROUP [AGName] GRANT CREATE ANY DATABASE a replikán. Bár ez a feltétel továbbra is érvényes az alapul szolgáló rendelkezésre állási csoportban részt vevő másodlagos replikákra, a második rendelkezésre állási csoport elsődleges replikája már rendelkezik a megfelelő engedélyekkel ahhoz, hogy az automatikus üzembe helyezés az elosztott rendelkezésre állási csoporthoz való hozzáadása után kezdődjön.

Megjegyzés:

• A másodlagos rendelkezésre állási csoportnak ugyanazt az adatbázis-tükrözési végpontot kell használnia. Ellenkező esetben a replikáció leáll egy helyi feladatátvétel után.
• A mögöttes rendelkezésre állási csoportoknak ugyanabban a rendelkezésre állási módban kell lenniük – vagy mindkét rendelkezésre állási csoportnak szinkron véglegesítési módban kell lennie, vagy mindkettőnek aszinkron véglegesítési módban kell lennie. Ha nem biztos benne, hogy melyiket használja, állítsa mindkettőt aszinkron véglegesítési módra, amíg készen nem áll a feladatátvételre.

Állapot figyelése

Az elosztott rendelkezésre állási csoport csak SQL Server-szerkezet, és nem látható a mögöttes WSFC-ben. Az alábbi kódminta két különböző WSFC-t (CLUSTER_A és CLUSTER_B) mutat be, mindegyiket saját rendelkezésre állási csoportokkal. Itt csak CLUSTER_A AG1 és CLUSTER_B AG2 van szó.

PS C:\> Get-ClusterGroup -Cluster CLUSTER_A

Name                            OwnerNode             State
----                            ---------             -----
AG1                             DENNIS                Online
Available Storage               GLEN                  Offline
Cluster Group                   JY                    Online
New_RoR                         DENNIS                Online
Old_RoR                         DENNIS                Online
SeedingAG                       DENNIS                Online

PS C:\> Get-ClusterGroup -Cluster CLUSTER_B

Name                            OwnerNode             State
----                            ---------             -----
AG2                             TOMMY                 Online
Available Storage               JC                    Offline
Cluster Group                   JC                    Online

Az elosztott rendelkezésre állási csoportokkal kapcsolatos minden részletes információ az SQL Serverben található, különösen a rendelkezésre állási csoport dinamikus felügyeleti nézeteiben. Jelenleg az elosztott rendelkezésre állási csoporthoz tartozó SQL Server Management Studióban az egyetlen információ a rendelkezésre állási csoportok elsődleges replikáján található. Ahogy az alábbi ábrán is látható, az SQL Server Management Studio rendelkezésre állási csoportok mappájában látható, hogy van egy elosztott rendelkezésre állási csoport. Az ábra az AG1-et mutatja elsődleges replikaként egy helyi rendelkezésre állási csoport esetén az adott példányhoz, nem egy elosztott rendelkezésre állási csoporthoz.

Ha azonban a jobb gombbal az elosztott rendelkezésre állási csoportra kattint, nincs lehetőség (lásd az alábbi ábrát), és a bővített rendelkezésre állási adatbázisok, a rendelkezésre állási csoport figyelői és a rendelkezésre állási replikák mappái mind üresek. Az SQL Server Management Studio 16 megjeleníti ezt az eredményt, de az SQL Server Management Studio egy későbbi verziójában változhat.

Az alábbi ábrán látható módon a másodlagos replikák semmit sem mutatnak az elosztott rendelkezésre állási csoporthoz kapcsolódó SQL Server Management Studióban. Ezek a rendelkezésre állási csoportok nevei az előző CLUSTER_A WSFC-rendszerképben látható szerepkörökhöz vannak megfeleltetve.

DMV az összes rendelkezésre állási replika nevét listázza

Ugyanezek a fogalmak a dinamikus felügyeleti nézetek használatakor is igaznak bizonyulnak. A következő lekérdezés használatával láthatja az összes rendelkezésre állási csoportot (normál és elosztott) és a bennük részt vevő csomópontokat. Ez az eredmény csak akkor jelenik meg, ha az elsődleges replikát az elosztott rendelkezésre állási csoportban részt vevő WSFC-k egyikében kérdezi le. A dinamikus felügyeleti nézetben sys.availability_groups van egy új oszlop neve is_distributed, amely 1, ha a rendelkezésre állási csoport elosztott rendelkezésre állási csoport. Az oszlop megtekintése:

-- shows replicas associated with availability groups
SELECT
   ag.[name] AS [AG Name],
   ag.Is_Distributed,
   ar.replica_server_name AS [Replica Name]
FROM sys.availability_groups AS ag
INNER JOIN sys.availability_replicas AS ar
   ON ag.group_id = ar.group_id;
GO

Az elosztott rendelkezésre állási csoportban részt vevő második WSFC kimenetére az alábbi ábrán látható példa látható. Az SPAG1 két replikából áll: DENNIS és JY. Az SPDistAG nevű elosztott rendelkezésre állási csoport azonban a példányok neve helyett a két részt vevő rendelkezésre állási csoport (SPAG1 és SPAG2) nevét tartalmazza, mint egy hagyományos rendelkezésre állási csoport esetében.

DMV az elosztott AG állapotának listázásához

Az SQL Server Management Studióban az irányítópulton és más területeken megjelenő állapotok csak az adott rendelkezésre állási csoporton belüli helyi szinkronizálásra szolgálnak. Az elosztott rendelkezésre állási csoportok állapotának megjelenítéséhez kérdezze le a dinamikus felügyeleti nézeteket. Az alábbi példa lekérdezés kibővíti és finomítja az előző lekérdezést:

-- shows sync status of distributed AG
SELECT
   ag.[name] AS [AG Name],
   ag.is_distributed,
   ar.replica_server_name AS [Underlying AG],
   ars.role_desc AS [Role],
   ars.synchronization_health_desc AS [Sync Status]
FROM  sys.availability_groups AS ag
INNER JOIN sys.availability_replicas AS ar
   ON  ag.group_id = ar.group_id
INNER JOIN sys.dm_hadr_availability_replica_states AS ars
   ON  ar.replica_id = ars.replica_id
WHERE ag.is_distributed = 1;
GO

DMV a mögöttes teljesítmény megtekintéséhez

Az előző lekérdezés további kibővítéséhez a dinamikus felügyeleti nézeteken keresztül is láthatja az alapul szolgáló teljesítményt, ha hozzáadja a sys.dm_hadr_database_replicas_states-t. A dinamikus felügyeleti nézet jelenleg csak a második rendelkezésre állási csoport adatait tárolja. Az alábbi példa lekérdezés, amely az elsődleges rendelkezésre állási csoportban fut, az alábbi mintakimenetet hozza létre:

-- shows underlying performance of distributed AG
SELECT
   ag.[name] AS [Distributed AG Name],
   ar.replica_server_name AS [Underlying AG],
   dbs.[name] AS [Database],
   ars.role_desc AS [Role],
   drs.synchronization_health_desc AS [Sync Status],
   drs.log_send_queue_size,
   drs.log_send_rate,
   drs.redo_queue_size,
   drs.redo_rate
FROM sys.databases AS dbs
INNER JOIN sys.dm_hadr_database_replica_states AS drs
   ON dbs.database_id = drs.database_id
INNER JOIN sys.availability_groups AS ag
   ON drs.group_id = ag.group_id
INNER JOIN sys.dm_hadr_availability_replica_states AS ars
   ON ars.replica_id = drs.replica_id
INNER JOIN sys.availability_replicas AS ar
   ON ar.replica_id = ars.replica_id
WHERE ag.is_distributed = 1;
GO

Az elosztott AG teljesítményszámlálóinak megtekintéséhez DMV-t használhat.

Az alábbi lekérdezés az adott elosztott rendelkezésre állási csoporthoz társított teljesítményszámlálókat jeleníti meg.

-- displays OS performance counters related to the distributed ag named 'distributedag'
SELECT * FROM sys.dm_os_performance_counters WHERE instance_name LIKE '%distributed%'

Megjegyzés:

A LIKE szűrőnek rendelkeznie kell az elosztott rendelkezésre állási csoport nevével. Ebben a példában az elosztott rendelkezésre állási csoport neve "distributedag". Módosítsa a LIKE módosítót úgy, hogy az tükrözze az elosztott rendelkezésre állási csoport nevét.

DMV az AG és az elosztott AG állapotának megjelenítéséhez

Az alábbi lekérdezés számos információt jelenít meg mind a rendelkezésre állási csoport, mind az elosztott rendelkezésre állási csoport állapotáról. (Tracy Boggiano engedélyével reprodukálva.)

-- displays sync status, send rate, and redo rate of availability groups,
-- including distributed AG
SELECT ag.name AS [AG Name],
    ag.is_distributed,
    ar.replica_server_name AS [AG],
    dbs.name AS [Database],
    ars.role_desc,
    drs.synchronization_health_desc,
    drs.log_send_queue_size,
    drs.log_send_rate,
    drs.redo_queue_size,
    drs.redo_rate,
    drs.suspend_reason_desc,
    drs.last_sent_time,
    drs.last_received_time,
    drs.last_hardened_time,
    drs.last_redone_time,
    drs.last_commit_time,
    drs.secondary_lag_seconds
FROM sys.databases dbs
INNER JOIN sys.dm_hadr_database_replica_states drs
    ON dbs.database_id = drs.database_id
INNER JOIN sys.availability_groups ag
    ON drs.group_id = ag.group_id
INNER JOIN sys.dm_hadr_availability_replica_states ars
    ON ars.replica_id = drs.replica_id
INNER JOIN sys.availability_replicas ar
    ON ar.replica_id = ars.replica_id
--WHERE ag.is_distributed = 1
GO

DMV-k az elosztott AG metaadatainak megtekintéséhez

Az alábbi lekérdezések a rendelkezésre állási csoportok által használt végponti URL-címekkel kapcsolatos információkat jelenítik meg, beleértve az elosztott rendelkezésre állási csoportot is. ( David Barbarin engedélyével reprodukálva.)

-- shows endpoint url and sync state for ag, and dag
SELECT
   ag.name AS group_name,
   ag.is_distributed,
   ar.replica_server_name AS replica_name,
   ar.endpoint_url,
   ar.availability_mode_desc,
   ar.failover_mode_desc,
   ar.primary_role_allow_connections_desc AS allow_connections_primary,
   ar.secondary_role_allow_connections_desc AS allow_connections_secondary,
   ar.seeding_mode_desc AS seeding_mode
FROM sys.availability_replicas AS ar
JOIN sys.availability_groups AS ag
   ON ar.group_id = ag.group_id;
GO

DMV a vetés aktuális állapotának megjelenítéséhez

Az alábbi lekérdezés a vetés aktuális állapotával kapcsolatos információkat jeleníti meg. Ez a replikák közötti szinkronizálási hibák elhárításához hasznos. ( David Barbarin engedélyével reprodukálva.)

-- shows current_state of seeding
SELECT ag.name AS aag_name,
    ar.replica_server_name,
    d.name AS database_name,
    has.current_state,
    has.failure_state_desc AS failure_state,
    has.error_code,
    has.performed_seeding,
    has.start_time,
    has.completion_time,
    has.number_of_attempts
FROM sys.dm_hadr_automatic_seeding AS has
INNER JOIN sys.availability_groups AS ag
    ON ag.group_id = has.ag_id
INNER JOIN sys.availability_replicas AS ar
    ON ar.replica_id = has.ag_remote_replica_id
INNER JOIN sys.databases AS d
    ON d.group_database_id = has.ag_db_id;
GO

Kapcsolódó tartalom

• A rendelkezésre állási csoport varázslójának használata (SQL Server Management Studio)
• Az új rendelkezésre állási csoport párbeszédpanel használata (SQL Server Management Studio)
• Rendelkezésre állási csoport létrehozása a Transact-SQL