A rendelkezésre állási csoport replikáinak frissítése

A következőkre vonatkozik:SQL Server

Ha egy Always On rendelkezésre állási csoportot (AG) futtató SQL Server-példányt frissít egy új SQL Server-verzióra, egy új SQL Server-szervizcsomagra vagy összegző frissítésre, vagy ha új Windows-szervizcsomagra vagy kumulatív frissítésre telepíti, az elsődleges replika állásidejét csak egyetlen manuális feladatátvételre csökkentheti egy gördülő frissítés végrehajtásával (vagy két manuális feladatátvétellel, ha az eredeti elsődlegesre való visszalépés meghiúsul).

A frissítési folyamat során a másodlagos replika nem lesz elérhető feladatátvételhez vagy írásvédett műveletekhez, és a frissítés után eltarthat egy ideig, amíg a másodlagos replika felzárkózik az elsődleges replikacsomóponthoz az elsődleges replikacsomópont tevékenységének mennyiségétől függően (így nagy hálózati forgalom várható).

Vegye figyelembe azt is, hogy az SQL Server újabb verzióját futtató másodlagos replika kezdeti feladatátvétele után az abban az AG-ben lévő adatbázisok egy frissítési folyamaton fognak keresztülfutni, hogy a legújabb verzióra juttassa őket. Ez idő alatt ezekhez az adatbázisokhoz nem lesznek olvasható replikák. A kezdeti feladatátvétel utáni állásidő az AG-ben lévő adatbázisok számától függ. Ha azt tervezi, hogy visszatér az eredeti elsődleges példányra, ez a lépés nem ismétlődik meg visszatéréskor.

Jegyzet

Ez a cikk az SQL Server frissítésére korlátozza a vitafórumot. Nem terjed ki a Windows Server feladatátvevő fürtöt (WSFC) tartalmazó operációs rendszer frissítésére. A feladatátvevő fürtöt futtató Windows operációs rendszer frissítése a Windows Server 2012 R2 előtti operációs rendszerek esetében nem támogatott. A Windows Server 2012 R2-n futó fürtcsomópont frissítéséről lásd a Fürt operációs rendszer gördülő frissítésecímű témakört.

Előfeltételek

Mielőtt hozzákezdene, tekintse át a következő fontos információkat:

• támogatott verzió- és kiadásfrissítések: Ellenőrizze, hogy frissíthet-e az SQL Server legújabb verziójára a Windows operációs rendszer és az SQL Server verziójáról. Ha például közvetlenül egy SQL Server 2005-példányról frissít, az adatbázis kompatibilitási szintje frissül.

• Válasszon adatbázismotor-frissítési módszert: A megfelelő sorrendben történő frissítéshez válassza ki a megfelelő frissítési módszert és lépéseket a támogatott verzió- és kiadásfrissítések áttekintése, valamint a környezetében telepített egyéb összetevők alapján.

• Az adatbázismotor frissítési tervének megtervezése és tesztelése: Tekintse át a kibocsátási megjegyzéseket és az ismert frissítési problémákat, az előzetes ellenőrzőlistát, és fejlessze ki és tesztelje a frissítési tervet.

• AZ SQL Servertelepítésének hardver- és szoftverkövetelményei: Tekintse át az SQL Server telepítéséhez szükséges szoftverkövetelményeket. Ha további szoftverre van szükség, telepítse azt minden egyes csomópontra a frissítési folyamat megkezdése előtt, hogy minimalizálja a kieső időt.

• Ellenőrizze, hogy a módosítási adatrögzítés vagy a replikáció használható-e az AG-adatbázisokhoz: Ha az AG-ben lévő adatbázisok engedélyezve vannak a változásadat-rögzítéshez (CDC), végezze el ezeket a utasításokat.

Jegyzet

• Az SQL Server-példányok ugyanazon AG-n belüli keverése nem támogatott egy gördülő frissítésen kívül, és hosszabb ideig nem létezhet ebben az állapotban, mert a frissítést gyorsan végre kell hajtani. Az SQL Server 2016 (13.x) és újabb verziók frissítésének másik lehetősége egy elosztott rendelkezésre állási csoport használata.
• A Cluster-Aware Frissítés (CAU) Windows szolgáltatás használata az Always On rendelkezésre állási csoportok frissítéséhez nem támogatott.

A rendelkezésre állási csoportok gördülő frissítési alapjai

A kiszolgálófrissítések vagy -frissítések végrehajtásakor kövesse az alábbi irányelveket az AG-k állásidejének és adatvesztésének minimalizálása érdekében:

• A működés közbeni frissítés megkezdése előtt:

  • Végezze el a manuális feladatátvételt legalább egy szinkron-véglegesítési replikapéldányon.

  • Az adatok védelméhez készítsen teljes adatbázis-biztonsági másolatot minden rendelkezésre állási adatbázisról.

  • Futtassa DBCC CHECKDB az összes rendelkezésre állási adatbázist.

• Először mindig frissítse a távoli másodlagos replikapéldányokat, majd a helyi másodlagos replikapéldányokat, majd az elsődleges replikapéldányt.

• A biztonsági mentések nem történhetnek olyan adatbázisokon, amelyek frissítése folyamatban van. A másodlagos replikák frissítése előtt konfigurálja az automatikus biztonsági mentési beállítást úgy, hogy csak az elsődleges replikán futtassa a biztonsági másolatokat. A verziófrissítés során a replikák nem olvashatók és nem érhetők el biztonsági másolatokhoz. A nemverziós frissítés során az automatikus biztonsági mentéseket úgy konfigurálhatja, hogy az elsődleges replika frissítése előtt futtassa a másodlagos replikákat.

• Verziófrissítés során az olvasható másodpéldányok nem érhetők el az olvasható másodpéldány frissítése után, és mielőtt az elsődleges replika vagy egy frissített másodpéldányra lenne átkapcsolva, vagy maga az elsődleges replika lenne frissítve.

• Ha meg szeretné akadályozni, hogy az AG a frissítési folyamat során ne hajtson végre nem kívánt feladatátvételt, a kezdés előtt távolítsa el a rendelkezésre állási feladatátvételt az összes szinkron véglegesítésű replikából.

• Ne frissítse az elsődleges replikapéldányt, mielőtt az AG-t egy másodlagos replikával rendelkező frissített példányra irányítja át. Ellenkező esetben az ügyfélalkalmazások hosszabb állásidőt szenvedhetnek az elsődleges replikapéldány frissítése során.

• Az AG-t mindig egy szinkron-commit másodlagos replikapéldányra kell átkapcsolnia. Ha átállást hajt végre egy aszinkron-commit másodlagos replikapéldányra, az adatbázisok ki vannak téve az adatvesztésnek, és az adatáthelyezés automatikusan felfüggesztődik, amíg manuálisan újra nem indítja.

• Ne frissítse az elsődleges replikapéldányt a többi másodlagos replikapéldány verzióváltása vagy frissítése előtt. A frissített elsődleges replika már nem tud naplókat szállítani olyan másodlagos replikára, amelynek SQL Server-példánya még nem lett frissítve ugyanarra a verzióra. Ha a másodlagos replikába történő adatáthelyezés fel van függesztve, az adott replika esetében nem fordulhat elő automatikus feladatátvétel, és a rendelkezésre állási adatbázisok ki vannak téve az adatvesztésnek. Ez a működés közbeni frissítés során is érvényes, ahol manuálisan kell feladatátvételt végrehajtani egy régi elsődlegesről egy új elsődlegesre. Ezért előfordulhat, hogy a régi elsődleges verzió frissítése után újra kell folytatnia a szinkronizálást.

• Mielőtt egy AG-ben feladatátvételt hajtana végre, ellenőrizze, hogy a feladatátvételi cél szinkronizálási állapota SYNCHRONIZED-e.

  Figyelmeztetés

  Ha az SQL Server egy új példányát vagy új verzióját telepíti egy olyan kiszolgálóra, amelyre telepítve van az SQL Server régebbi verziója, véletlenül megszakadhat az SQL Server régebbi verziója által üzemeltetett rendelkezésre állási csoportok száma. Ennek az az oka, hogy az SQL Server példányának vagy verziójának telepítése során az SQL Server magas rendelkezésre állású modulja (RHS.EXE) frissül. Ez a kiszolgáló elsődleges szerepkörében lévő meglévő rendelkezésre állási csoportok ideiglenes megszakadását eredményezi. Ezért javasoljuk, hogy tegye az alábbiak egyikét az SQL Server újabb verziójának olyan rendszerre való telepítésekor, amely már rendelkezik egy rendelkezésre állási csoporttal rendelkező SQL Server régebbi verzióját futtató rendszerrel:

  • Telepítse az SQL Server új verzióját egy karbantartási időszak alatt.

  • Feladatátvétel a rendelkezésre állási csoportnak a másodlagos replikára, így az nem elsődleges az új SQL Server-példány telepítése során.

Folyamatos frissítési folyamat

A gyakorlatban a pontos folyamat olyan tényezőktől függ, mint az AG-k üzembehelyezési topológiája és az egyes replikák véglegesítési módja. A legegyszerűbb forgatókönyvben azonban a működés közbeni frissítés egy többlépcsős folyamat, amely a legegyszerűbb formájában a következő lépéseket foglalja magában:

1. Automatikus feladatátvétel eltávolítása az összes szinkron-véglegesítési replikán
2. Frissítse az összes aszinkron elkötelezésű másodlagos replikapéldányt.
3. Frissítse az összes távoli, szinkron véglegesítési módú másodlagos replikapéldányt.
4. Frissítse az összes helyi szinkron-véglegesítési másodlagos replikapéldányt.
5. Az AG manuális átvitele egy (újonnan frissített) helyi szinkron elkötelezésű másodlagos replikára.
6. Frissítse vagy léptesse előre a helyi replikapéldányt, amely korábban az elsődleges replikát fogadta.
7. Igény szerint konfigurálja az automatikus feladatátvételi partnereket.

Szükség esetén további manuális feladatátvételt is végrehajthat az AG eredeti konfigurációjának visszaállításához.

A szinkron véglegesítésű replika frissítése és offline állapotba helyezése nem késlelteti az elsődlegesen végrehajtott tranzakciókat. Miután a másodlagos replika leválasztásra került, a tranzakciókat az elsődleges replikán nyugtázzák anélkül, hogy megvárnák a naplók másodlagos replikán való rögzítését. Ha REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT be van állítva vagy 12, akkor előfordulhat, hogy az elsődleges replika nem érhető el olvasási/írási műveletekhez, ha a frissítési folyamat során nem érhető el megfelelő számú másodlagos szinkronizálási replika.

Amikor helyben frissíti a másodlagos replikát az SQL Server újabb verziójára, a rendelkezésre állási csoporton belüli adatbázis a Szinkronizálás / Helyreállítási vagy Szinkronizált /Helyreállítási állapotban marad, amíg a rendelkezésre állási csoport manuális feladatátvétele befejeződik, és az adatbázis frissítése befejeződik. A frissített elsődleges replika már nem tud naplókat szállítani az alacsonyabb verziójú másodlagos replikára és az adatáthelyezési leállásokra, az adott replika esetében nem fordulhat elő automatikus feladatátvétel, és a rendelkezésre állási adatbázisok ki vannak téve az adatvesztésnek. Előfordulhat, hogy a régi elsődleges verzió frissítése után újra kell folytatnia a szinkronizálást. Javasoljuk, hogy frissítse az összes másodlagos replikát, mielőtt az új verzióval rendelkező replikára irányítja át a feladatokat. Így lehetősége van feladatátvételre az adatbázis(ok) új formátumra való frissítése után.

AG egy távoli másodlagos replikával

Ha csak vészhelyreállítás céljából telepített egy AG-t, előfordulhat, hogy át kell adnia az AG-t egy aszinkron véglegesítésű másodlagos replikára. Az alábbi ábra egy ilyen konfigurációt szemléltet:

Ebben az esetben a folyamatos frissítés során át kell állítania az AG-t az aszinkron módú másodlagos replikára. Az adatvesztés megakadályozása érdekében módosítsa a véglegesítési módot szinkron véglegesítésre, és várja meg, amíg a másodlagos replika szinkronizálva lesz az AG feladatátvétele előtt. Ezért a működés közbeni frissítési folyamat a következőképpen nézhet ki:

1. Frissítse a másodlagos replikapéldányt a távoli helyen.
2. Módosítsa a véglegesítési módot szinkron véglegesítésre.
3. Várjon, amíg a szinkronizálás állapota meg nem történik SYNCHRONIZED.
4. Feladatátvétel az AG-nek a távoli hely másodlagos replikájába.
5. Frissítse vagy frissítse a helyi (elsődleges hely) replikapéldányt.
6. Feladatátvétel az AG-nek az elsődleges helyre.
7. Módosítsa a véglegesítési módot aszinkron véglegesítésre.

Mivel a szinkron véglegesítési mód nem ajánlott beállítás távoli helyre történő adatszinkronizáláshoz, az ügyfélalkalmazások a beállítás módosítása után azonnal növelhetik az adatbázis késését. A feladatátvétel végrehajtása emellett az összes ismeretlen naplóüzenet elvetését eredményezi. Az elvetett naplóüzenetek száma jelentős lehet a két hely közötti magas hálózati késés miatt, ami miatt az ügyfelek nagy mennyiségű tranzakciós hibát tapasztalhatnak. Az alábbi műveletek végrehajtásával minimalizálhatja az ügyfélalkalmazásokra gyakorolt hatást:

• Az alacsony ügyfélforgalom során gondosan válasszon ki egy karbantartási időszakot.

• Az SQL Server elsődleges helyen történő frissítése vagy frissítése során módosítsa a rendelkezésre állási módot aszinkron véglegesítésre, majd térjen vissza szinkron véglegesítésre, ha készen áll arra, hogy ismét feladatátvételt hajtson végre az elsődleges helyen.

AG feladatátvevő fürtpéldány-csomópontokkal

Ha egy AG feladatátvevő fürtpéldányt (FCI) tartalmaz, az aktív csomópontok frissítése előtt frissítenie kell az inaktív csomópontokat. Az alábbi ábra egy gyakori AG-forgatókönyvet mutat be, amely FCI-ket használ helyi magas rendelkezésre álláshoz, valamint aszinkron véglegesítést biztosít a távoli vészhelyreállítási FCI-k között, továbbá bemutatja a frissítési sorrendet.

1. REMOTE2 frissítése vagy újítása
2. Az FCI2 átkapcsolása REMOTE2-ra
3. REMOTE1 frissítése vagy újítása
4. PRIMARY2 frissítése vagy újítása
5. Az FCI1 átkapcsolása a PRIMARY2-ra
6. PRIMARY1 frissítése vagy újítása

SQL Server-példányok frissítése vagy korszerűsítése több elérhetőségi csoporttal

Ha több AG-t futtat elsődleges replikákkal külön kiszolgálócsomópontokon (aktív/aktív konfiguráció), a frissítési útvonal több feladatátvételi lépést is magában foglal, hogy megőrizze a magas rendelkezésre állást a folyamatban. Tegyük fel, hogy három AG-t futtat három kiszolgálócsomóponton, és az összes replika szinkron véglegesítési módban van, ahogyan az alábbi táblázatban látható:

AG	Csomópont1	Csomópont2	Csomópont3
AG1	Elsődleges
AG2		Elsődleges
AG3			Elsődleges

Az ön esetében célszerű lehet terheléselosztásos gördülő frissítést végrehajtani a következő sorrendben:

1. Átkapcsolás az AG2-ről a Node3-ra (Node2felszabadításához)
2. Node2 frissítése vagy újítása
3. Hajts végre átváltást az AG1-ről a Node2-re (Node1felszabadításához)
4. Node1 frissítése vagy újítása
5. Az AG2 és az AG3 feladatátvétele Node1 (Node3felszabadításához)
6. Node3 frissítése vagy újítása
7. Az AG3 átváltása a Node3-ra

A frissítési sorozat átlagos állásideje AG-enként két feladatátvételnél kevesebb. Az eredményként kapott konfiguráció az alábbi táblázatban látható.

AG	Csomópont1	Csomópont2	Csomópont3
AG1		Elsődleges
AG2	Elsődleges
AG3			Elsődleges

Az adott implementációtól függően a frissítési útvonal változhat, és az ügyfélalkalmazások által tapasztalt állásidő is változhat.

Jegyzet

A működés közbeni frissítés befejezése után sok esetben a rendszer az eredeti elsődleges replikára fog visszaválást végrehajtani.

Elosztott rendelkezésre állási csoport folyamatos frissítése

Az elosztott rendelkezésre állási csoportok folyamatos frissítéséhez először frissítse az összes másodlagos replikát. Ezután feladatátvételt kell végrehajtania a továbbítón, és frissítenie kell a második rendelkezésre állási csoport utolsó fennmaradó példányát. Az összes többi replika frissítése után feladatátvételt kell végrehajtania a globális elsődleges példányon, és frissítenie kell az első rendelkezésre állási csoport utolsó fennmaradó példányát. A lépések részletes diagramja egy későbbi szakaszban található.

Az adott implementációtól függően a frissítési útvonal változhat, és az ügyfélalkalmazások által tapasztalt állásidő is változhat.

Jegyzet

A működés közbeni frissítés befejezése után sok esetben a rendszer az eredeti elsődleges replikákra fog visszakerülni.

Elosztott rendelkezésre állási csoport frissítésének általános lépései

1. Biztonsági másolatot készít az összes adatbázisról, beleértve a rendszeradatbázisokat és a rendelkezésre állási csoportban részt vevőket.
2. Frissítse és indítsa újra a második rendelkezésre állási csoport (az alsóbb réteg) összes másodlagos replikáját.
3. Frissítse és indítsa újra az első rendelkezésre állási csoport (a felsőbb réteg) összes másodlagos replikáját.
4. Átváltás az elsődleges továbbítóra a másodlagos rendelkezésre állási csoport frissített másodlagos replikájára.
5. Várjon az adatszinkronizálásra. Az adatbázisoknak szinkronizáltként kell megjelennie az összes szinkron-véglegesítési replikán, és a globális elsődleges példányt szinkronizálni kell a továbbítóval.
6. Frissítse és indítsa újra a másodlagos rendelkezésre állási csoport utolsó fennmaradó példányát.
7. Átváltás a globális elsődlegesről az első rendelkezésre állási csoport frissített másodlagos szerverére.
8. Frissítse az elsődleges rendelkezésre állási csoport utolsó fennmaradó példányát.
9. Indítsa újra az újonnan frissített kiszolgálót.
10. (nem kötelező) Állítsa vissza mindkét rendelkezésre állási csoportot az eredeti elsődleges replikáira.

Fontos

Ellenőrizze a szinkronizálást minden lépés között. Mielőtt továbblép a következő lépésre, győződjön meg arról, hogy a szinkron véglegesítési replikák szinkronizálva vannak a rendelkezésre állási csoportban, és hogy a globális elsődleges példány szinkronizálva van az elosztott AG továbbítóval.

javaslat: Minden alkalommal, amikor ellenőrzi a szinkronizálást, frissítse az adatbáziscsomópontot és az elosztott AG-csomópontot az SQL Server Management Studióban. A szinkronizálás után mentsen egy képernyőképet az egyes replikák állapotáról. Ez segít nyomon követni, hogy milyen lépésben dolgozik, bizonyítékkal szolgál arra vonatkozóan, hogy a következő lépés előtt minden megfelelően működött, és segít a hibaelhárításban, ha valami nem sikerül.

Példa egy elosztott rendelkezésre állási csoport működés közbeni frissítésére

Rendelkezésre állási csoport	Elsődleges replika	Másodlagos replika
AG1	NODE1\SQLAG	NODE2\SQLAG
AG2	NODE3\SQLAG	NODE4\SQLAG
DistributedAG	AG1 (globális)	AG2 (továbbító)

A diagram példányainak frissítésének lépései:

1. Biztonsági másolatot készít az összes adatbázisról, beleértve a rendszeradatbázisokat és a rendelkezésre állási csoportban részt vevőket.
2. Frissítse a NODE4\SQLAG-t (az AG2 másodlagosát), majd indítsa újra a kiszolgálót.
3. Frissítse a NODE2\SQLAG-t (az AG1 másodlagos eleme) és indítsa újra a szervert.
4. Az AG2 feladatot NODE3\SQLAG-ról NODE4\SQLAG-re hibáztassa.
5. Frissítse NODE3\SQLAG, és indítsa újra a kiszolgálót.
6. Feladat AG1 áthelyezése NODE1\SQLAG-ról NODE2\SQLAG-re.
7. Frissítse NODE1\SQLAG, és indítsa újra a kiszolgálót.
8. (nem kötelező) Visszaállás az eredeti elsődleges replikákra.
   1. Váltson AG2 hibáról a NODE4\SQLAG-ról vissza a NODE3\SQLAG-re.
   2. Hiba AG1 átvitele NODE2\SQLAG-ról vissza NODE1\SQLAG-re.

Ha az egyes rendelkezésre állási csoportokban létezik egy harmadik replika, akkor a korábbi és NODE1\SQLAGa korábbi verziót is frissítenie NODE3\SQLAG kell.

Fontos

Ellenőrizze a szinkronizálást minden lépés között. Mielőtt továbblép a következő lépésre, győződjön meg arról, hogy a szinkron véglegesítési replikák szinkronizálva vannak a rendelkezésre állási csoportban, és hogy a globális elsődleges példány szinkronizálva van az elosztott AG továbbítóval.

javaslat: Minden alkalommal, amikor ellenőrzi a szinkronizálást, frissítse az adatbáziscsomópontot és az elosztott AG-csomópontot az SQL Server Management Studióban. Miután minden szinkronizálva van, készítsen képernyőképet, és mentse azt. Ez segít nyomon követni, hogy milyen lépésben dolgozik, bizonyítékkal szolgál arra vonatkozóan, hogy a következő lépés előtt minden megfelelően működött, és segít a hibaelhárításban, ha valami nem sikerül.

Az adatrögzítés vagy a replikáció módosításának speciális lépései

Az alkalmazott frissítéstől függően további lépésekre lehet szükség a módosítási adatrögzítéshez vagy replikációhoz engedélyezett AG replikaadatbázisokhoz. A frissítés kibocsátási megjegyzéseiben megállapíthatja, hogy a következő lépések szükségesek-e:

1. Frissítsen minden másodlagos replikát.

2. Az összes másodlagos replika frissítése után az AG-t át kell állítani egy frissített példányra.

3. Futtassa a következő Transact-SQL-t azon a példányon, amely a primer másolatot tartalmazza:

   EXECUTE [master].[sys].[sp_vupgrade_replication];
   

   Jegyzet

   A parancs futtatása több percet is igénybe vehet. Hagyja ki ezt a lépést, ha az SQL Server 2019 CU1 vagy újabb verzióján dolgozik. További információért tekintse át KB4530283.

4. Frissítse az eredetileg elsődleges replikaként szolgáló példányt.

A háttérinformációkért tekintse meg a CDC funkcióit, amelyek a legújabb CU-ra való frissítés után megszakadhatnak.

Kapcsolódó tartalom

• SQL Server frissítése a Telepítővarázsló (Telepítés) segítségével
• Az SQL Server telepítése és konfigurálása Windows rendszeren a parancssorból