Obnovení dat kontejneru

Článek
06/25/2024

V tomto scénáři prozkoumáme obnovení dat. Data považujeme za poškozená, když kontejner dosáhne neplatného stavu, kdy nemůže zpracovat další akce uživatele. Výsledek poškozeného stavu je neočekávaně zavřený kontejner. Často se jedná o přechodný stav a při opětovném otevření se kontejner může chovat podle očekávání. V situaci, kdy se kontejner nepodaří načíst i po několika opakováních, nabízíme rozhraní API a toky, které můžete použít k obnovení dat, jak je popsáno níže.

Jak fluid Framework a Azure Fluid Relay šetří stav

Fluid Framework pravidelně ukládá snímky dat v kontejneru, které shrnují všechny změny provedené v datech až do tohoto okamžiku. Během normálního načítání se načte nejnovější snímek a všechny následné změny se použijí nad tímto stavem.

Pokud jsou nejnovější snímky nebo následné změny poškozené, funkce Fluid je nemusí normálně načíst. V tomto případě fluid nabízí kolekci rozhraní API pro zobrazení uložených verzí snímků a jejich načtení v režimu jen pro zobrazení bez následných změn. Díky tomu se data extrahují a volitelně vloží do nového kontejneru, aby se obnovila spolupráce.

Klientská rozhraní API Azure

Rozhraní API pro zobrazení a načítání verzí kontejneru

AzureClient má následující metody pro podporu tohoto scénáře:

Získání verzí kontejneru

getContainerVersions(id, options?)

Načtěte seznam dostupných verzí, ze které se můžou načíst.

Parameters:

id: ID kontejneru. Toto je stejné ID, které se používá při volání getContainer.
options?: Volitelně můžete zadat objekt možností:
- maxCount: Maximální počet verzí, které se mají načíst. Pokud je k dispozici více verzí, než je požadováno, načtou se nejnovější verze. Výchozí hodnota: 5

Returns: Příslib, který se přeloží na pole objektů představujících dostupné verze (seřazené od nejnovějších po nejstarší). Objekty mají následující vlastnosti:

id: ID verze.
- Poznámka: Toto se liší od ID kontejneru a konkrétně odkazuje na verzi snímku, nikoli na kontejner.
date: Časové razítko při vygenerování verze.

Zobrazení verze kontejneru

viewContainerVersion(id, containerSchema, version, compatibilityMode)

Načtěte konkrétní verzi kontejneru jen pro zobrazení. Každou verzi načtenou z getContainerVersions této verze je možné použít, ale pro účely obnovení poškozených dat se doporučuje začít s nejnovější verzí a vrátit se zpět a najít nejnovější nerušovanou verzi.

Kontejner se načte v pozastaveném stavu, což znamená, že nepoužije následné změny dat, ke kterým došlo po generování tohoto snímku. Při načtení v tomto stavu se data kontejneru můžou číst, ale ne upravovat.

Parameters:

id: ID kontejneru. Toto je stejné ID, které se používá při volání getContainer.
containerSchema: Schéma kontejneru. Toto je stejné schéma, které se používá při volání getContainer.
version: Objekt verze odkazující na verzi, ze které se má načíst. Objekt verze lze načíst prostřednictvím getContainerVersions.
compatibilityMode: Režim kompatibility. Jedná se o stejný režim kompatibility používaný při volání getContainer.

Returns: Příslib, který se přeloží na objekt představující načtený kontejner s jednou vlastností:

container: Objekt kontejneru. Jedná se o stejný typ objektu jako objekt kontejneru vrácený getContainer, ale je pozastaven v předchozím stavu z vybrané verze.

Příklad

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();

Klíčové pozorování

Vytváříme nový kontejner.

Stávající kontejner se neobnoví (vrací se zpět). copyContainer nám poskytne novou instanci s zkopírováním dat z původního kontejneru. V tomto procesu se starý kontejner neodstraní.

Nový kontejner je odpojený

Nový kontejner je zpočátku ve detached stavu. Můžeme pokračovat v práci s odpojeným kontejnerem nebo okamžitě připojit. Po volání attach získáme zpět jedinečné ID kontejneru, které představuje nově vytvořenou instanci.

Aspekty po obnovení

Pokud jde o vytváření případů použití v případě scénářů po obnovení, tady je několik aspektů, které by aplikace mohla chtít udělat, aby všichni vzdálení spolupracovníci pracovali na stejném kontejneru znovu.

Pokud modelujete data aplikace výhradně pomocí kontejnerů tekutin, komunikace "link" se efektivně přeruší, když je kontejner poškozený. Podobný skutečný příklad může být videohovor, kdy původní autor sdílel odkaz s účastníky a tento odkaz už nefunguje. S ohledem na tuto perspektivu je jednou z možností omezit oprávnění obnovení na původního autora a umožnit jim sdílet nový odkaz na kontejner stejným způsobem, jakým sdílel původní odkaz, po obnovení kopie původního kontejneru.

Alternativně platí, že pokud používáte architekturu tekutin pouze pro přechodná data, můžete vždy použít vlastní zdroj pravdivých dat a podpůrné služby ke správě více autonomních pracovních postupů obnovení. Proces obnovení může například zahajovat více klientů, dokud vaše aplikace nebude mít první obnovenou kopii. Aplikace pak může všem zúčastněným klientům oznámit přechod na nový kontejner. To může být užitečné, protože každý aktuálně aktivní klient může odblokovat zúčastněné skupiny a pokračovat ve spolupráci. Jedním z aspektů je vynaložené náklady na redundanci.

Sdílet prostřednictvím