다음을 통해 공유

컨테이너 데이터 복구

  • 아티클

이 시나리오에서는 데이터 복구를 살펴봅합니다. 컨테이너가 추가 사용자 작업을 처리할 수 없는 잘못된 상태에 도달하면 데이터가 손상된 것으로 간주합니다. 손상된 상태의 결과는 컨테이너가 예기치 않게 닫히는 것입니다. 일시적인 상태인 경우가 많으며 다시 열면 컨테이너가 예상대로 동작할 수 있습니다. 여러 번의 재시도 후에도 컨테이너가 로드되지 않는 상황에서는 아래 설명된 대로 데이터를 복구하는 데 사용할 수 있는 API 및 흐름을 제공합니다.

Fluid Framework 및 Azure Fluid Relay가 상태를 저장하는 방법

Fluid Framework는 컨테이너에 데이터의 스냅샷을 주기적으로 저장하여 해당 시점까지 데이터에 대한 모든 변경 내용을 요약합니다. 정상적으로 로드하는 동안 최신 스냅샷이 검색되고 후속 변경 내용이 해당 상태 위에 적용됩니다.

최신 스냅샷 또는 후속 변경 내용이 손상된 경우 Fluid가 정상적으로 로드하지 못할 수 있습니다. 이 경우 Fluid는 저장된 스냅샷 버전을 보고 후속 변경 내용이 적용되지 않은 보기 전용 모드로 로드하는 API 컬렉션을 제공합니다. 이렇게 하면 데이터를 추출하고 필요에 따라 새 컨테이너에 삽입하여 공동 작업을 다시 시작할 수 있습니다.

Azure 클라이언트 API

컨테이너 버전 보기 및 로드를 위한 API

AzureClient에는 이 시나리오를 지원하는 다음 방법이 있습니다.

컨테이너 버전 가져오기

getContainerVersions(id, options?)

로드할 수 있는 사용 가능한 버전 목록을 검색합니다.

Parameters:

  • id: 컨테이너 ID입니다. 이 ID는 호출 getContainer할 때 사용되는 ID와 동일합니다.
  • options?: 필요에 따라 지정할 옵션 개체입니다.
    • maxCount: 검색할 최대 버전 수입니다. 요청된 버전보다 더 많은 버전을 사용할 수 있는 경우 최신 버전이 검색됩니다. 기본값: 5

Returns: 사용 가능한 버전(최신 버전에서 가장 오래된 버전으로 정렬됨)을 나타내는 개체 배열로 확인되는 프라미스입니다. 개체에는 다음과 같은 속성이 있습니다.

  • id: 버전 ID입니다.
    • 참고: 컨테이너 ID와 다르며 특히 컨테이너가 아닌 스냅샷 버전을 참조합니다.
  • date: 버전이 생성된 타임스탬프입니다.

컨테이너 버전 보기

viewContainerVersion(id, containerSchema, version, compatibilityMode)

보기 전용 컨테이너의 특정 버전을 로드합니다. 검색된 getContainerVersions 모든 버전을 사용할 수 있지만 손상된 데이터를 복구하기 위해 가장 최근 버전으로 시작하고 이전 버전으로 작업하여 가장 최근에 손상되지 않은 버전을 찾는 것이 좋습니다.

컨테이너는 일시 중지된 상태로 로드됩니다. 즉, 해당 스냅샷을 생성한 후에 발생한 데이터에 후속 변경 내용을 적용하지 않습니다. 이 상태로 로드되면 컨테이너 데이터를 읽을 수 있지만 편집할 수는 없습니다.

Parameters:

  • id: 컨테이너 ID입니다. 이 ID는 호출 getContainer할 때 사용되는 ID와 동일합니다.
  • containerSchema: 컨테이너 스키마입니다. 이 스키마는 호출 getContainer할 때 사용되는 스키마와 동일합니다.
  • version: 로드할 버전을 참조하는 버전 개체입니다. 버전 개체는 .를 통해 getContainerVersions검색할 수 있습니다.
  • compatibilityMode: 호환 모드입니다. 이 모드는 호출 getContainer할 때 사용되는 것과 동일한 호환 모드입니다.

Returns: 단일 속성을 사용하여 로드된 컨테이너를 나타내는 개체로 확인되는 프라미스입니다.

  • container: 컨테이너 개체입니다. 이 개체는 반환된 getContainer컨테이너 개체와 동일한 형식이지만 선택한 버전에서 이전 상태에서 일시 중지됩니다.

예시

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

주요 관찰

새 컨테이너를 만드는 중입니다.

기존 컨테이너를 복구(롤백)하지 않습니다. copyContainer는 원본 컨테이너에서 데이터가 복사되는 새 인스턴스를 제공합니다. 이 프로세스에서는 이전 컨테이너가 삭제되지 않습니다.

새 컨테이너가 분리됨

새 컨테이너는 처음에 detached 상태입니다. 분리된 컨테이너로 계속 작업하거나 즉시 연결할 수 있습니다. attach를 호출한 후 새로 만든 인스턴스를 나타내는 고유한 컨테이너 ID를 다시 가져옵니다.

복구 후 고려 사항

복구 후 시나리오를 중심으로 사용 사례를 빌드할 때 원격 협력자가 모두 동일한 컨테이너에서 다시 작업하도록 하기 위해 애플리케이션에서 수행할 수 있는 몇 가지 고려 사항은 다음과 같습니다.

유동 컨테이너만 사용하여 애플리케이션 데이터를 모델링하는 경우 컨테이너가 손상되면 통신 "링크"가 효과적으로 손상됩니다. 비슷한 실제 예제는 원래 작성자가 참가자와 링크를 공유하고 해당 링크가 더 이상 작동하지 않는 화상 통화일 수 있습니다. 이러한 관점에서 원래 컨테이너의 복사본을 복구한 후 복구 권한을 원래 작성자로 제한하고 원래 링크를 공유한 것과 동일한 방식으로 새 컨테이너 링크를 공유할 수 있도록 하는 옵션이 있습니다.

또는 일시적인 데이터에만 유동 프레임워크를 사용하는 경우 항상 고유한 원본 데이터 및 지원 서비스를 사용하여 보다 자율적인 복구 워크플로를 관리할 수 있습니다. 예를 들어 여러 클라이언트가 앱에 처음 복구된 복사본이 있을 때까지 복구 프로세스를 시작할 수 있습니다. 그러면 앱이 참여하는 모든 클라이언트에게 새 컨테이너로 전환하도록 알릴 수 있습니다. 이는 현재 활성 클라이언트가 참여 그룹의 차단을 해제하여 협업을 진행할 수 있으므로 유용할 수 있습니다. 여기서 고려해야 할 한 가지 고려 사항은 중복으로 인해 발생하는 비용입니다.