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

Мақала
06/25/2024

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

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

Fluid Framework периодически сохраняет моментальные снимки данных в контейнере, которые суммируют все изменения, внесенные в данные до этой точки. Во время обычной загрузки извлекается последний моментальный снимок, и все последующие изменения применяются поверх этого состояния.

Если последние моментальные снимки или последующие изменения повреждены, жидкость может не загружать их обычно. В этом случае Fluid предлагает коллекцию API для просмотра сохраненных версий моментальных снимков и загрузки их в режиме только для просмотра без последующих изменений. Это позволяет извлекать и при необходимости внедрять данные в новый контейнер для возобновления совместной работы.

API клиента Azure

API для просмотра и загрузки версий контейнеров

AzureClient имеет следующие методы для поддержки этого сценария:

Получение версий контейнеров

getContainerVersions(id, options?)

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

Parameters:

id: идентификатор контейнера. Это тот же идентификатор, который используется при вызове getContainer.
options?: при необходимости объект параметров для указания:
- maxCount: максимальное количество версий для получения. Если доступно больше версий, чем запрошено, будут получены новейшие версии. Значение по умолчанию: 5

Returns: Обещание, разрешающее массив объектов, представляющих доступные версии (отсортированные до старых). Объекты имеют следующие свойства:

id: идентификатор версии.
- Примечание. Это отличается от идентификатора контейнера и, в частности, ссылается на версию моментального снимка, а не на контейнер.
date: метка времени при создании версии.

Просмотр версии контейнеров

viewContainerVersion(id, containerSchema, version, compatibilityMode)

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

Контейнер загружается в приостановленном состоянии, то есть не будет применять последующие изменения к данным, которые произошли после создания этого моментального снимка. При загрузке в этом состоянии данные контейнера могут быть считываются, но не редактируются.

Parameters:

id: идентификатор контейнера. Это тот же идентификатор, который используется при вызове getContainer.
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 мы вернемся к уникальному идентификатору контейнера, представляющего только что созданный экземпляр.

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

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

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

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

Бөлісу құралы: