Megbízhatóság a Azure Cosmos DB

A NoSQL Azure Cosmos DB egy globálisan elosztott, többmodelles adatbázis-szolgáltatás, amely rugalmas sémákkal rendelkező dokumentumadatmodelleket támogat. Azure Cosmos DB átfogó megbízhatósági funkciókat kínál, beleértve a több konzisztenciaszintet, amelyek lehetővé teszik a teljesítmény és a rendelkezésre állás egyensúlyát, a zónaredundáns üzembe helyezéseket, amelyek védelmet nyújtanak a rendelkezésre állási zónák hibáival szemben, többrégiós replikáció szolgáltatás által felügyelt vagy ügyfél által felügyelt feladatátvétellel, valamint folyamatos és rendszeres biztonsági mentési lehetőségek az adatvédelemhez.

Az Azure használatakor a megbízhatóság közös felelősség. A Microsoft számos lehetőséget kínál a rugalmasság és a helyreállítás támogatására. Ön a felelős azért, hogy megértse, hogyan működnek ezek a képességek az összes használt szolgáltatáson belül, és válassza ki azokat a képességeket, amelyekre szüksége van az üzleti célok és az üzemidő céljainak eléréséhez.

Ez a cikk azt ismerteti, hogyan lehet Azure Cosmos DB rugalmassá tenni a különböző lehetséges kimaradásokkal és problémákkal szemben, beleértve az átmeneti hibákat, a rendelkezésre állási zónák kimaradásait, a régiókimaradásokat és a szolgáltatáskarbantartást. Azt is ismerteti, hogyan használható biztonsági másolatok más típusú problémákra, és kiemeli a Azure Cosmos DB szolgáltatásiszint-szerződéssel (SLA) kapcsolatos legfontosabb információkat.

Termelési üzembe helyezési javaslatok

Az Azure Well-Architected-keretrendszer megbízhatósági, biztonsági, költség-, üzemeltetési és teljesítménybeli javaslatokat kínál. Ha szeretné megtudni, hogy ezek a területek hogyan befolyásolják egymást, és hogyan járulnak hozzá egy megbízható Azure Cosmos DB megoldáshoz, tekintse meg A Azure Cosmos DB ajánlott eljárásait.

A megbízhatósági architektúra áttekintése

Ez a szakasz a szolgáltatás megbízhatóság szempontjából leginkább releváns működésének néhány fontos aspektusát ismerteti. A szakasz bemutatja a logikai architektúrát, amely tartalmazza a telepített és használt erőforrásokat és funkciókat. Emellett a fizikai architektúrát is ismerteti, amely részletesen bemutatja, hogyan működik a szolgáltatás a borítók alatt.

Logikai architektúra

Az üzembe helyezhető elsődleges erőforrás egy Azure Cosmos DB account. Minden fiók több, több tárolóval rendelkező adatbázissal rendelkezhet. A tárolók az elosztás és a méretezhetőség logikai egységei. A Azure Cosmos DB használandó API-tól függően tárolókat, például gyűjteményeket, táblákat és grafikonokat hozhat létre. További információ az erőforrásmodellről: Adatbázisok, tárolók és elemek Azure Cosmos DB. Minden tároló particionálást használ, amely támogatja a nagy léptékű és a nagy teljesítményt.

Konfigurálja az átviteli sebességet, amely az adatok lekérdezéséhez és kezeléséhez használható rendszererőforrások mennyiségét jelöli. Manuálisan kiépítheti az átviteli sebességet, automatikus skálázással dinamikusan módosíthatja a kapacitást a számítási feladat követelményeinek megfelelően, vagy használhatja a kiszolgáló nélküli fióktípust a tényleges használatért.

Egyetlen fiók több Azure régiót ölelhet fel , ami növeli a régiókimaradásokkal szembeni rugalmasságot. Több régiót is konfigurálhat olvasásra, és ha az üzletileg kritikus szintet használja, több régiót is használhat íráshoz. Azure Cosmos DB automatikusan georeplikálja az adatait. A georeplikációs viselkedésre hatással van a használt konfiguráció, például a konzisztenciaszint, amely azt jelzi, hogyan kíván kompromisszumot elérni az adatkonzisztencia, a rendelkezésre állás, a késés és az átviteli sebesség között. A különböző konzisztenciaszintek különböző aggodalmakra optimalizálnak, támogatják a különböző garanciákat, és különböző típusú régiók közötti replikációt biztosítanak.

Fizikai architektúra

Azure Cosmos DB több példányt tárol a redundancia érdekében. A szolgáltatás automatikusan csökkenti a replikakimaradásokat azáltal, hogy kvórumot tart fenn az egyes régiókban található replikák között. Ez a megközelítés garantálja a magas rendelkezésre állást, és védelmet nyújt az adatvesztés ellen az egyes csomóponthibák során anélkül, hogy alkalmazásmódosítást vagy konfigurációt kellene igényelnie.

Belsőleg a Azure Cosmos DB különböző szerkezetekkel kezeli az adatokat, beleértve a fizikai partíciókat, partíciós csoportokat és replicakészleteket. Az Azure Cosmos DB működésével kapcsolatos részletesebb információkért lásd: Globális adateloszlás az Azure Cosmos DB-ben - a részletekben.

Rugalmasság átmeneti hibákhoz

Az átmeneti hibák rövid, időszakos meghibásodások a komponensekben. Gyakran előfordulnak elosztott környezetben, például a felhőben, és ezek a műveletek szokásos részei. Az átmeneti hibák rövid idő elteltével kijavítják magukat. Fontos, hogy az alkalmazások kezelni tudják az átmeneti hibákat, általában az érintett kérések újrapróbálásával.

Minden felhőalapú alkalmazásnak követnie kell az Azure átmeneti hibakezelési útmutatóját, amikor a felhőben üzemeltetett API-kkal, adatbázisokkal és egyéb összetevőkkel kommunikálnak. További információ: Átmeneti hibák kezelésére vonatkozó javaslatok.

Javasoljuk, hogy használja a Azure Cosmos DB SDK-kat. Az SDK-k automatikusan támogatnak számos rugalmassági szempontot, beleértve az automatikus újrapróbálkozásokon keresztüli átmeneti hibakezelést és a szolgáltatás által küldött sebességkorlát-válaszok betartását. További információért lásd: Tervezzen rugalmas alkalmazásokat az Azure Cosmos DB SDK-kkal.

Többrégiós fiók használata esetén az SDK támogatja a küszöbértékalapú rendelkezésre állási stratégiát, más néven fedezeti megoldást is, ahol párhuzamos olvasási kéréseket küld több régiónak, és fogadja el a leggyorsabb választ. Ez a megközelítés javíthatja az alkalmazások teljesítményét, ha egy régió átmenetileg a szokásosnál nagyobb késést tapasztal.

Rugalmasság a rendelkezésre állási zóna hibáival szemben

A rendelkezésre állási zónák fizikailag különálló adatközpont-csoportok egy Azure-régión belül. Ha egy zóna meghibásodik, a szolgáltatások a fennmaradó zónák egyikére is át tudnak adni feladatokat.

Az Azure Cosmos DB támogatja a zónaredundanciát. Ha engedélyezi a zónaredundanciát, az Azure több rendelkezésre állási zónában osztja el az adatok replikáit, így rugalmasságot biztosít az adatközponti problémákhoz és kimaradásokhoz. Microsoft kiválasztja a használni kívánt rendelkezésre állási zónákat.

Diagram, amelyen egy Azure Cosmos DB-fiók látható három replikát tartalmazó replikával, amelyek három különböző rendelkezésre állási zónában vannak elosztva.

A Azure Cosmos DB-fiókok több régiót (helyet) is használhatnak a globális terjesztéshez, skálázáshoz és feladatátvételhez. A zónaredundanciát a fiók minden régiójához külön konfigurálhatja.

A zónaredundancia használata a Azure Cosmos DB nincs észlelhető hatással a teljesítményre vagy a késésre. Nem igényel módosításokat a kiválasztott konzisztencia módhoz, és nem igényel módosítást az alkalmazáskódon.

Javasoljuk, hogy a zónaredundanciát olyan régiókban használja, ahol támogatott, különösen az egyrégiós fiókok esetében. Mivel a rendelkezésre állási zónák fizikailag különállóak, és eltérő energiaforrást, hálózatot és hűtést biztosítanak, az Azure Cosmos DB rendelkezésre állási SLA-jai magasabbak a zónaredundáns fiókok esetében, mint azok a fiókok, amelyek nem használnak rendelkezésre állási zónákat.

Jótanács

A zónaredundancia engedélyezése nagyszerű módja a Azure Cosmos DB-adatbázis rugalmasságának növelésének anélkül, hogy további alkalmazáskomplexitásokat vezet be, vagy hatással van a teljesítményre. A fiók konfigurációjától függően előfordulhat, hogy még további költségekkel sem jár.

Ha nem engedélyezi a zónaredundanciát, a fiók nem zónaalapú ebben a régióban. A nem zónára osztott fiókok replikákat helyezhetnek el egyetlen rendelkezésre állási zónában, ami potenciális leállást okozhat, ha az adott zóna problémákkal szembesül.

Requirements

  • Régió támogatása: Engedélyezheti a zónaredundanciát Azure rendelkezésre állási zónákat támogató régiókban. Annak megtekintéséhez, hogy a régió támogatja-e a rendelkezésre állási zónákat, tekintse meg a támogatott régiók listáját.

    A zónaredundancia nem fiókszintű beállítás. Azure Cosmos DB fiókok több régióra is kiterjedhetnek, és minden régió egymástól függetlenül konfigurálható a rendelkezésre állási zónák használatára. Azok a régiók, amelyek nem támogatják a rendelkezésre állási zónákat, nem akadályozzák meg a zónaredundanciát más, ugyanazon fiókon belüli régiókban.

  • Kiszolgáló nélküli fiókok: A zónaredundáns kiszolgáló nélküli fiókokat csak létrehozásukkor konfigurálhatja. A rendelkezésre állási zónák nélküli meglévő kiszolgáló nélküli fiókok nem alakíthatók át rendelkezésreállási zónakonfigurációvá. Kritikus fontosságú számítási feladatok esetén ajánlott a kiosztott átviteli sebesség használata.

Considerations

  • Több egyidejű zónakimaradás: A zónaredundanciával rendelkező egyrégiós fiókok olvasási-írási rendelkezésre állást tarthatnak fenn, ha egy kimaradás egyetlen rendelkezésre állási zónát érint. Ha azonban a szolgáltatáskimaradás több rendelkezésre állási zónát vagy a teljes régiót érint, az egyrégiós fiókok olvasási és írási hozzáférését elveszítik a szolgáltatás visszaállításáig. Fontolja meg többrégiós fiók üzembe helyezését, ha egyszerre több zóna meghibásodásával szemben is ellenállónak kell lennie.

  • Többrégiós fiókok: Ha többrégiós fiókkal rendelkezik, opcionálisan engedélyezheti a zónaredundanciát a rendelkezésre állási zónákat támogató bármely vagy az összes fiókrégióban. Javasoljuk, hogy engedélyezze a zónaredundanciát, ha a fiókja egyetlen régió használatára van konfigurálva, vagy ha egyetlen írási régió használatára van konfigurálva több olvasási régióval.

Cost

Azokat a régiókat, ahol engedélyezve van a zónaredundancia, prémium díjat számítunk fel. A rendelkezésre állási zónák prémium díjszabása azonban a többrégiós írási móddal konfigurált fiókok, valamint az automatikus skálázási átviteli sebesség használatára konfigurált gyűjtemények esetében nem érvényes. További információ: Azure Cosmos DB díjszabás.

A rendelkezésre állási zóna támogatásának konfigurálása

A legtöbb fiók esetében csak akkor engedélyezi a zónaredundanciát, ha új régiót ad hozzá egy Azure Cosmos DB-fiókhoz. Ha engedélyezni szeretné a rendelkezésre állási zóna támogatását egy meglévő fiókon, adjon hozzá egy régiót, és engedélyezze rajta a zónaredundanciát. Egy folyamatot követve hozzáadhat egy ideiglenes régiót, hogy konfigurálhassa a zónaredundanciát az eredeti régióban. Részletes lépésekért tekintse meg a Zónaredundancia engedélyezése egy Azure Cosmos DB-fiókon.

Kiszolgáló nélküli fiókok esetén engedélyeznie kell a zónaredundanciát a fiók létrehozásakor.

Viselkedés, ha minden zóna kifogástalan

Ez a szakasz azt ismerteti, hogy mire számíthat, ha egy Azure Cosmos DB-fiókot konfigurál a zónaredundanciához, és minden zóna működőképes.

  • Cross-zone művelet: Azure Cosmos DB automatikusan átirányítja a kérelmeket a rendelkezésre állási zónák replikáihoz, hogy bármely replika kiszolgálhassa a kéréseket.

  • Zónaközi adatreplikálás: Amikor egy ügyfél módosítja az adatokat, a rendszer a kvórum elérése érdekében a módosítást több replikára alkalmazza a különböző zónákban. Ezt a megközelítést szinkron replikációnak nevezzük. A szinkron replikáció magas szintű adatkonzisztenciát biztosít, ami csökkenti a zónahiba során bekövetkező adatvesztés valószínűségét. A rendelkezésre állási zónák viszonylag közel vannak egymáshoz, ami azt jelenti, hogy minimális hatással van a késésre vagy az átviteli sebességre.

Viselkedés zónahiba esetén

Ez a szakasz azt ismerteti, hogy mire számíthat, ha egy Azure Cosmos DB-fiókot konfigurál a zónaredundanciához, és az egyik zónában kimaradás történik.

  • Észlelés és válasz: Az Azure Cosmos DB platform felelős a rendelkezésre állási zónában bekövetkező hiba észleléséért. Nem kell semmit tennie a zóna átváltásának kezdeményezéséhez.
  • Értesítés: A Microsoft nem értesíti önt automatikusan, ha egy zóna nem működik. Az Azure Resource Health használatával azonban figyelheti az egyes erőforrások állapotát, és beállíthat Resource Health-riasztásokat a problémákról való értesítéshez. Az Azure Service Health használatával is megismerheti a szolgáltatás általános állapotát, beleértve a zónahibákat is, és beállíthat Service Health-riasztásokat a problémákról való értesítéshez.

  • Aktiválási kérelmek: Amikor egy rendelkezésre állási zóna elérhetetlenné válik, Azure Cosmos DB leállítja az érintett zónában lévő replikákhoz kapcsolódó folyamatban lévő kéréseket, és az alkalmazásnak újra meg kell próbálkoznia a kérésekkel. Az átmeneti hibakezelési útmutatót követve győződjön meg arról, hogy az alkalmazás készen áll.

  • Várható adatvesztés: Zónahiba miatt nem várható adatvesztés.

  • Várható állásidő: A zónakimaradások során a kapcsolatok rövid megszakításokat tapasztalhatnak, amelyek általában néhány másodpercig tartanak a forgalom újraelosztása során. Az átmeneti hibakezelési útmutatót követve győződjön meg arról, hogy az alkalmazások készen állnak.

  • Redistribution: Azure Cosmos DB automatikusan átirányítja a bejövő kéréseket más rendelkezésre állási zónák kifogástalan állapotú replikáira. Ha egy rendelkezésre állási zóna leáll, a platform automatikusan áttelepíti a kiosztott átviteli sebességet más replikákra.

Zóna helyreállítása

A rendelkezésre állási zóna helyreállításakor Azure Cosmos DB automatikusan visszaállítja a replikákat a rendelkezésre állási zónában, és a szokásos módon átirányítja a replikák közötti forgalmat.

Zónahibák tesztelése

Az Azure Cosmos DB rendelkezésre állási zónában történő feladatátvételét és helyreállítását teljes mértékben a Microsoft kezeli. Nem kell kezdeményeznie vagy ellenőriznie a rendelkezésre állási zóna meghibásodási folyamatait.

Rugalmasság régiószintű hibákhoz

Ha egyetlen régióban helyez üzembe Azure Cosmos DB fiókot, az összes Azure Cosmos DB csomópontot érintő régiószintű kimaradás általában nem okoz adatvesztést, de az alkalmazás nem fér hozzá az adatokhoz. Azure Cosmos DB visszaállítja az adathozzáférést, miután a szolgáltatás helyreállt az érintett régióban. Az adatvesztés csak akkor fordul elő, ha a régió helyreállíthatatlan katasztrófát tapasztal.

A régiókimaradások ritka eseteire való felkészüléshez az alábbi módszerek egyikével konfigurálhatja a Azure Cosmos DB a tartósság és a rendelkezésre állás különböző szintjeinek támogatásához:

Az alábbi táblázat a fiókkonfiguráció és a kimaradás típusa alapján összefoglalja a rendelkezésre álló helyreállítási lehetőségeket. A cikk későbbi szakaszai részletesen ismertetik ezeket a lehetőségeket és a kapcsolódó viselkedést.

Configuration Kimaradás típusa Rendelkezésre állási hatás Tartóssági hatás Teendők
Egyrégiós fiók Régió kimaradás Az olvasási és írási hozzáférés elveszik a szolgáltatás visszaállításáig. Nincs adatvesztés, hacsak a régió nem tapasztal helyreállíthatatlan katasztrófát. Várjon a szolgáltatás visszaállítására, vagy kérje a fiók visszaállítását a biztonsági másolatból egy másik régióba.
Egy írási régió, többrégiós fiók Olvasási régió kimaradása Az SDK az előnyben részesített régiók konfigurációja alapján átirányítja az elérhető régiókat.

Ha a fiókok erős konzisztenciát használnak csak két régióval, vagy a korlátos elavultság meghaladja az elavultsági időszakot, az írási rendelkezésre állás is elveszik, hacsak nem offline állapotba viszi az érintett régiót.		 Nincs adatvesztés. Gondoskodjon a megfelelő átviteli sebességről a fennmaradó régiókban. Az erős vagy korlátozott elavultsági konzisztencia érdekében fontolja meg az érintett régió offline állapotba helyezését.
Egy írási régió, többrégiós fiók Írási régió kimaradása (a PPAF engedélyezve van) Automatikus partíciószintű feladatátvétel; nincs szükség manuális beavatkozásra. Ha a fiók erős konzisztenciát használ, nincs adatvesztés. Ha a fiók nem használ erős konzisztenciát, a nem duplikált adatok elveszhetnek abban a valószínűtlen esetben, amikor a régió állandó adatvesztést szenved. Nincs szükség beavatkozásra. A PPAF automatikusan kezeli a feladatátvételt.
Egy írási régió, többrégiós fiók PPAF nélküli írási régiókiesés Az írási rendelkezésre állás elveszik, amíg egy régió offline művelete vagy a szolgáltatás által felügyelt feladatátvétel befejeződik. Olvasási műveletek egészséges régiókból folytatódnak. Ha a fiók erős konzisztenciát használ, nincs adatvesztés. Ha a fiók nem használ erős konzisztenciát, a nem duplikált adatok elveszhetnek abban a valószínűtlen esetben, amikor a régió állandó adatvesztést szenved. Hajts végre egy régió offline műveletet. Ha a szolgáltatás által felügyelt feladatátvétel engedélyezve van, Azure Cosmos DB automatikusan kezdeményezi a feladatátvételt, de ez egy vagy több órát is igénybe vehet. Ne módosítsa az írási régiót a kimaradás során.
Több írási régiós fiók Bármely régió kimaradása Automatikus útválasztás kifogástalan állapotú régiókba SDK-konfiguráción keresztül; nincs szükség manuális beavatkozásra. Előfordulhat, hogy a sikertelen régióban nemrég frissített adatok nem érhetők el a többi régióban. Abban a valószínűtlen esetben, ha a régió állandó adatvesztést szenved, a nem duplikált adatok elveszhetnek. Gondoskodjon a megfelelő átviteli sebességről a fennmaradó régiókban. A helyreállítás után a Azure Cosmos DB a konfigurált ütközésfeloldási módszerrel automatikusan helyreállítja a nem duplikált adatokat.
Bármilyen fiókkonfiguráció Adatsérülés vagy véletlen törlés Nincs hatással a rendelkezésre állásra. Lehetséges adatvesztés attól függően, hogy a rendszer mikor észleli a sérülést vagy a törlést. Időponthoz kötött visszaállítás (folyamatos biztonsági mentés) vagy visszaállítás rendszeres biztonsági mentésből.

Note

Ez a cikk a Azure Cosmos DB többrégiós funkcióinak megbízhatósági szempontjait ismerteti. A több olvasási és írási régiónak más előnyei is vannak, például a globálisan elosztott alkalmazások nagyobb teljesítménye és skálázása. Értékelnie kell a teljes megoldásarchitektúrát, és figyelembe kell vennie ezeknek a képességeknek az előnyeit.

SDK-k és rugalmasság

Az Azure Cosmos DB SDK-k fontos részét képezik az alkalmazás rugalmassági stratégiájának. Ha többrégiós fiókkal rendelkezik, az SDK-konfiguráció hatással van a kérések régiók közötti átirányítására, beleértve a csatlakozni kívánt régiókat és a kizárandó régiókat. Az SDK-k figyelik a régiók és partíciók rendelkezésre állását, és dinamikusan újrakonfigurálhatják magukat, hogy kifogástalan állapotú régiókat és partíciókat használjanak, például a partíciószintű kapcsolatcsoport-megszakítón keresztül.

További információ arról, hogy az SDK hogyan támogatja a magas rendelkezésre állást, tekintse meg a használt SDK magas rendelkezésre állási dokumentációját:

Lehetséges adatvesztés régiókimaradások során

Ha több régióban helyez üzembe Azure Cosmos DB fiókot, az adatok tartóssága a fiók konzisztenciaszintjén múlik. Az alábbi táblázat az összes konzisztenciaszint esetében részletezi egy legalább két régióban üzembe helyezett Azure Cosmos DB fiók helyreállítási pontjának célkitűzését (RPO). Az RPO a régiókimaradás során bekövetkező lehetséges adatvesztést jelöli.

Konzisztenciaszint RPO régiókimaradás esetén
Munkamenet, konzisztens előtag, végleges Kevesebb, mint 15 perc
Korlátozott elavultság K és T
Erős 0

K = Egy elem verzióinak (vagyis frissítéseinek) száma.

T = Az utolsó frissítés óta eltelt időintervallum.

Többrégiós fiókok esetén a K és a T minimális értéke 100 000 írási művelet vagy 300 másodperc. Ez az érték határozza meg az adatok minimális RPO-ját, ha korlátozott elavultságot használ.

A konzisztenciaszintek közötti különbségekről további információt az Azure Cosmos DB konzisztenciaszintjeiben talál.

Több olvasási régió egyetlen írási régióval

Ha a megoldás folyamatos üzemidőt igényel a régiókimaradások során, beállíthatja, hogy Azure Cosmos DB replikálja az adatokat több régióban, az elsődleges régió által kezelt írásokkal. Igény szerint konfigurálhatja az alkalmazásokat úgy, hogy meghatározott olvasási régiókhoz csatlakozzanak, ami segíthet a teljesítmény javításában. Ha egy régió kimaradásban szenved, a fiók továbbra is kifogástalan állapotú régiókból működhet.

Diagram egy Azure Cosmos DB-fiókot jelenít meg. Az A régió egy írási és olvasási régió, a B régió pedig olvasási régió. Az A régióban egy alkalmazás olvasási és írási műveleteket végez az A régió Azure Cosmos DB-fiókján. A B régióban egy alkalmazás olvasást végez a B régióban lévő fiókon, de az A régióba ír. A belső működés során az Azure Cosmos DB replikálja a módosításokat a régiók között.

Régiók közötti feladatátvétel

A Azure Cosmos DB SDK-t az olvasási régiók rangsorolt listájával konfigurálhatja. Az SDK csatlakoztatja az alkalmazást a lista első elérhető régiójához. Az olvasási régió kimaradása során az SDK észleli a régiókimaradást a háttérrendszer válaszkódjaival, elérhetetlenként jelöli meg, és a jövőbeli műveleteket a beállításlistában szereplő következő elérhető régióra irányítja. Győződjön meg arról, hogy az előnyben részesített régiók listája helyesen van beállítva, és megfelel az üzleti és késési követelményeknek. Részletes útmutatásért tekintse meg az Azure Cosmos DB SDK rendelkezésre állásának hibaelhárítását.

A feladatátvétel a fiók egyik régiójának teljes vagy részleges elérhetetlenné tételének folyamata. A feladatátvétel hatása attól függ, hogy a régió-e írási vagy olvasási régió:

  • Ha egy írási régió elérhetetlenné válik, egy másik régió lesz az írási régió.
  • Ha egy olvasási régió elérhetetlenné válik, az a régió nem tudja kiszolgálni az olvasási kérelmeket, és a rendszer más régiókat használ olvasási műveletekhez.

Azure Cosmos DB több feladatátvételi típust biztosít:

  • Partíció-nkénti automatikus átállás (PPAF): Belsőleg, az Azure Cosmos DB elosztja az adatokat több fizikai partícióra. Ha probléma merül fel a partíciót támogató infrastruktúrával kapcsolatban, előfordulhat, hogy más partíciók nem lesznek hatással. A PPAF lehetővé teszi az egy írási régiós fiókok számára, hogy automatikusan átvigyenek egyes partíciókat egy másodlagos régióba, miközben az egészséges partíciókat az elsődleges régióban tartják. A PPAF segíthet minimalizálni az állásidőt, és lehetővé tenni a gyorsabb helyreállítást részleges régióhiba esetén. További információt itt talál: Hogyan használjuk és vezessük be az Azure Cosmos DB Per-Partition automatikus feladatátvételt (PPAF).

    Note

    A partíciónkénti automatikus feladatátvétel nyilvános előzetes verzióban érhető el. Ez a funkció szolgáltatási szintű megállapodás nélkül áll rendelkezésre. További információkért lásd: Microsoft Azure Previews Kiegészítő Felhasználási Feltételek.

  • Kényszerített feladatátvétel: A fiók egyik régióját offline állapotba helyezheti. Ezt ügyfél által felügyelt feladatátvételnek vagy offline régióműveletnek is nevezik. Ez az ajánlott módszer a rendelkezésre állás gyors visszaállításához egy üzemkimaradás során. Ön a felelős a szolgáltatáskimaradás észleléséért és a feladatátvétel indításáért. A kényszerített feladatátvételekkel régióleállási forgatókönyveket is szimulálhat teszteléshez, például vészhelyreállítási próbák során.

    Ha offline állapotba viszi az írási régiót, a következő legmagasabb prioritású olvasási régió lesz az új írási régió. Ha offline állapotba hoz egy olvasási régiót, az alkalmazások a fiók bármely más olvasási régiójához csatlakozhatnak.

    Az írási régió kényszerített feladatátvétele az adatvesztés lehetőségét hordozza magában a nem duplikált írások esetében.

    A kényszerített feladatátvétel után Microsoft újra online állapotba kell hoznia a régiót. Az egészséges régiók esetében ez a folyamat automatizált, de akár több napot is igénybe vehet. Ha a régió egy-két napon belül nem tér vissza az internetre, nyisson meg egy támogatási esetet, amely segítséget kér.

  • Írási régió módosítása: Ha a régiók állapota kifogástalan, módosíthatja a fiók írási régióját. Ez a módosítás gyakorlatilag a fiók írási régiójának tervezett átállása.

    Az írási régió módosítása nem okoz adatvesztést, mivel az adatreplikálás az új írási régió előléptetése előtt felzárkzik. Előfordulhat egy rövid megszakítás, de az újrapróbálkozási logikát és más átmeneti hibakezelési technikákat használó ügyfelek általában nem tapasztalnak jelentős hatást.

    Ehhez a művelethez a régiók kifogástalan állapotúnak kell lenniük, ezért a régiókimaradás során nem használható.

  • Szolgáltatás által felügyelt feladatátvétel: Amikor a fiókja szolgáltatás által felügyelt feladatátvételt használ, Microsoft feladata eldönteni, hogy mikor kell feladatátvételt végrehajtani a régiók között. A szolgáltatás által felügyelt feladatátvétel engedélyezéséhez meg kell adnia az egyes régiók prioritásait. A szolgáltatás által felügyelt feladatátvétel deklarálásának és aktiválásának folyamata azonban jelentős időt vehet igénybe – akár egy órát vagy több órát is igénybe vehet. A gyorsabb helyreállítás érdekében a szolgáltatás által felügyelt feladatátvételre való várakozás helyett hajtsa végre a kényszerített feladatátvételt.

    Ha Microsoft aktiválja a szolgáltatás által felügyelt feladatátvételt a fiók írási régiójában, a nem ismétlődő írások elveszhetnek.

    A szolgáltatás által felügyelt feladatátvétel után Microsoft újra online állapotba kell hoznia egy régiót. Microsoft automatikusan online állapotba helyezi a régiót, de ez a folyamat több napot is igénybe vehet.

Requirements

Region support: Bármely Azure régiót beállíthatja olvasási régióként a Azure Cosmos DB-fiókjához.

Cost

Ha további olvasási régiót ad hozzá egy Azure Cosmos DB-fiókhoz, az növeli az egyes régiók meglévő költségeit. További információ: Azure Cosmos DB díjszabás.

Több olvasási régió konfigurálása

Kapacitástervezés és -kezelés

Ha az alkalmazás régiókra bontja a kérelmeket, és egy régió offline állapotba kerül, a fennmaradó régiók nagyobb kérésmennyiséget tapasztalnak. Az automatikus skálázású átviteli teljesítmény használatával dinamikusan módosíthatja a kapacitást az igények alapján. Ha kiosztott átviteli sebességet használ, tervezze meg a megfelelő kapacitást a szolgáltatáscsökkenés nélküli régió elvesztésének kezeléséhez, és fontolja meg a túlkiépítést. További információ: Kapacitás kezelése túlkiépítéssel.

Viselkedés, ha minden régió kifogástalan

Ez a szakasz azt ismerteti, hogy mire számíthat, ha több olvasási régióval rendelkező Azure Cosmos DB-fiókot konfigurál, és minden régió működőképes.

Viselkedés olvasási régió hibája esetén

Ez a szakasz azt ismerteti, hogy mire számíthat, ha több olvasási régióval konfigurál egy Azure Cosmos DB fiókot, és a fiók egyik olvasási régiójában kimaradás történik.

Important

Ideális esetben az olvasási régiók kimaradásait az ügyfél szintjén kell kezelni az SDK-konfiguráció előnyben részesített régiók listájának helyes konfigurálásával. Ha megfelelően van konfigurálva, az SDK automatikusan észleli a leállást, és a szolgáltatásoldali feladatátvétel nélkül átirányítja az olvasási műveleteket a következő elérhető régióba.

  • Észlelés és válasz: A kimaradás észlelésének és a válaszadásnak a felelőssége a fiók által használt feladatátvétel típusától függ.

    • PPAF: A PPAF általában nem vonatkozik az olvasási régiók kimaradásaira. Az erős konzisztenciájú és csak két régióval rendelkező fiókok esetében azonban az olvasási régió elvesztése egyetlen régióra csökkenti a fiókot, amely nem tudja fenntartani a dinamikus kvórumot. Ebben a forgatókönyvben a PPAF aktiválhat a rendelkezésre állás megőrzése érdekében az érintett partíciók kifogástalan állapotú régióba való áthelyezésével.

    • Kényszerített feladatátvétel: Ön a felelős a kényszerített feladatátvétel végrehajtásáért. Részletes lépéseket az Azure Cosmos DB-fiók kényszerített átállása című témakörben talál.

      \nHa nem hajt végre áállást, a fiók viselkedése a konzisztencia szintjétől függ:

      • Erős konzisztencia: Az erős konzisztencia két vagy több régiót igényel a dinamikus kvórum fenntartásához. Ha a rendelkezésre álló régiók száma kevesebb, mint kettő, és nem hajt végre feladatátvételt, a fiók elveszíti az írási rendelkezésre állást a szolgáltatás visszaállításáig.

      • Korlátozott elavultsági konzisztencia: A határolt elavultsági konzisztencia egy adott elavultsági küszöbérték fenntartásán alapul a régiók között. Ha a régiókimaradás hossza meghaladja a küszöbértéket, a rendszer nem tudja fenntartani az írások közötti konzisztenciát. Ha nem hajt végre átállást, a fiók a szolgáltatás visszaállításáig elveszíti az írási elérhetőséget.

    • Szolgáltatás által felügyelt feladatátvétel: Ha a szolgáltatás által felügyelt feladatátvétel engedélyezve van, Microsoft végül észleli a leállást, és kezdeményezi a fiók feladatátvételét. Ez a folyamat azonban jelentős időt vehet igénybe, akár egy órát vagy többet is. A gyorsabb helyreállítás érdekében a szolgáltatás által felügyelt feladatátvételre való várakozás helyett hajtsa végre a kényszerített feladatátvételt.

  • Aktív kérések: Előfordulhat, hogy az aktív kérések leállnak, és az ügyfélnek újra kell próbálkoznia a feladatátvétel befejezése után. Ha az ügyfelek rövid idő elteltével újrapróbálkozással megfelelően kezelik az átmeneti hibákat , általában elkerülik a jelentős hatást.

  • Várható adatvesztés: Az olvasási régió kimaradása nem okoz adatvesztést. Azure Cosmos DB továbbra is betartja az olvasási konzisztencia garanciáit.

  • Várható állásidő: A fiók által tapasztalt állásidő mértéke a fiók által használt feladatátvétel típusától függ.

    • PPAF: Ha a PPAF engedélyezve van, a rendszer automatikusan észleli és helyreállítja a hibát, jellemzően 3 percen belül, manuális beavatkozás nélkül.

    • Kényszerített átállás: Az állásidő a következőktől függ:

      • Mennyi ideig tart felderíteni a leállást, és kezdeményezni a feladatátvételt.

      • Mennyi ideig tart az átváltás, ez általában néhány másodperc.

        Figyelmeztetés

        A kimaradási forgatókönyvek során ne végezzen konfigurációs (vezérlősík) műveleteket az érintett régión, mert ezek a fiók inkonzisztencia és a helyreállítás késleltetését eredményezik. Néhány példa a vezérlősík-műveletekre, amelyeket el kell kerülni:

        • Írási régió módosítása vagy feladatátvételi prioritás módosítása
        • A fiók konfigurációjának frissítése többírásos beállításra
        • Konzisztenciaszintek vagy más fiókbeállítások frissítése
        • Privát végpont konfigurációinak vagy hálózati beállításainak frissítése
        • Fiók átviteli sebességének vagy skálázási műveleteinek frissítése
        • Bármely más művelet, amely módosítja a fiók konfigurációját vagy a régió beállításait

    • Szolgáltatás által felügyelt feladatátvétel: A szolgáltatás által felügyelt feladatátvétel kezdeményezéséért a Microsoft felelős, és a fiókja által tapasztalt állásidő attól függ, hogy mennyi időt vesz igénybe, míg a Microsoft deklarálja a kimaradást és kezdeményezi a feladatátvételt. Bizonyos helyzetekben egy vagy több órát is igénybe vehet. Ha a fiókjában írási zavarok lépnek fel, és gyorsan vissza kell állítania az írási rendelkezésre állást, hajtson végre kényszerített átállást.

  • Újraelosztás: Kényszerített feladatátvétel vagy szolgáltatás által felügyelt feladatátvétel esetén az érintett régió le van választva, és offlineként van megjelölve.

    Az olvasási régiók kimaradásainak kezeléséhez nincs szükség módosításra az alkalmazáskódban. A Azure Cosmos DB SDK-k átirányítják az olvasási műveleteket a következő elérhető régióba az előnyben részesített régiólistában. Ha az előnyben részesített régiólistában egyik régió sem érhető el, az olvasási műveletek automatikusan visszaesnek a fiók aktuális írási régiójába a szolgáltatásban konfigurált módon.

    Note

    Ha privát végpontokat használ egy Azure Cosmos DB-fiókkal, győződjön meg arról, hogy a privát DNS megfelelően működik útválasztva az offline régió művelete után. Részletes útmutatásért tekintse meg a privát végpontok feladatátvételi szempontjait.

Viselkedés írási régió hibája esetén

Ez a szakasz azt ismerteti, hogy mire számíthat, ha több olvasási régióval konfigurál egy Azure Cosmos DB fiókot, és kimaradás van a fiók írási régiójában.

  • Észlelés és válasz: A kimaradás észlelésének és a válaszadásnak a felelőssége a fiók által használt feladatátvétel típusától függ.

    • PPAF: Microsoft automatikusan észleli a leállást, és szükség esetén kezdeményezi egyes partíciók feladatátvételét. Az alkalmazásnak nem kell semmilyen műveletet elvégeznie.

    • Kényszerített feladatátvétel: Ön a felelős a kényszerített feladatátvétel végrehajtásáért. A részletes lépéseket lásd az Azure Cosmos DB-fiókjának kényszerített feladatátvételének végrehajtása című témakörben.

      Ha nem hajt végre áltállást, a fiók elveszíti írási lehetőségét a szolgáltatás visszaállításáig.

      Ha kimaradás van a fiók írási régiójában, kerülje el a írási régió módosításának műveletét. Az írási régió módosításai nem sikeresek, ha a forrás- vagy célrégió kimaradásban van. Ennek az az oka, hogy a régióváltoztatási eljárás tartalmaz egy konzisztencia-ellenőrzést, amely megköveteli a régiók közötti kapcsolatot.

    • Szolgáltatás által felügyelt feladatátvétel: Microsoft automatikusan észleli a leállást, és kezdeményezi a fiók feladatátvételét. Az alkalmazásnak nem kell semmilyen műveletet elvégeznie.

  • Aktív kérések: Előfordulhat, hogy az aktív kérések leállnak, és az ügyfélnek újra kell próbálkoznia a feladatátvétel befejezése után. Ha az ügyfelek rövid idő elteltével újrapróbálkozással megfelelően kezelik az átmeneti hibákat , általában elkerülik a jelentős hatást.

  • Várható adatvesztés: Ha erős konzisztenciával konfigurálja a fiókját, nem történik adatvesztés. Ellenkező esetben előfordulhat, hogy a feladatátvétel befejeződése után a nem replikált írások elvesznek. A régiókimaradás során várható maximális adatvesztésről további információt a régiókimaradások során bekövetkező lehetséges adatvesztéssel kapcsolatban talál.

  • Várható állásidő: A fiók által tapasztalt állásidő mértéke a fiók által használt feladatátvétel típusától függ.

    • PPAF: Ha a PPAF engedélyezve van, rövid megszakításra számíthat, amely általában 3 perc körül van.

    • Kényszerített átállás: Az állásidő a következőktől függ:

      • Mennyi ideig tart felderíteni a leállást, és kezdeményezni a feladatátvételt.
      • Mennyi ideig tart az átváltás, ez általában néhány másodperc.

    Figyelmeztetés

    A kimaradási forgatókönyvek során ne végezzen vezérlősík-műveleteket az érintett régión, mert ezek fiók inkonzisztenciát és a helyreállítás késleltetését eredményezik. Néhány példa a vezérlősík-műveletekre, amelyeket el kell kerülni:

    • Írási régió módosítása vagy feladatátvételi prioritás módosítása
    • A fiók konfigurációjának frissítése többírásos beállításra
    • Konzisztenciaszintek vagy más fiókbeállítások frissítése
    • Privát végpont konfigurációinak vagy hálózati beállításainak frissítése
    • Fiók átviteli sebességének vagy skálázási műveleteinek frissítése
    • Bármely más művelet, amely módosítja a fiók konfigurációját vagy a régió beállításait
    • Szolgáltatás által felügyelt feladatátvétel: A szolgáltatás által felügyelt feladatátvétel kezdeményezéséért a Microsoft felelős, és a fiókja által tapasztalt állásidő attól függ, hogy mennyi időt vesz igénybe, míg a Microsoft deklarálja a kimaradást és kezdeményezi a feladatátvételt. Bizonyos helyzetekben egy vagy több órát is igénybe vehet. Az írási rendelkezésre állás gyors visszaállításához hajtsa végre a kényszerített átkapcsolást.

  • Újraelosztás: Az írási forgalom újraelosztása a fiók által használt feladatátvétel típusától függ.

    • PPAF: A Azure Cosmos DB automatikusan átváltja a hibás partíciót egy egészséges régióba.

    • Kényszerített feladatátvétel: Kényszerített feladatátvétel végrehajtásakor a fiók írási régiója a megadott régióra változik.

    Note

    Ha privát végpontokat használ egy Azure Cosmos DB-fiókkal, győződjön meg arról, hogy a privát DNS megfelelően működik útválasztva az offline régió művelete után. Részletes útmutatásért tekintse meg a privát végpontok feladatátvételi szempontjait.

    • Szolgáltatás által felügyelt feladatátvétel: Azure Cosmos DB automatikusan előlépteti a fiók egyik másodlagos régióját az új elsődleges írási régióként. A feladatátvétel egy másik régióba történik a megadott régió prioritásának sorrendjében.

Régió helyreállítása

Microsoft egy régiót újra online állapotba kell hoznia. Ha egy régió leállást követően helyreáll, Microsoft automatikusan online állapotba helyezi a régiót. Ez a folyamat azonban több napot is igénybe vehet.

Important

A kényszerített feladatátvétel után Microsoft automatikusan újra online állapotba helyezi a régiót az egészséges régiók érdekében. Ha a régió egy-két napon belül nem tér vissza az internetre, nyisson meg egy támogatási esetet, amely segítséget kér.

A régió online állapotba helyezése után a végrehajtott műveletek eltérnek attól függően, hogy a kimaradás olvasási vagy írási régióban történt-e.

  • Olvasási régió leállása után: Amikor az érintett régió ismét online állapotban van, szinkronizálódik az aktuális írási régióval, és újra elérhető az olvasási kérelmek kiszolgálásához, miután teljesen felzárkózott. A további olvasásokat a szolgáltatás a helyreállt régiókhoz irányítja át anélkül, hogy módosítania kellene az alkalmazáskódot. A feladatátvétel és a korábban meghiúsult régiók újbóli csatlakoztatása során az Azure Cosmos DB továbbra is betartja az olvasási konzisztencia garanciáit.

  • Az írási régiók kimaradásait követően: Amikor az érintett régió újra online állapotban van, a régió "online" állapotúként jelenik meg az Azure portálon, és olvasható régióként válik elérhetővé. Ezen a ponton biztonságosan visszaállíthatja az írási régiót a helyreállított régióra.

    Important

    A helyreállított régiót a rendszer nem lépteti elő automatikusan az írási régióként a helyreállítás után. Az Ön felelőssége, hogy visszaváltson a helyreállított régióra írási régióként, ha ezt biztonságosan megteheti.

    Az írási régió módosítása előtt, közben vagy után nincs adat- vagy rendelkezésre állási veszteség . Az alkalmazás továbbra is magas rendelkezésre állású.

    Ha a régió offline állapotba helyezése előtt nem replikáltak írásokat, az ütközési hírcsatornából elolvashatja a nem duplikált írásokat. Az alkalmazás beolvassa az ütközési hírcsatornát, feloldhatja az alkalmazásspecifikus logikán alapuló ütközéseket, és szükség szerint visszaírhatja a frissített adatokat a tárolóba.

Régióhibák tesztelése

Előfordulhat, hogy az alkalmazás nem kezeli megfelelően a régió feladatátvételeit, még akkor sem, ha Azure Cosmos DB fiókja magas rendelkezésre állású. Az alkalmazás teljes végpontok közötti magas rendelkezésre állásának teszteléséhez, legyen szó akár alkalmazás tesztelésről, akár vészhelyreállítási (DR) gyakorlatról, ideiglenesen tiltsa le a szolgáltatás által felügyelt feladatátvételt a fiókjánál. Meghívhatja a kényszerített átállást a PowerShell, az Azure CLI vagy az Azure portál használatával, majd felügyelje az alkalmazást. A teszt elvégzése után visszaállíthatja a feladatátvételt az elsődleges régióba, amint a régió automatikusan újra elérhetővé válik, majd visszaállíthatja a szolgáltatás által felügyelt feladatátvételt a fiók esetén. Ha a régió egy-két napon belül nem tér vissza az internetre, nyisson meg egy támogatási esetet, amely segítséget kér.

Ha a fiókja PPAF-t használ, szimulálhatja a partíció meghibásodását. További információ: PPAF-beállítás tesztelése (hiba szimulálása).

Több írási régió

Az Azure Cosmos DB-t úgy konfigurálhatja, hogy több régióban is fogadjon írásokat. Ez a konfiguráció nagyon nagy rugalmasságot biztosít a régiókimaradásokkal szemben. A földrajzilag elosztott alkalmazások írási késésének csökkentéséhez is hasznos.

Diagram egy Azure Cosmos DB-fiókot jelenít meg. Az A régió és a B régió egyaránt írási és olvasási régiók. Az A régióban egy alkalmazás olvasási és írási műveleteket végez az A régió Azure Cosmos DB fiókján. A B régióban egy alkalmazás olvasási és írási műveleteket végez a B régió Azure Cosmos DB fiókján. Az Azure Cosmos DB belsőleg aszinkron módon replikálja a változásokat a régiók között.

Ha több írási régióhoz konfigurál egy Azure Cosmos DB-fiókot, az erős konzisztencia nem támogatott, és írási ütközések léphetnek fel. A központi régió írási ütközésekben arbiterként működik. További információ az ütközések megoldásáról: Ütközéstípusok és feloldási szabályzatok több írási régió használatakor.

Fontos figyelembe venni az alkalmazás kialakítását és működését több írási régióval. Tekintse át a többrégiós írási műveletek legjobb gyakorlatait.

Requirements

Region support: Bármely Azure régiót beállíthatja olvasási vagy írási régióként a Azure Cosmos DB-fiókjához.

Cost

Ha további írási régiót ad hozzá egy Azure Cosmos DB-fiókhoz, az növeli az egyes régiók meglévő költségeit. További információ: Azure Cosmos DB díjszabás.

Több írási régió konfigurálása

A fiók létrehozásakor vagy a fiók létrehozása után bármikor konfigurálhat több írási régiót a fiókjában. További információ: Több írási régió konfigurálása.

Több írási régió hatékony használatához az alkalmazást is megfelelően kell konfigurálni. Lásd: A több régiót érintő írások konfigurálása az Azure Cosmos DB-t használó alkalmazásokban.

Kapacitástervezés és -kezelés

Ha az alkalmazás régiókra bontja a kérelmeket, és egy régió offline állapotba kerül, a fennmaradó régiók nagyobb kérésmennyiséget tapasztalnak. Az automatikus skálázású átviteli teljesítmény használatával dinamikusan módosíthatja a kapacitást az igények alapján. Ha kiosztott átviteli sebességet használ, tervezze meg a megfelelő kapacitást a szolgáltatáscsökkenés nélküli régió elvesztésének kezeléséhez, és fontolja meg a túlkiépítést. További információ: Kapacitás kezelése túlkiépítéssel.

Viselkedés, ha minden régió kifogástalan

Ez a szakasz azt ismerteti, hogy mire számíthat, ha több írási régióval rendelkező Azure Cosmos DB-fiókot konfigurál, és minden régió működőképes.

Viselkedés régióhiba esetén

Ez a szakasz azt ismerteti, hogy mire számíthat, ha egy Azure Cosmos DB-fiókot több írási régióval konfigurál, és a fiók egyik olvasási vagy írási régiójában kimaradás történik.

  • Észlelés és válasz: Az alkalmazás észleli a régió elvesztését. Azure Cosmos DB SDK-k automatikus régióválasztási képességeket biztosítanak, amelyek az olvasási és írási műveleteket kifogástalan állapotú régiókba irányítják.

  • Aktív kérések: Előfordulhat, hogy az aktív kérések leállnak, és az ügyfélnek újra kell próbálkoznia a feladatátvétel befejezése után. Ha az ügyfelek rövid idő elteltével újrapróbálkozással megfelelően kezelik az átmeneti hibákat , általában elkerülik a jelentős hatást.

  • Várható adatvesztés: Előfordulhat, hogy a legutóbb frissített adatok más régiókban nem lesznek elérhetők. A régiókimaradás során várható maximális adatvesztésről további információt a régiókimaradások során bekövetkező lehetséges adatvesztéssel kapcsolatban talál. Abban a valószínűtlen esetben, ha az érintett régió állandó adatvesztést szenved, előfordulhat, hogy a nem duplikált adatok elvesznek.

  • Várható állásidő: A több írási konfigurációban nem várható állásidő, feltéve, hogy az SDK-k megfelelően vannak konfigurálva ApplicationRegions vagy PreferredRegions.

    Jótanács

    A legjobb eredmény érdekében a globálisan elosztott alkalmazásokat globális terheléselosztási szolgáltatásnak kell előtérbe helyeznie, például Azure Front Door vagy Azure Traffic Manager. Ezek a szolgáltatások észlelik a regionális romlást, és automatikusan átirányítják a forgalmat egy kifogástalan állapotú régió alkalmazáspéldányaihoz.

  • Redistribution: A Azure Cosmos DB SDK-k automatikusan észlelik, hogy a régió nem megfelelő, és átirányítja az olvasási és írási műveleteket a következő elérhető régióra az előnyben részesített régiólistában. Az alkalmazáskódban nincs szükség módosításokra.

    Jótanács

    Ha az alkalmazást Azure Front Door vagy Traffic Manager irányítja, akkor ezek a szolgáltatások regionális romlást is észlelnek, és a forgalmat egy kifogástalan állapotú régióba irányítják.

Régió helyreállítása

Ha az érintett régió ismét online állapotban van, a régió "online" állapotúként jelenik meg a Azure portálon, és újra elérhetővé válik.

Az kollíziós adatfolyamon keresztül elérhetővé válik minden olyan írási adat, amelyet nem replikáltak, amikor a régió meghibásodott. Az alkalmazások beolvashatják az ütközési hírcsatornát, feloldhatják az ütközéseket az alkalmazásspecifikus logika alapján, és szükség szerint visszaírhatják a frissített adatokat az Azure Cosmos DB-tárolóba.

Régióhibák tesztelése

A többrégiós írásátállási forgatókönyvek teszteléséhez offline állapotba helyezhet egy írási régiót egy kényszerített átváltás használatával. Ez a folyamat egy régiókimaradást szimulál, és megfigyelheti, hogyan reagál az alkalmazás.

Biztonsági mentés és visszaállítás

A legtöbb megoldás esetében nem szabad kizárólag biztonsági másolatokra támaszkodnia. Ehelyett használja az útmutatóban ismertetett egyéb képességeket a rugalmassági követelmények támogatására. A biztonsági másolatok azonban védelmet nyújtanak bizonyos kockázatok ellen, amelyeket más megközelítések nem. További információ: Mi a redundancia, a replikáció és a biztonsági mentés?

Adatvesztés történhet véletlen törlés vagy az alkalmazás egyéb olyan problémái miatt, amelyek adatsérülést okoznak. Ha egyrégiós fiókot használ, adatvesztés is előfordulhat a Azure Cosmos DB régióban helyreállíthatatlan katasztrófa miatt. Az adatvesztés elleni védelem érdekében Azure Cosmos DB biztonsági mentési és visszaállítási képességeket biztosít. A biztonsági mentéseket és a megőrzést a helyreállíthatósági követelmények és a költségkövetelmények alapján konfigurálhatja. További információ: Online biztonsági mentés és igény szerinti adat-visszaállítás az Azure Cosmos DB-ben.

A szolgáltatás karbantartásával szembeni rugalmasság

Azure Cosmos DB transzparensen kezeli az egyes számítási csomópontok összes részletét, és automatikusan elvégzi a javításokat és a tervezett karbantartás egyéb típusait. A rendelkezésre állásra és késésre vonatkozó Azure Cosmos DB SLA-k a rendszer által végrehajtott összes automatikus karbantartási műveletre vonatkoznak.

Szolgáltatásiszint-szerződés

Az Azure-szolgáltatások szolgáltatásiszint-szerződése (SLA) leírja az egyes szolgáltatások várható elérhetőségét, valamint azokat a feltételeket, amelyeket a megoldásnak teljesítenie kell a rendelkezésre állási elvárás eléréséhez. További információ: SLA-k az online szolgáltatásokhoz.

Azure Cosmos DB számos konfigurációhoz és szolgáltatástulajdonsághoz biztosít SLA-kat, beleértve a rendelkezésre állást, a késést, az átviteli sebességet és a konzisztenciát.

A rendelkezésre állási SLA-k eltérőek attól függően, hogy az alábbi termékfunkciók bármelyikét használja-e:

  • Kiosztott átviteli sebesség
  • Egyrégiós fiók rendelkezésre állási zóna támogatásával (zónaredundancia)
  • Több olvasási régiót használó fiókok
  • Több írási régiót használó fiókok (üzletileg kritikus szint)

Kapcsolódó tartalom

  • Last updated on