Megosztás:

Feladatátvételi és feladatátvételi módok (Always On Rendelkezésre állási csoportok)

A következőkre vonatkozik:SQL Server

Ez a cikk az SQL Server Always On rendelkezésre állási csoportok feladatátvételét és a feladatátvételi módokat ismerteti.

Áttekintés

A rendelkezésre állási csoport kontextusában a rendelkezésre állási replikák elsődleges és másodlagos szerepköre általában felcserélhető egy feladatátvételi folyamat során. A feladatátvétel három formája létezik: automatikus feladatátvétel (adatvesztés nélkül), tervezett manuális feladatátvétel (adatvesztés nélkül) és kényszerített manuális feladatátvétel (lehetséges adatvesztéssel), amelyet általában kényszerített feladatátvételnekhívnak. Az automatikus és a tervezett manuális átváltás is megőrzi az összes adatot. A rendelkezésre állási csoport failover-je a rendelkezésre állási replika szintjén történik meg. Vagyis egy rendelkezésre állási csoport az egyik másodlagos replikára (az aktuális feladatátvételi célra) irányítja át a feladatátvételt.

Megjegyzés:

Ha nincs konfigurálva az adatbázisszintű állapotészlelés , az adatbázis szintjén fellépő problémák( például egy adatbázis gyanússá válása adatfájl elvesztése, adatbázis törlése vagy egy tranzakciónapló sérülése miatt) nem okoznak feladatátvételt a rendelkezésre állási csoport számára.

A feladatátvétel során a feladatátvételi cél átveszi az elsődleges szerepkört, helyreállítja az adatbázisait, és új elsődleges adatbázisként online állapotba helyezi őket. A korábbi elsődleges replika, ha elérhető, a másodlagos szerepkörre vált, és adatbázisai másodlagos adatbázisokká válnak. Előfordulhat, hogy ezek a szerepkörök több hibára vagy rendszergazdai célokra válaszul oda-vissza (vagy másik feladatátvételi célra) válthatnak.

Az adott rendelkezésre állási replika által támogatott feladatátvételi formákat a feladatátvételi mód tulajdonság határozza meg. Egy adott rendelkezésre állási replika esetében a lehetséges feladatátvételi módok a replika rendelkezésre állási módjától függnek az alábbiak szerint:

  • A szinkron véglegesítési replikák két automatikus vagy manuális beállítást támogatnak. Az "automatikus" beállítás támogatja az automatikus feladatátvételt és a manuális feladatátvételt is. Az adatvesztés elkerülése érdekében az automatikus feladatátvétel és a tervezett feladatátvétel megköveteli, hogy a feladatátvételi cél egy szinkron véglegesítésű másodlagos replika legyen, kifogástalan szinkronizálási állapottal (ez azt jelzi, hogy a feladatátvételi cél összes másodlagos adatbázisa szinkronizálva van a megfelelő elsődleges adatbázissal). Ha egy másodlagos replika nem felel meg mindkét feltételnek, csak a kényszerített feladatátvételt támogatja. A kényszerített átállás a megoldás alatt álló replikákon is támogatott.

  • Az aszinkron véglegesítési replikák csak a manuális feladatátvételi módot támogatják. Emellett, mivel soha nem szinkronizálódnak, csak a kényszerített átállást támogatják.

Megjegyzés:

A feladatátvételt követően az elsődleges adatbázisok eléréséhez szükséges ügyfélalkalmazásoknak csatlakozniuk kell az új elsődleges replikához. Ha az új másodlagos replika írásvédett hozzáférés engedélyezésére van konfigurálva, az írásvédett ügyfélalkalmazások is csatlakozhatnak hozzá. Az ügyfelek rendelkezésre állási csoporthoz történő csatlakozásáról további információkért lásd: rendelkezésre állási csoport figyelői, ügyfélkapcsolatok és alkalmazás-feladatátvitel (SQL Server).

SQL Server 2025-módosítások

Az SQL Server 2025 a következő módosításokat vezeti be:

Gyors átváltás tartós egészségügyi problémák esetén

Always On rendelkezésre állási csoport környezetben a Windows feladatátvevő fürt (WSFC) figyeli a rendelkezésre állási csoport és replikái állapotát. Ha az elsődleges replikán állapotproblémát észlel, a WSFC korrekciós műveletek sorozatát aktiválja. Alapértelmezés szerint a WSFC újraindítja a rendelkezésre állási csoport erőforrását az aktuális replikán. Ha a WSFC nem tudja újra online állapotba hozni az erőforrást, akkor a WSFC a rendelkezésre állási csoport erőforrását egy másik replikára nem tudja átvinni. Bár a korrekciós műveletek sorozata átmeneti hibák esetén hatékony, a nem átmeneti hibák esetén a feladatátvétel késéséhez vezethet.

A WSFC feladatátvételi viselkedését a RestartThreshold érték vezérli. Alapértelmezés szerint RestartThreshold egy Always On rendelkezésre állási csoport esetében az 1 értékre van állítva, ami azt jelenti, hogy a WSFC megpróbálja újraindítani az erőforrást az aktuális csomóponton, mielőtt feladatátvételt adna.

Az SQL Server 2025 (17.x) verziójától kezdve beállíthatja egy Always On rendelkezésre állási csoport értékét 0-ra, amely utasítja a WSFC-t, hogy egy tartós egészségügyi probléma észlelésekor azonnal vegye át a rendelkezésre állási csoport erőforrásának kezelését. Ez olyan helyzetekben hasznos, ahol minimalizálni szeretné az állásidőt, és biztosítani szeretné, hogy a rendelkezésre állási csoport mindig elérhető legyen egy kifogástalan replikán.

Van egy nyilvánvaló kompromisszum:

  • Az 1 értékre állítással RestartThreshold a rendelkezésre állási csoport toleránsabb az átmeneti hibákhoz, és gyorsabban tér vissza az internetre. A feladatátvétel és az állásidő azonban hosszabb lehet a tartós hibák esetén.
  • A RestartThreshold értékének 0-ra állításával a rendelkezésre állási csoport kevésbé tolerálja az átmeneti hibákat, így előfordulhat, hogy a feladatátvétel szükségtelenül történik meg. A feladatátvétel és az állásidő azonban rövidebb lehet az elhúzódó vagy folyamatos hibák esetén.

A Feladatátvételi Fürtkezelő vagy a PowerShell használatával beállíthatja egy Always On rendelkezésre állási csoport erőforrásának RestartThreshold paramétereit.

Például, ha a `RestartThreshold`-t `0`-ra akarja állítani a `ag1` nevű rendelkezésre állási csoport esetén, használja a következő parancsot:

(Get-ClusterResource -Name "ag1").RestartThreshold = 0

Az aktuális RestartThreshold beállítást az alábbi parancs futtatásával ellenőrizheti:

Get-ClusterResource -Name "ag1" | Format-List *

Aszinkron lapkérelmek kézbesítésének javítása

Ha egy rendelkezésre állási csoport meghibásodik, minden replikának meg kell találnia egy közös helyreállítási pontot, a amelybe szinkronizálni kell. A helyreállítási pont stabilan tartja a rendelkezésre állási csoportot, hogy továbbra is át tudja vinni a változásokat. A visszavonás a szinkronizálási folyamat része. A visszaállítás visszavonása akkor történik, ha egy másodlagos replikának vissza kell állítania a tranzakciókat a közös helyreállítási ponthoz való visszatéréshez. A visszavonás-újra végrehajtás a leggyakoribb a vészhelyreállítás (DR) feladatátvétele során egy aszinkron replikára FAILOVER_ALLOW_DATA_LOSS.

Bizonyos helyzetekben a dr. feladatátvétel során, amikor a másodlagos replika átáll az elsődlegesre, az új elsődleges hálózati késéssel rendelkezik az eredeti elsődlegestől (új másodlagos), ami lelassítja az új másodlagos feladat visszavonását.

A forgatókönyv visszavonásának javítása érdekében az SQL Server 2025 (17.x) frissítést vezet be a szinkronizálási mechanizmushoz, így a rendelkezésre állási csoport mostantól aszinkron módon és kötegekben hajtja végre az oldalkéréseket.

Vegye figyelembe a következőket:

  • A szinkronizálási mechanizmus fejlesztése alapértelmezés szerint engedélyezve van. A fejlesztés letiltásához és az alapértelmezett működésre való visszatéréshez engedélyezze az 12348 nyomkövetési jelzőt egy rendelkezésre állási csoport összes olyan replikáján, amely jelenleg másodpéldány, vagy amelyek a jövőben másodpéldányok lehetnek.
  • Ha az AG-replikák nem rendelkeznek hálózati késéssel, előfordulhat, hogy ez a javulás nem javítja a visszavonást.

Az adatbázisok hiba után feloldó állapotra váltanak

Ritkán előfordulhat, hogy egy rendelkezésre állási csoport egy vagy több adatbázisa nem szinkronizált állapotban marad, miután egy rendelkezésre állási csoport rövid ideig offline állapotba kerül egy átmeneti WSFC kvórumveszteség miatt – például az ideiglenes hálózati kapcsolat megszakadása vagy a fürtcsomópontok többségének újraindítása miatt. Az SQL Server 2025 -ben (17.x) bevezetett rendelkezésreállási csoport helyreállítási logikájának frissítése javítja a fürtkvórum ilyen típusú veszteségének belső tűrését, és megakadályozza, hogy a rendelkezésre állási csoport adatbázisai a rendelkezésre állási csoport újbóli online állapotba helyezése után ne szinkronizálva állapotba kerüljenek.

Kifejezések és definíciók

Automatikus feladatátvétel
Olyan átkapcsolás, amely automatikusan megtörténik az elsődleges replika elvesztésekor. Az automatikus feladatátvétel csak akkor támogatott, ha az aktuális elsődleges és egy másodlagos replika automatikus feladatátvételi móddal van konfigurálva, és a másodlagos replika jelenleg szinkronizálva van. Ha az elsődleges vagy másodlagos replika feladatátvételi módja MANUÁLIS, az automatikus feladatátvétel nem történhet meg.

Tervezett kézi átállás (adatvesztés nélkül)
A tervezett manuális feladatátvétel vagy manuális feladatátvétel egy olyan feladatátvétel, amelyet általában rendszergazda indít el rendszergazdai célokra. A tervezett manuális feladatátvétel csak akkor támogatott, ha mind az elsődleges replika, mind a másodlagos replika szinkron-véglegesítési módra van konfigurálva, és az elsődleges és a másodlagos replika jelenleg szinkronizálva van (SZINKRONIZÁLT állapotban). A cél másodlagos replika szinkronizálásakor a manuális feladatátvétel (adatvesztés nélkül) akkor is lehetséges, ha az elsődleges replika összeomlott, mert a másodlagos adatbázisok készen állnak a feladatátvételre. Az adatbázis-rendszergazda manuálisan kezdeményezi a manuális feladatátvételt.

Kényszerített feladatátvétel (lehetséges adatvesztéssel)
Olyan feladatátvétel, amelyet egy adatbázis-rendszergazda kezdeményezhet, ha nincs szinkronizálva másodlagos replika az elsődleges replikával, vagy ha az elsődleges replika nem fut, és a másodlagos replika nem áll készen a feladatátvételre. A kényszerített átvétel lehetséges adatvesztést kockáztat, és szigorúan a katasztrófa utáni helyreállításhoz ajánlott. A kényszerített feladatátvételt kényszerített manuális feladatátvételnek is nevezik, mert csak manuálisan indítható el. Ez az egyetlen feladatátvételi forma, amelyet az aszinkron véglegesítési módban való rendelkezésre állás támogat.

Automatikus feladatátvételi csoport

Egy adott rendelkezésre állási csoportban egy rendelkezésre állási replikapár (beleértve az aktuális elsődleges replikát is), amelyek szinkron véglegesítési módra vannak konfigurálva automatikus feladatátvétellel, ha vannak ilyenek. Az automatikus feladatátvételi csoport csak akkor lép érvénybe, ha a másodlagos replika jelenleg szinkronizálva van az elsődleges replikával.

Szinkron véglegesítési feladatátvételi csoport

Egy adott rendelkezésre állási csoportban két vagy három rendelkezésre állási replika (beleértve az aktuális elsődleges replikát is), amelyek szinkron véglegesítési módra vannak konfigurálva, ha vannak ilyenek. A szinkron véglegesítési feladatátvételi csoport csak akkor lép érvénybe, ha a másodlagos replikák manuális feladatátvételi módra vannak konfigurálva, és legalább egy másodlagos replika jelenleg szinkronizálva van az elsődleges replikával.

Teljes feladatátvételi csoport

Egy adott rendelkezésre állási csoportban azoknak az összes rendelkezésre állási replikának a készlete, amelyek működési állapota jelenleg online, függetlenül a rendelkezésre állási módtól és a feladatátvételi módtól. A teljes átviteli készlet akkor válik fontossá, ha jelenleg nincs másodlagos másolat szinkronizálva az elsődleges másolattal.

Az átváltás áttekintése

Az alábbi táblázat összefoglalja, hogy a feladatátvétel mely formái támogatottak különböző rendelkezésre állási és feladatátvételi módokon. Az egyes párosítások esetében az érvényes rendelkezésre állási módot és a feladatátvételi módot az elsődleges replika módjainak metszete, valamint egy vagy több másodlagos replika módjainak metszete határozza meg.

Átállási űrlap Aszinkron véglegesítési mód Szinkron véglegesítési mód manuális átkapcsolási móddal Szinkron véglegesítési mód automatikus feladatátvételi móddal
Automatikus feladatátvétel Nem Nem Igen
Tervezett manuális átállás Nem Igen Igen
Kényszerített feladatátvétel Igen Igen Igen1

1 Ha kényszerített feladatátvételi parancsot ad ki egy szinkronizált másodlagos replikán, a másodlagos replika ugyanúgy viselkedik, mint a manuális feladatátvétel esetében.

Az az időtartam, ameddig az adatbázis nem érhető el feladatátvétel során, a feladatátvétel típusától és annak okától függ.

Fontos

A feladatátvételt követően az ügyfélkapcsolatok támogatásához a tartalmazott adatbázisok kivételével a korábbi elsődleges adatbázisokban definiált bejelentkezéseket és feladatokat manuálisan újra létre kell hozni az új elsődleges adatbázisban. További információ: Bejelentkezések és feladatok kezelése egy rendelkezésre állási csoport (SQL Server) adatbázisaihoz.

Átállási csoportok

Az adott rendelkezésre állási csoport számára lehetséges feladatátvételi formák a feladatátvételi csoportok szempontjából értelmezhetők. A feladatátvételi csoport az elsődleges replikából és a másodlagos replikákból áll, amelyek támogatják a feladatátvétel egy adott formáját, az alábbiak szerint:

  • Automatikus feladatátvételi csoport (nem kötelező): Egy adott rendelkezésre állási csoportban egy rendelkezésre állási replikapár (beleértve az aktuális elsődleges replikát is), amelyek szinkron véglegesítési módra vannak konfigurálva automatikus feladatátvétellel, ha vannak ilyenek. Az automatikus feladatátvételi csoport csak akkor lép érvénybe, ha a másodlagos replika jelenleg szinkronizálva van az elsődleges replikával.

  • Szinkron véglegesítési feladatátvételi csoport (nem kötelező): Egy adott rendelkezésre állási csoportban két vagy három rendelkezésre állási replika (beleértve az aktuális elsődleges replikát is), amelyek szinkron véglegesítési módra vannak konfigurálva, ha vannak ilyenek. A szinkron véglegesítési feladatátvételi csoport csak akkor lép érvénybe, ha a másodlagos replikák manuális feladatátvételi módra vannak konfigurálva, és legalább egy másodlagos replika jelenleg szinkronizálva van az elsődleges replikával.

  • Teljes feladatátvételi csoport: Egy adott elérhetőségi csoportban az összes elérhetőségi replika halmaza, amelynek működési állapota jelenleg online, az elérhetőségi módtól és a feladatátvételi módtól függetlenül. A teljes átviteli készlet akkor válik fontossá, ha jelenleg nincs másodlagos másolat szinkronizálva az elsődleges másolattal.

Ha szinkronizált véglegesítésként konfigurál egy rendelkezésre állási replikát automatikus feladatátvétellel, a rendelkezésre állási replika az automatikus feladatátvételi csoport részévé válik. Az, hogy a beállítás hatályba lép-e, az aktuális elsődlegestől függ. Az adott időpontban ténylegesen lehetséges feladatátvételi formák attól függenek, hogy jelenleg milyen feladatátvételi csoportok vannak érvényben.

Vegyük például azt a rendelkezésre állási csoportot, amely négy rendelkezésre állási replikával rendelkezik, az alábbiak szerint:

Kópia Rendelkezésre állási mód és feladatátvételi mód beállításai
Egy Szinkron véglegesítés automatikus feladatátvétellel
B Szinkron véglegesítés automatikus feladatátvétellel
C Szinkron véglegesítés csak tervezett manuális feladatátvétellel
D Aszinkron véglegesítés (csak kényszerített átállással)

Az egyes másodlagos replikák feladatátvételi viselkedése attól függ, hogy jelenleg melyik rendelkezésre állási replika az elsődleges replika. Alapvetően egy adott másodlagos replika esetében a feladatátvételi viselkedés az aktuális elsődleges replikához viszonyítva a legrosszabb eset. Az alábbi ábra bemutatja, hogyan változik a másodlagos replikák feladatátvételi viselkedése az aktuális elsődleges replikától függően, és hogy az aszinkron véglegesítési módra van-e konfigurálva (csak kényszerített feladatátvétellel) vagy szinkron véglegesítési módra (automatikus feladatátvétellel vagy anélkül).

Az elsődleges replikakonfiguráció hatása a feladatátvételre

Automatikus feladatátvétel

Az automatikus feladatátvétel következtében a minősített másodlagos replika automatikusan átvált az elsődleges szerepkörre, miután az elsődleges replika elérhetetlenné válik. Az automatikus feladatátvétel akkor ideális, ha az elsődleges replikát üzemeltető WSFC-csomópont helyi a másodlagos replikát üzemeltető csomóponton. Ennek az az oka, hogy az adatszinkronizálás a számítógépek közötti alacsony üzenetkésés esetén működik a legjobban, és az ügyfélkapcsolatok helyiek maradhatnak.

Ebben a szakaszban:

Automatikus feladatátvételhez szükséges feltételek

Az automatikus feladatátvétel csak a következő feltételek mellett történik:

  • Létezik egy automatikus feladatátvételi csoport. Ez a készlet egy elsődleges replikából és egy másodlagos replikából (az automatikus feladatátvételi célból) áll, amely szinkron-véglegesítési módra van konfigurálva, és automatikus feladatátvételre van beállítva. Ha az elsődleges replika MANUÁLIS feladatátvételre van beállítva, az automatikus feladatátvétel nem történhet meg akkor sem, ha egy másodlagos replika automatikus feladatátvételre van beállítva.

    További információért lásd: elérhetőségi módok (Always On elérhetőségi csoportok).

  • Az automatikus feladatátvételi cél állapota kifogástalan (ez azt jelzi, hogy a feladatátvételi cél minden másodlagos adatbázisa szinkronizálva van a megfelelő elsődleges adatbázissal).

    Jótanács

    Az Always On rendelkezésre állási csoportok automatikus feladatátvételi csoportban figyelik mindkét replika állapotát. Ha bármelyik replika meghibásodik, a rendelkezésre állási csoport állapota KRITIKUS értékre van állítva. Ha a másodlagos replika meghibásodik, az automatikus feladatátvétel nem lehetséges, mert az automatikus feladatátvételi cél nem érhető el. Ha az elsődleges replika sikertelen, a rendelkezésre állási csoport feladatátvételt fog végrehajtani a másodlagos replikán. Amíg a korábbi elsődleges replika online állapotba nem kerül, nem létezik automatikus feladatátvételi cél. Annak érdekében, hogy szekvenciális hiba esetén is biztosítsuk a rendelkezésre állást, javasoljuk, hogy állítson be egy másik másodlagos replikát automatikus feladatátvételi célnak.

    További információért lásd az Always On Policies használatával megtekintheti egy rendelkezésre állási csoport (SQL Server) állapotát és a rendelkezésre állási replika (SQL Server) feladatátvételi módjának megváltoztatása című témaköröket.

  • A Windows Server feladatátvevő fürtszolgáltatás (WSFC) fürtjének van kvóruma. További információ: WSFC kvórummódok és szavazási konfiguráció (SQL Server).

  • Az elsődleges replika elérhetetlenné vált, és a rugalmas feladatátvételi szabályzat által meghatározott feladatátvételi feltételek teljesültek. A feladatátvételi feltételek szintjeiről további információt a rendelkezésre állási csoport (SQL Server) automatikus feladatátvételére vonatkozó rugalmas feladatátvételi szabályzatban talál.

Az automatikus feladatátvétel működése

Az automatikus feladatátvétel a következő műveletsort indítja el:

  1. Ha az aktuális elsődleges replikát tartalmazó szerverpéldány továbbra is fut, az elsődleges adatbázisok állapotát LEVÁLASZTVA állapotra módosítja, és leválasztja az összes klienst.

  2. Ha bármilyen naplórekord várakozik a cél másodlagos replika helyreállítási sorában, a másodlagos replika alkalmazza a fennmaradó naplórekordokat, hogy befejezze az adatbázisok előrehaladását.

    Megjegyzés:

    A napló adott adatbázisra való alkalmazásához szükséges idő a rendszer sebességétől, a legutóbbi munkaterheléstől és a helyreállítási várólistában lévő napló mennyiségétől függ.

  3. A korábbi másodlagos replika elsődleges szerepbe lép. Az adatbázisok válhatnak a fő adatbázisokká. Az új elsődleges másolat a lehető leggyorsabban visszavonja a nem végrehajtott tranzakciókat a helyreállítás visszavonási fázisában. A zárolások elkülönítik ezeket a nem véglegesített tranzakciókat, és lehetővé teszik, hogy a visszaállítás a háttérben történjen, miközben az ügyfelek használják az adatbázist. Ez a folyamat nem hoz vissza véglegesített tranzakciókat.

    Amíg egy másodlagos adatbázis nem csatlakozik, a rendszer rövid ideig NOT_SYNCHRONIZED ként jelöli meg. A visszaállítási helyreállítás megkezdése előtt a másodlagos adatbázisok csatlakozhatnak az új elsődleges adatbázisokhoz, és gyorsan átválthatnak a SZINKRONIZÁLT állapotra. A legjobb eset általában egy harmadik szinkron-véglegesítési replika, amely a feladatátvétel után a másodlagos szerepkörben marad.

  4. Később, amikor a korábbi elsődleges replikát futtató kiszolgálópéldány újraindul, felismeri, hogy egy másik rendelkezésre állási replikaé lett az elsődleges szerepkör. A korábbi elsődleges replika áttér a másodlagos szerepkörre, és adatbázisai másodlagos adatbázisokká válnak. Az új másodlagos replika csatlakozik az aktuális elsődleges replikához, és a lehető leggyorsabban szinkronizálja az adatbázisát az aktuális elsődleges adatbázisokkal. Amint az új másodlagos replika újraszinkronizálta az adatbázisait, a feladatátvétel ismét lehetséges, fordított irányban.

Automatikus feladatátvétel konfigurálása

A rendelkezésre állási replika bármikor konfigurálható az automatikus feladatátvétel támogatására.

Automatikus átváltás konfigurálása

  1. Győződjön meg arról, hogy a másodlagos replika konfigurálva van a szinkron-commit elérhetőségi mód használatára. További információ: Rendelkezésre állási replika (SQL Server) rendelkezésre állási módjának módosítása.

  2. Állítsa a feladatátvételi módot automatikusra. További információért olvassa el a következő részt: Rendelkezésre állási replika (SQL Server) feladatátvételi módjának módosítása.

  3. Ha szeretné, módosítsa a rendelkezésre állási csoport rugalmas feladatátvételi szabályzatát, és adja meg azokat a hibák típusait, amelyek automatikus feladatátvételt okozhatnak. További információ : A rugalmas feladatátvételi szabályzat konfigurálása az automatikus feladatátvétel feltételeinek szabályozásához (Always On rendelkezésre állási csoportok) és feladatátvételi szabályzat feladatátvételi fürtpéldányokhoz.

Tervezett manuális átkapcsolás (adatvesztés nélkül)

A manuális feladatátvétel hatására a szinkronizált másodlagos replika áttér az elsődleges szerepkörre, miután egy adatbázis-rendszergazda manuális feladatátvételi parancsot ad ki a cél másodlagos replikát üzemeltető kiszolgálópéldányon. A manuális feladatátvétel támogatásához a másodlagos replikát és az aktuális elsődleges replikát szinkron véglegesítési módra kell konfigurálni, ha van ilyen. A rendelkezésre állási replikán lévő összes másodlagos adatbázist csatlakoztatni kell a rendelkezésre állási csoporthoz, és szinkronizálni kell a megfelelő elsődleges adatbázissal (azaz szinkronizálni kell a másodlagos replikát). Ez garantálja, hogy a korábbi elsődleges adatbázisban lekötött összes tranzakciót az új elsődleges adatbázisban is véglegesíteni kell. Ezért az új elsődleges adatbázisok megegyeznek a régi elsődleges adatbázisokkal.

Az alábbi ábra egy tervezett feladatátvétel szakaszait mutatja be:

  1. A feladatátvétel előtt az elsődleges replikát a kiszolgálópéldány üzemelteti.Node01

  2. Az adatbázisgazda tervezett átállást kezdeményez. A feladatátvételi cél a kiszolgálópéldány Node02 által üzemeltetett rendelkezésre állási replika.

  3. A feladatátvételi cél (on Node02) lesz az új elsődleges replika. Mivel ez egy tervezett feladatátvétel, a korábbi elsődleges replika a feladatátvétel során a másodlagos szerepkörre vált, és azonnal másodlagos adatbázisként online állapotba helyezi az adatbázisait.

Tervezett manuális feladatátvétel illusztrációja

Ebben a szakaszban:

Manuális átváltás feltételei

A manuális feladatátvétel támogatásához az aktuális elsődleges replikát szinkron véglegesítési módra kell állítani, a másodlagos replikának pedig a következőnek kell lennie:

  • Szinkron véglegesítési módra konfigurálva.

  • Jelenleg szinkronizálva van az elsődleges replikával.

Egy rendelkezésre állási csoport manuális feladatátvételéhez csatlakoznia kell ahhoz a másodlagos replikához, amely az új elsődleges replikává válik.

A tervezett manuális átállás működése

Egy tervezett manuális feladatátvétel, amelyet a cél másodlagos replikán kell kezdeményezni, a következő műveletsort indítja el:

  1. Annak biztosítása érdekében, hogy az eredeti elsődleges adatbázisokon ne történjen új felhasználói tranzakció, a WSFC-fürt kérést küld az elsődleges replikának, hogy offline állapotba lépjen.

  2. Ha bármely napló egy másodlagos adatbázis helyreállítási várólistájában várakozik, a másodlagos replika befejezi a másodlagos adatbázis továbbgördítését. A szükséges idő a rendszer sebességétől, a legutóbbi számítási feladattól és a helyreállítási várólistán lévő napló mennyiségétől függ. A helyreállítási üzenetsor aktuális méretének megismeréséhez használja a Helyreállítási várólista teljesítményszámlálóját. További információ: SQL Server, Adatbázisreplika.

    Megjegyzés:

    Az átkapcsolási idő a helyreállítási sor méretének korlátozásával szabályozható. Ez azonban azt eredményezheti, hogy az elsődleges replika lelassul, hogy a másodlagos replika lépést tartson.

  3. A másodlagos replika lesz az új elsődleges replika, a korábbi elsődleges replika pedig az új másodlagos replika.

  4. Az új elsődleges replika visszaállítja a nem véglegesített tranzakciókat, és elsődleges adatbázisként online állapotba helyezi az adatbázisait. Az összes másodlagos adatbázis rövid ideig NEM SZINKRONIZÁLVA állapotúként van megjelölve, amíg nem csatlakoznak és újraszinkronizálódnak az új elsődleges adatbázisokhoz. Ez a folyamat nem hoz vissza véglegesített tranzakciókat.

  5. Amikor a korábbi elsődleges replika újra online állapotba kerül, az felveszi a másodlagos szerepkört, és a korábbi elsődleges adatbázis lesz a másodlagos adatbázis. Az új másodlagos replika gyorsan újraszinkronizálja az új másodlagos adatbázisokat a megfelelő elsődleges adatbázisokkal.

    Megjegyzés:

    Amint az új másodlagos replika újraszinkronizálta az adatbázisokat, az átváltás ismét lehetséges, de ellenkező irányban.

A feladatátvétel után az ügyfeleknek újra csatlakozniuk kell az aktuális elsődleges adatbázishoz. További információt a rendelkezésre állási csoport figyelői, az ügyfélkapcsolatok és az alkalmazás feladatátvétele (SQL Server) című témakörben talál.

A rendelkezésre állás fenntartása a frissítések során

A rendelkezésre állási csoportok adatbázis-rendszergazdája manuális feladatátvételekkel tarthatja fenn az adatbázisok rendelkezésre állását a hardver vagy a szoftver frissítésekor. A szoftverfrissítésekhez rendelkezésre állási csoport használatához a cél másodlagos replikát futtató kiszolgálópéldánynak és/vagy számítógépcsomópontnak már meg kell kapnia a frissítéseket. További információ: Always On rendelkezésre állási csoport replikapéldányainak frissítése.

Kényszerített feladatátvétel (lehetséges adatvesztéssel)

Az elérhetőségi csoport feladatátvételének kényszerített végrehajtása (lehetséges adatvesztéssel) egy olyan vészhelyreállítási módszer, amely lehetővé teszi a másodlagos replika használatát, mint tartalék szervert. Mivel a feladatátvétel kényszerítése adatvesztést okozhat, óvatosan és takarékosan kell használni. Javasoljuk, hogy csak akkor kényszerítse ki a feladatátvételt, ha azonnal vissza kell állítania a szolgáltatást a rendelkezésre állási adatbázisokba, és hajlandó kockáztatni az adatok elvesztését. További információ a feladatátvétel kényszerítésének előfeltételeiről és javaslatairól, valamint egy olyan példaforgatókönyvről, amely kényszerített feladatátvételt használ egy katasztrofális hiba utáni helyreállításhoz, tekintse meg a rendelkezésre állási csoport (SQL Server) kényszerített manuális feladatátvételét ismertető témakört.

Figyelmeztetés

A feladatátvétel kényszerítéséhez a WSFC-fürtnek kvórumra van szüksége. A kvórum konfigurálásáról és a kvórum kényszerítéséről további információt a Windows Server feladatátvételi fürtszolgáltatás (WSFC) és az SQL Server használatával című témakörben talál.

Ebben a szakaszban:

A kényszerített feladatátvétel működése

A kényszerített feladatátvétel kezdeményezi az elsődleges szerepkör átadását egy célreplikára, amelynek a szerepköre MÁSODLAGOS vagy FELDOLGOZÁS állapotban van. Az átállási célpont lesz az új fő replika, és azonnal az adatbázisok másolataival szolgálja ki az ügyfeleket. Amikor a korábbi elsődleges replika elérhetővé válik, áttér a másodlagos szerepkörre, és adatbázisai másodlagos adatbázisokká válnak.

Minden másodlagos adatbázis (beleértve a korábbi elsődleges adatbázisokat is, amikor elérhetővé válnak) FELFÜGGESZTVE lesz. A felfüggesztett másodlagos adatbázisok korábbi adatszinkronizálási állapotától függően alkalmas lehet az elsődleges adatbázis hiányzó véglegesített adatainak mentésére. Az írásvédett hozzáférésre konfigurált másodlagos replikán lekérdezheti a másodlagos adatbázisokat a hiányzó adatok manuális felderítéséhez. Ezután Transact-SQL utasításokat adhat ki az új elsődleges adatbázisokon a szükséges módosítások elvégzéséhez.

A feladatátvétel kényszerítésének kockázatai

Fontos tisztában lenni azzal, hogy a feladatátvétel kényszerítése adatvesztést okozhat. Az adatvesztés azért lehetséges, mert a célreplika nem tud kommunikálni az elsődleges replikával, ezért nem tudja garantálni az adatbázisok szinkronizálását. A feladatátvétel kényszerítése új helyreállítási elágazást indít el. Mivel az eredeti elsődleges adatbázisok és a másodlagos adatbázisok különböző helyreállítási elágazásokon találhatók, ezek mindegyike olyan adatokat tartalmaz, amelyeket a másik adatbázis nem tartalmaz: minden eredeti elsődleges adatbázis tartalmazza azokat a módosításokat, amelyeket még nem küldtek el a küldési üzenetsorból a korábbi másodlagos adatbázisba (a nem küldött naplóba); a korábbi másodlagos adatbázisok a feladatátvétel kényszerítése után bármilyen módosítást tartalmaznak.

Ha a feladatátvétel azért van kényszerítve, mert az elsődleges replika meghiúsult, a lehetséges adatvesztés attól függ, hogy a sikertelenség előtt a rendszer elküldte-e a tranzakciónaplókat a másodlagos replikának. Az aszinkron véglegesítési módban mindig lehetőség van a halmozott el nem küldött naplóra. Szinkron véglegesítési módban ez csak a másodlagos adatbázisok szinkronizálásáig lehetséges.

Az alábbi táblázat egy adott adatbázis adatvesztésének lehetőségét foglalja össze azon a replikán, amelyre kényszerített feladatátvétel történik.

Másodlagos replika rendelkezésre állási módja Szinkronizálva van az adatbázis? Lehetséges az adatvesztés?
Szinkron véglegesítés Igen Nem
Szinkron véglegesítés Nem Igen
Aszinkron véglegesítés Nem Igen

A másodlagos adatbázisok csak két helyreállítási elágazást követnek nyomon, így ha több kényszerített átváltást hajt végre, előfordulhat, hogy az előző kényszerített átváltással adatszinkronizálást indító másodlagos adatbázis nem tudja folytatni. Ha ez történik, a nem folytatható másodlagos adatbázisokat el kell távolítani a rendelkezésre állási csoportból, vissza kell állítani a megfelelő időpontra, és újra csatlakozni kell a rendelkezésre állási csoporthoz. Ebben a forgatókönyvben az 1408-ás, 103-ás állapotú hiba figyelhető meg (hiba: 1408, Súlyosság: 16, Állapot: 103). A visszaállítás nem működik több helyreállítási elágazáson, ezért mindenképpen készítsen biztonsági másolatot egy naplóról egynél több kényszerített feladatátvétel végrehajtása után.

Miért van szükség kényszerített feladatátvitelre a kvórum kényszerítése után?

Miután kényszerített kvórumot hajt végre a WSFC-fürtön, kényszerített átvételt kell végrehajtania (amely adatvesztéssel járhat) minden rendelkezésre állási csoportra. A kényszerített feladatátvételre azért van szükség, mert a WSFC-fürt értékeinek valós állapota elveszhetett. A kényszerített kvórum után a normál feladatátvételek megakadályozása azért szükséges, mert előfordulhat, hogy egy nem szinkronizált másodlagos replika szinkronizálva lesz az újrakonfigurált WSFC-fürtön.

Vegyük például azt a WSFC-fürtöt, amely egy rendelkezésre állási csoportot üzemeltet három csomóponton: az A csomópont az elsődleges replikát, a B csomópontot és a C csomópontot pedig egy másodlagos replikát üzemeltet. A C csomópont leválasztódik a WSFC-fürtről, miközben a helyi másodlagos replika SZINKRONIZÁLVA van. Az A csomópont és a B csomópont azonban továbbra is kifogástalan kvórumot tart fenn, és a rendelkezésre állási csoport online állapotban marad. Az A csomóponton az elsődleges replika továbbra is fogadja a frissítéseket, a B csomóponton pedig a másodlagos replika továbbra is szinkronizálva lesz az elsődleges replikával. A C csomópont másodlagos replikája nem lesz szinkronizálva, és egyre inkább az elsődleges replika mögött marad. Mivel azonban a C csomópont leválasztva van, a replika helytelenül szinkronizált állapotban marad.

Ha a kvórum elvész, majd az A csomópontra kényszerítik, a WSFC-fürt rendelkezésre állási csoportjának szinkronizálási állapotát helyesen kell megadni, a C csomópont másodlagos replikája pedig UNSYNCHRONIZED értékként jelenik meg. Ha azonban a C csomóponton kvórum van kényszerítve, a rendelkezésre állási csoport szinkronizálása helytelen lesz. A fürt szinkronizációs állapota vissza fog térni arra az időpontra, amikor a C csomópontot leválasztották – a C csomóponton lévő másodlagos replika helytelenül SZINKRONIZÁLVA állapotként jelenik meg. Mivel a tervezett manuális feladatátvételek garantálják az adatok biztonságát, a kvórum kényszerítése után nem engedélyezik a rendelkezésre állási csoport visszahelyezését online állapotba.

Lehetséges adatvesztés nyomon követése

Ha a WSFC-fürt kvóruma kifogástalan, megbecsülheti az adatbázisok adatvesztésének jelenlegi lehetőségét. Egy adott másodlagos replika esetében az adatvesztés jelenlegi lehetősége attól függ, hogy a helyi másodlagos adatbázisok mennyire állnak le a megfelelő elsődleges adatbázisok mögött. Mivel az időbeli eltérés mértéke változó, javasoljuk, hogy rendszeresen kövesse nyomon a nem szinkronizált másodlagos adatbázisok lehetséges adatvesztéseit. A nyomon követési késés az összes elsődleges adatbázis és másodlagos adatbázis legutóbbi véglegesítési LSN-jének és utolsó véglegesítési időpontjának összehasonlítását foglalja magában az alábbiak szerint:

  1. Csatlakozzon az elsődleges replikához.

  2. Lekérdezzük a last_commit_lsn (az utolsó véglegesített tranzakció LSN-je) és last_commit_time (az utolsó véglegesítés időpontja) oszlopokat a sys.dm_hadr_database_replica_states dinamikus felügyeleti nézetben.

  3. Hasonlítsa össze az egyes elsődleges adatbázisokhoz és azok másodlagos adatbázisaihoz visszaadott értékeket. A legutóbbi véglegesítési LSN-k közötti különbség a késés mértékét jelzi.

  4. Riasztást akkor aktiválhat, ha egy adatbázis vagy adatbáziskészlet késése meghaladja a kívánt maximális késést egy adott időszakra vonatkozóan. A lekérdezést például egy olyan feladat futtathatja, amely percenként hajtja végre az egyes elsődleges adatbázisokon. Ha az elsődleges adatbázis last_commit_time és annak másodlagos adatbázisai közötti különbség túllépte a helyreállítási pont célkitűzését (például 5 percet) a feladat legutóbbi végrehajtása óta, a feladat riasztást adhat ki.

Fontos

Amikor a WSFC-fürt nem rendelkezik kvórummal, vagy kényszerített kvórummal működik, last_commit_lsn és last_commit_time NULL értékű. További információ arról, hogy miként kerülheti el az adatvesztést a kényszerített kvórum után: "Lehetséges módszerek az adatvesztés elkerülésére a kvórum kényszerítése után" című témakörben, amely egy rendelkezésre állási csoport (SQL Server) kényszerített manuális feladatátvételének végrehajtásával foglalkozik.

A lehetséges adatvesztés kezelése

Miután az átállás kényszerítve van, a másodlagos adatbázisok felfüggesztésre kerülnek. Ez magában foglalja a korábbi elsődleges adatbázisokat is, miután a korábbi elsődleges replika újra online állapotba kerül, és rájön, hogy ez most egy másodlagos replika. Minden egyes felfüggesztett adatbázist egyenként manuálisan kell folytatnia minden egyes másodlagos replikán.

Ha a korábbi elsődleges replika elérhetővé válik, feltéve, hogy az adatbázisai sértetlenek, megpróbálhatja kezelni a lehetséges adatvesztést. A lehetséges adatvesztés kezelésének elérhető módja attól függ, hogy az eredeti elsődleges replika csatlakozott-e az új elsődleges replikához. Feltételezve, hogy az eredeti elsődleges replika hozzáfér az új elsődleges példányhoz, az újracsatlakozás automatikusan és transzparensen történik.

Az eredeti elsődleges replika újracsatlakozott

Általában egy hiba után, amikor az eredeti elsődleges replika újraindul, gyorsan újracsatlakozik a partneréhez. Újracsatlakozáskor az eredeti elsődleges replika lesz a másodlagos replika. Az adatbázisok másodlagos adatbázisokká válnak, és a FELFÜGGESZTETT állapotba kerülnek. Az új másodlagos adatbázisok nem kerülnek visszavonásra, hacsak nem folytatja őket.

A felfüggesztett adatbázisok azonban nem érhetők el, így nem vizsgálhatja meg őket, hogy felmérje, milyen adatok elvesznének, ha egy adott adatbázist folytatna. Ezért a másodlagos adatbázis folytatásának vagy eltávolításának eldöntése attól függ, hogy hajlandó-e bármilyen adatvesztést elfogadni az alábbiak szerint:

  • Ha bármilyen adat elvesztése elfogadhatatlan lenne, távolítsa el az adatbázisokat a rendelkezésre állási csoportból az adatok mentéséhez.

    Az adatbázis-rendszergazda most már helyreállíthatja a korábbi elsődleges adatbázisokat, és megpróbálhatja helyreállítani az elveszett adatokat. Ha azonban egy korábbi elsődleges adatbázis online állapotba kerül, az eltér az aktuális elsődleges adatbázistól, ezért az adatbázis rendszergazdájának elérhetetlenné kell tennie az eltávolított vagy az aktuális elsődleges adatbázist az ügyfelek számára, hogy elkerülje az adatbázisok további eltérését, és megelőzze az ügyfél-feladatátvételi problémákat.

  • Ha az adatok elvesztése elfogadható az üzleti céloknak, folytathatja a másodlagos adatbázisokat.

    Ha egy új másodlagos adatbázist újrakezd, az az adatbázis szinkronizálásának első lépéseként vissza lesz állítva. Ha a sikertelenség időpontjában a küldési sorban várakozó naplórekordok elvesznek, akkor a megfelelő tranzakciók akkor is elvesznek, ha véglegesítették őket.

Az elsődleges replika nem kapcsolódik újra

Ha ideiglenesen megakadályozhatja, hogy az eredeti elsődleges replika újracsatlakozjon a hálózaton keresztül az új elsődleges replikához, megvizsgálhatja az eredeti elsődleges adatbázisokat annak kiértékeléséhez, hogy milyen adatok vesznének el, ha újraindulnának.

  • Ha a lehetséges adatvesztés elfogadható

    Engedélyezze, hogy az eredeti elsődleges replika újra csatlakozzon az új elsődleges replikához. Az újracsatlakozás miatt az új másodlagos adatbázisok fel lesznek függesztve. Az adatbázis adatszinkronizálásának elindításához egyszerűen indítsa újra az adatszinkronizálást. Az új másodlagos replika elveti az adatbázis eredeti helyreállítási elágazását, és elveszíti azokat a tranzakciókat, amelyeket a korábbi másodlagos replika soha nem küldött vagy fogadott.

  • Ha az adatvesztés elfogadhatatlan

    Ha az eredeti elsődleges adatbázis olyan kritikus adatokat tartalmaz, amelyek elvesznének a felfüggesztett adatbázis folytatásakor, az eredeti elsődleges adatbázis adatait úgy őrizheti meg, hogy eltávolítja azokat a rendelkezésre állási csoportból. Ez azt eredményezi, hogy az adatbázis a VISSZAÁLLÍTÁS állapotba kerül. Jelenleg azt javasoljuk, hogy kísérelje meg az eltávolított adatbázis naplója végének mentését. Ezután frissítheti az aktuális elsődleges adatbázist (a korábbi másodlagos adatbázist) úgy, hogy exportálja a mentendő adatokat az eredeti elsődleges adatbázisból, és importálja azokat az aktuális elsődleges adatbázisba. Javasoljuk, hogy a lehető leggyorsabban készítsen teljes adatbázis-biztonsági másolatot a frissített elsődleges adatbázisról.

    Ezután az új másodlagos replikát üzemeltető kiszolgálópéldányon törölheti a felfüggesztett másodlagos adatbázist, és létrehozhat egy új másodlagos adatbázist a biztonsági mentés visszaállításával (és legalább egy későbbi napló biztonsági mentésével) a RESTORE WITH NORECOVERY paranccsal. Javasoljuk, hogy késleltesse az aktuális elsődleges adatbázisok további naplómentéseit a megfelelő másodlagos adatbázisok helyreállításáig.

Figyelmeztetés

A tranzakciónapló-csonkolás egy elsődleges adatbázisban késik, miközben a másodlagos adatbázisok bármelyike fel van függesztve. A szinkron elkötelezésű másodlagos replika szinkronizálási állapota sem válhat egészségessé, amíg bármely helyi adatbázis felfüggesztve marad.

Kapcsolódó tartalom

Átváltási viselkedés konfigurálása

Manuális átváltás végrehajtása

A WSFC kvórumkonfigurációjának konfigurálása

  • Last updated on