Återställa containerdata

I det här scenariot utforskar vi dataåterställning. Vi anser att data är skadade när containern når ett ogiltigt tillstånd där den inte kan bearbeta ytterligare användaråtgärder. Resultatet av det skadade tillståndet är att containern oväntat stängs. Ofta är det tillfälligt tillstånd, och när containern öppnas igen kan den bete sig som förväntat. I en situation där en container inte kan läsas in även efter flera återförsök erbjuder vi API:er och flöden som du kan använda för att återställa dina data enligt beskrivningen nedan.

Hur Fluid Framework och Azure Fluid Relay sparar tillstånd

Fluid Framework sparar regelbundet tillstånd, som kallas sammanfattning, utan någon explicit säkerhetskopieringsåtgärd som initierats av användaren. Det här arbetsflödet inträffar var (1) minut om det inte finns någon användaraktivitet, eller tidigare om det finns fler än 1 000 väntande åtgärder. Varje väntande åtgärd översätts ungefär till en enskild användaråtgärd (välj textinmatning osv.) som inte har sammanfattats ännu.

Azure-klient-API:er

Vi har lagt till följande metoder i AzureClient som gör det möjligt för utvecklare att återställa data från skadade containrar.

getContainerVersions(ID, options)

getContainerVersions tillåter utvecklare att visa de tidigare genererade versionerna av containern.

copyContainer(ID, containerSchema)

copyContainer gör det möjligt för utvecklare att generera en ny frånkopplad container från en viss version av en annan container.

Exempel på återställningsflöde

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"));
}

Viktiga observationer

Vi skapar en ny container

Vi återställer inte (återställer) befintlig container. copyContainer ger oss en ny instans med data som kopieras från den ursprungliga containern. I den här processen tas inte den gamla containern bort.

Ny container kopplas från

Den nya containern är ursprungligen i detached tillstånd. Vi kan fortsätta att arbeta med en frånkopplad container eller ansluta omedelbart. När vi har ringt attach får vi tillbaka ett unikt container-ID som representerar den nyligen skapade instansen.

Överväganden efter återställning

När det gäller att skapa användningsfall kring efteråterställningsscenarier, här är några överväganden om vad programmet kanske vill göra för att få sina fjärranslutna medarbetare att arbeta med samma container igen.

Om du modellerar dina programdata enbart med hjälp av flytande containrar bryts kommunikationens "länk" effektivt när containern är skadad. Liknande verkliga exempel kan vara videosamtal där den ursprungliga författaren delade länken med deltagarna och länken inte fungerar längre. Med det perspektivet i åtanke är ett alternativ att begränsa återställningsbehörigheterna till den ursprungliga författaren och låta dem dela ny containerlänk på samma sätt som de delade den ursprungliga länken, efter att ha återställt kopian av den ursprungliga containern.

Om du använder flytande ramverk endast för tillfälliga data kan du alltid använda dina egna sanningskällor och stödtjänster för att hantera mer autonoma återställningsarbetsflöden. Till exempel kan flera klienter starta återställningsprocessen tills din app har en första återställd kopia. Din app kan sedan meddela alla deltagande klienter att övergå till en ny container. Detta kan vara användbart eftersom alla aktiva klienter kan avblockera den deltagande gruppen för att fortsätta samarbetet. Ett övervägande här är de kostnader som uppstår vid redundans.