Bagikan melalui

Memulihkan data kontainer

  • Artikel

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

Fluid Framework secara berkala menyimpan rekam jepret data dalam kontainer, yang meringkas semua perubahan yang dilakukan pada data hingga titik tersebut. Selama pemuatan normal, rekam jepret terbaru diambil, dan perubahan berikutnya diterapkan di atas status tersebut.

Jika rekam jepret terbaru atau perubahan berikutnya rusak, Fluid mungkin tidak dapat memuatnya secara normal. Dalam hal ini, Fluid menawarkan kumpulan API untuk melihat versi rekam jepret yang disimpan dan memuatnya dalam mode khusus tampilan tanpa perubahan berikutnya yang diterapkan. Ini memungkinkan data diekstrak dan secara opsional disuntikkan ke dalam kontainer baru untuk melanjutkan kolaborasi.

API klien Azure

API untuk melihat dan memuat versi kontainer

AzureClient memiliki metode berikut untuk mendukung skenario ini:

Mendapatkan versi kontainer

getContainerVersions(id, options?)

Ambil daftar versi yang tersedia yang mungkin dimuat.

Parameters:

  • id: ID kontainer. Ini adalah ID yang sama yang digunakan saat memanggil getContainer.
  • options?: Secara opsional, objek opsi untuk menentukan:
    • maxCount: Jumlah maksimum versi yang akan diambil. Jika ada lebih banyak versi yang tersedia daripada yang diminta, versi terbaru akan diambil. Default: 5

Returns: Janji yang diselesaikan ke array objek yang mewakili versi yang tersedia (diurutkan terbaru ke terlama). Objek memiliki properti berikut:

  • id: ID versi.
    • Catatan: Ini berbeda dari ID kontainer, dan secara khusus mereferensikan versi rekam jepret daripada kontainer.
  • date: Tanda waktu saat versi dibuat.

Menampilkan versi kontainer

viewContainerVersion(id, containerSchema, version, compatibilityMode)

Muat versi kontainer tertentu untuk ditampilkan saja. Versi apa pun yang diambil dari getContainerVersions dapat digunakan, tetapi untuk tujuan memulihkan data yang rusak, disarankan untuk memulai dengan versi terbaru dan bekerja mundur untuk menemukan versi terbaru yang tidak rusak.

Kontainer dimuat dalam status dijeda, yang berarti tidak akan menerapkan perubahan berikutnya pada data yang terjadi setelah pembuatan rekam jepret tersebut. Ketika dimuat dalam status ini, data kontainer mungkin dibaca, tetapi tidak diedit.

Parameters:

  • id: ID kontainer. Ini adalah ID yang sama yang digunakan saat memanggil getContainer.
  • containerSchema: Skema kontainer. Ini adalah skema yang sama yang digunakan saat memanggil getContainer.
  • version: Objek versi yang merujuk pada versi yang akan dimuat. Objek versi dapat diambil melalui getContainerVersions.
  • compatibilityMode: Mode kompatibilitas. Ini adalah mode kompatibilitas yang sama yang digunakan saat memanggil getContainer.

Returns: Janji yang diselesaikan ke objek yang mewakili kontainer yang dimuat dengan satu properti:

  • container: Objek kontainer. Ini adalah jenis objek yang sama dengan objek kontainer yang dikembalikan oleh getContainer, tetapi dijeda dalam keadaan sebelumnya dari versi yang dipilih.

Contoh

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();

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.