Memulihkan data kontainer

Dalam skenario ini, kami menjelajahi pemulihan data. Kami menganggap data rusak ketika kontainer mencapai status yang tidak valid di mana data tidak dapat memproses tindakan pengguna lebih lanjut. Hasil dari status rusak adalah kontainer yang ditutup secara tiba-tiba. Seringkali status sementara, dan setelah dibuka kembali, kontainer mungkin bersifat seperti yang diharapkan. Dalam situasi di mana kontainer gagal dimuat bahkan setelah beberapa percobaan ulang, kami menawarkan API dan alur yang dapat Anda gunakan untuk memulihkan data Anda, seperti yang dijelaskan di bawah ini.

Bagaimana Fluid Framework dan status penyimpanan Azure Fluid Relay

Kerangka kerja fluida secara berkala menyimpan status, yang disebut ringkasan, tanpa tindakan pencadangan eksplisit yang dimulai oleh pengguna. Alur kerja ini terjadi setiap satu (1) menit jika tidak ada aktivitas pengguna, atau lebih cepat jika ada lebih dari 1000 operasi yang tertunda. Setiap op yang tertunda kira-kira diterjemahkan ke tindakan pengguna individu (pilih, input teks, dll.) yang belum dirangkum.

API klien Azure

Kami menambahkan metode berikut ke AzureClient yang memungkinkan pengembang memulihkan data dari kontainer yang rusak.

getContainerVersions(ID, options)

getContainerVersions memungkinkan pengembang untuk melihat versi kontainer yang dihasilkan sebelumnya.

copyContainer(ID, containerSchema)

copyContainer memungkinkan pengembang untuk menghasilkan kontainer baru yang terlepas dari versi tertentu dari kontainer lain.

Contoh alur pemulihan

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

Pengamatan utama

Kami membuat Kontainer baru

Kami tidak memulihkan (menggulung balik) kontainer yang ada. copyContainer akan memberi kami instans baru, dengan data yang disalin dari kontainer asli. Dalam proses ini, kontainer lama tidak dihapus.

Kontainer Baru dilepas

Kontainer baru awalnya dalam detached status. Kita dapat terus bekerja dengan kontainer yang dilepaskan, atau segera melampirkan. Setelah memanggil attach , kita akan mendapatkan kembali ID Kontainer unik, mewakili instans yang baru dibuat.

Pertimbangan pasca-pemulihan

Dalam hal membangun kasus penggunaan di sekitar skenario pasca-pemulihan, berikut adalah beberapa pertimbangan tentang aplikasi apa yang mungkin ingin dilakukan untuk membuat kolaborator jarak jauh semuanya bekerja pada kontainer yang sama lagi.

Jika Anda memodelkan data aplikasi hanya menggunakan kontainer cairan, komunikasi "tautan" secara efektif rusak saat kontainer rusak. Contoh dunia nyata yang serupa mungkin berupa panggilan video di mana penulis asli berbagi tautan dengan peserta dan tautan tersebut tidak berfungsi lagi. Dengan perspektif tersebut, salah satu opsinya adalah membatasi izin pemulihan kepada penulis asli dan membiarkan mereka berbagi tautan kontainer baru dengan cara yang sama seperti mereka berbagi tautan asli, setelah memulihkan salinan kontainer asli.

Atau, jika Anda menggunakan kerangka kerja fluida hanya untuk data sementara, Anda selalu dapat menggunakan data sumber kebenaran dan layanan pendukung Anda sendiri untuk mengelola alur kerja pemulihan yang lebih otonom. Misalnya, beberapa klien dapat memulai proses pemulihan hingga aplikasi Anda memiliki salinan pertama yang dipulihkan. Aplikasi Anda kemudian dapat memberi tahu semua klien yang berpartisipasi untuk beralih ke kontainer baru. Ini dapat berguna karena klien yang saat ini aktif dapat membuka blokir grup yang berpartisipasi untuk melanjutkan kolaborasi. Salah satu pertimbangan di sini adalah biaya redundansi yang dikeluarkan.