Wskazówki dotyczące odtwarzania po awarii dopasowane do specyficznych doświadczeń

Ten artykuł zawiera specyficzne dla doświadczenia wskazówki dotyczące odzyskania danych Fabric w przypadku regionalnej katastrofy.

Przykładowy scenariusz

Wiele sekcji z instrukcjami w tym artykule wykorzystuje poniższy przykładowy scenariusz do celów objaśnienia i zilustrowania. W razie potrzeby zapoznaj się z tym scenariuszem.

Załóżmy, że masz pojemność C1 w regionie A z obszarem roboczym W1. Jeśli włączyłeś odzyskiwanie po awarii dla pojemności C1, dane OneLake są replikowane do kopii zapasowej w regionie B. Jeśli w regionie A wystąpią zakłócenia, usługa Fabric w C1 przełącza się do regionu B.

Na poniższej ilustracji przedstawiono ten scenariusz. Pudełko po lewej stronie pokazuje obszar zakłóceń. Pole w środku reprezentuje ciągłą dostępność danych po przejściu w tryb failover, a pole po prawej stronie pokazuje pełną sytuację po tym, jak klient działa w celu przywrócenia usług do pełnej funkcji.

Oto ogólny plan odzyskiwania:

1. Utwórz nową pojemność C2 dla Fabric w nowym regionie.

2. Utwórz nowy obszar roboczy W2 w języku C2, w tym odpowiadające mu elementy o takich samych nazwach jak w C1. W1.

3. Skopiuj dane z zakłóconego C1.W1 do C2.W2.

4. Postępuj zgodnie z dedykowanymi instrukcjami dla każdego składnika, aby przywrócić elementy do pełnej funkcji.

Plan odzyskiwania zakłada, że macierzysty region dzierżawcy pozostaje operacyjny. Jeśli region macierzysty najemcy doświadczy awarii, kroki opisane w tym artykule zależą od jego odzyskania, które musi zostać najpierw zainicjowane i ukończone przez Microsoft.

Plany przywracania specyficzne dla doświadczeń użytkownika

Poniższe sekcje zawierają krok po kroku przewodniki dotyczące każdego doświadczenia Fabric, które pomogą Ci przejść przez proces rekonwalescencji.

Inżynieria danych

Ten przewodnik przeprowadzi Cię przez procedury odzyskiwania w środowisku inżynierii danych. Obejmuje domy nad jeziorem, notebooki, definicje zadań w Spark, funkcje danych użytkownika oraz API GraphQL.

Lakehouse

Domy nad jeziorem z oryginalnego regionu są niedostępne dla klientów. Aby odzyskać Lakehouse, klienci mogą ponownie utworzyć ją w obszarze roboczym C2.W2. Zalecamy dwa podejścia do odzyskiwania jezior:

Podejście 1: Użycie niestandardowego skryptu do kopiowania tabel Delta i plików Lakehouse

Użytkownicy mogą odtworzyć lakehouse'y przy użyciu niestandardowego skryptu języka Scala.

1. Utwórz jezioro (na przykład LH1) w nowo utworzonym obszarze roboczym C2. W2.

2. Utwórz nowy notes w obszarze roboczym C2. W2.

3. Aby odzyskać tabele i pliki z oryginalnego Lakehouse’u, odwołaj się do danych ze ścieżkami OneLake, takimi jak abfss (zobacz Połączenie z usługą Microsoft OneLake). Możesz użyć następującego przykładu kodu (zobacz Wprowadzenie do Microsoft Spark Utilities) w notesie, aby uzyskać ścieżki ABFS plików i tabel z oryginalnego lakehouse. (Zastąp element C1.W1 rzeczywistą nazwą obszaru roboczego)

   notebookutils.fs.ls('abfs[s]://<C1.W1>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/<Tables>/<fileName>')
   

4. Użyj poniższego przykładu kodu, aby skopiować tabele i pliki do nowo utworzonego systemu lakehouse.

   1. W przypadku tablic Delta, należy skopiować każdą tabelę pojedynczo, aby odtworzyć dane w nowym lakehouse. W przypadku plików typu Lakehouse można skopiować pełną strukturę plików ze wszystkimi folderami bazowymi w ramach pojedynczej operacji.

   2. Skontaktuj się z zespołem pomocy technicznej, aby uzyskać znacznik czasu przełączenia awaryjnego wymagany w skrypcie.

   %%spark
   val source="abfs path to original Lakehouse file or table directory"
   val destination="abfs path to new Lakehouse file or table directory"
   val timestamp= //timestamp provided by Support
   
   notebookutils.fs.cp(source, destination, true)
   
   val filesToDelete = notebookutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelete <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelete.name}"
       println(s"Deleting file $destFileToDelete")
       notebookutils.fs.rm(destFileToDelete, false)
   }
   
   notebookutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. Po uruchomieniu skryptu tabele pojawią się w nowym lakehouse.

Podejście 2. Używanie Eksplorator usługi Azure Storage do kopiowania plików i tabel

Aby odzyskać tylko określone pliki lub tabele z oryginalnego Lakehouse, użyj Eksplorator usługi Azure Storage. Aby uzyskać szczegółowe instrukcje, zobacz Integrate OneLake with Eksplorator usługi Azure Storage. W przypadku dużych rozmiarów danych użyj podejścia 1.

Odzyskiwanie materializowanych widoków w Fabric Data Lake

Po przełączeniu awaryjnym nie można uzyskać dostępu do zmaterializowanych widoków jeziora w oryginalnym regionie. Proces przełączania awaryjnego nie replikuje harmonogramów odświeżania ani historii wykonania do regionu pomocniczego. Aby odzyskać te elementy, wykonaj następujące kroki po odzyskaniu danych z Lakehouse:

• Odzyskaj tabele Lakehouse, korzystając z podejścia 1 lub podejścia 2 opisanego wcześniej w tym artykule. Skopiuj tylko tabele źródłowe.
• Odzyskaj notesy zawierające definicje MLV. Kroki powrotu do zdrowia znajdziesz w sekcji Notatnik .
• Uruchom odzyskane notesy, aby ponownie utworzyć MLV w nowym Lakehouse. Aby uzyskać informacje na temat tworzenia zmaterializowanego widoku jeziora, zobacz Create a Materialized Lake View. Jeśli we wcześniejszym kroku skopiowano MLV, podczas ich ponownego tworzenia użyj CREATE OR REPLACE.
• Ręcznie odtwórz harmonogramy odświeżania MLV w nowym obszarze roboczym. Nie da się odzyskać historii harmonogramu ani metryk wykonania.
• Sprawdź i w razie potrzeby zaktualizuj odwołania do Lakehouse ID i dataset ID, jeśli twoje MLVs dostarczają dane do semantycznych modeli lub raportów. Ponownie połącz raporty ze zaktualizowanym modelem semantycznym i zweryfikuj świeżość danych.

Notatnik

Notebooki z regionu głównego pozostają niedostępne dla klientów, a kod w notatnikach nie replikuje się do regionu drugotnego. Aby odzyskać kod notatnika w nowym regionie, użyj jednego z następujących sposobów.

Podejście 1. Nadmiarowość zarządzana przez użytkownika z integracją z usługą Git (w publicznej wersji zapoznawczej)

Użyj integracji z Fabric Git, aby zsynchronizować swój notatnik z repozytorium Azure DevOps (ADO). Po przełączeniu usługi awaryjnie do innego regionu użyj repozytorium, aby odtworzyć notes w nowym obszarze roboczym, który utworzyłeś.

1. Skonfiguruj integrację z usługą Git dla obszaru roboczego i wybierz pozycję Połącz i zsynchronizuj z repozytorium ADO.

   

   Na poniższej ilustracji przedstawiono zsynchronizowany notes.

   

2. Odzyskaj notebook z repozytorium ADO.

   1. W nowo utworzonym obszarze roboczym ponownie połącz się z repozytorium Azure ADO.

      

   2. Wybierz przycisk Kontrola źródła . Następnie wybierz gałąź repozytorium odpowiednią dla danego zadania. Następnie wybierz pozycję Aktualizuj wszystko. Oryginalny laptop zostanie wyświetlony.

      

      

   3. Jeśli oryginalny notes ma domyślny domek nad jeziorem, sprawdź sekcję Domek nad jeziorem , aby go odzyskać, a następnie połącz nowo odzyskany domek nad jeziorem z nowo odzyskanym zeszytem.

      

   4. Integracja z usługą Git nie obsługuje synchronizowania plików, folderów ani migawek notesu w Eksploratorze zasobów notesu.

      1. Jeśli oryginalny notes zawiera pliki w Eksploratorze zasobów notesu:

         1. Zapisz pliki lub foldery na lokalny dysk lub w innym miejscu.

         2. Ponownie przekaż plik z dysku lokalnego lub dysków w chmurze do odzyskanego notesu.

      2. Jeśli oryginalny notatnik zawiera migawkę notatnika, zapisz również migawkę notatnika we własnym systemie kontroli wersji lub na dysku lokalnym.

         

         

Aby uzyskać więcej informacji na temat integracji z usługą Git, zobacz Wprowadzenie do integracji z usługą Git.

Podejście 2. Ręczne podejście do tworzenia kopii zapasowej zawartości kodu

Jeśli nie wybierzesz podejścia integracji z Gitem, zapisz najnowszą wersję kodu, pliki w eksploratorze zasobów i migawkę notatnika w systemie kontroli wersji, takim jak Git. Ręcznie odzyskaj zawartość notatnika po awarii:

1. Użyj funkcji Importuj notes, aby zaimportować kod notatnika, który chcesz odzyskać.

   

2. Po zaimportowaniu przejdź do żądanego obszaru roboczego (na przykład "C2. W2") w celu uzyskania do niego dostępu.

3. Jeśli oryginalny notatnik ma domyślny lakehouse, zapoznaj się z sekcją Lakehouse. Następnie połącz nowo odzyskaną usługę lakehouse (która ma taką samą zawartość jak oryginalna domyślna usługa Lakehouse) do nowo odzyskanego notesu.

4. Jeśli oryginalny notes zawiera pliki lub foldery w Eksploratorze zasobów, przekaż ponownie pliki lub foldery zapisane w systemie kontroli wersji użytkownika.

Definicja zadania platformy Spark

Definicje zadań spark (SJD) z regionu głównego pozostają niedostępne, a OneLake replikuje główny plik definicji i plik referencyjny w notatniku do regionu wtórnego. Jeśli chcesz odzyskać SJD w nowym regionie, wykonaj ręczne czynności opisane w tej sekcji. Historyczne przebiegi SJD nie zostały odzyskane.

Elementy SJD można odzyskać, kopiując kod z oryginalnego regionu przy użyciu Eksplorator usługi Azure Storage oraz ręcznie ponownie łącząc odniesienia do usługi Lakehouse po wystąpieniu awarii.

1. Utwórz nowy element SJD (na przykład SJD1) w nowym workspace C2. W2, z tymi samymi ustawieniami i konfiguracjami co oryginalny element SJD (na przykład język, środowisko itd.).

2. Użyj Eksplorator usługi Azure Storage, aby skopiować Libs, Mains i migawki z oryginalnego elementu SJD do nowego elementu SJD.

   

3. Zawartość kodu jest wyświetlana w nowo utworzonym SJD. Musisz ręcznie dodać nowo odzyskane odniesienie do Lakehouse do zadania (patrz kroki odzyskiwania Lakehouse). Użytkownicy muszą ręcznie ponownie wprowadzać oryginalne argumenty wiersza poleceń.

   

Teraz możesz uruchomić lub zaplanować nowo odzyskane SJD.

Aby uzyskać szczegółowe informacje na temat Eksplorator usługi Azure Storage, zobacz Integracja OneLake z Eksplorator usługi Azure Storage.

Funkcje danych użytkownika

Aby odzyskać funkcje danych użytkownika w zdrowym obszarze, zastosuj jedno z następujących sposobów.

Podejście 1: Z integracją z Gitem (zalecane)

Preferowanym mechanizmem odzyskiwania jest integracja z Fabric Git. Synchronizując projekty funkcji danych użytkownika z repozytorium Azure DevOps lub GitHub, można szybko odtworzyć je w nowym obszarze roboczym po przełączeniu awaryjnym.

Przygotuj się przed katastrofą

1. Konfiguruj integrację Fabric Git dla przestrzeni roboczej, która hostuje funkcję danych użytkownika.
2. Połącz przestrzeń roboczą z repozytorium Azure DevOps lub GitHub.
3. Zatwierdź wszystkie dane użytkownika w repozytorium i regularnie synchronizuj zmiany.
4. Jeśli jest to konieczne, przechowuj ustawienia specyficzne dla środowiska osobno w bibliotekach zmiennych.

Kroki odzyskiwania

Po katastrofie regionalnej:

1. Stwórz nową moc Fabric w zdrowym regionie, takim jak C2.
2. Utwórz nową przestrzeń roboczą, na przykład W2, w nowej pojemności.
3. Połącz workspace z tym samym repozytorium Azure DevOps lub GitHub.
4. Otwórz Kontrola źródła i zsynchronizuj zawartość repozytorium z obszarem roboczym.
5. Odtworzenie lub odzyskanie wszystkich zależnych zasobów Fabric, takich jak domy nad jeziorem, bazy SQL w Fabric, magazyny i wydarzenia biznesowe.
6. Przekonfiguruj funkcje danych użytkownika.
7. Walidacja wykonywania funkcji i łączności zależności.
8. Zaktualizuj aplikacje podrzędne, potoki danych lub inne zintegrowane systemy, aby odwoływały się do przywróconych funkcji.
9. Przeprowadz pełną weryfikację wszystkich swoich scenariuszy.

Istotne zagadnienia

• Integracja z Gitem odzyskuje tylko kod źródłowy i zasoby projektu.
• Historyczne dzienniki egzekucji nie zostały odzyskane.
• Systemy podrzędne mogą wymagać ponownego powiązania punktów końcowych.

Więcej informacji można znaleźć w artykule Funkcje danych użytkownika, kontrola źródeł i wdrożenie.

Podejście 2: Ręczne odzyskiwanie

Jeśli integracja z Gitem nie była skonfigurowana przed katastrofą, można ręcznie odtworzyć funkcje danych użytkownika na podstawie kopii zapasowych kodu źródłowego.

Przygotuj się przed katastrofą

Regularnie wykonuj następujące zadania i przechowuj elementy w zewnętrznym repozytorium kontroli wersji lub w miejscu kopii zapasowej:

• Eksportuj kod źródłowy funkcji do repozytorium GitHub.
• Dokumentuj i przechowuj informacje o zależnościach.
• Ustawienia środowiska dokumentu.

Kroki odzyskiwania

Po katastrofie regionalnej:

1. Stwórz nową moc Fabric w zdrowym regionie, takim jak C2.
2. Stwórz nową przestrzeń roboczą, na przykład W2.
3. Odzyskaj wszystkie zasoby wymagane przez tę funkcję, w tym domy nad jeziorem, bazy danych SQL w Fabric, magazyny, eventhouse i usługi zewnętrzne.
4. Stwórz nowy projekt funkcji danych użytkownika.
5. Importuj lub odtworz kod źródłowy funkcji.
6. Ponownie zastosuj ustawienia konfiguracji środowiska uruchomieniowego.
7. Przeinstaluj wszystkie zależności funkcji.
8. Wdróż funkcję ponownie.
9. Przekonfiguruj uwierzytelnianie i autoryzację.
10. Odtwórz wydawców lub odbiorców Business Event, jeśli są używani.
11. Wykonaj kompleksowe testy walidacyjne dla swoich scenariuszy i integracji.

GraphQL

Elementy GraphQL z regionu podstawowego nie są dostępne po awarii regionalnej, a definicje i konfiguracje graphQL nie są replikowane do regionu pomocniczego. Aby odzyskać język GraphQL w nowym regionie, użyj jednej z poniższych metod.

Podejście 1: Redundancja zarządzana przez użytkownika z integracją z Gitem

Najlepszym sposobem na uproszczenie i przyspieszenie tego procesu jest użycie integracji usługi Fabric z usługą Git, a następnie zsynchronizowanie elementu GraphQL z repozytorium ADO. Po przejściu usługi w tryb failover do innego regionu możesz użyć repozytorium, aby ponownie skompilować bibliotekę GraphQL w nowo utworzonym obszarze roboczym.

1. Utwórz nowy obszar roboczy w pojemności docelowej i regionie.

2. Odzyskaj wszystkie zależne źródła danych, takie jak Lakehouse, Warehouse lub bazy danych SQL, postępując zgodnie z odpowiednimi krokami odzyskiwania dla każdego z nich.

3. Zaktualizuj definicję GraphQL, aby wskazywać na nowo odzyskane zasoby poprzez modyfikację odniesień specyficznych dla środowiska, takich jak identyfikatory przestrzeni roboczej źródłowej, identyfikatory elementów źródłowych oraz szczegóły połączeń. Ten krok zapewnia prawidłowe powiązanie w czasie wdrażania.

4. Wdroż ponownie elementy GraphQL z repozytorium Git do nowej przestrzeni roboczej. Ten krok ponownie utworzy strukturę interfejsu API i konfigurację przy użyciu zaktualizowanych definicji.

5. Ponownie zastosuj ustawienia elementów, w tym role, kontrolę dostępu i konfigurację uwierzytelniania.

6. Ponownie przypisz odwołania do punktu końcowego, aktualizując wszystkie aplikacje lub integracje tak, aby korzystały z nowo utworzonego punktu końcowego GraphQL.

7. Zaktualizuj wszystkie istniejące potoki wdrażania wskazujące stary obszar roboczy, aby odwoływać się do nowo utworzonego obszaru roboczego.

8. Zweryfikuj kompleksową funkcjonalność interfejsu API.

Podejście 2. Podejście ręczne

Jeśli nie zastosujesz podejścia do integracji z usługą Git, możesz użyć następującego ręcznego podejścia do odzyskania języka GraphQL.

1. Utwórz nowy obszar roboczy w pojemności docelowej i regionie.

2. Odzyskaj wszystkie zależne źródła danych, takie jak Lakehouse, Warehouse lub BAZY danych SQL.

3. Odtwórz ręcznie interfejs API GraphQL w nowym obszarze roboczym, uwzględniając definicje schematu, połączenia ze źródłami danych i relacje.

4. Ponownie zastosuj ustawienia elementów, w tym role, kontrolę dostępu i konfigurację uwierzytelniania.

5. Ponownie przypisz odwołania do punktu końcowego, aktualizując wszystkie aplikacje lub integracje tak, aby korzystały z nowo utworzonego punktu końcowego GraphQL.

6. Zaktualizuj wszystkie istniejące potoki wdrażania wskazujące stary obszar roboczy, aby odwoływać się do nowo utworzonego obszaru roboczego.

7. Zweryfikuj kompleksową funkcjonalność interfejsu API.

Istotne zagadnienia

1. Narzędzie GraphQL opiera się na zależnościach zewnętrznych (takich jak Lakehouse, Warehouse i SQL), które należy odzyskać przed wdrożeniem programu GraphQL.

2. Definicje interfejsu API GraphQL obejmują odwołania specyficzne dla środowiska (takie jak sourceWorkspaceId i sourceItemId). Podczas odzyskiwania w nowym regionie odwołania te mogą stać się nieprawidłowe. Zaktualizuj je, aby wskazywały nowo zaaprowizowane zasoby.

3. Automatyczne łączenie źródeł danych nie jest gwarantowane w scenariuszach odzyskiwania po awarii, zwłaszcza w przypadku korzystania z zapisanych poświadczeń lub połączeń między obszarami roboczymi.

4. Inne ustawienia elementu, takie jak monitorowanie, autoryzacja, RBAC, introspekcja i nie tylko, nie są przenoszone po przełączeniu awaryjnym. Należy ponownie ustanowić te ustawienia w nowym regionie.

References

• Omówienie integracji Fabric Git — Microsoft Fabric | Microsoft Learn

• Kontrola wersji i potoki wdrażania w interfejsie API dla platformy GraphQL — Microsoft Fabric | Microsoft Learn 

App

System nie replikuje aplikacji Fabric, w tym ich kodu, konfiguracji i metadanych, do regionów drugorzędnych. Jeśli region podstawowy ulegnie awarii, aplikacja pozostanie niedostępna. Do odzyskiwania przechowuj kod źródłowy aplikacji poza systemem w GitHub, Azure DevOps lub innym systemie kontroli wersji. Odzyskuj dane aplikacji osobno, stosując się do wytycznych dotyczących odzyskiwania po awarii dla każdego bazowego magazynu danych Fabric.

Podejście ręczne

Możesz ręcznie odzyskać aplikację Fabric po regionalnej awarii, korzystając z kodu źródłowego aplikacji i CLI Rayfin. 

Prerequisites 

Zanim dojdzie do katastrofy:

• Przechowuj kod źródłowy Fabric App w GitHub, Azure DevOps lub innym repozytorium kontroli wersji. 

• Dokumentuj proces powrotu do zdrowia.  

Kroki odzyskiwania 

1. Utwórz nowy obszar roboczy w pojemności docelowej i regionie. 

2. Odzyskaj zależne zasoby przed ponownym wdrożeniem aplikacji.  

3. Pobierz najnowszy kod źródłowy Fabric App z repozytorium kontroli wersji lub lokalnej kopii zapasowej. 

4. Z katalogu źródłowego aplikacji wdróż aplikację Fabric App do obszaru roboczego odzyskiwania za pomocą narzędzia Rayfin CLI. Uruchom rayfin up --workspace <new workspace>. 

5. Odzyskaj podrzędny element aplikacji (bazę danych SQL w usłudze Fabric), postępując zgodnie z odpowiednimi procedurami odzyskiwania.  

6. Ponownie zastosuj ustawienia na poziomie przedmiotów, w tym role i kontrolę dostępu w razie potrzeby.  

7. Weryfikacja funkcjonalności aplikacji i zapewnienie użytkownikom odpowiednich uprawnień.  

Ważny 

• Utrzymywanie kodu źródłowego Fabric App poza regionem Fabric, aby umożliwić odzyskiwanie.  

• Dane aplikacji w bazie danych nie są odzyskiwane w ramach procesu wdrażania aplikacji Fabric i muszą być przywracane osobno.  Możesz ręcznie odzyskać aplikację Fabric po regionalnej awarii, korzystając z kodu źródłowego aplikacji i CLI Rayfin. 

Nauka o danych

Ten przewodnik krok po kroku przeprowadza przez procedury odzyskiwania doświadczenia związanego z nauką o danych. Obejmuje ona modele uczenia maszynowego i eksperymenty.

Model i eksperyment ML

Elementy Data Science z regionu pierwotnego pozostają niedostępne dla klientów, a zawartość i metadane w modelach ML i eksperymentach nie replikują się do regionu wtórnego. Aby w pełni odzyskać je w nowym regionie, zapisz zawartość kodu w systemie kontroli wersji (takim jak Git) i ręcznie ponownie uruchom zawartość kodu po awarii.

1. Odzyskaj notatnik. Zapoznaj się z krokami odzyskiwania notesu.

2. Konfiguracja, historyczne metryki uruchomień i metadane nie są replikowane do sparowanego regionu. Musisz ponownie uruchomić każdą wersję kodu data science, aby w pełni odzyskać modele ML i eksperymenty po katastrofie.

Data Warehouse

Ten przewodnik przeprowadza Cię przez procedury odzyskiwania Fabric Data Warehouse obciążenia pracą. Obejmuje przedmioty magazynowe.

Magazyn

Nie możesz uzyskać dostępu do magazynów z oryginalnego regionu. Aby odzyskać magazyny, wykonaj następujące dwa kroki.

1. Stwórz nowy tymczasowy dom nad jeziorem w obszarze roboczym C2. W2 dla danych, które kopiujesz z oryginalnego magazynu.

2. Wypełnij tabele Delta magazynu, korzystając z Eksploratora magazynu oraz funkcji T-SQL (patrz Tabele w Fabric Data Warehouse).

Pozyskiwanie danych za pośrednictwem usługi Lakehouse i kodu T-SQL

W nowo utworzonym obszarze roboczym C2. W2:

1. Utwórz tymczasowy lakehouse „LH2” w C2.W2.

2. Odzyskaj tabele Delta w tymczasowym Lakehouse z oryginalnego magazynu, wykonując kroki odzyskiwania Lakehouse.

3. Utwórz nowy magazyn "WH2" w C2.W2.

4. Połącz tymczasowy magazyn lakehouse w Eksploratorze magazynu.

5. W zależności od tego, jak wdrażasz definicje tabel przed importem danych, faktyczny T-SQL używany do importu może się różnić. Aby odzyskać tabele Warehouse z lakehouse'ów, możesz użyć podejścia INSERT INTO, SELECT INTO lub CREATE TABLE AS SELECT. W poniższym przykładzie używamy INSERT INTO. Jeśli używasz poniższego kodu, zastąp próbki rzeczywistymi nazwami tabel i kolumn.

   USE WH1
   
   INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])
   
   SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
   FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
   GO
   

6. Zmień parametry połączenia w aplikacjach korzystających z Twojego magazynu Fabric.

Dublowana baza danych

Klienci nie mają dostępu do lustrzanych baz danych z regionu głównego, a ustawienia nie replikują się do regionu wtórnego. Aby odzyskać lustrzaną bazę danych po awarii regionalnej, należy odtworzyć ją w innym obszarze roboczym w innym regionie.

Data Factory

Klienci nie mogą uzyskać dostępu do elementów Data Factory z regionu głównego, a ustawienia i konfiguracja w potokach lub elementach Dataflow Gen2 nie replikują się do regionu wtórnego. Aby odzyskać te elementy po awarii regionalnej, musisz odtworzyć elementy integracji danych w innym obszarze roboczym z innego regionu. W poniższych sekcjach opisano szczegóły.

Przepływy danych Gen2

Aby odzyskać element Dataflow Gen2 w nowym regionie, wyeksportuj .pqt plik do systemu kontroli wersji, takiego jak Git, a następnie ręcznie odzyskaj zawartość Dataflow Gen2 po awarii.

1. Z elementu Dataflow Gen2, w zakładce Home edytora Power Query, wybierz szablon Eksport.

   

2. W oknie dialogowym Eksport szablonu wpisz nazwę (obowiązkową) oraz opis (opcjonalny) dla tego szablonu. Gdy skończysz kliknij OK.

   

3. Po awarii utwórz nowy element Dataflow Gen2 w nowym obszarze roboczym "C2. W2".

4. W bieżącym okienku widoku edytora Power Query wybierz pozycję Importuj z szablonu Power Query.

   

5. W oknie Otwórz przejdź do domyślnego folderu pobieranych plików i wybierz plik, .pqt który zapisałeś w poprzednich krokach. Następnie wybierz pozycję Otwórz.

6. Szablon zostanie następnie zaimportowany do nowego elementu dataflow Gen2.

Funkcja Zapisz jako dla przepływów danych nie jest wspierana w przypadku odzyskiwania po awarii.

Pipelines

Klienci nie mogą uzyskać dostępu do potoków w przypadku awarii regionalnej, a konfiguracje nie są replikowane do sparowanego regionu. Buduj swoje kluczowe pipeline'y w wielu przestrzeniach roboczych w różnych regionach.

Zadanie kopiowania

Użytkownicy zadania CopyJob muszą podjąć aktywne środki w celu ochrony przed awarią regionalną. Poniższe podejście gwarantuje, że po awarii regionalnej zadania CopyJob użytkownika pozostaną dostępne.

Redundancja zarządzana przez użytkownika z integracją z Git (w publicznej wersji próbnej)

Najlepszym sposobem na ułatwienie i przyspieszenie tego procesu jest użycie integracji z Fabric Git, a następnie synchronizacja CopyJobu z repozytorium Azure DevOps. Po przejściu usługi w tryb failover do innego regionu możesz użyć repozytorium, aby ponownie skompilować zadanie CopyJob w nowo utworzonym obszarze roboczym.

1. Skonfiguruj integrację Git w swoim workspace i wybierz połącz i zsynchronizuj z repozytorium Azure DevOps.

   

   Na poniższej ilustracji przedstawiono zsynchronizowany proces CopyJob.

   

2. Odzyskaj CopyJob z repozytorium Azure DevOps.

   1. W nowo utworzonym workspace połącz się i zsynchronizuj ponownie ze swoim repozytorium Azure DevOps. Wszystkie elementy Fabric w tym repozytorium są automatycznie pobierane do nowej przestrzeni roboczej.

      

   2. Jeśli oryginalne polecenie CopyJob używa usługi Lakehouse, użytkownicy mogą odwoływać się do sekcji Lakehouse w celu odzyskania usługi Lakehouse, a następnie połączyć nowo odzyskane polecenie CopyJob z nowo odzyskaną usługą Lakehouse.

Aby uzyskać więcej informacji na temat integracji z usługą Git, zobacz Wprowadzenie do integracji z usługą Git.

Zadanie Apache Airflow

Musisz podjąć proaktywne działania, aby chronić miejsca pracy Apache Airflow w Fabric przed katastrofą regionalną.

Zarządzaj redundancją za pomocą integracji z Fabric Git. Najpierw zsynchronizuj zadanie Airflow z repozytorium ADO. Jeśli usługa zostanie przełączona do innego regionu, możesz użyć repozytorium do ponownego utworzenia zadania Airflow w nowo utworzonym obszarze roboczym.

Postępuj zgodnie z tymi krokami, aby osiągnąć ten cel:

1. Skonfiguruj integrację Git w swoim obszarze roboczym i wybierz Połącz i synchronizuj z repozytorium ADO.

2. Po tym widzisz synchronizację zadania Airflow z repozytorium ADO.

3. Jeśli musisz odzyskać zadanie airflow z repozytorium ADO, utwórz nowy obszar roboczy, połącz się i zsynchronizuj ponownie z repozytorium ADO Azure. Wszystkie elementy Fabric w tym repozytorium, w tym Airflow, są automatycznie pobierane do nowego obszaru roboczego.

Analiza w czasie rzeczywistym

Ten przewodnik przeprowadzi Cię krok po kroku przez procedury odzyskiwania doświadczenia analizy w czasie rzeczywistym. Obejmuje bazy danych KQL, zestawy zapytań oraz elementy strumienia zdarzeń.

Activator

Elementy aktywatora z regionu podstawowego pozostają niedostępne dla klientów, a definicje wyzwalaczy aktywatora nie są replikowane do regionu pomocniczego. Użytkownicy Activatora muszą podjąć odpowiednie działania zapobiegawcze, aby przygotować się na regionalne odzyskiwanie po awarii.

Aby mieć pewność, że będzie można odzyskać elementy usługi Activator w przypadku katastrofy regionalnej, skonfiguruj integrację usługi Fabric z usługą Git, aby utworzyć kopię zapasową definicji wyzwalaczy i przywrócić je w obszarze roboczym w innym regionie.

1. Skonfiguruj integrację usługi Git w usłudze Fabric w obszarze roboczym, który zawiera element Activator, i zsynchronizuj definicje wyzwalaczy z repozytorium Git.
2. Regularnie zatwierdzaj i synchronizuj definicje wyzwalaczy Activator.
3. Podczas odzyskiwania utwórz nowy obszar roboczy w regionie docelowym (C2). W2), połącz go z tym samym repozytorium i zsynchronizuj, aby przywrócić definicje wyzwalacza.
4. Skonfiguruj ponownie i zweryfikuj wszystkie źródła danych i zależności aktywatora w nowym obszarze roboczym.

Aby uzyskać więcej informacji na temat integracji z usługą Git, zobacz Wprowadzenie do integracji z usługą Git.

Model programu Graph/zestaw zapytań

Klienci nie mogą uzyskać dostępu do elementów modelu Graph i zestawu zapytań Graph z regionu podstawowego, a usługa Fabric nie replikuje tych elementów do regionu pomocniczego. Aby odzyskać dane, utwórz lub użyj jednostki pojemności w innym regionie i odtwórz tam model Graph oraz elementy zestawu zapytań Graph w tym regionie.

1. Utwórz lub użyj istniejącej pojemności Fabric w innym regionie, który nie jest dotknięty awarią.

2. Utwórz nowy obszar roboczy lub użyj istniejącego obszaru roboczego w tej pojemności.

3. Odtwórz element modelu Graph w pomocniczej przestrzeni roboczej, o której mowa w kroku 2. Przekonfiguruj definicję modelu, w tym węzły, krawędzie i inne, aby pasowała do oryginalnego modelu grafu.

4. Jeśli oryginalny lakehouse znajduje się w regionie, w którym występuje awaria, najpierw odzyskaj go, postępując zgodnie z sekcją Lakehouse.

5. Połącz lakehouse jako źródło danych OneLake dla nowo utworzonego elementu modelu grafu. Użyj odzyskanego lakehouse'u, jeśli znajdował się on w regionie, w którym wystąpił problem, lub połącz się ponownie z istniejącym lakehouse'em, jeśli jest nadal dostępny.

6. Przekonfiguruj harmonogramy ładowania danych lub połączenia modelu Graph w nowym obszarze roboczym.

7. Odtwórz element zestawu zapytań Graph w pomocniczej przestrzeni roboczej. Ręcznie ponownie wprowadź zapytania oraz zapisane konfiguracje zapytań z oryginalnego zestawu zapytań Graph.

Baza danych/Queryset KQL

Użytkownicy baz danych KQL i zestawu zapytań muszą podjąć proaktywne kroki, aby chronić się przed katastrofą regionalną. Poniższe podejście zapewnia, że w przypadku regionalnej katastrofy dane w bazach danych i zestawach zapytań KQL pozostają bezpieczne i dostępne.

Wykonaj poniższe kroki, aby zagwarantować efektywne rozwiązanie odzyskiwania po awarii dla baz danych I zestawów zapytań języka KQL.

1. Ustaw niezależne bazy danych KQL: Skonfiguruj dwie lub więcej niezależnych baz danych i zestawów zapytań KQL na dedykowanych przepustowościach Fabric. Ustaw te bazy danych w dwóch różnych regionach Azure (najlepiej regionach sparowanych z Azure), aby zmaksymalizować odporność.

2. Replikuj działania związane z zarządzaniem: Odzwierciedlaj każde działanie związane z zarządzaniem, które wykonasz w jednej bazie danych KQL, w drugiej. To podejście utrzymuje synchronizację obu baz danych. Kluczowe działania do powtórzenia obejmują:

   • Tabele: Upewnij się, że struktury tabel i definicje schematów są spójne w bazach danych.

   • Mapowanie: Duplikuj wszystkie wymagane mapowania. Upewnij się, że źródła danych i miejsca docelowe są prawidłowo dopasowane.

   • Polityki: Upewnij się, że obie bazy danych mają podobne zasady dotyczące przechowywania danych, dostępu i innych istotnych zasad.

3. Zarządzanie uwierzytelnianiem i autoryzacją: Ustaw wymagane uprawnienia dla każdej repliki. Upewnij się, że ustalisz odpowiednie poziomy autoryzacji, umożliwiając dostęp wymaganemu personelowi przy jednoczesnym zachowaniu standardów bezpieczeństwa.

4. Równoległe pozyskiwanie danych: aby zapewnić spójność i gotowość danych w wielu regionach, załaduj ten sam zestaw danych do każdej bazy danych KQL w tym samym czasie, gdy je pozyskasz.

Eventstream

Strumień zdarzeń to scentralizowane miejsce na platformie Fabric do przechwytywania, przekształcania i przekierowywania zdarzeń w czasie rzeczywistym do różnych miejsc docelowych (na przykład lakehouses, baz danych KQL/zestawów zapytań) z doświadczeniem bez kodowania. Dopóki lokalizacje docelowe obsługują funkcję odzyskiwania po awarii, strumienie zdarzeń nie tracą danych. Dlatego wykorzystaj możliwości odzyskiwania po awarii tych systemów docelowych, aby zagwarantować dostępność danych.

Możesz także osiągnąć georedundancję, wdrażając identyczne obciążenia strumienia zdarzeń w wielu regionach Azure w ramach strategii aktywno-aktywnej na wielu lokalizacjach. Dzięki podejściu aktywno-aktywne na wielu lokalizacjach możesz uzyskać dostęp do swojego obciążenia w dowolnym wdrożonym regionie. Takie podejście jest najbardziej złożonym i kosztownym podejściem do odzyskiwania po awarii, ale może skrócić czas odzyskiwania do niemal zera w większości sytuacji. Aby być w pełni geograficznie redundantnym:

1. Twórz repliki swoich źródeł danych w różnych regionach.

2. Twórz elementy Eventstream w odpowiednich regionach.

3. Połącz te nowe elementy z identycznymi źródłami danych.

4. Dodaj identyczne miejsca docelowe dla każdego strumienia zdarzeń w różnych regionach.

Zdarzenia biznesowe, zdarzenia Fabric i zdarzenia Azure

Chociaż Business Events, Fabric Events i Azure Events Microsoft Fabric korzystają z tej samej infrastruktury Real-Time hub, mają one odrębne pochodzenie, zachowania i wymagania dotyczące odzyskiwania. Zrozum te różnice przed planowaniem odbudowy po katastrofie:

• Fabric Events to subskrypcje eventów, które reagują na aktywność generowaną przez same zasoby Fabric. Zdarzenia te obejmują zmiany cyklu życia elementów przestrzeni roboczej (takie jak tworzenie, aktualizacja lub usuwanie domów nad jeziorem, notatników czy magazynów), wykonywanie zadań (np. uruchamianie potoków czy notatników) oraz operacje związane z plikami i folderami OneLake. Te subskrypcje są oparte na mechanizmie push i są tymczasowe. Subskrypcje nie są replikowane do regionu drugorzędnego.

• Azure Zdarzenia to subskrypcje zdarzeń na działania generowane przez konta Azure Blob Storage. Te zasoby platformy Azure istnieją niezależnie od jakiejkolwiek jednostki mocy obliczeniowej lub regionu usługi Fabric. Chociaż sam zasób Azure Blob Storage może pozostać dostępny podczas awarii regionalnej usługi Fabric, subskrypcje skonfigurowane w centrum Real-Time nie są replikowane do regionu pomocniczego i muszą zostać utworzone ponownie.

• Zdarzenia biznesowe to odrębna funkcja analizy Fabric Real-Time, która umożliwia zespołom definiowanie, publikowanie i działanie na znaczących sygnałach biznesowych. Zdarzenia biznesowe są generowane z poziomu Fabric za pośrednictwem aktywatora, notesów platformy Spark lub funkcji danych użytkownika, a następnie publikowane w centrum Real-Time, w którym odbiorcy podrzędni, tacy jak Aktywacja, Eventhouse lub Power Automate mogą reagować na nie. Schematy zdarzeń są zarządzane centralnie za pośrednictwem rejestru schematów. Usługa Eventhouse automatycznie przechowuje każde opublikowane wydarzenie biznesowe, więc jego odzyskiwanie bezpośrednio wpływa na dostępność historii zdarzeń biznesowych. Żadna z konfiguracji wydawcy lub odbiorcy, definicji schematu lub subskrypcji nie jest replikowana do regionu pomocniczego.

Wykonaj poniższe kroki, aby przywrócić zdarzenia biznesowe, zdarzenia Fabric i zdarzenia Azure w nowym obszarze roboczym w regionie odzyskiwania.

W przypadku zdarzeń biznesowych:

1. Utwórz ponownie zdarzenie biznesowe używane przez wydawców i odbiorców, postępując zgodnie z artykułem Tworzenie zdarzeń biznesowych w usłudze Fabric Real-Time Hub. Podczas tworzenia zdarzenia biznesowego tworzysz zasób Zestaw schematów zdarzeń. Zasób usługi Eventhouse jest opcjonalny w zależności od scenariusza. Jeśli zrobiłeś kopię zapasową swojego zestawu schematu zdarzeń z integracją z Gitem, najpierw go przywróć, podążając za sekcją Zestaw schematów zdarzeń, a następnie skieruj zdarzenie biznesowe na przywrócony zestaw schematów.

2. Utwórz ponownie w nowym obszarze roboczym wszystkie elementy publikujące, które generują zdarzenia biznesowe, takie jak notesy Spark lub funkcje danych użytkownika, korzystając z następujących artykułów dotyczących publishera: Używanie funkcji danych użytkownika jako publishera zdarzeń biznesowych, Używanie aktywatora jako publishera zdarzeń biznesowych, Używanie notesu jako publishera zdarzeń biznesowych i Używanie Eventstream jako publishera zdarzeń biznesowych.

3. Utwórz ponownie subskrypcje odbiorców w centrum Real-Time Hub (na przykład reguły Activatora, wyzwalacze notesnika lub przepływy Power Automate), które pierwotnie reagowały na zdarzenia biznesowe w regionie, którego dotyczy problem, postępując zgodnie z instrukcjami w artykułach Eventhouse and Real-Time Dashboard Integration with Business Events oraz Consume Business Events from Activator.

4. Zweryfikuj, że zdarzenia przepływają od początku do końca, potwierdzając, że subskrypcje są aktywne i że dane docierają do oczekiwanych miejsc docelowych w regionie odzyskiwania.

W przypadku zdarzeń Fabric:

1. Utwórz ponownie subskrypcje w centrum Real-Time tak, aby wskazywały na elementy obszaru roboczego, zadania lub ścieżki OneLake, które przywrócono w regionie odzyskiwania, zgodnie z instrukcjami w artykule Explore Fabric events in Fabric Real-Time hub.

2. Zweryfikuj, że zdarzenia przepływają od początku do końca, potwierdzając, że subskrypcje są aktywne i że dane docierają do oczekiwanych miejsc docelowych w regionie odzyskiwania.

W przypadku zdarzeń Azure:

1. Konta Azure Blob Storage nie są dotknięte regionalną awarią Fabric. Utwórz ponownie subskrypcje zdarzeń w centrum Real-Time wskazując na te same konta Azure Blob Storage, postępując zgodnie z artykułem Ustawianie alertów dotyczących zdarzeń Azure Blob Storage w centrum Real-Time.

2. Zweryfikuj, że zdarzenia przepływają od początku do końca, potwierdzając, że subskrypcje są aktywne i że dane docierają do oczekiwanych miejsc docelowych w regionie odzyskiwania.

Zestaw schematów zdarzeń

Zestaw schematów zdarzeń to element usługi Fabric, który zawiera definicje typów zdarzeń i schematów w usłudze Real-Time Intelligence. Inne funkcje opierają się na niej: wydawcy publikują zdarzenia zgodne z jej schematami, a odbiorcy odczytują je zgodnie z tymi samymi definicjami.

Zestawy schematów zdarzeń z regionu głównego pozostają niedostępne dla klientów i nie są replikowane do regionu wtórnego. Jednak ponieważ zbiór schematu zdarzeń jest trwałą definicją autorską, a nie efemeryczną subskrypcją, można go wcześniej zbackupować i przywrócić, zamiast tworzyć go ręcznie.

Polecam: wykonaj kopię zapasową z integracją Fabric Git

Aby odzyskać zestaw schematów zdarzeń po regionalnej awarii, skonfiguruj integrację usługi Fabric z usługą Git, zanim dojdzie do awarii, i zsynchronizuj przestrzeń roboczą zawierającą zestawy schematów zdarzeń z repozytorium Git.

1. Skonfiguruj integrację Fabric Git dla przestrzeni roboczej zawierającej twój zestaw schematów zdarzeń i zsynchronizuj ją z repozytorium Git.

2. Dbaj o to, aby zestaw schematów zdarzeń był zatwierdzany i regularnie synchronizowany, szczególnie po dodaniu typów zdarzeń lub opublikowaniu nowych wersji schematu.

3. Podczas odzyskiwania utwórz nowy obszar roboczy w regionie docelowym (C2.W2), podłącz go do tego samego repozytorium i zsynchronizuj, aby przywrócić zestaw schematów zdarzeń. Ponieważ nowa przestrzeń robocza jest pusta, synchronizacja Git przenosi zawartość z repozytorium do przestrzeni roboczej.

4. Odtwórz wszystkich wydawców i konsumentów korzystających z zestawu schematów, zgodnie z wytycznymi dla tych typów elementów.

5. Sprawdź, czy wydawcy mogą publikować na podstawie przywróconych typów zdarzeń oraz czy konsumenci otrzymują zdarzenia zgodnie z oczekiwaniami.

Zsynchronizowana definicja obejmuje typy zdarzeń w zbiorze schematów, schematy oraz wersje schematów. Nie obejmuje rejestracji wydawców, subskrypcji konsumenckich ani historii wydarzeń. Odzyskaj je osobno, zgodnie z wytycznymi dotyczącymi typów elementów wykorzystujących zestaw schematów.

Alternatywa: odtworzyć ją ręcznie

Jeśli przed awarią nie skonfigurowano integracji z narzędziem Git, odtwórz zestaw schematów zdarzeń w regionie odzyskiwania po awarii, postępując zgodnie z instrukcjami w dokumencie Create and manage event schema sets, a następnie dodaj typy zdarzeń i schematy, które zawierał oryginalny zestaw, postępując zgodnie z instrukcjami w dokumencie Create and manage event schemas in schema sets.

Map

Elementy mapy z regionu podstawowego pozostają niedostępne dla klientów, a elementy mapy nie są replikowane do regionu pomocniczego.

Jeśli chcesz odzyskać element mapy po wystąpieniu awarii, skonfiguruj integrację Fabric z usługą Git i zsynchronizuj element mapy przy użyciu repozytorium Git.

Podczas odzyskiwania, po skonfigurowaniu nowego regionu/pojemności w Fabric, można użyć repozytorium, aby odtworzyć element Mapy w nowo utworzonym obszarze roboczym. Ponieważ nowy obszar roboczy jest pusty, Git sync pobiera zawartość z repozytorium do pustego obszaru roboczego. Ten krok powoduje powrót elementu Mapy do życia.

Ontologia

Użytkownicy ontologii muszą podjąć aktywne kroki, aby przygotować się na regionalne odzyskiwanie po katastrofach. Podejście opisane poniżej gwarantuje, że po awarii regionalnej twoja Ontologia pozostaje możliwa do odzyskania i może zostać szybko przywrócona.

Najprostszym i najszybszym sposobem włączenia odzyskiwania jest użycie integracji Fabric Git i zsynchronizowanie aplikacji Ontology z repozytorium Azure DevOps (ADO). Jeśli usługa ulegnie awarii w innym regionie, możesz użyć tego repozytorium do ponownego skompilowania ontologii w nowo utworzonym obszarze roboczym.

Elementy ontologii w regionie podstawowym nie są dostępne dla klientów po awarii regionalnej, a elementy ontologii nie są replikowane do regionu pomocniczego.

Aby odzyskać element ontologii podczas awarii, skonfiguruj integrację Fabric z usługą Git i zsynchronizuj element ontologii z repozytorium ADO z wyprzedzeniem.

Podczas odzyskiwania, po skonfigurowaniu nowego regionu i pojemności w Fabric, można za pomocą repozytorium ponownie zbudować element Ontology w nowym workspace. Ponieważ nowy obszar roboczy jest pusty, Git sync pobiera zawartość z repozytorium do obszaru roboczego, co skutecznie przywraca element Ontology.

Planning

Ten artykuł opisuje procedury odzyskiwania funkcji planowania w aplikacji IQ. Określa on kroki niezbędne do przywrócenia kluczowych komponentów, w tym arkusze planowania, arkusze PowerTable, arkusze inteligencji, InfoBridge oraz powiązane zasoby danych.

Integracja z usługą Git w celu przywrócenia elementów planu

Preferowaną metodą jest synchronizowanie wszystkich elementów planu z repozytorium Azure DevOps (ADO) lub GitHub przy użyciu integracji z usługą Fabric Git. Po przejściu w tryb failover użyj repozytorium, aby przywrócić elementy w nowym obszarze roboczym.

Działania przed katastrofą (proaktywne działania):

1. W obszarze roboczym W1 przejdź do pozycji Ustawienia obszaru roboczego i skonfiguruj integrację z usługą Git.

2. Wybierz pozycję Połącz i zsynchronizuj z repozytorium ADO lub GitHub.

3. Wybierz elementy planu, które mają być przekazywane do repozytorium, a następnie wybierz pozycję Zatwierdź.

   

4. Upewnij się, że stan usługi Git elementów planu jest zsynchronizowany.

5. Wprowadź dyscyplinę commitowania — wykonuj commit po każdej znaczącej zmianie w definicji planu, aby repozytorium zawsze odzwierciedlało najnowszy stan.

Kroki odzyskiwania:

1. Utwórz nowy obszar roboczy W2 wewnątrz pojemności C2 w regionie w dobrej kondycji.

2. W obszarze roboczym W2 przejdź do Ustawienia obszaru roboczego i ponownie połącz się z tym samym repozytorium ADO/GitHub.

3. Wybierz pozycję Kontrola źródła. Wybierz odpowiednią gałąź repozytorium i wybierz pozycję Aktualizuj wszystko. Wszystkie elementy planu są pobierane do W2.

Następujące składniki są przywracane po odzyskiwaniu:

• Arkusze PowerTable: Ustawienia tabeli źródłowej, konfiguracja kolumny, dostęp do wiersza, właściwości wizualizacji (układ, formaty i inne), identyfikacja wierszy, ustawienia komentarza, powolne zmienianie wymiarów (SCD), zatwierdzenia, automatyzacje i formularze.
• Arkusze planowania: Właściwości arkusza (formatowanie, formatowanie warunkowe i inne), ustawienia komentarzy, ustawienia zapisywania zwrotnego, kolumny wejściowe danych, wiersze wejściowe danych, scenariusze i zakładki.
• InfoBridge: źródła InfoBridge, zapytania InfoBridge, etapy transformacji, lokalizacje docelowe zapisu zwrotnego, ustawienia zapisu zwrotnego, mapowania połączonych zapytań, grupy zapytań, właściwości wizualne (mieszanie). Nie można odzyskać tych elementów: źródeł opartych na plikach (CSV, Excel) oraz arkuszy obejmujących wiele obciążeń, które korzystają ze źródeł opartych na plikach.
• Analiza: Wszystkie wykresy i macierze.

Przywracanie SQL w usłudze Fabric na potrzeby planowania

Dane wprowadzone w arkuszach planowania, tabelach używanych w programie PowerTable i danych zapisywania zwrotnego są przechowywane w bazach danych SQL i muszą być brane pod uwagę jako część strategii odzyskiwania po awarii. Aby odzyskać bazy danych SQL, zobacz sekcję Bazy danych SQL .

• Metadane planu odtwarzania: Każda pozycja planu jest skojarzona z bazą danych __fabric_plan_sys, która przechowuje metadane używane przez funkcje planowania, w tym komentarze, scenariusze, dane wejściowe i konfigurację zapisu zwrotnego. Baza danych __fabric_plan_sys nie jest przywracana automatycznie i musi zostać jawnie odzyskana.

• Przywracanie baz danych zapisywania zwrotnego: jeśli plan używa miejsc docelowych zapisywania zwrotnego SQL, należy również ręcznie odzyskać skojarzone bazy danych. Skonfigurowane docelowe lokalizacje zapisu zwrotnego SQL nie są przywracane automatycznie.

• Przywracanie tabel używanych w PowerTable: Wszystkie tabele utworzone za pomocą PowerTable są przechowywane w bazie danych SQL w Fabric. Te tabele należy również odzyskać podczas DR.

Agenci operacji

Użytkownicy agentów operacyjnych powinni podjąć proaktywne kroki w celu przygotowania się do regionalnego odzyskiwania po awarii. Stosowanie podejścia opisanego w tej sekcji pomaga zapewnić, że agenci mogą zostać szybko przywróceni po awarii regionalnej.

Użyj integracji usługi Fabric z usługą Git, aby zsynchronizować obszar roboczy z repozytorium. Takie podejście umożliwia odtworzenie konfiguracji agenta w nowym obszarze roboczym, jeśli usługa ulegnie awarii w innym regionie.

Elementy agenta operacyjnego w regionie podstawowym są niedostępne podczas awarii regionalnej. Konfiguracje agentów, modele zachowania i dzienniki aktywności nie są replikowane do regionu pomocniczego. Operacje w toku, aktywne sesje czatu i wcześniej zaimportowane zdarzenia w chwili awarii również zostaną utracone.

Aby przygotować się do odzyskiwania po awarii, skonfiguruj integrację Git w usłudze Fabric i zsynchronizuj elementy agenta z repozytorium ADO, zanim dojdzie do awarii.

Podczas odzyskiwania skonfiguruj nowy region i pojemność w Fabric, a następnie użyj zsynchronizowanego repozytorium, aby przywrócić konfiguracje agenta do nowego obszaru roboczego. Usługa Git Sync pobiera przechowywaną zawartość z repozytorium do pustego obszaru roboczego, ponownie odtwarzając elementy agenta.

Po przywróceniu konfiguracji upewnij się, że wszystkie bazy danych usługi Eventhouse (KQL) lub źródła danych specyficzne dla regionu są dostępne w nowym regionie. Zaktualizuj odwołania do punktów końcowych w konfiguracjach agentów w razie potrzeby. Na koniec uruchom ponownie agentów i zainicjuj nowe sesje czatu. Nie można wznowić poprzednich konwersacji.

Databases

Ten przewodnik opisuje procedury odzyskiwania dla środowiska baz danych.

baza danych SQL

Aby chronić się przed awarią regionalną, użytkownicy baz danych SQL mogą podejmować proaktywne działania, aby okresowo eksportować swoje dane i używać wyeksportowanych danych do ponownego utworzenia bazy danych w nowym obszarze roboczym w razie potrzeby.

Użyj narzędzia SqlPackage CLI, które zapewnia przenośność baz danych i ułatwia wdrażanie baz danych.

1. Użyj narzędzia SqlPackage, aby wyeksportować bazę danych do .bacpac pliku. Aby uzyskać więcej informacji, zobacz Eksportowanie bazy danych za pomocą pakietu SqlPackage .
2. Zapisz .bacpac plik w bezpiecznym miejscu, które znajduje się w innym regionie niż baza danych. Przykłady to przechowywanie .bacpac pliku w Lakehouse w innym regionie, użycie georedundantnego konta Azure Storage lub użycie innego bezpiecznego nośnika w innym regionie.
3. Jeśli baza danych SQL i region są niedostępne, możesz użyć .bacpac pliku z pakietem SqlPackage, aby ponownie utworzyć bazę danych w obszarze roboczym w nowym regionie — Obszar roboczy C2. W2 w regionie B zgodnie z opisem w powyższym scenariuszu. Wykonaj kroki opisane w temacie Importowanie bazy danych za pomocą pakietu SqlPackage , aby ponownie utworzyć bazę danych przy użyciu .bacpac pliku.

Utworzona ponownie baza danych jest niezależną bazą danych od oryginalnej bazy danych i odzwierciedla stan danych w czasie operacji eksportowania.

Zagadnienia dotyczące powrotu po awarii

Utworzona ponownie baza danych jest niezależną bazą danych. Dane dodane do odtworzonej bazy danych nie byłyby odzwierciedlone w oryginalnej bazie danych. Jeśli planujesz powrót do oryginalnej bazy danych, gdy region macierzysty stanie się dostępny, musisz rozważyć ręczne uzgadnianie danych z odtworzonej bazy z oryginalną bazą danych.

Platforma

Platforma odnosi się do podstawowych usług udostępnionych i architektury, które mają zastosowanie do wszystkich obciążeń. Ta sekcja opisuje procedury odzyskiwania dla współdzielonych funkcji Fabric.

Monitorowanie obszaru roboczego

Monitorowanie przestrzeni roboczej zbiera logi dotyczące aktywności w przestrzeni roboczej, w której je włączysz. Po odzyskaniu przestrzeni roboczej jako C2. W2, włącz monitorowanie przestrzeni roboczej na W2. Zaczyna zbierać dane monitorujące dla odzyskanej przestrzeni roboczej.

Dane monitorowania z oryginalnego obszaru roboczego (C1.W1) nie są przenoszone, ponieważ monitorowanie odzwierciedla aktywność obszaru roboczego, w którym jest uruchomione.

Biblioteka zmiennych

Microsoft Fabric Biblioteki zmiennych umożliwiają deweloperom dostosowywanie i udostępnianie konfiguracji elementów w obszarze roboczym, usprawniając zarządzanie cyklem życia zawartości. Z punktu widzenia odzyskiwania po awarii użytkownicy bibliotek zmiennych muszą aktywnie chronić się przed awarią regionalną. Ochronę tę można zapewnić poprzez integrację Fabric Git, która zapewnia, że po regionalnej awarii biblioteka zmiennych użytkownika pozostaje dostępna. Aby odzyskać bibliotekę zmiennych, należy postępować zgodnie z następującymi krokami:

• Użyj integracji Fabric z Git, aby zsynchronizować bibliotekę zmiennych z repozytorium ADO. W przypadku awarii możesz użyć repozytorium, aby ponownie skompilować bibliotekę zmiennych w nowo utworzonym obszarze roboczym. Wykonaj następujące czynności:

  1. Połącz obszar roboczy z repozytorium Git zgodnie z opisem w tym miejscu.
  2. Pamiętaj, aby utrzymywać WS i repozytorium zsynchronizowane przy pomocy zatwierdzenia i aktualizacji.
  3. Odzyskiwanie — w przypadku awarii użyj repozytorium, aby odtworzyć bibliotekę Variable na nowo w nowym obszarze roboczym.

• W nowo utworzonym obszarze roboczym połącz się i zsynchronizuj ponownie z repozytorium ADO Azure.

• Wszystkie elementy Fabric w tym repozytorium są automatycznie pobierane do nowego obszaru roboczego.

• Po zsynchronizowaniu elementów z usługi Git otwórz biblioteki zmiennych w nowym obszarze roboczym i ręcznie wybierz żądany aktywny zestaw wartości.

Klucze zarządzane przez klienta dla obszarów roboczych Fabric

Możesz użyć kluczy zarządzanych przez klienta (CMK) przechowywanych w Azure Key Vault, aby dodać dodatkową warstwę szyfrowania na podstawie kluczy zarządzanych przez Microsoft dla danych spoczynkowych. Jeśli Fabric stanie się niedostępny lub nieoperacyjny w danym regionie, jego komponenty przechodzą na instancję zapasową. Funkcja CMK podczas przełączania awaryjnego obsługuje operacje w trybie tylko do odczytu. Dopóki usługa Azure Key Vault pozostaje sprawna, a uprawnienia do sejfu są nienaruszone, Fabric nadal łączy się z Twoim kluczem i pozwala normalnie odczytywać dane. Oznacza to, że następujące operacje nie są obsługiwane podczas przełączania awaryjnego: włączanie i wyłączanie ustawienia CMK obszaru roboczego i aktualizowanie klucza.

Fabric Asystent migracji dla bazy danych SQL w Fabric

Asystent migracji Fabric może przenieść bazę danych SQL Server do bazy danych SQL w usłudze Fabric w trzech etapach: kreator migracji tworzy docelową bazę danych i rozpoczyna migrację, monitor migracji śledzi postęp wdrażania schematu z pakietu DACPAC, a Asystent migracji Fabric pomaga przejrzeć i naprawić błędy skryptów, przygotować bazę danych, skopiować dane za pomocą zadania kopiowania oraz sfinalizować kopiowanie.

Postęp migracji nie jest replikowany do innego regionu, a przerwane wdrożenie nie może zostać wznowione. Te awarie nie wpływają na źródłową bazę danych SQL Server, więc możesz ponownie uruchomić asystenta migracji. Jeśli oryginalny region jest niedostępny, najpierw postępuj zgodnie z ogólnym planem odzyskiwania zawartym w tym artykule, aby utworzyć pojemność C2 i przestrzeń roboczą W2 w sparowanym regionie, a następnie przeprowadź migrację w W2. Jeśli oryginalny region wróci do działania, możesz ponownie spróbować przeprowadzić migrację w oryginalnym obszarze roboczym.

Regionalne zakłócenia mogą spowodować niepowodzenie migracji na trzy sposoby:

• Docelowa baza danych nie jest tworzona

  Jeśli Fabric nie może utworzyć docelowej bazy danych, kreator migracji wyświetla błąd i migracja się nie rozpoczyna. Wybierz Start migracji , aby spróbować ponownie, lub spróbuj ponownie później.

  Kreator próbuje usunąć niekompletną bazę danych, ale oczyszczanie może się nie powieść w przypadku zakłócenia. Przed ponowną próbą sprawdź przestrzeń roboczą, czy nie ma bazy danych o nazwie docelowej. Potwierdź, że to niekompletna baza danych z nieudanej próby, zanim ją usuniesz.

• Wdrożenie zakończyło się niepowodzeniem

  Jeśli wdrożenie zostanie przerwane, monitor migracji przestaje raportować postępy, otwiera docelową bazę danych i wyświetla dialog informujący o niepowodzeniu wdrożenia. Nie można wznowić nieudanego wdrożenia, a baza danych utworzona przez próbę pozostaje w workspace.

  Aby odzyskać:

  1. Potwierdź, że Fabric jest dostępny i czy do pierwotnej migracji użyto DACPAC.
  2. Zidentyfikuj bazę danych utworzoną w wyniku nieudanej próby. Usuń go, jeśli nie zawiera niczego, co musisz zachować. W przeciwnym razie zachowaj ją i użyj innej nazwy dla nowej bazy danych.
  3. Uruchom nową migrację ze źródłowego pakietu DACPAC. Migracja tworzy nową bazę danych.

  Dane są kopiowane przez zadanie kopiowania w Data Factory. Jeśli zsynchronizowałeś zadanie kopiowania z Gitem przed zakłóceniem, zobacz Copy Job w instrukcji Data Factory. W przeciwnym razie utwórz nowe zadanie kopiowania w ramach nowej migracji.

• Historia migracji się nie ładuje

  Jeśli Asystent migracji nie może pobrać historii migracji, raportuje, że informacje o migracji nie są już dostępne. Postęp zapisany w obecnej przeglądarce jest zachowywany, a docelowa baza danych nie jest dotknięta. Odśwież stronę, aby ponownie załadować historię migracji.

OneLake

W tej sekcji opisano procedury odzyskiwania funkcji usługi OneLake. Aby uzyskać więcej informacji na temat odzyskiwania po awarii dla danych usługi OneLake, zobacz OneLake disaster recovery (Odzyskiwanie po awarii w usłudze OneLake).

Zasady zarządzania cyklem życia

Jeśli usługa Fabric stanie się niedostępna lub przestanie działać w danym regionie, nadal możesz odczytywać i aktualizować zasady cyklu życia usługi OneLake podczas przełączania awaryjnego. Wszelkie dane przeniesione do poziomu chłodnego lub zimnego pozostają w tym poziomie. Aby zastosować istniejącą politykę do nowego miejsca pracy w rehabilitacji, postępuj zgodnie z następującymi krokami:

1. Wywołaj zasady eksportu w oryginalnym obszarze roboczym i zapisz całe zasady cyklu życia.
2. Wywołaj funkcję Import Policy dla odzyskanego obszaru roboczego, używając wyeksportowanej zasady cyklu życia jako treści żądania.

Reguły wystąpień zasobów

Reguły wystąpień zasobów ułatwiają bezpieczne kontrolowanie dostępu do danych w usłudze OneLake przy użyciu zaufanych tożsamości zasobów Azure. Podczas regionalnego przełączenia awaryjnego system nadal wymusza istniejące reguły dostępu do odczytu. Nie można jednak tworzyć, aktualizować ani usuwać reguł wystąpień zasobów, dopóki obszar roboczy nie powróci do stanu zapisywalnego.

Informacje pokrewne

• Microsoft Fabric przewodnik odzyskiwania po awarii