استرداد بيانات الحاوية

في هذا السيناريو، نستكشف استرداد البيانات. نعتبر البيانات تالفة عندما تصل الحاوية إلى حالة غير صالحة حيث لا يمكنها معالجة المزيد من إجراءات المستخدم. نتيجة الحالة التالفة هي إغلاق الحاوية بشكل غير متوقع. غالبا ما تكون حالة عابرة، وعند إعادة الفتح، قد تتصرف الحاوية كما هو متوقع. في حالة فشل الحاوية في التحميل حتى بعد إعادة المحاولة المتعددة، نقدم واجهات برمجة التطبيقات والتدفقات التي يمكنك استخدامها لاسترداد بياناتك، كما هو موضح أدناه.

كيف إطار عمل Fluid وحالة حفظ Azure Fluid Relay

يحفظ إطار عمل Fluid الحالة بشكل دوري، ويسمى الملخص، دون أي إجراء نسخ احتياطي صريح بدأه المستخدم. يحدث سير العمل هذا كل دقيقة (1) إذا لم يكن هناك نشاط مستخدم، أو في وقت أقرب إذا كان هناك أكثر من 1000 عمليات معلقة موجودة. تترجم كل عملية معلقة تقريبا إلى إجراء مستخدم فردي (تحديد، إدخال نص وما إلى ذلك) لم يتم تلخيصه بعد.

واجهات برمجة تطبيقات عميل 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 ، سنستعيد معرف الحاوية الفريد، الذي يمثل المثيل الذي تم إنشاؤه حديثا.

اعتبارات ما بعد الاسترداد

عندما يتعلق الأمر بإنشاء حالات استخدام حول سيناريوهات ما بعد الاسترداد، فيما يلي بعض الاعتبارات حول ما قد يرغب التطبيق في القيام به لجعل جميع المتعاونين عن بعد يعملون جميعا على نفس الحاوية مرة أخرى.

إذا كنت تقوم بنمذجة بيانات التطبيق الخاص بك فقط باستخدام حاويات سائلة، يتم قطع الاتصال "ارتباط" بشكل فعال عندما تكون الحاوية تالفة. مثال مماثل في العالم الحقيقي قد يكون مكالمة فيديو حيث شارك المؤلف الأصلي الارتباط مع المشاركين ولم يعد هذا الارتباط يعمل بعد الآن. مع وضع هذا المنظور في الاعتبار، أحد الخيارات هو تقييد أذونات الاسترداد للمؤلف الأصلي والسماح لهم بمشاركة ارتباط حاوية جديد بنفس الطريقة التي شاركوا بها الارتباط الأصلي، بعد استرداد نسخة الحاوية الأصلية.

بدلا من ذلك، إذا كنت تستخدم إطار عمل مرن للبيانات العابرة فقط، يمكنك دائما استخدام بيانات مصدر الحقيقة والخدمات الداعمة الخاصة بك لإدارة مهام سير عمل الاسترداد الأكثر استقلالا. على سبيل المثال، قد تبدأ عدة عملاء عملية الاسترداد حتى يحتوي تطبيقك على أول نسخة تم استردادها. يمكن لتطبيقك بعد ذلك إعلام جميع العملاء المشاركين بالانتقال إلى حاوية جديدة. يمكن أن يكون هذا مفيدا حيث يمكن لأي عميل نشط حاليا إلغاء حظر المجموعة المشاركة لمتابعة التعاون. أحد الاعتبارات هنا هو التكاليف المتكبدة للتكرار.