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

Vloeiend Framework slaat periodiek momentopnamen van de gegevens in de container op, waarin alle wijzigingen in de gegevens tot dat moment worden samengevat. Tijdens het normaal laden wordt de meest recente momentopname opgehaald en worden eventuele volgende wijzigingen boven op die status toegepast.

Als de meest recente momentopname of volgende wijzigingen beschadigd zijn, kan Fluid deze mogelijk niet normaal laden. In dit geval biedt Fluid een verzameling API's om de opgeslagen momentopnameversies weer te geven en te laden in een modus die alleen-weergeven is, zonder dat daarop volgende wijzigingen zijn toegepast. Hierdoor kunnen de gegevens worden geëxtraheerd en eventueel worden geïnjecteerd in een nieuwe container om de samenwerking te hervatten.

Azure-client-API's

API's voor het weergeven en laden van containerversies

De AzureClient heeft de volgende methoden om dit scenario te ondersteunen:

Containerversies ophalen

getContainerVersions(id, options?)

Haal een lijst met beschikbare versies op waaruit mogelijk wordt geladen.

Parameters:

• id: de container-id. Dit is dezelfde id die wordt gebruikt bij het aanroepen getContainer.
• options?: Optioneel een optiesobject om op te geven:
  • maxCount: het maximum aantal versies dat moet worden opgehaald. Als er meer versies beschikbaar zijn dan aangevraagd, worden de nieuwste versies opgehaald. Standaard: 5

Returns: Een belofte die wordt omgezet in een matrix met objecten die beschikbare versies vertegenwoordigen (gesorteerd nieuwste naar oudste). De objecten hebben de volgende eigenschappen:

• id: de versie-id.
  • Opmerking: dit verschilt van de container-id en verwijst specifiek naar een momentopnameversie in plaats van de container.
• date: de tijdstempel waarop de versie is gegenereerd.

Containerversie weergeven

viewContainerVersion(id, containerSchema, version, compatibilityMode)

Laad een specifieke versie van een container alleen voor weergave. Elke versie die wordt opgehaald uit getContainerVersions kan worden gebruikt, maar voor het herstellen van beschadigde gegevens is het raadzaam om te beginnen met de meest recente versie en achterwaarts te werken om de meest recente niet-beschadigde versie te vinden.

De container wordt in een onderbroken status geladen, wat betekent dat de volgende wijzigingen niet worden toegepast op de gegevens die zijn aangebracht na het genereren van die momentopname. Wanneer deze status is geladen, worden de containergegevens mogelijk gelezen, maar niet bewerkt.

Parameters:

• id: de container-id. Dit is dezelfde id die wordt gebruikt bij het aanroepen getContainer.
• containerSchema: het containerschema. Dit is hetzelfde schema dat wordt gebruikt bij het aanroepen getContainer.
• version: Het versieobject waarnaar wordt verwezen naar de versie waaruit moet worden geladen. Het versieobject kan worden opgehaald via getContainerVersions.
• compatibilityMode: de compatibiliteitsmodus. Dit is dezelfde compatibiliteitsmodus die wordt gebruikt bij het aanroepen getContainer.

Returns: Een belofte die wordt omgezet in een object dat de geladen container vertegenwoordigt met één eigenschap:

• container: Het containerobject. Dit is hetzelfde type object als het containerobject dat wordt geretourneerd door getContainer, maar wordt onderbroken in de vorige status van de geselecteerde versie.

Opmerking

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

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.