Always On rendelkezésre állási csoport feladatátvétele Linux rendszeren

A következőkre vonatkozik:SQL Server Linux rendszeren

A rendelkezésre állási csoport (AG) 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 tervezett manuális feladatátvételek megőrzik az összes adatot. Egy AG átváltása a rendelkezésre állási replika szintjén történik. Vagyis egy AG az egyik másodlagos replikára (az aktuális feladatátvételi célra) irányítja át a feladatátvételt.

Az átállásról szóló háttérinformációkért lásd a Feladatátvétel és Feladatátvételi módok (Always On rendelkezésre állási csoportok).

Az SQL Server 2025 (17.x) verzióban a Cumulative Update (CU) 3 és újabb verziókkal egy új Pacemaker HA agent v2 érhető el Red Hat Enterprise Linux (RHEL) és Ubuntu számára a mssql-server-ha csomagban.

A Pacemaker HA-ügynök v2-ben megbízhatósági és teljesítménybeli fejlesztések történtek az előző ügynökkel szemben, beleértve a következőket:

Továbbfejlesztett feladatátvételi teljesítmény a tervezett és a nem tervezett feladatátvételi idő csökkentése érdekében.
Rugalmas automatikus feladatátvételi szabályzatok támogatása, beleértve az állapot-ellenőrzési időtúllépés és a hibaállapot-szint konfigurálását.
A TLS 1.3 támogatása a Pacemaker-klaszter és az SQL Server közötti kommunikációhoz.

A Pacemaker HA-ügynök v2 jelenleg előzetes verzióban érhető el. A meglévő Pacemaker HA-ügynök (v1) továbbra is teljes mértékben támogatott a produkciós telepítésekhez.

Kézi átváltás

A fürtfelügyeleti eszközökkel feladatátvételt kell végrehajtania egy külső fürtkezelő által felügyelt AG-nek. Ha például egy megoldás a Pacemaker használatával felügyel egy Linux-fürtöt, a pcs használatával manuális feladatátvételeket hajthat végre Red Hat Enterprise Linux (RHEL) vagy Ubuntu rendszeren. A SUSE Linux Enterprise Serveren (SLES) használja a crm. (Az SQL Server 2025 -től (17.x) kezdődően a SUSE Linux Enterprise Server (SLES) nem támogatott.)

Important

Normál működés mellett ne végezzen feladatátvételt a Transact-SQL (T-SQL) vagy SQL Server felügyeleti eszközök, például az SSMS vagy a PowerShell használatával. Ha CLUSTER_TYPE = EXTERNAL, a FAILOVER_MODE egyetlen elfogadható értéke EXTERNAL. Ezekkel a beállításokkal minden manuális vagy automatikus átállási műveletet a külső klászermenedszer hajt végre. Az adatvesztést is okozható feladatátvétel kényszerítésével kapcsolatos utasításokért lásd: Feladatátvétel kényszerítése.

Manuális átállási lépések

Az átkapcsoláshoz annak a másodlagos replikának, amelyik elsődleges replikává válik, szinkronnak kell lennie. Ha egy másodlagos replika aszinkron, változtassa meg a rendelkezésre állási módot.

Manuális feladatátvétel két lépésben.

Először manuális feladatátvételt úgy, hogy áthelyezi az erőforrás- a fürtcsomópontról egy új csomópontra.

A fürt áthelyezi az AG-erőforrást, és hozzáad egy helykorlátozást. Ez a korlátozás úgy konfigurálja az erőforrást, hogy az új csomóponton fusson. Távolítsa el ezt a korlátozást a sikeres feladatátvétel érdekében a jövőben.
Másodszor, távolítsa el a helymegkötést.

1. lépés. Manuális feladatátvétel a rendelkezésre állási csoport erőforrásának áthelyezésével történik.

Ha manuálisan szeretne átállást végrehajtani a(z) ag_cluster nevű AG-erőforráson a(z) nodeName2nevű fürtcsomópontra, futtassa a megfelelő parancsot az Ön disztribúciójához.

RHEL/Ubuntu példa

sudo pcs resource move ag_cluster-master nodeName2 --master --lifetime=30S

SLES-példa

crm resource migrate ag_cluster nodeName2 --lifetime=30S

Amikor ezt --lifetime az opciót használod, az erőforrás mozgatásához létrehozott helykorlátozás ideiglenes jellegű, és az előző példában 30 másodpercig érvényes.

Az ideiglenes korlátozás nem törlődik automatikusan, és megjelenhet a kényszerlistában, de lejárt kényszerként. A lejárt korlátozások nem befolyásolják a Pacemaker klaszter failover viselkedését. Ha nem használja a --lifetime beállítást az erőforrás áthelyezésekor, távolítsa el az automatikusan hozzáadott helymegkötést, amelyet a következő szakaszban jegyezünk fel.

2. lépés. A helymegkötés eltávolítása

A manuális feladatátvétel során a pcs parancs move vagy crm parancs migrate helykorlátot ad hozzá az új célcsomópontra helyezendő erőforráshoz. Az új korlátozás megtekintéséhez futtassa a következő parancsot az erőforrás manuális áthelyezése után:

RHEL/Ubuntu példa
```
sudo pcs constraint list --full
```
SLES-példa
```
crm config show
```
Ez egy példa a manuális feladatátvétel miatt létrejövő kényszerre.

Enabled on: Node1 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)

Note

A Red Hat Enterprise Linux 8.x és Ubuntu 18.04 rendszeren futó Pacemaker-klaszterekben az AG-erőforrás neve hasonlíthat az ag_cluster-clone formára, mivel az erőforrásokkal kapcsolatos elnevezések egyre inkább a promotable clone kifejezés használata felé mozdulnak el.
RHEL/Ubuntu példa

Az alábbi parancsban cli-prefer-ag_cluster-master az eltávolítandó kényszer azonosítója. sudo pcs constraint list --full ezt az azonosítót adja vissza.
```
sudo pcs resource clear ag_cluster-master
```
Vagy
```
sudo pcs constraint remove cli-prefer-ag_cluster-master
```
Másik lehetőségként az automatikusan létrehozott kényszerek áthelyezését és törlését is elvégezheti egyetlen sorban az alábbiak szerint. Az alábbi példa a Red Hat Enterprise Linux 8.x-nek megfelelő klónozási terminológiát használja.
```
sudo pcs resource move ag_cluster-clone --master nodeName2 && sleep 30 && sudo pcs resource clear ag_cluster-clone
```
SLES-példa

Az alábbi parancsban cli-prefer-ms-ag_cluster a kényszer azonosítója. crm config show ezt az azonosítót adja vissza.
```
crm configure
delete cli-prefer-ms-ag_cluster
commit
```

Note

Az automatikus feladatátvétel nem ad helykorlátozást, ezért nincs szükség törlésre.

További információért:

Kényszerített átállás

A kényszerített feladatátvétel célja kifejezetten a katasztrófa utáni helyreállítás. Ebben az esetben nem lehet feladatátvételt végrehajtani a fürtfelügyeleti eszközökkel, mert az elsődleges adatközpont leállt. Ha egy nem szinkronizált másodlagos replikára kényszeríti a feladatátvételt, előfordulhat adatvesztés. Csak akkor kényszerítse ki a feladatátvételt, ha azonnal vissza kell állítania a szolgáltatást az AG-nek, és hajlandó kockáztatni az adatok elvesztését.

Ha nem tudja használni a fürtfelügyeleti eszközöket a fürttel való interakcióhoz (például, ha a fürt az elsődleges adatközpontban egy katasztrófaesemény miatt nem válaszol), előfordulhat, hogy kényszerítenie kell az átváltást a külső fürtkezelő megkerülése érdekében. Ez az eljárás nem ajánlott a rendszeres műveletekhez, mert adatvesztéssel jár. Akkor használja, ha a fürtfelügyeleti eszközök nem hajtják végre a feladatátvételi műveletet. Funkcionálisan ez az eljárás hasonlít arra, ahogyan a kényszerített manuális feladatátvételt hajt végre egy AG-n a Windowsban.

A feladatátvétel kényszerítési folyamata a Linuxon futó SQL Serverre vonatkozik.

Ellenőrizze, hogy a fürt már nem kezeli-e az AG-erőforrást.
- Állítsa az erőforrást nem felügyelt módra a cél klaszter csomóponton. Ez a parancs jelzi az erőforrás-ügynöknek, hogy állítsa le az erőforrás-figyelést és -kezelést. Például:
```
sudo pcs resource unmanage <resourceName>
```
- Ha az erőforrás mód nem felügyelt módra történő beállítására tett kísérlet meghiúsul, törölje az erőforrást. Például:
```
sudo pcs resource delete <resourceName>
```
  Note
  
  Ha törlök egy erőforrást, az minden hozzá tartozó korlátozást is eltörli.
A másodlagos replikát futtató SQL Server-példányon állítsa be a munkamenet környezeti változóját external_cluster.
```
EXECUTE sp_set_session_context
    @key = N'external_cluster',
    @value = N'yes';
```
Az AG feladatátvételének végrehajtása T-SQL használatával. Az alábbi példában cserélje le <MyAg> az AG nevére. Csatlakozzon a cél másodlagos replikát üzemeltető SQL Server-példányhoz, és futtassa a következő parancsot:
```
ALTER AVAILABILITY GROUP <MyAg> FORCE_FAILOVER_ALLOW_DATA_LOSS;
```
A kényszerített feladatátvétel után állítsa az AG-t kifogástalan állapotba, mielőtt újraindítaná a fürterőforrás-figyelést és -felügyeletet, vagy újrakezdené az AG-erőforrást. Tekintse át a alapvető feladatokat a kényszerített feladatátvételiután.
Indítsa újra a fürterőforrás-figyelést és -felügyeletet:

A fürterőforrás-figyelés és -kezelés újraindításához futtassa a következő parancsot:
```
sudo pcs resource manage <resourceName>
sudo pcs resource cleanup <resourceName>
```
Ha törölte a fürterőforrást, hozza létre újra. A fürterőforrás újbóli létrehozásához kövesse a Rendelkezésre állási csoport erőforrásának létrehozásacímű témakör utasításait.

Important

Ne használja az előző lépéseket vészhelyreállítási próbákhoz, mert adatvesztést kockáztatnak. Ehelyett változtasd az aszinkron replikát szinkronra, és kövesd a normál kézi failover-utasításokat.

Adatbázisszintű monitorozás és feladatátvételi aktiváló

A CLUSTER_TYPE=EXTERNALesetében a feladatátvételi eseményindító szemantikája eltér a WSFC-hez képest. Amikor az AG egy SQL Server WSFC-példányon van, az adatbázis ONLINE állapotából való átmenet az AG egészségügyi állapotának hibát jelző jelentését eredményezi. Válaszul a fürtkezelő feladatátvételi műveletet indít el. Linux rendszeren az SQL Server-példány nem tud kommunikálni a fürttel. Az adatbázis állapotának figyelése külsőtörténik. Ha a felhasználó engedélyezi az adatbázisszintű feladatátvétel figyelését és a feladatátvételt (az AG létrehozásakor az DB_FAILOVER=ON beállítás megadásával), a klaszter minden egyes monitoringművelet során ellenőrzi, hogy az adatbázis állapota ONLINE-e. A klaszter lekérdezi az állapotot a sys.databases adatbázisokban. A ONLINEállapottól eltérő állapot esetén automatikusan elindítja a feladatátvételt (ha teljesülnek az automatikus feladatátvételi feltételek). A failover tényleges ideje a megfigyelési művelet gyakoriságától és az adatbázis állapotának frissítésétől sys.databasesfügg.

Az automatikus feladatátvételhez legalább egy szinkron replika szükséges.

Közreműködés az SQL dokumentációjában

Tudta, hogy saját maga szerkesztheti az SQL-tartalmakat? Ha így tesz, nem csak a dokumentáció fejlesztésében segít, hanem az oldal közreműködőjeként is jóváírást kap.

További információ: Microsoft Learn-dokumentáció szerkesztése.

Visszajelzés

Hasznosnak találta ezt az oldalt?

Last updated on 2026-10-01