Tárolóadatok helyreállítása

Ebben a forgatókönyvben az adat-helyreállítást vizsgáljuk meg. Úgy gondoljuk, hogy az adatok sérültek, amikor a tároló érvénytelen állapotba kerül, ahol nem tudja feldolgozni a további felhasználói műveleteket. A sérült állapot eredménye, hogy a tároló váratlanul bezárul. Gyakran átmeneti állapotról van szó, és újranyitáskor a tároló a várt módon viselkedhet. Abban az esetben, ha egy tároló több újrapróbálkozás után sem töltődik be, api-kat és folyamatokat kínálunk az adatok helyreállításához az alábbiak szerint.

A Dinamikus keretrendszer és az Azure Fluid Relay mentési állapota

A Fluid-keretrendszer rendszeres időközönként menti az állapotot, az úgynevezett összegzést anélkül, hogy a felhasználó által kezdeményezett explicit biztonsági mentési műveletet hajtanak végre. Ez a munkafolyamat minden (1) percben megtörténik, ha nincs felhasználói tevékenység, vagy ha több mint 1000 függőben lévő művelet van jelen. Minden függőben lévő művelet nagyjából lefordít egy egyéni felhasználói műveletre (kiválasztás, szövegbevitel stb.), amelyet még nem foglalt össze.

Azure-ügyfél API-k

A következő metódusokat adtuk hozzá az AzureClienthez, amelyek lehetővé teszik a fejlesztők számára az adatok helyreállítását sérült tárolókból.

getContainerVersions(ID, options)

getContainerVersions lehetővé teszi a fejlesztők számára a tároló korábban létrehozott verzióinak megtekintését.

copyContainer(ID, containerSchema)

copyContainer lehetővé teszi a fejlesztők számára, hogy új leválasztott tárolót generáljanak egy másik tároló adott verziójából.

Példa helyreállítási folyamatra

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

Főbb megfigyelések

Új tárolót hozunk létre

A meglévő tároló helyreállítása (visszagördülése) nem. copyContainer új példányt ad nekünk, és az adatok az eredeti tárolóból lesznek átmásolva. Ebben a folyamatban a régi tároló nem törlődik.

Az új tároló leválasztva

Az új tároló kezdetben állapotban detached van. Folytathatjuk a munkát a leválasztott tárolóval, vagy azonnal csatolhatjuk. A hívás attach után visszakapjuk az újonnan létrehozott példányt képviselő egyedi tárolóazonosítót.

A helyreállítás utáni szempontok

Ha használati eseteket szeretne létrehozni a helyreállítás utáni forgatókönyvek köré, az alábbiakban néhány szempontot figyelembe kell vennie azzal kapcsolatban, hogy az alkalmazás mit szeretne tenni annak érdekében, hogy a távoli közreműködők ismét ugyanazon a tárolón dolgozzanak.

Ha az alkalmazásadatokat kizárólag folyadéktárolók használatával modellezi, a "hivatkozás" kommunikációja gyakorlatilag megszakad a tároló sérülése esetén. Hasonló valós példa lehet a videohívás, ahol az eredeti szerző megosztotta a hivatkozást a résztvevőkkel, és ez a hivatkozás már nem működik. Ezt a perspektívát szem előtt tartva az egyik lehetőség az, hogy a helyreállítási engedélyeket az eredeti szerzőre korlátozza, és lehetővé teszi számukra az új tárolóhivatkozás megosztását ugyanúgy, mint az eredeti hivatkozást, miután helyreállította az eredeti tároló másolatát.

Alternatív megoldásként, ha csak átmeneti adatokhoz használ folyékony keretrendszert, akkor mindig használhatja a saját forrásadatait és a támogató szolgáltatásokat az autonómabb helyreállítási munkafolyamatok kezeléséhez. Előfordulhat például, hogy több ügyfél is elindítja a helyreállítási folyamatot, amíg az alkalmazás nem rendelkezik az első helyreállított másolatsal. Az alkalmazás ezután értesítheti az összes résztvevő ügyfelet egy új tárolóra való áttérésről. Ez hasznos lehet, mivel bármely jelenleg aktív ügyfél feloldhatja a részt vevő csoport letiltását az együttműködés folytatásához. Itt az egyik szempont a redundancia felmerülő költségei.