Containergegevens herstellen

In dit scenario verkennen we gegevensherstel. We beschouwen gegevens als beschadigd wanneer de container een ongeldige status bereikt, waarbij verdere gebruikersacties niet kunnen worden verwerkt. Het resultaat van beschadigde status is dat de container onverwacht wordt gesloten. Vaak is deze tijdelijke status en bij het opnieuw openen kan de container zich gedragen zoals verwacht. In een situatie waarin een container niet kan worden geladen, zelfs na meerdere nieuwe pogingen, bieden we API's en stromen die u kunt gebruiken om uw gegevens te herstellen, zoals hieronder wordt beschreven.

De opslagstatus van Vloeiend Framework en Azure Fluid Relay

Fluid Framework slaat periodiek de status, de samenvatting genoemd, op zonder expliciete back-upactie die door de gebruiker is geïnitieerd. Deze werkstroom vindt elke (1) minuut plaats als er geen gebruikersactiviteit is, of sneller als er meer dan 1000 lopende bewerkingen aanwezig zijn. Elke actie die in behandeling is, wordt ruwweg omgezet in een afzonderlijke gebruikersactie (selecteren, tekstinvoer, enzovoort) die nog niet is samengevat.

Azure-client-API's

We hebben de volgende methoden toegevoegd aan AzureClient waarmee ontwikkelaars gegevens kunnen herstellen uit beschadigde containers.

getContainerVersions(ID, options)

getContainerVersions biedt ontwikkelaars de mogelijkheid om de eerder gegenereerde versies van de container weer te geven.

copyContainer(ID, containerSchema)

copyContainer hiermee kunnen ontwikkelaars een nieuwe losgekoppelde container genereren van een specifieke versie van een andere container.

Voorbeeld van herstelstroom

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

Belangrijke waarnemingen

Er wordt een nieuwe container gemaakt

Bestaande container wordt niet hersteld (terugdraaien). copyContainer geeft ons een nieuw exemplaar, waarbij gegevens worden gekopieerd uit de oorspronkelijke container. In dit proces wordt de oude container niet verwijderd.

Nieuwe container is losgekoppeld

Nieuwe container heeft in eerste instantie de detached status. We kunnen blijven werken met een losgekoppelde container of direct bijvoegen. Na het aanroepen attach krijgen we een unieke container-id terug, die het zojuist gemaakte exemplaar vertegenwoordigt.

Overwegingen na herstel

Als het gaat om het bouwen van use cases rond scenario's na herstel, zijn hier enkele overwegingen over wat de toepassing kan doen om de externe medewerkers weer aan dezelfde container te laten werken.

Als u uw toepassingsgegevens alleen modelleert met behulp van vloeistofcontainers, wordt de communicatiekoppeling effectief verbroken wanneer de container beschadigd is. Een vergelijkbaar praktijkvoorbeeld kan een videogesprek zijn waarbij de oorspronkelijke auteur de koppeling met deelnemers heeft gedeeld en die koppeling niet meer werkt. Met dit perspectief in gedachten, is één optie om herstelmachtigingen te beperken tot de oorspronkelijke auteur en hen nieuwe containerkoppeling op dezelfde manier te laten delen als ze de oorspronkelijke koppeling hebben gedeeld, nadat de kopie van de oorspronkelijke container is hersteld.

Als u een vloeiend framework gebruikt voor alleen tijdelijke gegevens, kunt u ook altijd uw eigen bron-of-waarheidsgegevens en ondersteunende services gebruiken om meer autonome herstelwerkstromen te beheren. Meerdere clients kunnen bijvoorbeeld het herstelproces starten totdat uw app een eerste herstelde kopie heeft. Uw app kan vervolgens alle deelnemende clients op de hoogte stellen van de overgang naar een nieuwe container. Dit kan handig zijn omdat elke actieve client de blokkering van de deelnemende groep kan opheffen om door te gaan met samenwerking. Een overweging hier is de gemaakte kosten van redundantie.