Odzyskiwanie danych kontenera

W tym scenariuszu eksplorujemy odzyskiwanie danych. Uważamy, że dane są uszkodzone, gdy kontener osiągnie nieprawidłowy stan, w którym nie może przetworzyć dalszych akcji użytkownika. Wynik uszkodzonego stanu to nieoczekiwanie zamknięty kontener. Często jest to stan przejściowy, a po ponownym otwarciu kontener może zachowywać się zgodnie z oczekiwaniami. W sytuacji, gdy kontener nie może załadować nawet po wielu ponownych próbach, oferujemy interfejsy API i przepływy, których można użyć do odzyskania danych, jak opisano poniżej.

Jak zapisać stan Elastyczna struktura i usługi Azure Fluid Relay

Elastyczna struktura okresowo zapisuje migawki danych w kontenerze, które podsumowują wszystkie zmiany wprowadzone w danych do tego momentu. Podczas normalnego ładowania jest pobierana najnowsza migawka, a wszelkie kolejne zmiany są stosowane na podstawie tego stanu.

Jeśli najnowsza migawka lub kolejne zmiany są uszkodzone, płyn może nie być w stanie załadować ich normalnie. W tym przypadku fluid oferuje kolekcję interfejsów API do wyświetlania przechowywanych wersji migawek i ładowania ich w trybie tylko do wyświetlania bez stosowania kolejnych zmian. Dzięki temu dane mogą być wyodrębniane i opcjonalnie wstrzykiwane do nowego kontenera w celu wznowienia współpracy.

Interfejsy API klienta platformy Azure

Interfejsy API do wyświetlania i ładowania wersji kontenerów

Obiekt AzureClient ma następujące metody obsługi tego scenariusza:

Pobieranie wersji kontenera

getContainerVersions(id, options?)

Pobierz listę dostępnych wersji, z których można załadować.

Parameters:

• id: identyfikator kontenera. Jest to ten sam identyfikator używany podczas wywoływania elementu getContainer.
• options?: Opcjonalnie obiekt opcji do określenia:
  • maxCount: maksymalna liczba wersji do pobrania. Jeśli jest dostępnych więcej wersji niż zażądano, zostaną pobrane najnowsze wersje. Ustawienie domyślne: 5

Returns: Obietnica, która rozwiązuje tablicę obiektów reprezentujących dostępne wersje (posortowane od najnowszych do najstarszych). Obiekty mają następujące właściwości:

• id: identyfikator wersji.
  • Uwaga: różni się to od identyfikatora kontenera, a w szczególności odwołuje się do wersji migawki, a nie kontenera.
• date: sygnatura czasowa wygenerowania wersji.

Wyświetlanie wersji kontenera

viewContainerVersion(id, containerSchema, version, compatibilityMode)

Załaduj określoną wersję kontenera tylko do wyświetlania. Każda wersja pobrana z getContainerVersions programu może być używana, ale w celu odzyskania uszkodzonych danych zaleca się rozpoczęcie od najnowszej wersji i pracę wstecz w celu znalezienia najnowszej niekorupcyjnej wersji.

Kontener jest ładowany w stanie wstrzymania, co oznacza, że nie zastosuje kolejnych zmian do danych, które wystąpiły po wygenerowaniu tej migawki. Po załadowaniu w tym stanie dane kontenera mogą być odczytywane, ale nie edytowane.

Parameters:

• id: identyfikator kontenera. Jest to ten sam identyfikator używany podczas wywoływania elementu getContainer.
• containerSchema: schemat kontenera. Jest to ten sam schemat używany podczas wywoływania metody getContainer.
• version: obiekt wersji odwołujące się do wersji do załadowania. Obiekt wersji można pobrać za pomocą polecenia getContainerVersions.
• compatibilityMode: tryb zgodności. Jest to ten sam tryb zgodności używany podczas wywoływania metody getContainer.

Returns: Obietnica, która rozwiązuje problem z obiektem reprezentującym załadowany kontener z jedną właściwością:

• container: obiekt kontenera. Jest to ten sam typ obiektu co obiekt kontenera zwrócony przez getContainerelement , ale jest wstrzymany w poprzednim stanie z wybranej wersji.

Przykład

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

Kluczowe obserwacje

Tworzymy nowy kontener

Nie odzyskujemy istniejącego kontenera (wycofywania). copyContainer da nam nowe wystąpienie, a dane są kopiowane z oryginalnego kontenera. W tym procesie stary kontener nie jest usuwany.

Nowy kontener jest odłączony

Nowy kontener jest początkowo w detached stanie. Możemy kontynuować pracę z odłączonym kontenerem lub natychmiast dołączyć. Po wywołaniu attach wywołania zostanie wyświetlony unikatowy identyfikator kontenera reprezentujący nowo utworzone wystąpienie.

Zagadnienia dotyczące odzyskiwania po odzyskiwaniu

Jeśli chodzi o tworzenie przypadków użycia w scenariuszach po odzyskiwaniu, poniżej przedstawiono kilka zagadnień dotyczących tego, co aplikacja może zrobić, aby wszyscy współpracownicy zdalni pracowali nad tym samym kontenerem ponownie.

Jeśli modelujesz dane aplikacji wyłącznie przy użyciu kontenerów płynnych, komunikacja "link" zostanie skutecznie przerwana po uszkodzeniu kontenera. Podobny rzeczywisty przykład może być połączeniem wideo, w którym oryginalny autor udostępnił link uczestnikom i że link już nie działa. Mając na uwadze tę perspektywę, jedną z opcji jest ograniczenie uprawnień odzyskiwania do oryginalnego autora i zezwolenie im na udostępnianie nowego linku kontenera w taki sam sposób, jak w przypadku udostępniania oryginalnego linku po odzyskaniu kopii oryginalnego kontenera.

Alternatywnie, jeśli używasz struktury płynów tylko dla danych przejściowych, zawsze możesz użyć własnych danych źródłowych prawdy i usług pomocniczych do zarządzania bardziej autonomicznymi przepływami pracy odzyskiwania. Na przykład wielu klientów może rozpocząć proces odzyskiwania do momentu, aż aplikacja ma pierwszą odzyskaną kopię. Następnie aplikacja może powiadomić wszystkich uczestniczących klientów o przejściu do nowego kontenera. Może to być przydatne, ponieważ każdy aktualnie aktywny klient może odblokować uczestniczącą grupę, aby kontynuować współpracę. Jedną z kwestii jest to, że koszty nadmiarowości są naliczane.