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

Tárolóadatok helyreállítása

  • Cikk

Ebben a forgatókönyvben az adat-helyreállítást vizsgáljuk meg. Úgy gondoljuk, hogy az adatok sérültek, amikor a tároló érvénytelen állapotba kerül, ahol nem tudja feldolgozni a további felhasználói műveleteket. A sérült állapot eredménye, hogy a tároló váratlanul bezárul. Gyakran átmeneti állapotról van szó, és újranyitáskor a tároló a várt módon viselkedhet. Abban az esetben, ha egy tároló több újrapróbálkozás után sem töltődik be, api-kat és folyamatokat kínálunk az adatok helyreállításához az alábbiak szerint.

A Dinamikus keretrendszer és az Azure Fluid Relay mentési állapota

Dinamikus keretrendszer rendszeres időközönként menti a tárolóban lévő adatok pillanatképeit, amelyek összegzik az adatok ezen pontig végrehajtott módosításait. A normál betöltés során a rendszer lekéri a legújabb pillanatképet, és az azt követő módosításokat az adott állapotra alkalmazza.

Ha a legújabb pillanatkép vagy az azt követő módosítások sérültek, előfordulhat, hogy a Fluid nem tudja megfelelően betölteni őket. Ebben az esetben a Fluid API-k gyűjteményét kínálja a tárolt pillanatkép-verziók megtekintéséhez, és csak megtekintési módban tölti be őket, további módosítások nélkül. Ez lehetővé teszi az adatok kinyerését és opcionálisan egy új tárolóba való beszúrését az együttműködés folytatásához.

Azure-ügyfél API-k

API-k tárolóverziók megtekintéséhez és betöltéséhez

Az AzureClient a következő módszerekkel támogatja ezt a forgatókönyvet:

Tárolóverziók lekérése

getContainerVersions(id, options?)

Kérje le az elérhető verziók listáját, amelyekből betölthető.

Parameters:

  • id: A tároló azonosítója. Ez ugyanaz az azonosító, amelyet a híváskor getContainerhasználnak.
  • options?: Opcionálisan megadható beállításobjektum:
    • maxCount: A lekérendő verziók maximális száma. Ha a kértnél több verzió érhető el, a rendszer lekéri a legújabb verziókat. Alapértelmezett: 5

Returns: Ígéret, amely az elérhető verziókat (legújabbtól a legrégebbiig rendezve) képviselő objektumtömböt oldja fel. Az objektumok a következő tulajdonságokkal rendelkeznek:

  • id: A verzióazonosító.
    • Megjegyzés: Ez eltér a tárolóazonosítótól, és a tároló helyett egy pillanatkép-verzióra hivatkozik.
  • date: Az időbélyeg a verzió létrehozásakor.

Tárolóverzió megtekintése

viewContainerVersion(id, containerSchema, version, compatibilityMode)

Töltse be a tároló egy adott verzióját csak megtekintésre. Bármely lekért getContainerVersions verzió használható, de a sérült adatok helyreállítása céljából ajánlott a legújabb verzióval kezdeni, és visszafelé dolgozni a legutóbbi javítás nélküli verzió megkereséséhez.

A tároló szüneteltetett állapotban van betöltve, ami azt jelenti, hogy nem alkalmazza a pillanatkép létrehozása után történt adatok későbbi módosításait. Ebben az állapotban a tárolóadatok olvashatók, de nem szerkeszthetők.

Parameters:

  • id: A tároló azonosítója. Ez ugyanaz az azonosító, amelyet a híváskor getContainerhasználnak.
  • containerSchema: A tárolóséma. Ez ugyanaz a séma, amelyet híváskor getContainerhasználnak.
  • version: A verzióobjektum hivatkozik a betöltendő verzióra. A verzióobjektum lekérhető a következőn keresztül getContainerVersions: .
  • compatibilityMode: A kompatibilitási mód. Ez ugyanaz a kompatibilitási mód, amelyet híváskor getContainerhasználnak.

Returns: Ígéret, amely egyetlen tulajdonsággal oldja fel a betöltött tárolót képviselő objektumot:

  • container: A tárolóobjektum. Ez ugyanaz az objektumtípus, mint a tárolóobjektum által getContainervisszaadott objektum, de a rendszer a kijelölt verzióból szünetelteti a korábbi állapotában.

Példa

const azureClient = new AzureClient(/* ... */);
const versions = await azureClient.getContainerVersions(id);
// Since the versions are sorted in order from newest to oldest, versions[0] will attempt to load the most recent version.
// If the most recent version is corrupted, we could try again with versions[1] and so on to find the most-recent uncorrupted version.
const { container } = await azureClient.viewContainerVersion(id, containerSchema, versions[0], "2");

// We can now start reading the data from the container.
const someData = container.initialObjects.someSharedMap.get("hello");

// With the data extracted, we can inject it into a new uncorrupted container and attach it to start collaborating again.
const { container: newContainer } = await azureClient.createContainer(containerSchema, "2");
newContainer.initialObjects.someSharedMap.set("hello", someData);
const newId = await newContainer.attach();

Főbb megfigyelések

Új tárolót hozunk létre

A meglévő tároló helyreállítása (visszagördülése) nem. copyContainer új példányt ad nekünk, és az adatok az eredeti tárolóból lesznek átmásolva. Ebben a folyamatban a régi tároló nem törlődik.

Az új tároló leválasztva

Az új tároló kezdetben állapotban detached van. Folytathatjuk a munkát a leválasztott tárolóval, vagy azonnal csatolhatjuk. A hívás attach után visszakapjuk az újonnan létrehozott példányt képviselő egyedi tárolóazonosítót.

A helyreállítás utáni szempontok

Ha használati eseteket szeretne létrehozni a helyreállítás utáni forgatókönyvek köré, az alábbiakban néhány szempontot figyelembe kell vennie azzal kapcsolatban, hogy az alkalmazás mit szeretne tenni annak érdekében, hogy a távoli közreműködők ismét ugyanazon a tárolón dolgozzanak.

Ha az alkalmazásadatokat kizárólag folyadéktárolók használatával modellezi, a "hivatkozás" kommunikációja gyakorlatilag megszakad a tároló sérülése esetén. Hasonló valós példa lehet a videohívás, ahol az eredeti szerző megosztotta a hivatkozást a résztvevőkkel, és ez a hivatkozás már nem működik. Ezt a perspektívát szem előtt tartva az egyik lehetőség az, hogy a helyreállítási engedélyeket az eredeti szerzőre korlátozza, és lehetővé teszi számukra az új tárolóhivatkozás megosztását ugyanúgy, mint az eredeti hivatkozást, miután helyreállította az eredeti tároló másolatát.

Alternatív megoldásként, ha csak átmeneti adatokhoz használ folyékony keretrendszert, akkor mindig használhatja a saját forrásadatait és a támogató szolgáltatásokat az autonómabb helyreállítási munkafolyamatok kezeléséhez. Előfordulhat például, hogy több ügyfél is elindítja a helyreállítási folyamatot, amíg az alkalmazás nem rendelkezik az első helyreállított másolatsal. Az alkalmazás ezután értesítheti az összes résztvevő ügyfelet egy új tárolóra való áttérésről. Ez hasznos lehet, mivel bármely jelenleg aktív ügyfél feloldhatja a részt vevő csoport letiltását az együttműködés folytatásához. Itt az egyik szempont a redundancia felmerülő költségei.