Magas rendelkezésre állás (megbízhatóság) az Azure Cosmos DB for NoSQL-ben
Ez a cikk az Azure CosmosDB for NoSQL magas rendelkezésre állási (megbízhatósági) támogatását ismerteti, és a rendelkezésre állási zónákat, valamint a régiók közötti vészhelyreállítást és az üzletmenet folytonosságát is ismerteti.
Az Azure Cosmos DB for NoSQL-hez készült általános rugalmassági javaslatokért tekintse meg az Azure Cosmos DB for NoSQL rugalmassági ajánlásait.
Rendelkezésre állási zóna támogatása
Az Azure rendelkezésre állási zónái legalább három fizikailag különálló adatközpont-csoport az egyes Azure-régiókban. Az egyes zónákban lévő adatközpontok független energiaellátási, hűtési és hálózati infrastruktúrával rendelkeznek. Helyi zónahiba esetén a rendelkezésre állási zónák úgy vannak kialakítva, hogy az egy zóna érintettsége esetén a fennmaradó két zóna támogassa a regionális szolgáltatásokat, a kapacitást és a magas rendelkezésre állást.
A hibák a szoftver- és hardverhibáktól az olyan eseményekig terjedhetnek, mint a földrengések, árvizek és tűzesetek. A hibáktól való tolerancia az Azure-szolgáltatások redundanciával és logikai elkülönítésével érhető el. Az Azure-beli rendelkezésre állási zónákkal kapcsolatos részletesebb információkért tekintse meg a Régiók és a rendelkezésre állási zónák című témakört.
Az Azure rendelkezésre állási zónákkal kompatibilis szolgáltatások a megfelelő megbízhatósági és rugalmassági szintet biztosítják. Ezek kétféleképpen konfigurálhatók. Ezek lehetnek zónaredundánsak, a zónák közötti automatikus replikációval vagy a zónák közötti automatikus replikációval, egy adott zónába rögzített példányokkal. Ezeket a megközelítéseket kombinálhatja is. A zónaredundáns és a zónaredundáns architektúrával kapcsolatos további információkért tekintse meg a rendelkezésre állási zónák és régiók Javaslatok.
Az Azure Cosmos DB egy több-bérlős szolgáltatás, amely transzparens módon kezeli az egyes számítási csomópontok minden részletét. Nem kell aggódnia semmilyen javítás vagy tervezett karbantartás miatt. Az Azure Cosmos DB a rendszer által végrehajtott összes automatikus karbantartási művelettel garantálja a rendelkezésre állási és P99-késési SLA-kat.
Azure Cosmos DB-ajánlatok:
Az egyes csomópontkimaradások rugalmassága. Az Azure Cosmos DB automatikusan csökkenti a replikakimaradásokat azáltal, hogy legalább három replikát biztosít az adatokból az egyes Azure-régiókban a fiókhoz egy négy replika kvórumán belül. Ez a garancia 0 RTO-t és 0-s RPO-t eredményez az egyes csomópontkimaradások esetén, alkalmazásmódosítások vagy konfigurációk megkövetelése nélkül.
Zónakimaradás rugalmassága. Ha rendelkezésre állási zónák használatával helyez üzembe egy Azure Cosmos DB-fiókot, az Azure Cosmos DB 0-ás RTO-t és 0-s RPO-t biztosít, még zónakimaradás esetén is. Az RTO-ról további információt a helyreállítási célkitűzésekben talál.
Ha engedélyezve vannak a rendelkezésre állási zónák, az Azure Cosmos DB for NoSQL támogatja a zónaredundáns konfigurációt.
Előfeltételek
A replikákat olyan Azure-régióban kell üzembe helyezni, amely támogatja a rendelkezésre állási zónákat. 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.
Annak meghatározása, hogy a rendelkezésre állási zónák elegendő értéket adnak-e az aktuális konfigurációhoz a rendelkezésre állási zónák használatának hatásában.
A rendelkezésre állási zónák használatának hatása
A rendelkezésre állási zónák a Cosmos DB for NoSQL-adatbázis magas rendelkezésre állására gyakorolt hatása a fiók konzisztenciaszintjétől és attól függ, hogy mely régiókban engedélyezve vannak a rendelkezésre állási zónák. A rendelkezésre állási zónák sok esetben nem adnak hozzá értéket, és nem adnak hozzá minimális értéket, ha a fiók többrégiós (kivéve, ha erős konzisztenciával van konfigurálva).
A rendelkezésre állási zónák aktuális fiókkonfigurációban való használatának hatásának becsléséhez tekintse meg az alábbi táblázatot:
| Fiókkonzisztencia szintje | A rendelkezésre állási zónákkal rendelkező régiók engedélyezve | A rendelkezésre állási zónák használatának hatása |
|---|---|---|
| Aszinkron (korlátozott elavultság vagy gyengébb) | Tetszőleges számú másodlagos olvasási régió. | Minimális értéket biztosít, mert az SDK már zökkenőmentes átirányításokat biztosít az olvasásokhoz, ha egy olvasási régió meghibásodik. |
| Szinkron (erős) | Két vagy több másodlagos olvasási régió | Marginális értéket biztosít, mert a rendszer dinamikus kvórumot használhat, ha egy olvasási régió elveszíti a rendelkezésre állást, ami lehetővé teszi az írások folytatását. |
| Szinkron (erős) | Egy másodlagos olvasási régió | Nagyobb értéket biztosít, mert az olvasási régió elvesztése ebben a forgatókönyvben hatással lehet az írási rendelkezésre állásra. |
| Mind | Írási régiók és tetszőleges számú másodlagos régió | Nagyobb rendelkezésre állást biztosít az írási műveletekhez a zonális hibák esetén. |
| Mind | Egyetlen régió | Az egyetlen régió nem használhatja ki a többrégiós feladatátvételi képességet. A rendelkezésre állási zónák használata védi a teljes rendelkezésre állási veszteséget a zónahiba miatt. |
SLA-fejlesztések
Mivel a rendelkezésre állási zónák fizikailag különállóak, és eltérő áramforrást, hálózatot és hűtést biztosítanak, a rendelkezésre állási SLA-k (szolgáltatásiszint-szerződések) magasabbak (99,995%), mint az egyetlen régióval rendelkező fiókok (99,99%). Azok a régiók, ahol a rendelkezésre állási zónák engedélyezve vannak, 25%-os prémium díjat számítunk fel, míg azok, amelyek nem rendelkezik rendelkezésre állási zónákkal, nem járnak a prémium összeggel. Emellett a rendelkezésre állási zónák prémium díjszabása a többrégiós írási móddal konfigurált fiókok és/vagy az automatikus skálázási móddal konfigurált gyűjtemények esetében is el lesz mondva.
Ha további régiót ad hozzá a Cosmos DB-fiókhoz, az általában 100%-kal növeli a meglévő számlát (additívan nem szorzósan), bár a régiók költségének kisebb változatai léteznek. További részletekért tekintse meg a díjszabási oldalt.
Az AZ-k engedélyezése, További régió(ok) hozzáadása vagy többrégiós írás bekapcsolása többrégiós írási módszernek tekinthető, amely minden lépésnél növeli egy adott Cosmos DB-fiók rugalmasságát és rendelkezésre állását – a 4 9-es rendelkezésre állástól az egyrégiós nem AZ konfigurációig, a 4 és a fél 9-esig az AZ-ekkel rendelkező egyetlen régióhoz, egészen a többrégiós konfiguráció 5 9-es rendelkezésre állásához a többrégiós írási lehetőség engedélyezésével. Az egyes konfigurációk SLA-jainak összegzéséhez tekintse meg az alábbi táblázatot.
| KPI | Egyrégiós írások rendelkezésre állási zónák nélkül | Egyrégiós írások rendelkezésre állási zónákkal | Többrégiós, egyrégiós írások rendelkezésre állási zónák nélkül | Többrégiós, egyrégiós írások rendelkezésre állási zónákkal | Többrégiós, többrégiós írás rendelkezésre állási zónákkal vagy anélkül |
|---|---|---|---|---|---|
| Rendelkezésre állási SLA írása | 99,99% | 99.995% | 99,99% | 99.995% | 99,999% |
| Rendelkezésre állási SLA olvasása | 99,99% | 99.995% | 99,999% | 99,999% | 99,999% |
| Zónahibák: adatvesztés | Adatvesztés | Nincs adatvesztés | Nincs adatvesztés | Nincs adatvesztés | Nincs adatvesztés |
| Zónahibák: rendelkezésre állás | Rendelkezésre állási veszteség | Nincs rendelkezésre állási veszteség | Nincs rendelkezésre állási veszteség | Nincs rendelkezésre állási veszteség | Nincs rendelkezésre állási veszteség |
| Regionális kimaradás: adatvesztés | Adatvesztés | Adatvesztés | Konzisztenciaszinttől függ. További információ: Konzisztencia, rendelkezésre állás és teljesítménybeli kompromisszumok. | Konzisztenciaszinttől függ. További információ: Konzisztencia, rendelkezésre állás és teljesítménybeli kompromisszumok. | Konzisztenciaszinttől függ. További információ: Konzisztencia, rendelkezésre állás és teljesítménybeli kompromisszumok. |
| Regionális kimaradás: rendelkezésre állás | Rendelkezésre állási veszteség | Rendelkezésre állási veszteség | Nincs rendelkezésre állási veszteség az olvasási régió meghibásodása esetén, ideiglenes írási régióhiba esetén | Nincs rendelkezésre állási veszteség az olvasási régió meghibásodása esetén, ideiglenes írási régióhiba esetén | Nincs olvasási rendelkezésre állási veszteség, ideiglenes írási rendelkezésre állási veszteség az érintett régióban |
| Ár (1) | Nem alkalmazható | Kiosztott RU/s x 1,25-ös sebesség | Kiépített RU/s x N régió | Kiosztott RU/s x 1,25 sebesség x N régió (2) | Többrégiós írási sebesség x N régió |
1 Kiszolgáló nélküli fiókok esetén a kérelemegységek szorzata 1,25.
2 Az 1,25-ös díj csak azokra a régiókra vonatkozik, ahol engedélyezi a rendelkezésre állási zónákat.
Erőforrás létrehozása engedélyezett rendelkezésre állási zónákkal
A rendelkezésre állási zónákat csak akkor konfigurálhatja, ha új régiót ad hozzá egy Azure Cosmos DB NoSQL-fiókhoz.
A rendelkezésre állási zónák támogatásának engedélyezéséhez használhatja a következőt:
Migrálás a rendelkezésre állási zónák támogatására
A Cosmos DB-fiók rendelkezésre állási zóna támogatásba való migrálásáról az Azure Cosmos DB for NoSQL migrálása a rendelkezésre állási zónák támogatására című témakörben olvashat.
Régiók közötti vészhelyreállítás és üzletmenet-folytonosság
A vészhelyreállítás (DR) a nagy hatású események, például a természeti katasztrófák vagy az állásidőt és adatvesztést eredményező sikertelen üzemelő példányok helyreállításáról szól. A katasztrófa okától függetlenül a legjobb megoldás egy jól definiált és tesztelt DR-terv, valamint egy olyan alkalmazásterv, amely aktívan támogatja a DR-t. Mielőtt elkezdene gondolkodni a vészhelyreállítási terv létrehozásáról, tekintse meg a Javaslatok a vészhelyreállítási stratégia megtervezéséhez.
A DR-ről a Microsoft a megosztott felelősségi modellt használja. Egy megosztott felelősségi modellben a Microsoft biztosítja, hogy az alapinfrastruktúra és a platformszolgáltatások elérhetők legyenek. Ugyanakkor számos Azure-szolgáltatás nem replikálja automatikusan az adatokat, vagy egy meghibásodott régióból visszaesik egy másik engedélyezett régióba történő keresztreplikáláshoz. Ezekért a szolgáltatásokért Ön felel a számítási feladathoz használható vészhelyreállítási terv beállításáért. Az Azure-platformon szolgáltatásként (PaaS) futó szolgáltatások többsége funkciókkal és útmutatással támogatja a DR-t, és szolgáltatásspecifikus funkciókkal támogatja a gyors helyreállítást a dr. csomag fejlesztéséhez.
A régiókimaradások olyan kimaradások, amelyek egy Azure-régió összes Azure Cosmos DB-csomópontja érintett az összes rendelkezésre állási zónában. A régiókimaradások ritka eseteiben az Azure Cosmos DB-t konfigurálhatja a tartósság és a rendelkezésre állás különböző eredményeinek támogatásához.
Tartósság
Ha egy Azure Cosmos DB-fiók egyetlen régióban van üzembe helyezve, általában nincs adatvesztés. Az adathozzáférés az Azure Cosmos DB-szolgáltatásoknak az érintett régióban való helyreállítása után lesz visszaállítva. Az adatvesztés csak az Azure Cosmos DB-régióban helyreállíthatatlan katasztrófa esetén fordulhat elő.
Az Azure Cosmos DB két biztonsági mentési módot biztosít, hogy védelmet nyújtsunk a régióban előforduló katasztrofális katasztrófákból eredő teljes adatvesztéssel szemben:
- A folyamatos biztonsági mentések 100 másodpercenként biztonsági másolatot készítnek az egyes régiókról. Lehetővé teszik az adatok bármely időpontra való visszaállítását 1 másodperces részletességgel. Minden régióban a biztonsági mentés az adott régióban lekötött adatoktól függ. Ha a régióban engedélyezve vannak a rendelkezésre állási zónák, akkor a biztonsági mentés zónaredundáns tárfiókokban lesz tárolva.
- A rendszeres biztonsági mentések teljes mértékben biztonsági másolatot készítenek az összes partícióról a fiók összes tárolójából, a partíciók közötti szinkronizálás nélkül. A minimális biztonsági mentési időköz 1 óra.
Ha egy Azure Cosmos DB-fiók több régióban van üzembe helyezve, az adatok tartóssága a fiókon konfigurált konzisztenciaszinttől függ. 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 RPO-ját.
| Konzisztenciaszint | RPO régiókimaradás esetén |
|---|---|
| Munkamenet, konzisztens előtag, végleges | Kevesebb, mint 15 perc |
| Korlátozott frissessé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.
Szolgáltatás által felügyelt feladatátvétel
Ha a megoldás folyamatos üzemidőt igényel a régiókimaradások során, konfigurálhatja az Azure Cosmos DB-t, hogy több régióban replikálja az adatokat, és szükség esetén transzparens feladatátvételt hajtson végre az üzemeltetési régiókban.
Az egyrégiós fiókok regionális leállás után elveszíthetik az akadálymentességet. Az üzletmenet folyamatosságának biztosítása érdekében javasoljuk, hogy az Azure Cosmos DB-fiókot egyetlen írási régióval és legalább egy második (olvasási) régióval állítsa be, és engedélyezze a szolgáltatás által felügyelt feladatátvételt.
A szolgáltatás által felügyelt feladatátvétel lehetővé teszi, hogy az Azure Cosmos DB feladatátvételt hajthasson létre egy többrégiós fiók írási területén, hogy megőrizze az üzletmenet folytonosságát az adatvesztés költségén, ahogyan azt a tartóssági szakaszban korábban leírtuk. A regionális feladatátvételeket az Azure Cosmos DB-ügyfél észleli és kezeli. Nem igényelnek módosításokat az alkalmazástól. A több olvasási régió engedélyezésével és a szolgáltatás által felügyelt feladatátvétellel kapcsolatos utasításokért lásd : Azure Cosmos DB-fiók kezelése az Azure Portal használatával.
Fontos
Ha több olvasási régióval rendelkező egyrégiós írási konfigurációt választott, javasoljuk, hogy konfigurálja az éles számítási feladatokhoz használt Azure Cosmos DB-fiókokat a szolgáltatás által felügyelt feladatátvétel engedélyezéséhez. Ez a konfiguráció lehetővé teszi, hogy az Azure Cosmos DB feladatátvételt hajtson a fiókadatbázisokon az elérhető régiókban. Ennek a konfigurációnak a hiányában a fiók az írási régió kimaradásának teljes időtartama alatt az írási rendelkezésre állás elvesztését fogja tapasztalni. A manuális feladatátvétel nem sikerül a régiókapcsolat hiánya miatt.
Figyelmeztetés
A szolgáltatás által felügyelt feladatátvétel engedélyezése esetén is előfordulhat, hogy a részleges kimaradás manuális beavatkozást igényel az Azure Cosmos DB szolgáltatáscsapata számára. Ezekben a forgatókönyvekben a feladatátvétel érvénybe lépése akár 1 órát (vagy több órát) is igénybe vehet. A részleges kimaradások során jobb írási rendelkezésre állás érdekében javasoljuk, hogy a szolgáltatás által felügyelt feladatátvétel mellett engedélyezze a rendelkezésre állási zónákat.
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ó hasznos a földrajzilag elosztott alkalmazások írási késésének csökkentéséhez.
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. 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
Ugyanazon dokumentumazonosító gyakori frissítése (vagy a TTL vagy a törlés után gyakran ismételt dokumentumazonosító) hatással lesz a replikáció teljesítményére a rendszerben generált ütközések számának növekedése miatt.
Ütközésfeloldási régió
Ha egy Azure Cosmos DB-fiók többrégiós írással van konfigurálva, az egyik régió írási ütközések esetén arbiterként fog működni.
Ajánlott eljárások többrégiós írásokhoz
Az alábbiakban néhány ajánlott eljárást érdemes megfontolni, amikor több régióba ír.
Helyi forgalom megtartva
Ha többrégiós írást használ, az alkalmazásnak ki kell adnia a helyi régióból származó olvasási és írási forgalmat szigorúan a helyi Cosmos DB-régiónak. Az optimális teljesítmény érdekében kerülje a régiók közötti hívásokat.
Fontos, hogy az alkalmazás minimalizálja az ütközéseket a következő antipatternek elkerülésével:
Ugyanazt az írási műveletet küldi el minden régiónak, hogy növelje a gyors válaszidő esélyét
Az olvasási vagy írási művelet célrégiójának véletlenszerű meghatározása kérésenként
Ciklikus időszeleteléses szabályzat használata az olvasási vagy írási műveletek célrégiójának meghatározásához kérésenként.
A replikáció késésének elkerülése
Nem konfigurálhat többrégiós írási fiókokat az erős konzisztencia érdekében. Az a régió, amely az Azure Cosmos DB helyi replikálása után azonnal válaszol, miközben aszinkron módon replikálja az adatokat globálisan.
Bár ritkán fordul elő, az adatok georeplikálása során replikációs késés léphet fel egy vagy néhány partíción. A replikáció késése a hálózati forgalom ritka három pontjának vagy a szokásosnál magasabb ütközésfeloldási aránynak köszönhetően fordulhat elő.
Például egy architektúra, amelyben az alkalmazás az A régióba ír, de a B régióból olvas, függőséget vezet be a replikáció késésétől a két régió között. Ha azonban az alkalmazás ugyanabba a régióba olvas és ír, a teljesítmény a replikáció késése esetén is állandó marad.
Munkamenet-konzisztencia használatának kiértékelése írási műveletekhez
A munkamenet-konzisztenciában a munkamenet-jogkivonatot olvasási és írási műveletekhez is használhatja.
Olvasási műveletek esetén az Azure Cosmos DB elküldi a gyorsítótárazott munkamenet-jogkivonatot a kiszolgálónak, és garantálja a megadott (vagy újabb) munkamenet-jogkivonatnak megfelelő adatok fogadását.
Írási műveletek esetén az Azure Cosmos DB elküldi a munkamenet-jogkivonatot az adatbázisnak, és garantálja, hogy csak akkor őrizze meg az adatokat, ha a kiszolgáló elérte a megadott munkamenet-jogkivonatot. Az egyrégiós írási fiókokban az írási régió mindig garantáltan felzárkózott a munkamenet-jogkivonathoz. A többrégiós írási fiókokban azonban előfordulhat, hogy az ön által írt régió nem érte el a másik régiónak kiadott írásokat. Ha az ügyfél a B régióból származó munkamenet-jogkivonattal ír az A régióba, az A régió nem fogja tudni őrizni az adatokat, amíg el nem éri a B régióban végrehajtott módosításokat.
A munkamenet-jogkivonatokat érdemes csak olvasási műveletekhez használni, írási műveletekhez nem, amikor munkamenet-jogkivonatokat ad át az ügyfélpéldányok között.
Ugyanazon dokumentum gyors frissítéseinek enyhítése
Az ütközések feloldásához vagy megerősítéséhez a kiszolgáló frissítései ütközhetnek az alkalmazás által aktivált írásokkal, amikor ugyanazt a dokumentumot ismételten frissítik. Az ugyanazon dokumentumra való gyors egymásutánban történő ismételt frissítések nagyobb késést tapasztalnak az ütközések feloldása során.
Bár az ugyanazon dokumentum ismétlődő frissítéseinek időnkénti kirobbanása elkerülhetetlen, érdemes lehet olyan architektúrát megvizsgálni, amelyben új dokumentumok jönnek létre, ha az állandó állapotú forgalom hosszabb időn keresztül gyors frissítéseket lát ugyanannak a dokumentumnak a gyors frissítésében.
Olvasási és írási kimaradások
Az egyrégiós fiókok ügyfelei az olvasási és írási rendelkezésre állás elvesztését tapasztalják a szolgáltatás visszaállításáig.
A többrégiós fiókok eltérő viselkedést tapasztalnak az alábbi konfigurációktól és kimaradástípusoktól függően.
| Konfiguráció | Szolgáltatáskimaradás | Rendelkezésre állási hatás | Tartóssági hatás | Teendők |
|---|---|---|---|---|
| Egy írási régió | Olvasási régió kimaradása | Minden ügyfél automatikusan átirányítja az olvasásokat más régiókba. Az összes konfigurációhoz nincs olvasási vagy írási rendelkezésre állási veszteség. Ez alól kivételt képez két, erős konzisztenciájú régió konfigurációja, amely a szolgáltatás visszaállításáig elveszíti az írási rendelkezésre állást. Vagy ha engedélyezi a szolgáltatás által felügyelt feladatátvételt, a szolgáltatás sikertelenként jelöli meg a régiót, és feladatátvétel történik. | Nincs adatvesztés. | A kimaradás során győződjön meg arról, hogy a fennmaradó régiókban elegendő kiépített kérelemegység (KÉRELEM) áll rendelkezésre az olvasási forgalom támogatásához. Ha a leállás véget ért, szükség szerint újra kiépített kérelemegységek. |
| Egy írási régió | Régióleállás írása | Az ügyfelek más régiókba irányítják át az olvasásokat. Szolgáltatás által felügyelt feladatátvétel nélkül az ügyfelek írási rendelkezésre állási veszteséget tapasztalnak. Az írási rendelkezésre állás visszaállítása automatikusan megtörténik, amikor a leállás véget ér. A szolgáltatás által felügyelt feladatátvétel esetén az ügyfelek írási rendelkezésre állási veszteséget tapasztalnak, amíg a szolgáltatás nem kezeli a feladatátvételt egy ön által kiválasztott új írási régióba. |
Ha nem választja ki az erős konzisztenciaszintet, előfordulhat, hogy a szolgáltatás nem replikál néhány adatot a fennmaradó aktív régiókba. Ez a replikáció a választott konzisztenciaszinttől függ. Ha az érintett régió állandó adatvesztést szenved, a nem duplikált adatok elveszhetnek. | A kimaradás során győződjön meg arról, hogy a fennmaradó régiókban elegendő kiépített kérelemegység található az olvasási forgalom támogatásához. A kimaradás során ne aktiváljon manuális feladatátvételt, mert az nem sikerülhet. Ha a leállás véget ért, szükség szerint újra kiépített kérelemegységek. Az API for NoSQL-t használó fiókok szintén helyreállíthatják a sikertelen régióban lévő nem duplikált adatokat az ütközési hírcsatornából. |
| Több írási régió | Regionális kimaradás | Előfordulhat, hogy az írási rendelkezésre állás ideiglenesen megszűnik, ami hasonló a szolgáltatás által felügyelt feladatátvétellel rendelkező egyetlen írási régióhoz. Az ütközésfeloldási régió feladatátvétele az írási rendelkezésre állás elvesztését is okozhatja, ha a leállás időpontjában nagy számú ütköző írás történik. | Előfordulhat, hogy a sikertelen régióban nemrég frissített adatok a kiválasztott konzisztenciaszinttől függően nem érhetők el a többi aktív régióban. Ha az érintett régió állandó adatvesztést szenved, előfordulhat, hogy a nem duplikált adatok elvesznek. | A kimaradás során győződjön meg arról, hogy a fennmaradó régiókban elegendő kiépített kérelemegység van a nagyobb forgalom támogatásához. Ha a kimaradás véget ért, a kiépített kérelemegységeket szükség szerint újra módosíthatja. Ha lehetséges, az Azure Cosmos DB automatikusan helyreállítja a nem duplikált adatokat a sikertelen régióban. Ez az automatikus helyreállítás a NoSQL API-t használó fiókokhoz konfigurált ütközésfeloldási módszert használja. Más API-kat használó fiókok esetében ez az automatikus helyreállítás az utolsó írási nyerést használja. |
További információ az olvasási régió kimaradásairól
Az érintett régió leválasztva van, és offline állapotban van megjelölve. Az Azure Cosmos DB SDK-k átirányítják az olvasási hívásokat 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, a hívások automatikusan visszaesnek az aktuális írási régióba.
Az olvasási régiók kimaradásainak kezeléséhez nincs szükség módosításra az alkalmazáskódban. Amikor az érintett olvasási 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érések 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.
Még olyan ritka és szerencsétlen esetben sem, amikor egy Azure-írási régió véglegesen helyreállíthatatlan, nincs adatvesztés, ha a többrégiós Azure Cosmos DB-fiók erős konzisztenciával van konfigurálva. Egy többrégiós Azure Cosmos DB-fiók a Tartósság szakaszban korábban megadott tartóssági jellemzőkkel rendelkezik.
További információ az írási régió kimaradásairól
Az írási régió leállása során az Azure Cosmos DB-fiók előléptet egy másodlagos régiót az új elsődleges írási régióként, amikor a szolgáltatás által felügyelt feladatátvétel az Azure Cosmos DB-fiókon van konfigurálva. A feladatátvétel egy másik régióba történik a megadott régió prioritásának sorrendjében.
A manuális feladatátvételt nem szabad aktiválni, és nem lesz sikeres a forrás- vagy célrégió leállása esetén. Ennek az az oka, hogy a feladatátvételi eljárás tartalmaz egy konzisztencia-ellenőrzést, amely megköveteli a régiók közötti kapcsolatot.
Amikor a korábban érintett régió ismét online állapotban van, a rendszer az ütközési hírcsatornán keresztül elérhetővé teszi azokat az írási adatokat, amelyeket nem replikáltak, amikor a régió meghiúsult. 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.
A korábban érintett írási régió helyreállítása után az "online" állapot jelenik meg az Azure Portalon, és olvasási régióként válik elérhetővé. Ezen a ponton biztonságosan vissza lehet térni a helyreállított régióra írási régióként a [PowerShell, az Azure CLI vagy az Azure Portal] (.) használatával. /cosmos-db/how-to-manage-database-account.yml#perform-manual-failover-on-an-azure-cosmos-db-account. Az írási régió váltá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ú.
Figyelmeztetés
Olyan írási régió leállása esetén, ahol az Azure Cosmos DB-fiók egy másodlagos régiót előléptet az új elsődleges írási régióként a szolgáltatás által felügyelt feladatátvételen keresztül, a rendszer nem lépteti elő az eredeti írási régiót, mivel a helyreállítás után az írási régió automatikusan vissza lesz léptetve. Az Ön felelőssége, hogy visszaálljon a helyreállított régióra írási régióként a PowerShell, az Azure CLI vagy az Azure Portal használatával (ha ezt biztonságosan megteheti, a fent leírtak szerint).
Üzemkimaradás észlelése, értesítés és felügyelet
Az egyrégiós fiókok esetében az ügyfelek olvasási és írási rendelkezésre állásának elvesztését tapasztalják egy Azure Cosmos DB-régió kimaradása során. A többrégiós fiókok eltérő viselkedést tapasztalnak az alábbi táblázatban leírtak szerint.
| Írási régiók | Szolgáltatás által felügyelt feladatátvétel | Amire számíthat | Teendők |
|---|---|---|---|
| Egy írási régió | Nincs engedélyezve | Ha egy olvasási régióban kimaradás van, ha nem használ erős konzisztenciát, az összes ügyfél más régiókba irányít át. Nincs olvasási vagy írási rendelkezésre állási veszteség, és nincs adatvesztés. Ha erős konzisztenciát használ, az olvasási régió kimaradása hatással lehet az írási rendelkezésre állásra, ha kétnál kevesebb olvasási régió marad. Ha kimaradás van az írási régióban, az ügyfelek írási rendelkezésre állási veszteséget tapasztalnak. Ha nem erős konzisztenciát választott, előfordulhat, hogy a szolgáltatás nem replikál néhány adatot a fennmaradó aktív régiókba. Ez a replikáció a kiválasztott konzisztenciaszinttől függ. Ha az érintett régió állandó adatvesztést szenved, előfordulhat, hogy a nem duplikált adatok elvesznek. Az Azure Cosmos DB visszaállítja az írási rendelkezésre állást, amikor a leállás véget ér. |
A kimaradás során győződjön meg arról, hogy a fennmaradó régiókban elegendő kiépített kérelemegység található az olvasási forgalom támogatásához. A kimaradás során ne aktiváljon manuális feladatátvételt, mert az nem sikerülhet. Ha a leállás véget ért, szükség szerint újra kiépített kérelemegységek. |
| Egy írási régió | Engedélyezve | Ha egy olvasási régióban kimaradás van, ha nem használ erős konzisztenciát, az összes ügyfél más régiókba irányít át. Nincs olvasási vagy írási rendelkezésre állási veszteség, és nincs adatvesztés. Ha erős konzisztenciát használ, az olvasási régió kimaradása hatással lehet az írási rendelkezésre állásra, ha kétnál kevesebb olvasási régió marad. Ha kimaradás van az írási régióban, az ügyfelek írási rendelkezésre állási veszteséget tapasztalnak, amíg az Azure Cosmos DB nem választ új régiót új írási régióként a beállításoknak megfelelően. Ha nem erős konzisztenciát választott, előfordulhat, hogy a szolgáltatás nem replikál néhány adatot a fennmaradó aktív régiókba. Ez a replikáció a kiválasztott konzisztenciaszinttől függ. Ha az érintett régió állandó adatvesztést szenved, előfordulhat, hogy a nem duplikált adatok elvesznek. |
A kimaradás során győződjön meg arról, hogy a fennmaradó régiókban elegendő kiépített kérelemegység található az olvasási forgalom támogatásához. A kimaradás során ne aktiváljon manuális feladatátvételt, mert az nem sikerülhet. Ha a kimaradás véget ért, az írási régiót visszahelyezheti az eredeti régióba, és szükség szerint módosíthatja a kiosztott kérelemegységeket. Az API for NoSQL-t használó fiókok a sikertelen régióban lévő nem replikált adatokat is helyreállíthatják az ütközési hírcsatornából. |
| Több írási régió | Nem alkalmazható | Előfordulhat, hogy a sikertelen régióban nemrég frissített adatok nem érhetők el a többi aktív régióban. A végleges, konzisztens előtag- és munkamenetkonzisztenciaszintek 15 percnél rövidebb elavultságot garantálnak. A kötött elavultság a konfigurációtól függően kevesebb, mint K vagy T másodpercet garantál. Ha az érintett régió állandó adatvesztést szenved, előfordulhat, hogy a nem duplikált adatok elvesznek. | A kimaradás során győződjön meg arról, hogy a fennmaradó régiókban elegendő kiépített kérelemegység van a nagyobb forgalom támogatásához. Ha a kimaradás véget ért, a kiépített kérelemegységeket szükség szerint újra módosíthatja. Ha lehetséges, az Azure Cosmos DB helyreállítja a nem duplikált adatokat a sikertelen régióban. Ez a helyreállítás a NoSQL API-t használó fiókokhoz konfigurált ütközésfeloldási módszert használja. Más API-kat használó fiókok esetében ez a helyreállítás az utolsó írási nyerést használja. |
Magas rendelkezésre állás tesztelése
Még ha az Azure Cosmos DB-fiókja is magas rendelkezésre állású, előfordulhat, hogy az alkalmazás nem megfelelően lett kialakítva, hogy magas rendelkezésre állású maradjon. Az alkalmazás végpontok közötti magas rendelkezésre állásának teszteléséhez az alkalmazás tesztelése vagy vészhelyreállítási (DR) gyakorlat részeként ideiglenesen tiltsa le a szolgáltatás által felügyelt feladatátvételt a fiókhoz. Manuális feladatátvétel meghívása a PowerShell, az Azure CLI vagy az Azure Portal használatával, majd az alkalmazás monitorozása. A teszt elvégzése után visszaadhatja a feladatátvételt az elsődleges régióba, és visszaállíthatja a szolgáltatás által felügyelt feladatátvételt a fiókhoz.
Fontos
Ne hívja meg a manuális feladatátvételt az Azure Cosmos DB leállása során a forrás- vagy célrégióban. A manuális feladatátvételhez régiókapcsolat szükséges az adatkonzisztencia fenntartásához, így az nem fog sikerülni.