Share via

コンテナー データの復旧

  • [アーティクル]

このシナリオでは、データ復旧について説明します。 コンテナーが無効な状態に達し、それ以上のユーザー アクションを処理できない場合、データが破損していると見なします。 破損した状態の結果は、コンテナーが予期せず閉じられている状態です。 多くの場合、一時的な状態であり、再度開くと、コンテナーが期待どおりに動作する場合があります。 複数回の再試行の後でもコンテナーの読み込みに失敗する状況では、以下で説明するように、データの復旧に使用できる API とフローを提供しています。

Fluid Framework と Azure Fluid Relay での状態の保存方法

Fluid フレームワークは、ユーザーが明示的なバックアップ アクションを開始することなく、概要と呼ばれる状態を定期的に保存します。 このワークフローは、ユーザー アクティビティがない場合は 1 分ごとに発生し、保留中の操作が 1000 を超える場合はより早く発生します。 保留中の各操作は、まだ要約されていない個々のユーザー アクション (選択、テキスト入力など) に大まかに変換されます。

Azure クライアント API

開発者が破損したコンテナーからデータを回復できるようにする次のメソッドを 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 を呼び出した後、新しく作成されたインスタンスを表す一意のコンテナー ID が返されます。

復旧後の考慮事項

復旧後のシナリオに関するユース ケースの構築について、リモート コラボレーター全員が同じコンテナーで再び作業できるようにするためにアプリケーションで行えることに関するいくつかの考慮事項を次に示します。

流体コンテナーのみを使用してアプリケーション データをモデル化している場合、コンテナーが破損すると、通信 "リンク" が効果的に切断されます。 実際の例と同様に、元の作成者が参加者とリンクを共有し、そのリンクが機能しなくなったビデオ通話があります。 その点に留意して、1 つのオプションとして、復旧アクセス許可を元の作成者に制限し、元のコンテナーのコピーを復旧した後に、元のリンクを共有したのと同じ方法で新しいコンテナー リンクを共有できるようにすることが考えられます。

または、一時的なデータのみに流体フレームワークを使用している場合は、独自の信頼できるソース データとサポート サービスを常に使用して、より自律的な復旧ワークフローを管理できます。 たとえば、アプリで最初の復旧されたコピーが作成されるまで、複数のクライアントで復旧プロセスを開始できます。 その後、アプリは、参加しているすべてのクライアントに新しいコンテナーに移行するように通知できます。 これは、現在アクティブな任意のクライアントで参加しているグループのブロックを解除してコラボレーションを再開できるため便利です。 ここでの考慮事項の 1 つとして、冗長化によってコストが生じることが挙げられます。