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 de forma periódica el estado (denominado resumen), sin ninguna acción de copia de seguridad explícita iniciada por el usuario. Este flujo de trabajo se produce cada (1) minuto si no hay ninguna actividad de usuario o incluso antes si hay más de 1000 operaciones pendientes presentes. Cada operación pendiente se traduce aproximadamente en una acción de usuario individual (selección, entrada de texto, etc.) que aún no se ha sintetizado.

API del cliente de Azure

Hemos agregado los métodos siguientes a AzureClient que permiten a los desarrolladores recuperar datos de contenedores dañados.

getContainerVersions(ID, options)

getContainerVersions permite a los desarrolladores consultar las versiones generadas previamente del contenedor.

copyContainer(ID, containerSchema)

copyContainer permite a los desarrolladores generar un nuevo contenedor desasociado de una versión específica de otro.

Ejemplo de flujo de recuperación

async function recoverDoc(
    client: AzureClient,
    orgContainerId: string,
    containerScema: ContainerSchema,
): Promise<string> {
    /* Collect doc versions */
    let versions: AzureContainerVersion[] = [];
    try {
        versions = await client.getContainerVersions(orgContainerId);
    } catch (e) {
        return Promise.reject(new Error("Unable to get container versions."));
    }

    for (const version of versions) {
        /* Versions are returned in chronological order.
        Attempt to copy doc from next available version */
        try {
            const { container: newContainer } = await client.copyContainer(
                orgContainerId,
                containerSchema,
                version,
            );
            return await newContainer.attach();
        } catch (e) {
            // Error. Keep going.
        }
    }

    return Promise.reject(new Error("Could not recreate document"));
}

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.