Obnovení dat kontejneru

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á stav označovaný jako souhrn bez explicitní akce zálohování iniciované uživatelem. K tomuto pracovnímu postupu dochází každých jednu (1) minutu, pokud neexistuje žádná aktivita uživatele nebo pokud existuje více než 1 000 čekajících operací. Každý čekající operace se zhruba přeloží na akci jednotlivého uživatele (výběr, textové zadání atd.), která ještě nebyla sumarizovat.

Klientská rozhraní API Azure

Do AzureClient jsme přidali následující metody, které vývojářům umožňují obnovit data z poškozených kontejnerů.

getContainerVersions(ID, options)

getContainerVersions umožňuje vývojářům zobrazit dříve generované verze kontejneru.

copyContainer(ID, containerSchema)

copyContainer umožňuje vývojářům vygenerovat nový odpojený kontejner z konkrétní verze jiného kontejneru.

Příklad toku obnovení

async function recoverDoc(
    client: AzureClient,
    orgContainerId: string,
    containerScema: ContainerSchema,
): Promise<string> {
    /* Collect doc versions */
    let versions: AzureContainerVersion[] = [];
    try {
        versions = await client.getContainerVersions(orgContainerId);
    } catch (e) {
        return Promise.reject(new Error("Unable to get container versions."));
    }

    for (const version of versions) {
        /* Versions are returned in chronological order.
        Attempt to copy doc from next available version */
        try {
            const { container: newContainer } = await client.copyContainer(
                orgContainerId,
                containerSchema,
                version,
            );
            return await newContainer.attach();
        } catch (e) {
            // Error. Keep going.
        }
    }

    return Promise.reject(new Error("Could not recreate document"));
}

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.