Rendelkezésre állás redundancián keresztül – Azure SQL Database

A következőkre vonatkozik:Azure SQL DatabaseSQL Database a Fabric-ben

Ez a cikk az Azure SQL Database és a Fabricben található SQL Database architektúráját ismerteti, amely helyi redundanciával és magas rendelkezésre állással érhető el a zónaredundancián keresztül.

Áttekintés

Az Azure SQL Database és az SQL Database in Fabric egyaránt az SQL Server adatbázismotor legújabb stabil verzióján fut a Windows operációs rendszeren az összes vonatkozó javítással. Az SQL Database automatikusan kezeli a kritikus karbantartási feladatokat, például javításokat, biztonsági mentéseket, Windows- és SQL-motorfrissítéseket, valamint nem tervezett eseményeket, például a mögöttes hardvereket, szoftvereket vagy hálózati hibákat. Ha az SQL Database-ben egy adatbázist vagy rugalmas készletet kijavítanak vagy átváltanak, az állásidő nem lesz hatással a működésre, ha újrapróbálkozási logikát alkalmaz az alkalmazásban. Az SQL Database a legkritikusabb körülmények között is gyorsan helyreállhat, biztosítva, hogy az adatok mindig elérhetők legyenek. A felhasználók többsége nem veszi észre, hogy a frissítések végrehajtása folyamatosan történik.

Alapértelmezés szerint az Azure SQL Database a helyi redundancia segítségével rendelkezésre állási biztosít, ezáltal adatbázisának elérhetőségét biztosítja a következő esetekben:

• Az ügyfél által kezdeményezett menedzsment műveletek rövid állásidőt eredményeznek
• Szolgáltatáskarbantartási műveletek
• A következőkkel kapcsolatos problémák:
  • állvány, ahol a szolgáltatást működtető gépek futnak
  • az SQL-adatbázismotort üzemeltető fizikai gép
• Az SQL-adatbázismotor egyéb problémái
• Egyéb lehetséges nem tervezett helyi kimaradások

Az alapértelmezett rendelkezésre állási megoldás úgy lett kialakítva, hogy a véglegesített adatok soha ne vesszenek el hibák miatt, hogy a karbantartási műveletek ne befolyásolják a számítási feladatokat, és hogy az adatbázis ne legyen egyetlen meghibásodási pont a szoftverarchitektúrában.

Azonban a zónaredundancia engedélyezésével magas rendelkezésre állást érhet el, ezzel minimalizálva az adatokra gyakorolt hatást egy teljes zóna kimaradása esetén. Zónaredundancia nélkül a feladatátvételek helyileg, ugyanabban az adatközpontban történnek, ami azt eredményezheti, hogy az adatbázis a kimaradás feloldásáig nem érhető el – a helyreállítás egyetlen módja egy vészhelyreállítási megoldás, például az aktív georeplikáció geo-feladatátvételenkeresztül, a feladatátvételi csoportokhasználata, vagy a georedundáns biztonsági mentés geo-visszaállítása. Ha többet szeretne megtudni, tekintse át az üzletmenet folytonosság áttekintését.

Három rendelkezésre állási architektúramodell létezik:

• távoli tárolási modell, amely a számítás és a tárolás szétválasztásán alapul. A távoli tárolási szint rendelkezésre állására és megbízhatóságára támaszkodik. Ez az architektúra olyan költségvetés-orientált üzleti alkalmazásokat céloz meg, amelyek a karbantartási tevékenységek során képesek némi teljesítménycsökkenést elviselni.
• helyi tárolási modell, amely adatbázismotor-folyamatok fürtöjén alapul. Arra a tényre támaszkodik, hogy mindig rendelkezésre áll egy kvórum az adatbázismotor-csomópontokból. Ez az architektúra olyan kritikus fontosságú alkalmazásokat céloz meg, amelyek magas I/O-teljesítménnyel, magas tranzakciós sebességgel és minimális teljesítménybeli hatással vannak a számítási feladatokra a karbantartási tevékenységek során.
• rugalmas skálázású modell, amely magas rendelkezésre állású összetevők, például számítási csomópontok, lapkiszolgálók, naplószolgáltatás és állandó tárterület elosztott rendszerét használja. A rugalmas skálázású adatbázist támogató minden összetevő saját redundanciát és rugalmasságot biztosít a hibákhoz. A számítási csomópontok, lapkiszolgálók és naplószolgáltatás az Azure Service Fabricen futnak, amely szabályozza az egyes összetevők állapotát, és szükség esetén feladatátvételt végez az elérhető kifogástalan állapotú csomópontokra. Az állandó tár a natív magas rendelkezésre állási és redundancia-képességekkel rendelkező Azure Storage-t használja. További információ: rugalmas skálázású architektúra.

A három rendelkezésre állási modell mindegyikében az SQL Database támogatja a helyi redundancia és a zónaredundancia beállításait. A helyi redundancia rugalmasságot biztosít az adatközponton belül, míg a helyi redundancia tovább javítja a rugalmasságot azáltal, hogy védelmet nyújt egy régión belüli rendelkezésre állási zóna kimaradása ellen.

Az alábbi táblázat a szolgáltatási szinteken alapuló rendelkezésre állási lehetőségeket mutatja be:

A különböző szolgáltatási szintekhez tartozó speciális SLA-kkal kapcsolatos további információkért tekintse át az Azure SQL Database SLA-ját.

Rendelkezésre állás helyi redundancián keresztül

A helyi redundanciával biztosított rendelkezésre állást az adja, hogy az adatbázisa helyileg redundáns tárolásba (LRS) kerül, amely háromszor másolja az adatokat az elsődleges régió egyik adatközpontján belül. Ez védi az adatokat helyi meghibásodás esetén, például kisebb hálózati vagy áramellátási hiba esetén. Az LRS a legalacsonyabb költségű redundancia lehetőség, és a többi lehetőséghez képest a legkevésbé tartósságot biztosítja. Ha egy régióban nagy méretű katasztrófa, például tűz vagy áradás történik, előfordulhat, hogy egy LRS-t használó tárfiók összes replikája elveszik vagy helyreállíthatatlan lesz. A helyileg redundáns rendelkezésre állási lehetőség használata esetén az adatok további védelme érdekében érdemes lehet rugalmasabb tárolási lehetőséget használni a adatbázis biztonsági mentéseihez. Ez nem vonatkozik a rugalmas skálázású adatbázisokra, ahol ugyanazt a tárterületet használják adatfájlokhoz és biztonsági másolatokhoz is.

A helyileg redundáns rendelkezésre állás az összes szolgáltatási szinten lévő összes adatbázis számára elérhető, és a helyreállítási pont célkitűzése (RPO), amely azt jelzi, hogy az adatvesztés mennyisége nulla.

Alapszintű, standard és általános célú szolgáltatási szintek

A DTU-alapú vásárlási modell alapszintű és standard szolgáltatási szintjei, valamint a virtuális magalapú vásárlási modell általános célú szolgáltatási szintje a távoli tárolási rendelkezésre állási modellt kiszolgáló nélküli és kiépített számításhoz is használják. Az alábbi ábra négy különböző csomópontot mutat be a különálló számítási és tárolási rétegekkel.

A távoli tár rendelkezésre állási modellje két réteget tartalmaz:

• Egy állapot nélküli számítási réteg, amely az adatbázismotor folyamatát futtatja, és csak átmeneti és gyorsítótárazott adatokat tartalmaz, például a csatolt SSD-n lévő tempdb és model adatbázisokat, valamint a gyorsítótárat, a pufferkészletet és az oszloptárkészletet a memóriában. Ezt az állapot nélküli csomópontot az Azure Service Fabric üzemelteti, amely inicializálja az adatbázismotort, szabályozza a csomópont állapotát, és szükség esetén feladatátvételt hajt végre egy másik csomópontra.
• Állapotalapú adatréteg az Azure Blob Storage-ban tárolt adatbázisfájlokkal (.mdf és .ldf). Az Azure Blob Storage beépített adat rendelkezésre állási és redundanciafunkciókkal rendelkezik. Garantálja, hogy az adatfájl naplófájljának vagy lapjának minden rekordja megmarad, még akkor is, ha az adatbázismotor folyamata összeomlik.

Amikor az adatbázismotort vagy az operációs rendszert frissítik, vagy hiba észlelhető, az Azure Service Fabric áthelyezi az állapot nélküli adatbázismotor-folyamatot egy másik, elegendő szabad kapacitással rendelkező állapot nélküli számítási csomópontra. Az Azure Blob Storage-ban lévő adatokat nem befolyásolja az áthelyezés, és az adatok/naplófájlok az újonnan inicializált adatbázismotor folyamatához vannak csatolva. Ez a folyamat garantálja a magas rendelkezésre állást, de a nagy számítási feladatok teljesítménycsökkenést tapasztalhatnak az átmenet során, mivel az új adatbázismotor-folyamat hideg gyorsítótárral kezdődik.

Prémium és üzleti szempontból kritikus szolgáltatási szint

A DTU-alapú vásárlási modell prémium szolgáltatási szintje és a virtuális magalapú vásárlási modell üzletileg kritikus szolgáltatási szintje a helyi tárolási rendelkezésre állási modellt használja, amely egyetlen csomóponton integrálja a számítási erőforrásokat (adatbázismotor-folyamatot) és a tárolást (helyileg csatlakoztatott SSD). A magas rendelkezésre állás úgy érhető el, hogy a számítást és a tárolást további csomópontokra replikálja.

A mögöttes adatbázisfájlokat (.mdf/.ldf) a csatolt SSD-tárolóba helyezi a rendszer, hogy nagyon alacsony késésű IO-t biztosítson a számítási feladat számára. Az SQL Server Always On rendelkezésre állási csoportoktechnológiájához hasonló megoldással valósítják meg a magas rendelkezésre állást. A fürt egyetlen elsődleges replikát tartalmaz, amely olvasási-írási ügyfélfeladatokhoz érhető el, és legfeljebb három másodlagos replikát (számítást és tárolást) tartalmaz, amelyek adatmásolatokat tartalmaznak. Az elsődleges replika folyamatosan leküldi a módosításokat a másodlagos replikákra, és biztosítja, hogy az adatok elegendő számú másodlagos replikán megmaradjanak az egyes tranzakciók véglegesítése előtt. Ez a folyamat garantálja, hogy ha az elsődleges replika vagy egy olvasható másodlagos replika bármilyen okból összeomlik, mindig van egy teljesen szinkronizált replika, amelyhez át tud állni. A feladatátvételt az Azure Service Fabric kezdeményezi. Amikor egy másodlagos replika válik új primer replikává, létrehoznak egy másik másodlagos replikát annak biztosítására, hogy a fürt elégséges számú replikával rendelkezzen a kvórum fenntartása érdekében. A feladatátvétel befejezése után a rendszer automatikusan átirányítja az Azure SQL-kapcsolatokat az új elsődleges replikára vagy olvasható másodlagos replikára.

További előny, hogy a helyi tárolási rendelkezésre állási modell lehetővé teszi az írásvédett Azure SQL-kapcsolatok átirányítását az egyik másodlagos replikára. Ezt a funkciót Olvasási skálázásnaknevezzük.% százalékkal több számítási kapacitást biztosít felár nélkül, hogy a csak olvasható műveletek, például az elemzői munkaterhelések, átirányításra kerüljenek az elsődleges replikáról.

Rugalmas skálázású szolgáltatási szint

A rugalmas skálázású szolgáltatásszint architektúráját Elosztott függvények architektúrájaismerteti.

A rugalmas skálázású rendelkezésre állási modell négy réteget tartalmaz:

• Állapot nélküli számítási réteg, amely az adatbázismotor folyamatait futtatja, és csak átmeneti és gyorsítótárazott adatokat tartalmaz, mint például a nem teljes RBPEX gyorsítótár, a tempdb és model adatbázisok stb. a csatolt SSD-n, valamint a tervgyorsítótár, a pufferkészlet és az oszloptárkészlet a memóriában. Ez az állapot nélküli réteg tartalmazza az elsődleges számítási replikát, és opcionálisan több másodlagos számítási replikát is, amelyek feladatátvételi célként szolgálhatnak.
• Lapkiszolgálók által létrehozott állapot nélküli tárolási réteg. Ez a réteg a számítási replikákon futó adatbázismotor-folyamatok elosztott tárolómotorja. Minden lapkiszolgáló csak átmeneti és gyorsítótárazott adatokat tartalmaz, például az RBPEX gyorsítótár lefedése a csatolt SSD-n, és a memóriában gyorsítótárazott adatoldalak. Minden lapkiszolgáló rendelkezik egy párosított lapkiszolgálóval egy aktív-aktív konfigurációban, amely terheléselosztást, redundanciát és magas rendelkezésre állást biztosít.
• Állapotalapú tranzakciónapló-tárolási réteg, amelyet a naplószolgáltatás-folyamatot, a tranzakciónapló kezdőzónát és a tranzakciónapló hosszú távú tárolását futtató számítási csomópont hoz létre. A leszállási zóna és a hosszú távú tárolás az Azure Storage-t használja, amely rendelkezésre állást és redundanciát biztosít a naplófájlhoz, biztosítva az adatok tartósságát a véglegesített tranzakciók esetén.
• Állapotalapú adattárolási réteg az Azure Storage-ban tárolt és lapkiszolgálók által frissített adatbázisfájlokkal (.mdf/.ndf). Ez a réteg az Azure Storage adat-hozzáférési és redundancia funkcióit használja. Garantálja, hogy az adatfájlok minden oldala megmarad, még akkor is, ha a rugalmas skálázású architektúra más rétegeiben lévő folyamatok összeomlanak, vagy ha a számítási csomópontok meghibásodnak.

Az összes rugalmas skálázási réteg számítási csomópontjai az Azure Service Fabricen futnak, amely szabályozza az egyes csomópontok állapotát, és szükség esetén feladatátvételt végez az elérhető kifogástalan állapotú csomópontokra.

A Hyperscale magas rendelkezésre állásáról további információért lásd a Hyperscale adatbázis magas rendelkezésre állásacímű részt.

Magas rendelkezésre állás zónaredundancián keresztül

A zónaredundáns rendelkezésre állás biztosítja, hogy az adatok az elsődleges régióban három Azure-rendelkezésre állási zónában oszlanak meg. Minden rendelkezésre állási zóna egy különálló fizikai hely, amely független energiaellátással, hűtéssel és hálózatkezeléssel rendelkezik.

A zónaredundáns rendelkezésre állás az vCore-alapú vásárlási modell Üzletileg Kritikus, Általános Célú és Hiperskálázást szolgáltatási szintjeibenérhető el adatbázisok számára, és csak a DTU-alapú vásárlási modell Prémium szolgáltatási szintjében érhető el — az alapszintű és a standard szolgáltatási szintek nem támogatják a zónaredundanciát.

Bár az egyes szolgáltatási szintek eltérő módon implementálják a zónaredundanciát, minden implementáció biztosítja a helyreállítási pont célkitűzését (RPO), amely a feladatátvétel során nem veszt el véglegesített adatokat.

Általános célú szolgáltatási szint

Az általános rendeltetésű szolgáltatási szint zónaredundáns konfigurációja a szerver nélküli és kiépített számítási lehetőségekhez is elérhető, a vCore alapú vásárlási modell szerint az adatbázisok számára. Ez a konfiguráció Azure rendelkezésre állási zónákat használ az adatbázisok azure-régión belüli több fizikai helyre történő replikálásához. A zónaredundancia kiválasztásával az új és meglévő kiszolgáló nélküli és kiépített általános célú önálló adatbázisokat és rugalmas készleteket rugalmassá teheti sokkal nagyobb hibákkal szemben, beleértve a katasztrofális adatközpont-kimaradásokat is, az alkalmazáslogika módosítása nélkül.

Az Általános célú szint zónaredundáns konfigurációja két rétegből áll:

• Állapotalapú adatréteg a ZRS-ben (zónaredundáns tárolás) tárolt adatbázisfájlokkal (.mdf/.ldf). Az ZRS segítségével az adatokat és a naplófájlokat szinkron módon másolják három fizikailag elkülönített Azure-rendelkezésre állási zónába.
• A sqlservr.exe folyamatot futtató állapot nélküli számítási réteg, amely csak átmeneti és gyorsítótárazott adatokat tartalmaz, például a csatolt SSD tempdb és model adatbázisait, valamint a memória gyorsítótárát, pufferkészletét és oszlopkészletét. Ezt az állapot nélküli csomópontot az Azure Service Fabric üzemelteti, amely inicializálja sqlservr.exe, szabályozza a csomópont állapotát, és szükség esetén feladatátvételt hajt végre egy másik csomópontra. Zónaredundáns kiszolgáló nélküli és kiépített általános célú adatbázisok esetén a tartalék kapacitással rendelkező csomópontok könnyen elérhetők más rendelkezésre állási zónákban a feladatátvételhez.

Az Általános célú szolgáltatási szint magas rendelkezésre állású architektúrájának zónaredundáns verzióját az alábbi ábra szemlélteti:

• A regionális rendelkezésre állásról az Azure SQL Database általános célú zónaredundancia-funkciók régiónkénti rendelkezésre állását ismertető cikkben olvashat.
• Zónaredundáns rendelkezésre állás esetén az alapértelmezetten kívüli karbantartási időszak kiválasztása jelenleg a kijelölt régiókban érhető el. További információ: Karbantartási időszak rendelkezésre állása régiónként az Azure SQL Database.
• A zónaredundáns konfiguráció csak akkor érhető el az SQL Database-ben, ha standard sorozatú (Gen5) hardver van kiválasztva.
• A zónaredundancia nem érhető el a DTU vásárlási modell alapszintű és standard szolgáltatási szintjeihez.

Prémium és üzleti szempontból kritikus szolgáltatási szintek

Ha a zónaredundancia engedélyezve van a prémium vagy az üzleti szempontból kritikus szolgáltatási szinten, a replikák ugyanabban a régióban különböző rendelkezésre állási zónákba kerülnek. Egy meghibásodási pont kiküszöbölése érdekében a vezérlőgyűrű három átjárógyűrűként (GW) is duplikálva van több zónában. Az adott átjárógyűrűhöz való útválasztást Azure Traffic Managerszabályozza. Mivel a prémium vagy üzleti szempontból kritikus szolgáltatási szintek zónaredundáns konfigurációja a meglévő replikáit használja a különböző rendelkezésre állási zónákba való helyezéshez, további költségek nélkül engedélyezheti azt. Zónaredundáns konfiguráció kiválasztásával rugalmassá teheti prémium vagy üzleti szempontból kritikus adatbázisait és rugalmas készleteit a sokkal nagyobb hibákkal szemben, beleértve a katasztrofális adatközpont-kimaradásokat is, az alkalmazáslogika módosítása nélkül. Bármely meglévő prémium vagy üzleti szempontból kritikus adatbázist vagy rugalmas készletet zónaredundáns konfigurációvá alakíthat.

A magas rendelkezésre állású architektúra zónaredundáns verzióját az alábbi ábra szemlélteti:

Vegye figyelembe a következőket, amikor zónaredundanciával konfigurálja prémium vagy üzleti szempontból kritikus fontosságú adatbázisait:

• A zónaredundáns adatbázisokat támogató régiókról a Szolgáltatások támogatása régiónkéntcímű témakörben olvashat.
• Zónaredundáns rendelkezésre állás esetén az alapértelmezetten kívüli karbantartási időszak kiválasztása jelenleg a kijelölt régiókban érhető el. További információ: Karbantartási időszak rendelkezésre állása régiónként az Azure SQL Database.

Rugalmas skálázású szolgáltatási szint

A rugalmas skálázási szolgáltatási szinten lévő adatbázisok zónaredundanciája konfigurálható. További információkért tekintse át a Zónaredundáns Hyperscale adatbázis létrehozásaleírást.

A konfiguráció engedélyezése zónaszintű rugalmasságot biztosít a rendelkezésre állási zónák közötti replikáció révén az összes rugalmas skálázási réteg esetében. A zónaredundancia kiválasztásával rugalmassá teheti a rugalmas skálázású adatbázisokat sokkal nagyobb hibákkal szemben, beleértve a katasztrofális adatközpont-kimaradásokat is, az alkalmazáslogika módosítása nélkül. Minden olyan Azure-régió, amely Elérhetőségi zónákkal rendelkezik, támogatja a zónaredundáns Hyperscale adatbázist. A rugalmas skálázású PRMS- és MOPRMS-hardverek zónaredundancia-támogatása bizonyos régiókban érhető el. További információ: Rugalmas skálázású prémium sorozatok rendelkezésre állása régiónként az Azure SQL Database.

A zónaredundáns rendelkezésre állás támogatott a Hyperscale önálló adatbázisokban és a Hyperscale rugalmas készletekben. További információért lásd a hiperskálázott rugalmas készletek.

Az alábbi ábra a zónaredundáns rugalmas skálázású adatbázisok mögöttes architektúráit mutatja be:

Vegye figyelembe a következő korlátozásokat:

• Zónaredundáns konfiguráció csak az adatbázis létrehozásakor adható meg. Ez a beállítás nem módosítható az erőforrás kiépítése után. Az Adatbázis-másolás, időponthoz kötött visszaállítás, vagy hozzon létre egy georeplikát a meglévő Hyperscale adatbázis zónaredundáns konfigurációjának frissítéséhez. Ezen frissítési beállítások egyikének használatakor, ha a céladatbázis más régióban van, mint a forrás, vagy ha az adatbázis biztonsági mentési tárolójának redundanciái eltérnek a forrásadatbázistól, a másolási művelet adatművelet mérete lesz.

• Zónaredundáns rendelkezésre állás esetén az alapértelmezetten kívüli karbantartási időszak kiválasztása jelenleg a kijelölt régiókban érhető el. További információ: Karbantartási időszak rendelkezésre állása régiónként az Azure SQL Database.

• Jelenleg nincs lehetőség zónaredundancia megadására, ha egy adatbázist rugalmas skálázásba migrál az Azure Portal használatával. A zónaredundancia azonban megadható az Azure PowerShell, az Azure CLI vagy a REST API használatával, amikor egy meglévő adatbázist egy másik Azure SQL Database szolgáltatási szintről Hyperscale-re migrál. Íme egy példa az Azure CLI-vel:

  az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true`
  

• A Hyperscale zónaredundáns konfigurációjának engedélyezéséhez legalább 1 nagy rendelkezésre állású replika és zónaredundáns vagy georedundáns biztonsági mentési tárhely használata szükséges.

Az adatbázis zónák redundanciájával biztosított rendelkezésre állás

Az Azure SQL Database-ben a kiszolgálói egy logikai szerkezet, amely központi felügyeleti pontként szolgál az adatbázisok gyűjteményéhez. A kiszolgáló szintjén kezelheti a bejelentkezéseket, a hitelesítési módszert, a tűzfalszabályokat, a naplózási szabályokat, a fenyegetésészlelési szabályzatokat és a feladatátvételi csoportokat. Ezen funkciók némelyikével kapcsolatos adatokat, például a bejelentkezéseket és a tűzfalszabályokat a master adatbázis tárolja. Hasonlóképpen, egyes DMV-k adatai, például sys.resource_stats, szintén a master adatbázisban vannak tárolva.

Ha egy logikai kiszolgálón zónaredundáns konfigurációval rendelkező adatbázis jön létre, a kiszolgálóhoz társított master adatbázis is automatikusan zónaredundánssá válik. Ez biztosítja, hogy egy zónakimaradás esetén az adatbázist használó alkalmazások ne legyenek hatással, mivel a master adatbázistól függő funkciók, például a bejelentkezések és a tűzfalszabályok továbbra is elérhetők. A master adatbázis zónaredundánssá tétele aszinkron folyamat, és némi időt vesz igénybe a háttérben.

Ha a kiszolgálón lévő adatbázisok egyike sem zónaredundáns, vagy ha üres kiszolgálót hoz létre, akkor a kiszolgálóhoz társított master adatbázis nem zónaredundáns .

Az Azure PowerShell, az Azure CLI vagy a REST API használatával ellenőrizheti a ZoneRedundant adatbázis master tulajdonságát:

Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"

az sql db show --resource-group "myResourceGroup" --server "myServerName" --name master

Az alkalmazások hibatűrésének tesztelése

A magas rendelkezésre állás az SQL Database platform alapvető része, amely transzparens módon működik az adatbázis-alkalmazás számára. Felismerjük azonban, hogy érdemes lehet tesztelni, hogy a tervezett vagy nem tervezett események során indított automatikus feladatátvételi műveletek hogyan befolyásolnák az alkalmazást, mielőtt éles környezetben üzembe helyezné. A feladatátvételt manuálisan is aktiválhatja, ha egy speciális API-t hív meg egy adatbázis vagy egy rugalmas készlet újraindításához. Zónaredundáns kiszolgáló nélküli vagy kiépített általános célú adatbázis vagy rugalmas készlet esetén az API-hívás az ügyfélkapcsolatokat a régi elsődleges rendelkezésre állási zónától eltérő rendelkezésre állási zónában lévő új elsődlegesre irányítaná át. Így a feladatátvétel a meglévő adatbázis-munkamenetekre gyakorolt hatásának tesztelése mellett azt is ellenőrizheti, hogy a teljes körű teljesítményt módosítja-e a hálózati késés változása miatt. Mivel az újraindítási művelet tolakodó, és nagy számban stresszelhetik a platformot, minden adatbázis vagy rugalmas készlet esetében 15 percenként csak egy feladatátvételi hívás engedélyezett.

Az Azure SQL Database magas rendelkezésre állásával és vészhelyreállításával kapcsolatos további információkért tekintse át a HA/DR ellenőrzőlistát.

A feladatátvétel a PowerShell, a REST API vagy az Azure CLI használatával kezdeményezhető:

Következtetés

Az Azure SQL Database beépített magas rendelkezésre állású megoldást tartalmaz, amely mélyen integrálva van az Azure-platformmal. A szolgáltatás a Service Fabrictől függ a hibák észleléséhez és helyreállításához, az Azure Blob Storage-hoz az adatvédelemhez, valamint a rendelkezésre állási zónáktól a nagyobb hibatűrés érdekében. Az SQL Database emellett az SQL Server Always On rendelkezésre állási csoport technológiáját használja adatszinkronizáláshoz és feladatátvételhez. Ezeknek a technológiáknak a kombinációja lehetővé teszi az alkalmazások számára, hogy teljes mértékben kihasználják a vegyes tárolási modell előnyeit, és támogatják a legigényesebb SLA-kat.

Kapcsolódó tartalom

További információkért tekintse át az alábbiakat:

• Azure rendelkezésre állási zónák
• Service Fabric
• Azure Traffic Manager
• Az Azure SQL Database üzletmenet-folytonosságának áttekintése