Восстановление данных контейнера

Статья
10/24/2023

В этом сценарии мы рассмотрим восстановление данных. Мы считаем, что данные повреждены, когда контейнер достигает недопустимого состояния, в котором он не может обрабатывать дальнейшие действия пользователя. Результат поврежденного состояния является неожиданно закрытым контейнером. Часто это временное состояние, и при повторном открытии контейнер может вести себя должным образом. В ситуации, когда контейнер не загружается даже после нескольких повторных попыток, мы предлагаем API и потоки, которые можно использовать для восстановления данных, как описано ниже.

Сохранение состояния "Fluid Framework" и "Ретранслятор жидкости Azure"

Динамическая платформа периодически сохраняет состояние, вызываемое сводной, без каких-либо явных действий резервного копирования, инициированных пользователем. Этот рабочий процесс происходит каждые 1 минуты, если нет действий пользователя или раньше, если существует более 1000 ожидающих операций. Каждый ожидающий оп примерно преобразуется в отдельное действие пользователя (выбор, ввод текста и т. д.), которое еще не было сведено.

API клиента Azure

Мы добавили следующие методы в AzureClient, которые позволяют разработчикам восстанавливать данные из поврежденных контейнеров.

getContainerVersions(ID, options)

getContainerVersions позволяет разработчикам просматривать ранее созданные версии контейнера.

copyContainer(ID, containerSchema)

copyContainer позволяет разработчикам создавать новый отсоединяемый контейнер из определенной версии другого контейнера.

Пример потока восстановления


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"));
}

Ключевые наблюдения

Мы создадим новый контейнер

Мы не восстанавливаем существующий контейнер (откат). copyContainer будет предоставлять нам новый экземпляр, при этом данные копируются из исходного контейнера. В этом процессе старый контейнер не удаляется.

Отсоединение нового контейнера

Новый контейнер изначально находится в detached состоянии. Мы можем продолжить работу с отсоединением контейнера или немедленно подключиться. После вызова attach мы вернемся к уникальному идентификатору контейнера, представляющего только что созданный экземпляр.

Рекомендации по после восстановления

Когда дело доходит до создания вариантов использования в сценариях после восстановления, ниже приведены несколько рекомендаций о том, что приложение может сделать, чтобы удаленные сотрудники работали над тем же контейнером снова.

Если вы моделируете данные приложения исключительно с помощью гибких контейнеров, обмен данными "ссылка" фактически нарушается при повреждении контейнера. Аналогичный пример реального мира может быть видеозвонком, где исходный автор поделился ссылкой с участниками, и эта ссылка больше не работает. Учитывая это, один из вариантов заключается в ограничении разрешений на восстановление исходного автора и позволить им совместно использовать новую ссылку контейнера таким же образом, как они предоставили исходную ссылку после восстановления копии исходного контейнера.

Кроме того, если вы используете динамную платформу только для временных данных, вы всегда можете использовать собственные исходные данные и вспомогательные службы для управления более автономными рабочими процессами восстановления. Например, несколько клиентов могут запустить процесс восстановления до тех пор, пока приложение не будет восстановлено. Затем приложение может уведомить всех участвующих клиентов о переходе в новый контейнер. Это может быть полезно, так как любой активный клиент в настоящее время может разблокировать участвующие группы, чтобы продолжить совместную работу. Одним из соображений здесь является расходы на избыточность.

Share via