Megosztás a következőn keresztül:

Folyamatos biztonsági mentés időponthoz kötött visszaállítással az Azure Cosmos DB-ben

A KÖVETKEZŐKRE VONATKOZIK: NoSQL MongoDB Gremlin Asztal

Az Azure Cosmos DB időponthoz kötött visszaállítási funkciója több forgatókönyvben is segít, például:

  • Helyreállítás egy tárolón belüli véletlen írási vagy törlési műveletből.
  • Törölt fiók, adatbázis vagy tároló visszaállítása.
  • Visszaállítás bármely régióba (ahol biztonsági másolatok léteztek) a visszaállítási időpontban.

Az Azure Cosmos DB anélkül végez adatmentést a háttérben, hogy extra kiosztott átviteli sebességet (RU-kat) használ, vagy befolyásolná az adatbázis teljesítményét és rendelkezésre állását. A rendszer folyamatos biztonsági mentéseket készít minden olyan régióban, ahol a fiók létezik. Egy fiók például rendelkezhet írási régióval az USA nyugati régiójában, és olvasási régiókat az USA keleti régiójában és az USA 2. keleti régiójában. Ezek a replikarégiók ezután biztonsági másolatot készíthetnek egy távoli Azure Storage-fiókról az egyes régiókban. Alapértelmezés szerint minden régió helyileg redundáns tárfiókokban tárolja a biztonsági mentést. 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.

Diagram, amely bemutatja, hogyan készít biztonsági másolatot egy tároló több régióban.

A visszaállításhoz rendelkezésre álló időkeret (más néven megőrzési időszak) a következő két lehetőség alacsonyabb értéke: 30 napos és 7 napos.

A kiválasztott beállítás a folyamatos biztonsági mentés kiválasztott szintjétől függ. A visszaállítás időpontja a megőrzési időszakon belül bármely időbélyeg lehet, amely nem lehet hosszabb az erőforrás létrehozásának időpontjánál. Erős konzisztencia módban az írási régióban készített biztonsági másolatok naprakészebbek az olvasási régiókhoz képest. Az olvasási régiók hálózati vagy egyéb átmeneti problémák miatt elmaradhatnak. A visszaállítás során lekérheti a legújabb visszaállítható időbélyeget egy adott erőforráshoz egy adott régióban. A legújabb visszaállítható időbélyegre hivatkozva ellenőrizheti, hogy az erőforrás-biztonsági másolatok a megadott időbélyegre vannak-e felállítva, és visszaállíthatók-e ebben a régióban.

Jelenleg egy Azure Cosmos DB-fiókot (API for NoSQL vagy MongoDB, API for Table, API for Gremlin) egy adott időpontban visszaállíthat egy másik fiókba. Ezt a visszaállítási műveletet az Azure Portalon, az Azure CLI-vel, az Azure PowerShell-lel vagy az Azure Resource Manager-sablonokkal hajthatja végre.

A biztonsági mentési tár redundanciája

Az Azure Cosmos DB alapértelmezés szerint helyileg redundáns tárolóblobokban tárolja a folyamatos módú biztonsági mentési adatokat. A zónaredundanciával rendelkező régiók esetében a biztonsági mentés zónaredundáns tárolási blobokban van tárolva. Folyamatos biztonsági mentési módban nem frissítheti a biztonsági mentési tár redundanciát.

A visszaállítás különböző módjai

A folyamatos biztonsági mentési mód két módon támogatja a törölt tárolók és adatbázisok visszaállítását. Visszaállíthatók egy új fiókba vagy egy meglévő fiókba. A két mód közötti választás a forgatókönyvtől függ. A legtöbb esetben célszerű a törölt tárolókat és adatbázisokat egy meglévő fiókba visszaállítani. Így elkerülhető az új fiókba való visszaállításhoz szükséges adatátvitel költsége. Olyan esetekben, amikor véletlen adatmódosítás történt, az új fiókba való visszaállítás lehet az előnyben részesített lehetőség.

Mi lesz visszaállítva egy új fiókba?

Állandó állapotban a forrásfiókon (beleértve az adatbázisokat, tárolókat és elemeket is) végrehajtott összes mutáció aszinkron módon, 100 másodpercen belül biztonsági másolatot készít. Ha az Azure Storage biztonsági mentési adathordozója le van kapcsolva vagy nem érhető el, a mutációk helyileg megmaradnak, amíg az adathordozó el nem érhető. Ezután a mutációk ki vannak ürítve, hogy megakadályozzák a helyreállítható műveletek megbízhatóságának elvesztését.

A kiosztott átviteli tárolókat, a megosztott átviteli adatbázist és a teljes fiókot bármilyen kombinációban visszaállíthatja. A visszaállítási művelet visszaállítja az összes adatot és az indextulajdonságokat egy új fiókba. A visszaállítási folyamat biztosítja, hogy egy fiókban, adatbázisban vagy tárolóban visszaállított összes adat konzisztens legyen a megadott visszaállítási időpontig. A visszaállítás időtartama a visszaállítani kívánt adatok mennyiségétől függ. Az újonnan visszaállított adatbázisfiók konzisztenciabeállítása megegyezik a forrásadatbázis-fiók konzisztenciabeállításával.

Feljegyzés

A folyamatos biztonsági mentési móddal a biztonsági mentések minden olyan régióban készülnek, ahol az Azure Cosmos DB-fiók elérhető. Az egyes régiófiókok biztonsági másolatai alapértelmezés szerint helyileg redundánsak , és zónaredundánsak, ha a fiók rendelkezik az adott régióhoz engedélyezett rendelkezésre állási zóna funkcióval. A visszaállítási művelet mindig új fiókba állítja vissza az adatokat.

Mi nem állítható vissza?

Az időponthoz kötött helyreállítás után a következő konfigurációk nem állíthatók vissza:

  • A megosztott átviteli sebesség adatbázisában lévő tárolók egy részhalmaza nem állítható vissza. A teljes adatbázis teljes egészében visszaállítható.
  • Tűzfal, virtuális hálózat, adatsík szerepköralapú hozzáférés-vezérlés vagy privát végpont beállításai.
  • A forrásfiók összes régiója.
  • Tárolt eljárások, eseményindítók, UDF-ek.
  • Szerepköralapú hozzáférés-vezérlési hozzárendelések.

Ezeket a konfigurációkat a visszaállítás befejezése után hozzáadhatja a visszaállított fiókhoz.

Visszaállítható időbélyeg élő fiókokhoz

A nem törölt Azure Cosmos DB élő fiókok visszaállításához ajánlott mindig azonosítani a tároló legújabb visszaállítható időbélyegét . Ezt az időbélyeget használva visszaállíthatja a fiókot a legújabb verzióra.

Visszaállítási forgatókönyvek

Az időponthoz kötött visszaállítás funkció a következő forgatókönyveket támogatja. Az 1–3. forgatókönyv bemutatja, hogyan aktiválható a visszaállítás, ha a visszaállítási időbélyeg előre ismert. Lehetnek azonban olyan esetek, amikor nem tudja pontosan a véletlen törlés vagy sérülés időpontját. A 4. és az 5. forgatókönyv bemutatja, hogyan deríthető fel a visszaállítási időbélyeg az új eseménycsatorna API-jaival a visszaállítható adatbázison vagy tárolókon.

Egy visszaállítható fiók időbélyegeit tartalmazó életciklus-eseményeket bemutató ábra.

  • 1. forgatókönyv – Törölt fiók visszaállítása: A visszaállítható összes törölt fiók látható a Visszaállítás panelen. Ha például az A fiókot a T3 időbélyegben törlik. Ebben az esetben a T3 előtti időbélyeg, a hely, a célfiók neve, az erőforráscsoport és a célfiók neve elegendő az Azure Portalról, a PowerShellből vagy a parancssori felületről való visszaállításhoz.

    Egy visszaállítható adatbázis és tároló időbélyegeivel rendelkező életciklus-események.

  • 2. forgatókönyv – Fiók adatainak visszaállítása egy adott régióban: Ha például az A fiók az USA keleti régiójában és az USA nyugati régiójában található a T3 időbélyegnél. Ha szüksége van az A fiók másolatára az USA nyugati régiójában, visszaállíthatja az időpont szerint a mentést az Azure portálról, a PowerShellből, vagy a CLI-ból úgy, hogy az USA nyugati régiója van kijelölve célhelyként.

  • 3. forgatókönyv – Helyreállítás egy ismert visszaállítási időbélyeggel rendelkező tárolón belüli véletlen írási vagy törlési műveletből: Ha például tudja, hogy az 1. adatbázis1. tárolójának tartalma véletlenül módosult a T3 időbélyeggel. Az Azure Portalról, a PowerShellből vagy a CLI-ból egy időponthoz kötött visszaállítást végezhet egy másik fiókba a T3 időbélyegen a tároló kívánt állapotának visszaállításához.

  • 4. forgatókönyv – Fiók visszaállítása egy korábbi időpontra az adatbázis véletlen törlése előtt: Az Azure Portalon az eseménycsatorna panel használatával állapíthatja meg, hogy mikor törölték az adatbázist, és megkeresheti a visszaállítási időt. Az Azure CLI-vel és a PowerShell-lel hasonlóképpen felfedezheti az adatbázis-törlési eseményt az adatbázis eseménycsatornájának számbavételével, majd aktiválhatja a visszaállítási parancsot a szükséges paraméterekkel.

  • 5. forgatókönyv – Fiók visszaállítása egy korábbi időpontra a tárolótulajdonságok véletlen törlése vagy módosítása előtt: Az Azure Portalon az eseménycsatorna panel használatával meghatározhatja, hogy mikor lett létrehozva, módosítva vagy törölve egy tároló a visszaállítási idő megkereséséhez. Hasonlóképpen, az Azure CLI és a PowerShell használatával az összes tárolóeseményt felderítheti a tárolóesemény-hírcsatorna számbavételével, majd aktiválhatja a visszaállítási parancsot a szükséges paraméterekkel.

Engedélyek

Az Azure Cosmos DB lehetővé teszi a folyamatos biztonsági mentési fiók visszaállítási engedélyeinek elkülönítését és korlátozását egy adott szerepkörre vagy egyszerű fiókra. További információ: Azure Cosmos DB-fiók visszaállítására vonatkozó engedélyek kezelése.

A többrégiós írási fiókok visszaállításának ismertetése

A központi régióban végrehajtott írásokat a rendszer azonnal megerősíti, és 100 másodpercen belül biztonsági másolatot készít aszinkron módon. Multi-write fiókokban a műholdrégióban végrehajtott módosításokat a rendszer megerősítés céljából elküldi a központi régióba. A központi régió ellenőrzi, hogy szükség van-e ütközésmegoldásra , hozzárendel egy ütközésfeloldási időbélyeget az ütközések feloldása után, és visszaküldi a dokumentumot a műholdas régiónak. A műholdas régió csak a megerősítést követően készít biztonsági másolatot a dokumentumokról. Röviden: a visszaállítási folyamat csak a központi régió által a visszaállítási időpontig megerősített dokumentumokat állítja vissza.

Mi történik a többrégiós írási fiók visszaállításához?

  • A visszaállítási időbélyeg által még nem igazolt mutációk nem lesznek visszaállítva.
  • Az egyéni ütközésfeloldási szabályzattal rendelkező gyűjtemények az időbélyeg alapján az utolsó írói győzelemre lesznek visszaállítva.

Feljegyzés

A műholdas régióból való visszaállítás lassabb, mint a többrégiós fiók központi régiójában történő visszaállítás, amely feloldja a helyi feltételes írásokat a megerősített módon, vagy műveletet hajt végre a visszaállításukhoz.

Ha többet szeretne megtudni a több írásra képes fiók időbélyegeiről, olvassa el az időbélyegek ismertetése című témakört.

Példaforgatókönyv: Ha egy több írási régiót tartalmazó fiók az USA keleti régiójával és az USA nyugati régiójával rendelkezik, amelyek közül az USA keleti régiója a központi régió, vegye figyelembe az alábbi események sorozatát:

  • T1: Az ügyfél egy Dokumentum1 dokumentumot ír az USA keleti régiójába (mivel az USA keleti régiója a központi régió, az írás azonnal megerősítést nyer)

  • T2: Az ügyfél dokumentumot ír a Doc2-be az USA nyugati régiójába

  • T3: Az USA nyugati régiója elküldi a Doc2-t az USA keleti régiójába megerősítés céljából

  • T4: Az USA keleti régiója megkapta a Doc2-t, megerősíti a dokumentumot, és visszaküldi a Doc2-t az USA nyugati régiójába

  • T5: Az USA nyugati régiója megerősítette a Doc2-t

Ebben a forgatókönyvben, ha a megadott visszaállítási időpont forrásként a központi régióhoz van megadva T3, akkor csak a Doc1 lesz visszaállítva. A "Doc2"-t a központ a T3 szerint nem erősítette meg. Csak akkor, ha a visszaállítási időbélyeg több, mint T4, a doc2 vissza lesz állítva, mivel a T4-nél a műholdas visszaállítás csak doc1-et tartalmaz, mivel a doc2 még nincs megerősítve.

Díjszabás

A folyamatos, 30 napos biztonsági mentéssel rendelkező Azure Cosmos DB-fiók havi díjat számít fel a biztonsági mentés tárolásához. A 30 napos és a 7 napos folyamatos visszalépési szint is díjakat von maga után az adatok visszaállításához. A visszaállítási költség minden alkalommal hozzáadódik, amikor a visszaállítási műveletet elindítják. Ha folyamatos biztonsági mentéssel konfigurál egy fiókot, de nem állítja vissza az adatokat, csak a biztonsági mentés tárolási költségeit tartalmazza a számla.

Az alábbi példa az USA nyugati régiójában üzembe helyezett Azure Cosmos DB-fiók árán alapul. A díjszabás és a számítás a használt régiótól függően változhat. A legfrissebb díjszabási információkért tekintse meg az Azure Cosmos DB díjszabási oldalát .

  • A 30 napos folyamatos biztonsági mentési szabályzattal engedélyezett összes fiók havi díjat számít fel a biztonsági mentési tárterületért, amely az alábbiak szerint van kiszámítva:

    0,20 USD/GB * Adatméret GB-ban a fiókban * Régiók száma

  • Minden visszaállítási API-hívás egyszeri díjat von maga után. A díj a visszaállított adatok mennyiségének függvénye:

    0,15 USD/GB * Adatméret GB-ban

Ha például két régióban 1 TB adat található:

  • A biztonsági mentés tárolási költsége 1000 * 0,20 * 2 = 400 USD havonta

  • A visszaállítás költsége 1000 * 0,15 = 150 USD visszaállításonként

Tipp.

Az Azure Cosmos DB-fiók aktuális adathasználatának méréséről további információt az Azure Monitor Azure Cosmos DB-elemzések felfedezése című témakörben talál. A folyamatos 7 napos szint nem jár díjakkal az adatok biztonsági mentéséért.

Folyamatos 30 napos szint és 7 napos szint

  • Az egyik szint megőrzési ideje 30 nap, míg egy másik szint 7 napos.
  • A biztonsági mentési tárterületért 30 napos megőrzési szintet kell fizetni. A hétnapos megőrzési szintért nem számítanak fel díjat.
  • A visszaállítás minden esetben mindkét szinten díjköteles

Élettartam

  • Az alapértelmezett visszaállítási folyamat alapértelmezés szerint visszaállítja a tároló összes tulajdonságát, beleértve annak TTL-konfigurációját is. Ez az adatok törlését eredményezheti, ha a visszaállítás a TTL letiltása nélkül történik. A törlés megakadályozása érdekében adjon meg egy paramétert, amely letiltja a TTL-t a PowerShellben (-DisableTtl $true) vagy a parancssori felületen (--disable-ttl True) a visszaállítás során.

Felhasználó által kezelt kulcsok

További információ : Hogyan befolyásolják az ügyfél által felügyelt kulcsok a folyamatos biztonsági mentéseket ?

  • Az Azure Cosmos DB-fiók konfigurálása ügyfél által felügyelt kulcsok folyamatos biztonsági mentéssel történő használatakor.
  • Hogyan befolyásolják az ügyfél által felügyelt kulcsok a visszaállításokat?

Jelenlegi korlátozások

Az időponthoz kötött visszaállítási funkció jelenleg a következő korlátozásokkal rendelkezik:

  • Az SQL, a MongoDB, a Gremlin és a Table azure Cosmos DB API-jai a folyamatos biztonsági mentéshez támogatottak. A Cassandra API jelenleg nem támogatott.

  • Az Azure Synapse Link általánosan elérhető folyamatos biztonsági mentési módot használó adatbázisfiókokhoz. Ellenkező esetben a Synapse Link-kompatibilis fiókok folyamatos biztonsági mentési módja nyilvános előzetes verzióban érhető el. Jelenleg azok az ügyfelek, akik letiltották a Synapse Linket a tárolókról, nem tudnak áttelepülni a folyamatos biztonsági mentésre. Az elemzési tár nem szerepel a biztonsági másolatokban. További információkért tekintse meg az elemzési tár biztonsági mentését.

  • A visszaállított fiók ugyanabban a régióban jön létre, ahol a forrásfiók található. Nem állíthat vissza fiókot olyan régióba, ahol a forrásfiók nem létezett.

  • A visszaállítási időszak csak 30 nap folyamatos 30 napos szint esetén, a folyamatos 7 napos szint esetén pedig hét nap. Ezek a szintek válthatók, de a tényleges mennyiségek (7 vagy 30) nem módosíthatók. Továbbá, ha a 30 napos szintről a 7 napos szintre vált, az adatvesztés a hetediket követő napokon is fennállhat.

  • A biztonsági másolatok nem automatikusan georeduktúra-rezisztensek. A fiók és a biztonsági mentés rugalmassága érdekében explicit módon hozzá kell adni egy másik régiót.

  • Amíg a visszaállítás folyamatban van, ne módosítsa vagy törölje az Identitás- és hozzáférés-kezelési (IAM-) szabályzatokat. Ezek a szabályzatok engedélyt adnak a fióknak a virtuális hálózat és a tűzfal konfigurációjának módosítására.

  • A MongoDB-hez készült Azure Cosmos DB-fiókok folyamatos biztonsági mentéssel nem támogatják egy meglévő gyűjtemény egyedi indexének létrehozását. Ilyen fiók esetén egyedi indexeket kell létrehozni a gyűjtemény létrehozásával együtt, amelyeket csak a gyűjteménybővítmény-parancsok létrehozásával lehet elvégezni.

  • A visszaállítás után lehetséges, hogy bizonyos gyűjtemények esetében a konzisztens index újraépíthető. Az újraépítési művelet állapotát az IndexTransformationProgress tulajdonságon keresztül ellenőrizheti.

  • A MongoDB API-ban nem lehet egyedi indexeket hozzáadni, frissíteni vagy elvetni folyamatos biztonsági mentési módú fiók létrehozásakor. Nem módosíthatók, ha egy fiókot időszakosról folyamatos módba migrál.

  • Előfordulhat, hogy a folyamatos módú visszaállítás nem állítja vissza a visszaállítási ponttól érvényes átviteli sebességet.

Következő lépések

  • Last updated on