Återställa containerdata

  • Artikel

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 Dinamična platforma och Azure Fluid Relay sparar tillstånd

Dinamična platforma sparar regelbundet ögonblicksbilder av data i containern, som sammanfattar alla ändringar som gjorts i data fram till den tidpunkten. Vid normal inläsning hämtas den senaste ögonblicksbilden och eventuella efterföljande ändringar tillämpas ovanpå det tillståndet.

Om den senaste ögonblicksbilden eller efterföljande ändringar är skadade kanske Fluid inte kan läsa in dem normalt. I det här fallet erbjuder Fluid en samling API:er för att visa de lagrade ögonblicksbildversionerna och läsa in dem i ett visningsläge utan efterföljande ändringar. Detta gör att data kan extraheras och eventuellt matas in i en ny container för att återuppta samarbetet.

Azure-klient-API:er

API:er för att visa och läsa in containerversioner

AzureClient har följande metoder för att stödja det här scenariot:

Hämta containerversioner

getContainerVersions(id, options?)

Hämta en lista över tillgängliga versioner som kan läsas in från.

Parameters:

  • id: Container-ID:t. Det här är samma ID som används när du anropar getContainer.
  • options?: Du kan också ange ett alternativobjekt som ska anges:
    • maxCount: Det maximala antalet versioner som ska hämtas. Om det finns fler tillgängliga versioner än vad som begärts hämtas de senaste versionerna. Standard: 5

Returns: Ett löfte som matchar en matris med objekt som representerar tillgängliga versioner (sorterade senaste till äldsta). Objekten har följande egenskaper:

  • id: Versions-ID.
    • Obs! Detta skiljer sig från container-ID:t och refererar specifikt till en ögonblicksbildversion i stället för containern.
  • date: Tidsstämpeln när versionen genererades.

Visa containerversion

viewContainerVersion(id, containerSchema, version, compatibilityMode)

Läs in en specifik version av en container för endast visning. Alla versioner som hämtas från getContainerVersions kan användas, men för att återställa skadade data rekommenderar vi att du börjar med den senaste versionen och arbetar bakåt för att hitta den senaste omkorruperade versionen.

Containern läses in i ett pausat tillstånd, vilket innebär att den inte tillämpar de efterföljande ändringarna på de data som inträffade efter genereringen av ögonblicksbilden. När de läses in i det här tillståndet kan containerdata läsas, men inte redigeras.

Parameters:

  • id: Container-ID:t. Det här är samma ID som används när du anropar getContainer.
  • containerSchema: Containerschemat. Det här är samma schema som används när du anropar getContainer.
  • version: Versionsobjektet som refererar till den version som ska läsas in från. Versionsobjektet kan hämtas via getContainerVersions.
  • compatibilityMode: Kompatibilitetsläget. Det här är samma kompatibilitetsläge som används när du anropar getContainer.

Returns: Ett löfte som matchar ett objekt som representerar den inlästa containern med en enda egenskap:

  • container: Containerobjektet. Det här är samma typ av objekt som containerobjektet som returneras av getContainer, men pausas i dess tidigare tillstånd från den valda versionen.

Exempel

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

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.