Recuperación de datos de contenedor

En este escenario, se explora la recuperación de datos. Se considera que los datos están dañados cuando el contenedor alcanza un estado no válido en el que no puede procesar más acciones de usuario. Como resultado de este estado dañado, el contenedor se cierra de forma inesperada. Normalmente, se trata de un estado transitorio y, al volver a abrirse, el contenedor puede comportarse según lo esperado. En el supuesto de que un contenedor no se cargue, incluso después de varios intentos, puede usar las API y los flujos para recuperar los datos, tal como se describe a continuación.

Cómo guardan Fluid Framework y Azure Fluid Relay el estado

Fluid Framework guarda periódicamente instantáneas de los datos del contenedor, que resumen todos los cambios realizados en los datos hasta ese momento. Durante la carga normal de la instantánea más reciente se recupera y los cambios posteriores se aplican encima de ese estado.

Si la instantánea más reciente o los cambios posteriores están dañados, es posible que Fluid no pueda cargarlos normalmente. En este caso, Fluid ofrece una colección de API para ver las versiones de instantáneas almacenadas y cargarlas en un modo de solo vista sin que se apliquen cambios posteriores. Esto permite que los datos se extraigan y, opcionalmente, se inserten en un nuevo contenedor para reanudar la colaboración.

API del cliente de Azure

API para ver y cargar versiones de contenedor

AzureClient tiene los métodos siguientes para admitir este escenario:

Obtención de versiones de contenedor

getContainerVersions(id, options?)

Recupere una lista de versiones disponibles desde las que se puede cargar.

Parameters:

• id: el identificador del contenedor. Este es el mismo identificador que se usa al llamar a getContainer.
• options?: opcionalmente, un objeto options que se va a especificar:
  • maxCount: número máximo de versiones que se van a recuperar. Si hay más versiones disponibles de las solicitadas, se recuperarán las versiones más recientes. Predeterminado: 5

Returns: Promesa que se resuelve en una matriz de objetos que representan versiones disponibles (ordenadas más recientes a más antiguas). Los objetos tienen las siguientes propiedades:

• id: identificador de versión.
  • Nota: Esto es diferente del identificador de contenedor y hace referencia específicamente a una versión de instantánea en lugar del contenedor.
• date: marca de tiempo cuando se generó la versión.

Visualización de la versión del contenedor

viewContainerVersion(id, containerSchema, version, compatibilityMode)

Cargue una versión específica de un contenedor solo para su visualización. Se puede usar cualquier versión recuperada de getContainerVersions , pero para recuperar datos dañados, se recomienda empezar con la versión más reciente y trabajar con versiones anteriores para encontrar la versión más reciente no interrumpida.

El contenedor se carga en un estado en pausa, lo que significa que no aplicará los cambios posteriores a los datos que se produjeron después de la generación de esa instantánea. Cuando se carga en este estado, se pueden leer los datos del contenedor, pero no editarlos.

Parameters:

• id: el identificador del contenedor. Este es el mismo identificador que se usa al llamar a getContainer.
• containerSchema: el esquema del contenedor. Este es el mismo esquema que se usa al llamar a getContainer.
• version: objeto de versión desde el que se hace referencia a la versión desde la que se va a cargar. El objeto de versión se puede recuperar a través de getContainerVersions.
• compatibilityMode: modo de compatibilidad. Este es el mismo modo de compatibilidad que se usa al llamar a getContainer.

Returns: Promesa que se resuelve en un objeto que representa el contenedor cargado con una sola propiedad:

• container: el objeto contenedor. Este es el mismo tipo de objeto que el objeto contenedor devuelto por getContainer, pero está en pausa en su estado anterior de la versión seleccionada.

Ejemplo

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

Observaciones clave

Creación de un nuevo contenedor

No se trata de recuperar (revertir) el contenedor existente. copyContainer proporcionará una nueva instancia, con los datos que se copian del contenedor original. En este proceso, el contenedor antiguo no se elimina.

Se desasocia el nuevo contenedor

El nuevo contenedor al principio se encuentra en estado detached. Es posible seguir trabajando con un contenedor desasociado o adjuntarlo de forma inmediata. Después de llamar a attach, se recuperará el id. de contenedor único, que representará la instancia recién creada.

Consideraciones posteriores a la recuperación

En lo que respecta a la creación de casos de uso en torno a escenarios posteriores a la recuperación, a continuación se indican algunas consideraciones sobre lo que podría querer hacer la aplicación para que sus colaboradores remotos vuelvan a trabajar en el mismo contenedor.

Si va a modelar los datos de la aplicación únicamente mediante contenedores fluidos, la comunicación "vínculo" se interrumpe eficazmente cuando el contenedor está dañado. Un ejemplo similar del mundo real puede ser videollamada donde el autor original compartió el vínculo con los participantes y ese vínculo ya no funciona. Teniendo en cuenta esa perspectiva, una opción es limitar los permisos de recuperación al autor original y permitirle que comparta un nuevo vínculo de contenedor de la misma manera en que compartió el vínculo original, después de recuperar la copia del contenedor original.

Como alternativa, si usa fluid framework solo para datos transitorios, siempre puede usar sus propios datos de origen de verdad y servicios auxiliares para administrar flujos de trabajo de recuperación más autónomos. Por ejemplo, varios clientes pueden iniciar el proceso de recuperación hasta que la aplicación tenga una primera copia recuperada. A continuación, la aplicación puede notificar a todos los clientes participantes que realicen la transición a un nuevo contenedor. Esto puede ser útil, ya que cualquier cliente activo actualmente puede desbloquear el grupo participante para continuar con la colaboración. Una consideración aquí son los costos de redundancia en los que se incurre.