Veiledning for opplevelsesspesifikk nødutvinning

Dette dokumentet gir erfaringsspesifikk veiledning for å gjenopprette dine Fabric-data ved en regional katastrofe.

Eksempelscenario

Mange veiledningsdeler i dette dokumentet bruker følgende eksempelscenario for å forklare og illustrere. Referer tilbake til dette scenarioet etter behov.

La oss si at du har en kapasitet C1 i område A som har et arbeidsområde W1. Hvis du har aktivert katastrofegjenoppretting for kapasitet C1, blir OneLake-data replikert til en sikkerhetskopi i region B. Hvis region A opplever forstyrrelser, går Fabric-tjenesten i C1 over til region B.

Merk

Denne gjenopprettingsveiledningen gjelder kun når primærregionen har en Azure-paret sekundærregion og Fabric støttes i den parrede regionen.

Bildet nedenfor illustrerer dette scenarioet. Boksen til venstre viser det forstyrrede området. Boksen i midten representerer fortsatt tilgjengelighet av dataene etter failover, og boksen til høyre viser den fullstendig dekkede situasjonen etter at kunden fungerer for å gjenopprette tjenestene til full funksjon.

Her er den generelle gjenopprettingsplanen:

1. Lag en ny Fabric-kapasitet C2 i en ny region.

2. Opprett et nytt W2-arbeidsområde i C2, inkludert tilsvarende elementer med samme navn som i C1. W1.

3. Kopier data fra den avbrutte C1. W1 til C2. W2.

4. Følg de dedikerte instruksjonene for hver komponent for å gjenopprette elementer til sin fulle funksjon.

Denne gjenopprettingsplanen forutsetter at leietakerboligområdet fortsatt er operativt. Hvis leietakerens hjemregion opplever et strømbrudd, er trinnene som er beskrevet i dette dokumentet betinget av gjenopprettingen, som først må initieres og fullføres av Microsoft.

Opplevelsesspesifikke gjenopprettingsplaner

Følgende avsnitt gir trinnvise guider for hver Fabric-opplevelse for å hjelpe kundene gjennom gjenopprettingsprosessen.

Datateknikk

Denne veiledningen veileder deg gjennom gjenopprettingsprosedyrene for Dataingeniør opplevelsen. Den dekker lakehouses, notatbøker, Spark-jobbdefinisjoner, brukerdatafunksjoner og GraphQL-API-er.

Lakehouse

Lakehouses fra den opprinnelige regionen forblir utilgjengelig for kunder. Hvis du vil gjenopprette et lakehouse, kan kunder opprette det på nytt i arbeidsområde C2. W2. Vi anbefaler to fremgangsmåter for å gjenopprette lakehouses:

Fremgangsmåte 1: Bruke egendefinert skript til å kopiere Lakehouse Delta-tabeller og -filer

Kunder kan gjenskape lakehouses ved hjelp av et egendefinert Scala-skript.

1. Opprett lakehouse (for eksempel LH1) i det nyopprettede arbeidsområdet C2. W2.

2. Opprett en ny notatblokk i arbeidsområdet C2. W2.

3. For å gjenopprette tabellene og filene fra det opprinnelige lakehouse, se dataene med OneLake-stier som abfss (se Connecting to Microsoft OneLake). Du kan bruke følgende kodeeksempel (se Introduksjon til Microsoft Spark Utilities) i notatboken for å hente ABFS-stier for filer og tabeller fra det opprinnelige innsjøhuset. (Erstatt C1. W1 med det faktiske arbeidsområdenavnet)

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

4. Bruk følgende kodeeksempel til å kopiere tabeller og filer til det nyopprettede lakehouse.

   1. For Delta-tabeller må du kopiere tabell én om gangen for å gjenopprette i det nye lakehouse. Når det gjelder Lakehouse-filer, kan du kopiere den fullstendige filstrukturen med alle de underliggende mappene med én enkelt kjøring.

   2. Ta kontakt med kundestøtteteamet for tidsstempelet for failover som kreves i skriptet.

   %%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. Når du har kjørt skriptet, vises tabellene i det nye innsjøhuset.

Tilnærming 2: Bruk Azure Storage Explorer for å kopiere filer og tabeller

For å gjenopprette kun spesifikke Lakehouse-filer eller tabeller fra det opprinnelige Lakehouse, bruk Azure Storage Explorer. Se Integrer OneLake med Azure Storage Explorer for detaljerte trinn. Bruk Tilnærming 1 for store datastørrelser.

Merk

De to fremgangsmåtene som er beskrevet ovenfor, gjenoppretter både metadataene og dataene for Delta-formaterte tabeller, fordi metadataene er plassert sammen og lagret sammen med dataene i OneLake. For tabeller som ikke er Delta-formaterte (for eksempel CSV, Parquet osv.) som opprettes ved hjelp av DDL-skript/-kommandoer (Spark Data Definition Language), er brukeren ansvarlig for å vedlikeholde og kjøre Spark DDL-skriptene/-kommandoene på nytt for å gjenopprette dem.

Gjenoppretting av Fabric materialiserte innsjøutsikter

Materialiserte Lake Views fra den opprinnelige regionen er fortsatt utilgjengelige for kundene etter failover. Oppdateringsplaner og kjørehistorikk blir ikke replikert til sekundærregionen. For å gjenopprette dem, fullfør følgende steg etter at du har gjenopprettet dine Lakehouse-data.

• Hent ut Lakehouse-tabellene ved å bruke Tilnærming 1 eller Tilnærming 2 beskrevet ovenfor. Kopier kun kildetabellene.
• Hent notatbøkene som inneholder dine MLV-definisjoner. Se avsnittet Notatbok for restitusjonstrinn.
• Kjør de gjenvunne notatbøkene for å gjenskape MLV-ene i det nye Lakehouse. For informasjon om hvordan du lager MLV-er, se Lag en materialisert innsjøutsikt. Hvis MLV-er også ble kopiert i det tidligere steget, kjør CREATE OR REPLACE mens du gjenskaper dem.
• Lag MLV-oppdateringsplanene manuelt i det nye arbeidsområdet. Tidsplanhistorikk og gjennomføringsmålinger kan ikke gjenopprettes.
• Hvis MLV-ene dine mater semantiske modeller eller rapporter, verifiser og oppdater Lakehouse-ID-en og datasett-ID-referansene etter behov. Koble rapportene til den oppdaterte semantiske modellen igjen og valider dataens ferskhet.

Tips

For å minimere kodeendringer når du kjører notatbøker etter failover, bruk samme arbeidsområde- og Lakehouse-navn i den nye regionen (spesielt når du bruker Workspace- eller Lakehouse-navnet i navnekonvensjonene). Oppdateringsplanene, gjennomføringshistorikken og operasjonelle måleparametere starter på nytt i det gjenopprettede området. Planlegg for en grunnlinjeperiode når du etablerer nye overvåkingsgrenser.

Notatblokk

Notatblokker fra det primære området forblir utilgjengelige for kunder, og koden i notatblokker replikeres ikke til det sekundære området. Hvis du vil gjenopprette notatblokkkoden i det nye området, finnes det to fremgangsmåter for å gjenopprette notatblokkkodeinnhold.

Tilnærming 1: Brukeradministrert redundans med Git-integrasjon (i offentlig forhåndsvisning)

Den beste måten å gjøre dette enkelt og raskt på er å bruke Fabric Git-integrasjon, og deretter synkronisere notatboken med ADO-repoet ditt. Når tjenesten mislykkes til et annet område, kan du bruke repo til å gjenoppbygge notatblokken i det nye arbeidsområdet du opprettet.

1. Konfigurer Git-integrering for arbeidsområdet, og velg Koble til og synkroniser med ADO-repositoriet.

   

   Bildet nedenfor viser den synkroniserte notatblokken.

   

2. Gjenopprett notatblokken fra ADO-repo.

   1. I det nyopprettede arbeidsområdet, koble til Azure ADO-repoet igjen.

      

   2. Velg Kildekontroll-knappen. Velg deretter den relevante grenen av repo. Velg deretter Oppdater alle. Den originale notatblokken vises.

      

      

   3. Hvis den opprinnelige notatblokken har et standard lakehouse, kan brukerne referere til Lakehouse-delen for å gjenopprette lakehouse og deretter koble det nylig gjenopprettede lakehouse til den nylig gjenopprettede notatblokken.

      

   4. Git-integreringen støtter ikke synkronisering av filer, mapper eller øyeblikksbilder av notatblokker i ressursutforskeren for notatblokken.

      1. Hvis den opprinnelige notatblokken har filer i ressursutforskeren for notatblokken:

         1. Pass på at du lagrer filer eller mapper på en lokal disk eller et annet sted.

         2. Last opp filen på nytt fra den lokale disken eller skystasjonene til den gjenopprettede notatblokken.

      2. Hvis den opprinnelige notatblokken har et øyeblikksbilde av notatblokken, lagrer du også øyeblikksbildet av notatblokken i ditt eget versjonskontrollsystem eller en lokal disk.

         

         

Hvis du vil ha mer informasjon om Git-integrering, kan du se Innføring i Git-integrasjon.

Tilnærming 2: Manuell tilnærming til sikkerhetskopiering av kodeinnhold

Hvis du ikke tar git-integreringstilnærmingen, kan du lagre den nyeste versjonen av koden, filene i ressursutforskeren og øyeblikksbilde av notatblokken i et versjonskontrollsystem, for eksempel Git, og gjenopprette notatblokkinnholdet manuelt etter en katastrofe:

1. Bruk funksjonen Importer notatblokk til å importere notatblokkkoden du vil gjenopprette.

   

2. Når du har importert, går du til ønsket arbeidsområde (for eksempel C2. W2") for å få tilgang til den.

3. Hvis den opprinnelige notatblokken har et standard lakehouse, kan du se Lakehouse-delen. Deretter kobler du det nylig gjenopprettede lakehouse (som har samme innhold som det opprinnelige standard lakehouse) til den nylig gjenopprettede notatblokken.

4. Hvis den opprinnelige notatblokken har filer eller mapper i ressursutforskeren, laster du opp filene eller mappene som er lagret i brukerens versjonskontrollsystem.

Spark-jobbdefinisjon

Spark-jobbdefinisjoner (SJD) fra det primære området forblir utilgjengelige for kunder, og hoveddefinisjonsfilen og referansefilen i notatblokken replikeres til det sekundære området via OneLake. Hvis du vil gjenopprette SJD i det nye området, kan du følge de manuelle trinnene som er beskrevet nedenfor for å gjenopprette SJD. Historiske løp av SJD vil ikke bli gjenopprettet.

Du kan gjenopprette SJD-elementene ved å kopiere koden fra den opprinnelige regionen ved å bruke Azure Storage Explorer og manuelt koble til Lakehouse-referanser etter katastrofen.

1. Opprett et nytt SJD-element (for eksempel SJD1) i det nye arbeidsområdet C2. W2, med de samme innstillingene og konfigurasjonene som det opprinnelige SJD-elementet (for eksempel språk, miljø osv.).

2. Bruk Azure Storage Explorer for å kopiere Libs, Mains og Snapshots fra det opprinnelige SJD-elementet til det nye SJD-elementet.

   

3. Kodeinnholdet vises i den nyopprettede SJD-en. Du må legge til den nylig gjenopprettede Lakehouse-referansen manuelt i jobben (se trinnene for Lakehouse-gjenoppretting). Brukere må angi de opprinnelige kommandolinjeargumentene manuelt på nytt.

   

Nå kan du kjøre eller planlegge den nylig gjenopprettede SJD-en.

For detaljer om Azure Storage Explorer, se Integrér OneLake med Azure Storage Explorer.

Funksjoner for brukerdata

For å gjenopprette dine datafunksjoner i et sunt område, bruk en av følgende tilnærminger.

Tilnærming 1: Med Git-integrasjon (anbefalt)

Den foretrukne gjenopprettingsmekanismen er Fabric Git-integrasjon. Ved å synkronisere brukerdatafunksjonsprosjekter med et Azure DevOps- eller GitHub-repositorium, kan du raskt rekonstruere dem i et nytt arbeidsområde etter failover.

Gjør deg klar før en katastrofe oppstår

1. Konfigurer Fabric Git-integrasjon for arbeidsområdet som hoster brukerdatafunksjonen.
2. Koble arbeidsområdet til et Azure DevOps- eller GitHub-repositorium.
3. Forplikt all brukerdata-funksjon til repositoriet og synkroniser endringer regelmessig.
4. Lagre miljøspesifikke innstillinger separat i variabelbiblioteker om nødvendig.

Gjenopprettingssteg

Etter en regional katastrofe:

1. Lag en ny Fabric-kapasitet i en sunn region, som C2.
2. Opprett et nytt arbeidsområde, som W2, i den nye kapasiteten.
3. Koble arbeidsområdet til det samme Azure DevOps- eller GitHub-arkivet.
4. Open Source-kontroll og synkroniser innholdet i arkivet til arbeidsområdet.
5. Gjenskap eller gjenopprett alle avhengige Fabric-ressurser, som lakehouses, SQL-databaser i Fabric, lagre og Business Events.
6. Distribuer brukerdatafunksjonene på nytt.
7. Valider funksjonsutførelse og avhengighetstilkobling.
8. Oppdater nedstrømsapplikasjoner, datapipelines eller andre integrerte systemer for å referere til de gjenopprettede funksjonene.
9. Fullstendig ende-til-ende-validering av alle dine scenarioer.

Viktige hensyn

• Git-integrasjon gjenoppretter kun kildekode og prosjektressurser.
• Historiske henrettelseslogger blir ikke funnet.
• Nedstrømssystemer kan kreve endepunktsrebinding.

For mer informasjon, se Brukerdatafunksjoner kildekontroll og distribusjon.

Tilnærming 2: Manuell gjenoppretting

Hvis Git-integrasjonen ikke var konfigurert før katastrofen, kan du manuelt rekonstruere brukerdatafunksjoner fra kildekodebackuper.

Gjør deg klar før en katastrofe oppstår

Utfør regelmessig følgende oppgaver, og lagre artefaktene i et eksternt kildekontrollarkiv eller sikkerhetskopisted:

• Eksporter funksjonens kildekode til et GitHub-repositorium.
• Dokumenter og bevar informasjon om avhengighet.
• Dokumentmiljøinnstillinger.

Gjenopprettingssteg

Etter en regional katastrofe:

1. Lag en ny Fabric-kapasitet i en sunn region, som C2.
2. Opprett et nytt arbeidsområde, for eksempel W2.
3. Gjenopprett alle ressurser som kreves av funksjonen, inkludert innsjøhus, SQL-databaser i Fabric, lagre, eventhouses og eksterne tjenester.
4. Opprett et nytt user data-funksjonsprosjekt.
5. Importer eller lag kildekoden til funksjonen på nytt.
6. Gjenbruk konfigurasjonsinnstillinger for kjøretid.
7. Installer alle funksjonsavhengigheter på nytt.
8. Omplasser funksjonen.
9. Konfigurer autentisering og autorisasjon på nytt.
10. Gjenskap Business Event-utgivere eller forbrukere, hvis det brukes.
11. Fullfør ende-til-ende valideringstesting for dine scenarioer og integrasjoner.

GraphQL

GraphQL-elementer fra primærregionen er ikke tilgjengelige etter en regional katastrofe, og GraphQL-definisjoner og konfigurasjoner replikeres ikke til sekundærregionen. For å gjenopprette GraphQL i et nytt område, bruk en av følgende tilnærminger.

Tilnærming 1: Brukerstyrt redundans med Git-integrasjon

Den beste måten å gjøre denne prosessen enkel og rask på, er å bruke Fabric Git-integrasjon, og deretter synkronisere GraphQL med ADO-repoet ditt. Etter at tjenesten har gått over til en annen region, kan du bruke repoet til å bygge opp GraphQL på nytt i det nye arbeidsområdet du har opprettet.

1. Opprett et nytt arbeidsområde i målkapasiteten og regionen.

2. Gjenopprett alle avhengige datakilder, som Lakehouse-, Warehouse- eller SQL-databaser, ved å følge deres respektive gjenopprettingstrinn.

3. Oppdater GraphQL-definisjonen til å peke på de nylig gjenopprettede ressursene ved å endre miljøspesifikke referanser som kildearbeidsområde-IDer, kildeartefakt-IDer og tilkoblingsdetaljer. Dette trinnet sikrer korrekt binding ved utrullingstidspunkt.

4. Redeploy GraphQL-artefakter fra Git-repositoriet til det nye arbeidsområdet. Dette steget gjenskaper API-strukturen og konfigurasjonen ved å bruke de oppdaterte definisjonene.

5. Bruk artefaktinnstillinger på nytt, inkludert roller, tilgangskontroller og autentiseringskonfigurasjon.

6. Bruk endepunktsreferanser på nytt ved å oppdatere applikasjoner eller integrasjoner til å bruke det nyopprettede GraphQL-endepunktet.

7. Oppdater eventuelle eksisterende distribusjonspipelines som pekte til det gamle arbeidsområdet for å referere til det nyopprettede arbeidsområdet.

8. Valider ende-til-ende-funksjonalitet i API-et.

Tilnærming 2: Manuell tilnærming

Hvis du ikke bruker Git-integrasjonsmetoden, kan du bruke følgende manuelle tilnærming for å gjenopprette GraphQL.

1. Opprett et nytt arbeidsområde i målkapasiteten og regionen.

2. Gjenopprette alle avhengige datakilder, som Lakehouse, Warehouse eller SQL-databaser.

3. Gjenskap GraphQL-API-et manuelt i det nye arbeidsområdet, inkludert skjemadefinisjoner, datakildetilkoblinger og relasjoner.

4. Bruk artefaktinnstillinger på nytt, inkludert roller, tilgangskontroller og autentiseringskonfigurasjon.

5. Bruk endepunktsreferanser på nytt ved å oppdatere applikasjoner eller integrasjoner til å bruke det nyopprettede GraphQL-endepunktet.

6. Oppdater eventuelle eksisterende distribusjonspipelines som pekte til det gamle arbeidsområdet for å referere til det nyopprettede arbeidsområdet.

7. Valider ende-til-ende-funksjonalitet i API-et.

Viktige hensyn

1. GraphQL er avhengig av eksterne avhengigheter (som Lakehouse, Warehouse og SQL), som du må gjenopprette før GraphQL-distribusjon.

2. GraphQL API-definisjoner inkluderer miljøspesifikke referanser (som sourceWorkspaceId og sourceItemId). Ved gjenoppretting i et nytt område kan disse referansene bli ugyldige. Oppdater dem til å peke på nylig opprettede ressurser.

3. Automatisk rebinding av datakilder er ikke garantert i katastrofegjenopprettingssituasjoner, spesielt ved bruk av lagrede legitimasjoner eller kryss-arbeidsområde-tilkoblinger.

4. Andre artefaktinnstillinger som overvåking, autorisasjon, RBAC, introspeksjon og mer overføres ikke etter failover. Du må gjenopprette disse innstillingene i den nye regionen.

Referanser

• Oversikt over Fabric Git-integrasjon - Microsoft Fabric | Microsoft Learn

• Kildekontroll- og distribusjonspipelines i API for GraphQL - Microsoft Fabric | Microsoft Learn 

App

Systemet replikerer ikke Fabric Apps, inkludert deres kode, konfigurasjon og metadata, til sekundære regioner. Hvis primærregionen feiler, forblir appen utilgjengelig. For gjenoppretting, lagre appens kildekode utenfor systemet i GitHub, Azure DevOps eller et annet kildekontrollsystem. Hent appdata separat ved å følge katastrofegjenopprettingsveiledningen for hver underliggende Fabric-datalagring.

Manuell tilnærming

Du kan manuelt gjenopprette en Fabric App etter en regional katastrofe ved å bruke applikasjonens kildekode og Rayfin CLI. 

Forutsetninger 

Før en katastrofe inntreffer:

• Lagre Fabric App-kildekoden i GitHub, Azure DevOps eller et annet kildekontrollarkiv. 

• Dokumenter prosessen for gjenoppretting.  

Gjenopprettingssteg 

1. Opprett et nytt arbeidsområde i målkapasiteten og regionen. 

2. Gjenopprett avhengige ressurser før du distribuerer applikasjonen på nytt.  

3. Hent den nyeste Fabric App-kildekoden fra ditt kildekodearkiv eller lokal backup. 

4. Fra applikasjonskildekatalogen, distribuer Fabric App til gjenopprettingsarbeidsområdet ved å bruke Rayfin CLI. Kjør rayfin up --workspace <new workspace>. 

5. Gjenopprett appens barneobjekt (Fabric SQL Database) ved å følge de respektive gjenopprettingsprosedyrene.  

6. Påfør artefaktnivåinnstillinger på nytt, inkludert roller og tilgangskontroller etter behov.  

7. Valider applikasjonens funksjonalitet og sørg for at brukerne har riktige tillatelser.  

Viktig! 

• Vedlikehold Fabric App-kildekoden utenfor Fabric-regionen for å muliggjøre gjenoppretting.  

• Applikasjonsdata i databasen blir ikke gjenopprettet som en del av Fabric App-distribusjonsprosessen og må gjenopprettes separat.  Du kan manuelt gjenopprette en Fabric App etter en regional katastrofe ved å bruke applikasjonens kildekode og Rayfin CLI. 

Datavitenskap

Denne veiledningen veileder deg gjennom gjenopprettingsprosedyrene for Data Science-opplevelsen. Den dekker ML-modeller og eksperimenter.

ML-modell og eksperiment

Datavitenskapselementer fra det primære området forblir utilgjengelige for kunder, og innholdet og metadataene i ML-modeller og eksperimenter replikeres ikke til det sekundære området. Hvis du vil gjenopprette dem fullstendig i det nye området, lagrer du kodeinnholdet i et versjonskontrollsystem (for eksempel Git), og kjører kodeinnholdet manuelt etter katastrofen.

1. Gjenopprette notatblokken. Se trinnene for gjenoppretting av notatblokken.

2. Konfigurasjon, historisk kjøring av måledata og metadata replikeres ikke til det parede området. Du må kjøre hver versjon av datavitenskapskoden på nytt for å gjenopprette ML-modeller og eksperimenter etter katastrofen.

datalager

Denne guiden går gjennom gjenopprettingsprosedyrene for datalager-opplevelsen. Den dekker lagre.

Warehouse

Lagre fra det opprinnelige området forblir utilgjengelige for kunder. Hvis du vil gjenopprette lagre, bruker du følgende to trinn.

1. Opprett et nytt midlertidig lakehouse i arbeidsområde C2. W2 for dataene du kopierer fra det opprinnelige lageret.

2. Fyll lagerets Delta-tabeller ved å utnytte warehouse Explorer og T-SQL-funksjonene (se Tables in data warehousing in Microsoft Fabric).

Merk

Det anbefales at du beholder lagerkoden (skjema, tabell, visning, lagret prosedyre, funksjonsdefinisjoner og sikkerhetskoder) versjonskontroll og lagret på et trygt sted (for eksempel Git) i henhold til utviklingspraksisen din.

Datainntak via Lakehouse- og T-SQL-kode

I nylig opprettet arbeidsområde C2. W2:

1. Opprett en midlertidig lakehouse "LH2" i C2. W2.

2. Gjenopprett Delta-tabellene i det midlertidige lakehouse fra det opprinnelige lageret ved å følge Lakehouse-gjenopprettingstrinnene.

3. Opprett et nytt lager "WH2" i C2. W2.

4. Koble til midlertidig lakehouse i lagerutforskeren.

5. Avhengig av hvordan du skal distribuere tabelldefinisjoner før dataimport, kan den faktiske T-SQL-en som brukes for import, variere. Du kan bruke INSERT INTO, SELECT INTO eller CREATE TABLE AS SELECT til å gjenopprette lagertabeller fra lakehouses. Videre i eksemplet vil vi bruke INSERT INTO-smak. (Hvis du bruker koden nedenfor, erstatter du eksempler med faktiske tabell- og kolonnenavn)

   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. Til slutt, bytt tilkoblingsstreng i applikasjoner som bruker Fabric-lageret ditt.

Merk

For kunder som trenger tverrregional katastrofegjenoppretting og fullstendig automatisert forretningskontinuitet, anbefaler vi å ha to Fabric Warehouse-oppsett i separate Fabric-regioner og opprettholde kode- og dataparitet ved regelmessige utrullinger og datainntak til begge stedene.

Speilet database

Speilede databaser fra det primære området forblir utilgjengelige for kunder, og innstillingene replikeres ikke til det sekundære området. Hvis du vil gjenopprette den i tilfelle en regional feil, må du gjenopprette den speilede databasen i et annet arbeidsområde fra et annet område.

Data Factory

Data Factory-elementer fra det primære området forblir utilgjengelige for kunder, og innstillingene og konfigurasjonen i pipeliner eller dataflyt gen2-elementer replikeres ikke til det sekundære området. Hvis du vil gjenopprette disse elementene i tilfelle en regional feil, må du gjenopprette dataintegreringselementene i et annet arbeidsområde fra et annet område. Avsnittene nedenfor beskriver detaljene.

Dataflyter Gen2

Hvis du vil gjenopprette et Dataflyt Gen2-element i det nye området, må du eksportere en PQT-fil til et versjonskontrollsystem, for eksempel Git, og deretter gjenopprette Dataflyt gen2-innholdet manuelt etter katastrofen.

1. Fra Dataflow Gen2-elementet, i Hjem-fanen i Power Query-editoren, velg Eksporter mal.

   

2. Skriv inn et navn (obligatorisk) og en beskrivelse (valgfritt) for denne malen i dialogboksen Eksporter mal. Når du er ferdig, velger du OK.

   

3. Etter katastrofen oppretter du et nytt Dataflyt Gen2-element i det nye arbeidsområdet C2. W2".

4. Fra det nåværende visningspanelet i Power Query-editoren, velg Importer fra en Power Query-mal.

   

5. Bla til standard nedlastingsmappe i dialogboksen Åpne, og velg PQT-filen du lagret i de forrige trinnene. Velg deretter Åpne.

6. Malen importeres deretter til det nye Dataflyt gen2-elementet.

Funksjonen for lagring som for dataflyter støttes ikke i tilfelle nødgjenoppretting.

Pipelines

Kunder får ikke tilgang til pipeliner i tilfelle regional katastrofe, og konfigurasjonene replikeres ikke til det sammenkoblede området. Vi anbefaler at du bygger kritiske datasamlebånd i flere arbeidsområder på tvers av ulike områder.

Kopier jobb

CopyJob-brukere må foreta proaktive tiltak for å beskytte mot en regional katastrofe. Følgende fremgangsmåte sikrer at en brukers CopyJobs forblir tilgjengelig etter en regional katastrofe.

Brukeradministrert redundans med Git-integrasjon (i offentlig forhåndsvisning)

Den beste måten å gjøre denne prosessen enkel og rask på, er å bruke Fabric Git-integrasjon, og deretter synkronisere CopyJob med ADO-repoet. Når tjenesten mislykkes til et annet område, kan du bruke repositoriet til å gjenoppbygge CopyJob i det nye arbeidsområdet du opprettet.

1. Konfigurer arbeidsområdets Git-integrering, og velg koble til og synkronisere med ADO-repositoriet.

   

   Bildet nedenfor viser den synkroniserte CopyJob.

   

2. Gjenopprett CopyJob fra ADO-repo.

   1. I det nyopprettede arbeidsområdet, koble til og synkroniser til Azure ADO-repoet ditt igjen. Alle Fabric-elementer i dette arkivet lastes automatisk ned til ditt nye arbeidsområde.

      

   2. Hvis den opprinnelige CopyJob bruker en Lakehouse, brukere kan referere til Lakehouse delen for å gjenopprette Lakehouse og deretter koble den nylig gjenopprettede CopyJob til den nylig gjenopprettede Lakehouse.

Hvis du vil ha mer informasjon om Git-integrering, kan du se Innføring i Git-integrasjon.

Apache Airflow-jobb

Brukere av Apache Airflow Job in Fabric må iverksette proaktive tiltak for å beskytte seg mot en lokal katastrofe.

Vi anbefaler å håndtere redundans med Fabric Git-integrasjon. Først synkroniserer du Airflow Job med ADO-repoen. Hvis tjenesten mislykkes til et annet område, kan du bruke repositoriet til å gjenoppbygge Airflow-jobben i det nye arbeidsområdet du opprettet.

Her er trinnene for å oppnå dette:

1. Konfigurer arbeidsområdets Git-integrering, og velg «koble til og synkroniser» med ADO-repositoriet.

2. Etter det vil du se at Airflow-jobben din er synkronisert med ADO-repoen.

3. Hvis du trenger å gjenopprette Airflow-jobben fra ADO-repoet, opprett et nytt arbeidsområde, koble til, og synkroniser til Azure ADO-repoet ditt igjen. Alle Fabric-elementer, inkludert Airflow, i dette arkivet vil automatisk bli lastet ned til ditt nye arbeidsområde.

Sanntidsinnsikt

Denne veiledningen veileder deg gjennom gjenopprettingsprosedyrene for sanntidsintelligensopplevelsen. Den dekker KQL-databaser/spørringssett og hendelsesstrømmer.

Activator

Aktivator-elementer fra primærregionen er fortsatt utilgjengelige for kundene, og Activator-triggerdefinisjoner replikeres ikke til sekundærregionen. Aktivatorbrukere må ta proaktive grep for å forberede seg på regional katastrofegjenoppretting.

For å sikre at du kan gjenopprette Activator-elementer ved en regional katastrofe, sett opp Fabric Git-integrasjon for å sikkerhetskopiere triggerdefinisjoner og gjenopprette dem i et arbeidsområde i en annen region.

1. Konfigurer Fabric Git-integrasjon for arbeidsområdet som inneholder Activator-elementet ditt, og synkroniser triggerdefinisjonene dine med Git-repositoriet ditt.
2. Hold Activator-triggerdefinisjonene dine forpliktet og synkronisert jevnlig.
3. Under gjenoppretting, opprett et nytt arbeidsområde i målregionen (C2. W2), koble den til samme repository, og synkronisere for å gjenopprette triggerdefinisjonene.
4. Rekonfigurer og valider alle Activator-datakilder og avhengigheter i det nye arbeidsområdet.

Merk

Den vanlige Fabric-failover-prosessen gjelder ikke for Activator-elementer. Gjenoppretting er begrenset til Git-basert sikkerhetskopiering og gjenoppretting av triggerdefinisjoner.

Hvis du vil ha mer informasjon om Git-integrering, kan du se Innføring i Git-integrasjon.

Grafmodell/spørringssett

Graph Model- og Graph Queryset-elementer fra primærregionen forblir utilgjengelige for kundene, og disse elementene replikeres ikke til sekundærregionen. For å gjenopprette, opprett eller bruk en kapasitet i en annen region og gjenskap Graph Model og Graph Queryset-elementene der.

1. Opprett eller bruk en eksisterende Fabric-kapasitet i en annen region som ikke er berørt av katastrofen.

2. Opprett et nytt arbeidsområde eller bruk et eksisterende arbeidsområde i den kapasiteten.

3. Gjenskap Graph Model-elementet i det sekundære arbeidsområdet (referert i steg 2). Rekonfigurer modelldefinisjonen, inkludert noder, kanter osv., for å matche den opprinnelige grafmodellen.

4. Hvis det opprinnelige innsjøhuset ligger i det sviktende området, bør du først ta det opp igjen ved å følge innsjøhuset-delen.

5. Koble til et innsjøhus som OneLake-datakilde for det nyopprettede Graph Model-elementet. Bruk det gjenvunne innsjøhuset hvis det lå i det sviktende området, eller koble til det eksisterende innsjøhuset igjen hvis det fortsatt er tilgjengelig.

6. Rekonfigurer eventuelle datalasteplaner eller tilkoblinger for grafmodellen i det nye arbeidsområdet.

7. Gjenskap Graph Queryset-elementet i det sekundære arbeidsområdet. Manuelt tast inn spørringene og eventuelle lagrede spørringskonfigurasjoner fra det opprinnelige Graph Queryset.

KQL-database/spørringssett

Brukere av KQL-database/spørringssett må foreta proaktive tiltak for å beskytte mot en regional katastrofe. Følgende fremgangsmåte sikrer at i tilfelle en regional katastrofe forblir data i KQL-databasespørringene trygge og tilgjengelige.

Bruk følgende fremgangsmåte for å garantere en effektiv løsning for nødgjenoppretting for KQL-databaser og spørringssett.

1. Etabler uavhengige KQL-databaser: Konfigurer to eller flere uavhengige KQL-databaser/spørringssett på dedikerte Fabric-kapasiteter. Disse bør settes opp over to forskjellige Azure-regioner (helst Azure-par-regioner) for å maksimere robustheten.

2. Repliker administrasjonsaktiviteter: Alle administrasjonshandlinger som utføres i én KQL-database, bør speiles i den andre. Dette sikrer at begge databasene forblir synkroniserte. Viktige aktiviteter som skal replikeres inkluderer:

   • Tabeller: Kontroller at tabellstrukturene og skjemadefinisjonene er konsekvente på tvers av databasene.

   • Tilordning: Dupliser eventuelle nødvendige tilordninger. Kontroller at datakilder og mål justeres på riktig måte.

   • Policyer: Kontroller at begge databasene har lignende dataoppbevaring, tilgang og andre relevante policyer.

3. Behandle godkjenning og autorisasjon: Konfigurer de nødvendige tillatelsene for hver replika. Kontroller at det er etablert riktige godkjenningsnivåer, noe som gir tilgang til det nødvendige personellet samtidig som sikkerhetsstandardene opprettholdes.

4. Parallell datainntak: Hvis du vil holde dataene konsekvente og klare i flere områder, laster du inn det samme datasettet i hver KQL-database samtidig som du inntar dem.

Eventstream

En hendelsesstrøm er et sentralisert sted i Fabric-plattformen for å fange, transformere og rute sanntidshendelser til ulike destinasjoner (for eksempel innsjøhus, KQL-databaser/spørringssett) med en no-code-opplevelse. Så lenge destinasjonene støttes av nødgjenoppretting, mister ikke hendelsesstrømmer data. Derfor bør kunder bruke nødgjenopprettingsfunksjonene til disse målsystemene for å garantere datatilgjengelighet.

Kunder kan også oppnå geo-redundans ved å distribuere identiske Eventstream-arbeidsbelastninger i flere Azure-regioner som en del av en multi-site active/active-strategi. Med en aktiv/aktiv tilnærming for flere nettsteder kan kunder få tilgang til arbeidsbelastningen i alle de distribuerte områdene. Denne tilnærmingen er den mest komplekse og kostbare tilnærmingen til nødgjenoppretting, men det kan redusere gjenopprettingstiden til nær null i de fleste situasjoner. For å være fullstendig geo-redundant, kan kundene

1. Opprett replikaer av datakildene i forskjellige områder.

2. Opprett Eventstream-elementer i tilsvarende områder.

3. Koble disse nye elementene til de identiske datakildene.

4. Legg til identiske mål for hver hendelsesstrøm i forskjellige områder.

Forretningsarrangementer, Fabric-arrangementer og Azure-arrangementer

Selv om Business Events, Fabric Events og Azure Events deler samme Real-Time hub-infrastruktur i Microsoft Fabric, har de distinkte opprinnelser, atferd og gjenopprettingskrav som må forstås før man planlegger katastrofegjenoppretting:

• Fabric Events er hendelsesabonnementer som reagerer på aktivitet produsert av Fabric-ressurser selv, inkludert endringer i arbeidsområdets livssyklus (som opprettelse, oppdatering eller sletting av lakehouses, notatbøker eller lagre), jobbutførelser (som pipelinekjøringer eller notatblokkkjøringer), samt OneLake-fil- og mappeoperasjoner. Disse abonnementene er push-baserte og midlertidige. Abonnementene blir ikke replikert til sekundærregionen.

• Azure Events er hendelsesabonnementer på aktivitet produsert av Azure Blob Storage-kontoer. Disse Azure-ressursene eksisterer uavhengig av enhver Fabric-kapasitet eller region. Selv om Azure Blob Storage-ressursen selv kan forbli tilgjengelig under et Fabric regionalt avbrudd, blir ikke abonnementene som er konfigurert i Real-Time huben replikert til sekundærregionen og må gjenopprettes.

• Forretningshendelser er en distinkt funksjon i Fabric Real-Time Intelligence som gjør det mulig for team å definere, publisere og handle på meningsfulle forretningssignaler. Forretningshendelser genereres fra Fabric gjennom Activator, Spark-notatbøker eller User Data Functions, og publiseres deretter til Real-Time hub hvor nedstrøms forbrukere som Activator, Eventhouse eller Power Automate kan reagere på dem. Hendelsesskjemaer styres sentralt gjennom Schema Registry. Eventhouse lagrer automatisk alle publiserte forretningshendelser, så gjenopprettingen påvirker direkte tilgjengeligheten av forretningshendelseshistorikk. Ingen av utgiver- eller forbrukerkonfigurasjonene, skjemadefinisjonene eller abonnementene replikeres til sekundærregionen.

Bruk følgende steg for å gjenopprette Business Events, Fabric Events og Azure Events i det nye arbeidsområdet i gjenopprettingsregionen.

For forretningsarrangementer:

1. Gjenskap forretningsarrangementet som brukes av utgivere og forbrukere ved å følge artikkelen Create Business Events i Fabric Real-Time Hub. Under opprettelsen av forretningshendelsen oppretter du ressursen Event Schema Set. Eventhouse-ressursen er valgfri avhengig av scenarioet. Hvis du har sikkerhetskopiert hendelsesskjemasettet ditt med Git-integrasjon, gjenopprette det først ved å følge avsnittet for hendelsesskjemasettet, og pek deretter forretningshendelsen på det gjenopprettede skjemasettet.

2. Gjenskap alle publisher-elementer som genererer forretningshendelser, som Spark-notatbøker eller User Data Functions, i det nye arbeidsområdet ved å følge publisher-artiklene: Use User Data Function as Business Events Publisher, Use Activator as a Business Events Publisher, Use Notebook as a Business Events Events Publisher, og bruk Eventstream som Business Events Publisher.

3. Gjenskap forbrukerabonnementene i Real-Time hub (for eksempel Activator-regler, notatbok-triggere eller Power Automate flows) som opprinnelig reagerte på forretningshendelser i den berørte regionen ved å følge artiklene Eventhouse og Real-Time Dashboard-integrasjon med forretningshendelser og Consume Business Events fra Activator.

4. Valider at hendelser flyter fra ende til ende ved å verifisere at abonnementene er aktive og at data ankommer forventede destinasjoner i gjenopprettingsregionen.

For Fabric-arrangementer:

1. Gjenskap abonnementene i Real-Time hub som peker på arbeidsområdets elementer, jobber eller OneLake-stier som ble gjenopprettet i gjenopprettingsområdet ved å følge artikkelen Utforsk Fabric hendelser i Fabric Real-Time hub.

2. Valider at hendelser flyter fra ende til ende ved å verifisere at abonnementene er aktive og at data ankommer forventede destinasjoner i gjenopprettingsregionen.

For Azure-arrangementer:

1. Azure Blob Storage-kontoer påvirkes ikke av et regionalt Fabric-avbrudd. Gjenskap arrangementsabonnementene i Real-Time hub som peker til de samme Azure Blob Storage kontoene ved å følge artikkelen Sett varsler på Azure Blob Storage hendelser i Real-Time hub.

2. Valider at hendelser flyter fra ende til ende ved å verifisere at abonnementene er aktive og at data ankommer forventede destinasjoner i gjenopprettingsregionen.

Merk

Hendelseshistorikken for forretningshendelser avhenger av Eventhouse-gjenoppretting. Business Events, Fabric Events og Azure Events er push-baserte og flyktige, så ingen historiske hendelsesdata kan gjenopprettes for disse typene. Kun hendelser produsert etter at gjenopprettingen er fullført, er tilgjengelige i den nye regionen.

Hendelsesskjema sett

Et hendelsesskjema-sett er det Fabric elementet som inneholder definisjoner av hendelsestype og skjema i Real-Time Intelligence. Andre muligheter bygger videre på dette: utgivere skriver hendelser som følger skjemaene deres, og forbrukerne leser mot de samme definisjonene.

Hendelsesskjema-sett fra primærregionen forblir utilgjengelige for kundene, og de replikeres ikke til sekundærregionen. Men fordi et hendelsesskjema-sett er en varig definert definisjon og ikke et flyktig abonnement, kan du sikkerhetskopiere det på forhånd og gjenopprette det i stedet for å skrive det på nytt for hånd.

Anbefalt: ta backup med integrasjon av Fabric Git

For å gjenopprette et hendelsesskjema satt etter en regional katastrofe, sett opp Fabric Git-integrasjon før en katastrofe oppstår, og synkroniser arbeidsområdet som inneholder hendelsesskjemasettene dine med ditt Git-repositorium.

1. Konfigurer Fabric Git-integrasjon for arbeidsområdet som inneholder hendelsesskjemasettet ditt, og synkroniser det med ditt Git-repositorium.

2. Hold hendelsesskjema-settet forpliktet og synkronisert regelmessig, spesielt etter at hendelsestyper er lagt til eller nye skjemaversjoner er publisert.

3. Under gjenoppretting, opprett et nytt arbeidsområde i målregionen (C2. W2), koble den til samme repository, og synkroniser for å gjenopprette hendelsesskjemasettet. Fordi det nye arbeidsområdet er tomt, bringer Git-synkronisering innholdet fra repositoriet inn i arbeidsområdet.

4. Gjenskap alle utgivere og brukere som bruker skjemasettet, og følg veiledningen for disse varetypene.

5. Valider at utgivere kan publisere mot de gjenopprettede hendelsestypene, og at forbrukere mottar hendelser som forventet.

Den synkroniserte definisjonen inkluderer hendelsestypene i skjemasettet, skjemaene og skjemaversjonene. Den inkluderer ikke utgiverregistreringer, forbrukerabonnementer eller hendelseshistorikk. Hent disse separat, og følg veiledningen for itemtypene som bruker skjemasettet.

Alternativ: gjenskap manuelt

Hvis du ikke konfigurerte Git-integrasjon før katastrofen, gjenskap hendelsesskjemasettet i gjenopprettingsområdet ved å følge Create and manage event schema sets, og legg deretter til hendelsestypene og skjemaene som det opprinnelige skjemasettet inneholdt ved å følge Create and manage event schemas in schema sets.

Merk

Hendelsesskjema-sett deles ofte mellom flere utgivere og forbrukere. Hent skjemasettet før du lager elementene som er avhengige av det på nytt, slik at disse elementene har hendelsestyper å binde seg til.

Kart

Kartobjekter fra primærregionen forblir utilgjengelige for kundene, og kartelementene blir ikke replikert til sekundærregionen.

Hvis du vil gjenopprette et kartelement når en katastrofe skjer, sett opp Fabric Git-integrasjon, og synchronize kartelementet ditt med Git-repoet.

Under gjenopprettingen, etter at den nye regionen/kapasiteten i Fabric er satt opp, kan du bruke repoet til å bygge opp kartelementet i det nye arbeidsområdet du har opprettet. Siden det nye arbeidsområdet er tomt, henter Git sync innholdet fra repoet inn i det tomme arbeidsområdet. Dette steget bringer Kart-gjenstanden tilbake til liv.

Merk

Hvis det opprinnelige kartelementet har et lakehouse- eller KQL-spørringssett konfigurert, se først Lakehouse-seksjonen og KQL-spørringssettet for å gjenopprette dem. Når disse avhengighetene er løst, kobler du det nylig gjenopprettede innsjøhuset og spørringssettet til det nylig gjenopprettede kartelementet.

Ontologi

Ontologibrukere må ta proaktive grep for å forberede seg på regional katastrofegjenoppretting. Tilnærmingen beskrevet nedenfor sikrer at etter en regional katastrofe kan Ontologien din fortsatt gjenopprettes og kan gjenopprettes raskt.

Den enkleste og raskeste måten å muliggjøre gjenoppretting på er å bruke Fabric Git-integrasjon og synkronisere ontologien din med et Azure DevOps (ADO)-repositorium. Hvis tjenesten går over til en annen region, kan du bruke dette repositoriet til å bygge opp ontologien på nytt i et nyopprettet arbeidsområde.

Ontologielementer i primærregionen er ikke tilgjengelige for kunder etter en regional katastrofe, og ontologielementer replikeres ikke til sekundærregionen.

For å gjenopprette et Ontology-element under en katastrofe, konfigurere Fabric Git-integrasjon, og synchronize Ontology-elementet med ADO-repositoriet ditt på forhånd.

Under gjenoppretting, når den nye regionen og kapasiteten i Fabric er satt opp, kan du bruke repositoryet til å bygge opp Ontology-elementet i et nytt arbeidsområde. Fordi det nye arbeidsområdet er tomt, henter Git sync innholdet fra repositoriet inn i arbeidsområdet, og gjenoppretter dermed effektivt Ontology-elementet.

Merk

Hvis det opprinnelige Ontology-elementet har et lakehouse konfigurert, se Lakehouse-seksjonen for å gjenopprette lakehouse først. Når disse avhengighetene er tatt hånd om, koble det nylig gjenopprettede innsjøhuset til det nylig gjenopprettede Ontologi-elementet.

Plan

Denne artikkelen beskriver gjenopprettingsprosedyrene for Plan-opplevelsen i IQ. Den beskriver trinnene som kreves for å gjenopprette nøkkelkomponenter, inkludert Planning, PowerTable, Intelligence, InfoBridge og tilhørende dataressurser.

Git-integrasjon for å gjenopprette planelementer

Den foretrukne tilnærmingen er å synkronisere alle planelementer med et Azure DevOps (ADO) eller GitHub-repositorium ved å bruke Fabric Git-integrasjon. Etter en failover, bruk repositoryet for å gjenopprette elementene i det nye arbeidsområdet.

Forkatastrofe (proaktive tiltak):

1. I arbeidsområde W1, gå til Arbeidsområdeinnstillinger og konfigurer Git-integrasjon.

2. Velg Connect og synkroniser med ADO eller GitHub-repositoriet ditt.

3. Velg planelementene som skal lastes opp til depotet og velg Forplikt.

   

4. Bekreft at Git-statusen til planobjektene er Synkronisert.

5. Etabler en commit-disiplin – commit etter hver betydelig endring i en plandefinisjon slik at repositoryet alltid gjenspeiler den nyeste tilstanden.

Gjenopprettingstrinn:

1. Lag et nytt arbeidsområde W2 innenfor kapasitet C2 i det sunne området.

2. I arbeidsområde W2, gå til Arbeidsområdeinnstillinger og koble til samme ADO/GitHub-repositorium igjen.

3. Velg kildekontroll. Velg den relevante repository-grenen og velg Oppdater Alt. Alle planposter lastes ned til W2.

Viktig!

Kun planleggingsarkets struktur og innstillinger gjenopprettes ved bruk av Git-integrasjon. Data som legges inn i planleggingsarket, som inndataverdier, notater og kommentarer, blir ikke automatisk gjenopprettet. Den krever Fabric SQL-gjenoppretting. Semantiske modelldata må også hentes separat.

Følgende komponenter gjenopprettes etter gjenoppretting:

• PowerTable-ark: Innstillinger for kildetabeller, kolonnekonfigurasjon, rad-tilgang, visuelle egenskaper (layout, formater og mer), radidentifikasjon, kommentarinnstillinger, gradvis endrende dimensjoner (SCD), godkjenninger, automatiseringer og skjemaer.
• Planleggingsark: Arkegenskaper (formatering, betinget formatering og mer), kommentarinnstillinger, tilbakeskrivingsinnstillinger, datainndatakolonner, datainndatarader, scenarier og bokmerker.
• InfoBridge: InfoBridge-kilder, InfoBridge-spørringer, transformasjonssteg, writeback-destinasjoner, writeback-innstillinger, koblede spørringsmappinger, spørringsgrupper, visuelle egenskaper (blend). Disse elementene kan ikke gjenopprettes: filbaserte kilder (CSV, Excel), tverrarbeidsmengdeark som bruker filbaserte kilder.
• Etterretning: Alle horoskoper og matriser.

Fabric SQL-gjenoppretting for plan

Data som legges inn i planleggingsark, tabeller brukt i PowerTable, og tilbakeskrivingsdata lagres i SQL-databaser og må vurderes som en del av din katastrofegjenopprettingsstrategi. For å gjenopprette SQL-databaser, se SQL-databasedelen .

• Gjenopprette planmetadata: Hvert planelement er knyttet til en __fabric_plan_sys database som lagrer metadata for planleggingsfunksjoner, inkludert kommentarer, scenarioer, datainndata og tilbakeskrivingskonfigurasjon. Den __fabric_plan_sys databasen gjenopprettes ikke automatisk og må eksplisitt gjenopprettes.

• Gjenopprette writeback-databaser: Hvis planen din bruker SQL-writeback-destinasjoner, må du også gjenopprette de tilknyttede databasene manuelt. Konfigurerte SQL-writeback-destinasjoner gjenopprettes ikke automatisk.

• Gjenopprettingstabeller brukt i PowerTable: Alle tabeller laget ved bruk av PowerTable lagres i en Fabric SQL-database. Du må også gjenopprette disse tabellene under DR.

Operasjonsagenter

Brukere av operasjonsagenter bør ta proaktive grep for å forberede seg på regional katastrofegjenoppretting. Å følge tilnærmingen beskrevet i dette avsnittet bidrar til å sikre at agentene dine raskt kan gjenopprettes etter et regionalt driftsavbrudd.

Bruk Fabric Git-integrasjon for å synkronisere arbeidsområdet ditt med et repository. Denne tilnærmingen gjør det mulig å rekonstruere agentkonfigurasjoner i et nytt arbeidsområde hvis tjenesten går over til en annen region.

Operasjonsagenter i primærregionen er ikke tilgjengelige under en regional katastrofe. Agentkonfigurasjoner, atferdsmodeller og aktivitetslogger blir ikke replikert til sekundærområdet. Pågående operasjoner, aktive chat-økter og tidligere inntatte hendelser på tidspunktet for katastrofen går også tapt.

For å forberede gjenoppretting, konfigurere Fabric Git-integrasjon og synkroniser agentelementene dine med ADO-repositoriet før en katastrofe inntreffer.

Når du gjenoppretter, sett opp din nye region og kapasitet i Fabric, og bruk deretter det synkroniserte repositoriet for å gjenopprette agentkonfigurasjoner i et nytt arbeidsområde. Git Sync henter det lagrede innholdet fra repositoriet inn i det tomme arbeidsområdet, og gjenskaper agent-elementene dine.

Når konfigurasjonene er gjenopprettet, bekreft at eventuelle refererte Eventhouse (KQL)-databaser eller regionsspesifikke datakilder er tilgjengelige i den nye regionen. Oppdater endepunktreferanser i agentkonfigurasjoner etter behov. Til slutt, start agentene dine på nytt og la brukerne starte nye chat-økter. Tidligere samtaler kan ikke gjenopptas.

Transaksjonell database

Denne veiledningen beskriver gjenopprettingsprosedyrene for transaksjonsdatabaseopplevelsen.

SQL-database

For å beskytte mot en regional feil kan brukere av SQL-databaser iverksette proaktive tiltak for å eksportere dataene sine med jevne mellomrom og bruke de eksporterte dataene til å opprette databasen på nytt i et nytt arbeidsområde når det er nødvendig.

Dette kan oppnås ved å bruke SqlPackage CLI-verktøyet som gir databaseportabilitet og forenkler databasedistribusjoner.

1. Bruk SqlPackage-verktøyet til å eksportere databasen til en .bacpac fil. Se Eksportere en database med SqlPackage hvis du vil ha mer informasjon.
2. Lagre .bacpac filen på et sikkert sted som er i et annet område enn databasen. Eksempler inkluderer lagring av filen .bacpac i en Lakehouse i en annen region, ved bruk av en geo-redundant Azure Storage-konto, eller ved bruk av et annet sikkert lagringsmedium i en annen region.
3. Hvis SQL-databasen og området ikke er tilgjengelig, kan du bruke .bacpac filen med SqlPackage til å opprette databasen på nytt i et arbeidsområde i et nytt område – arbeidsområde C2. W2 i region B som beskrevet i scenariet ovenfor. Følg fremgangsmåten som er beskrevet i Importere en database med SqlPackage for å opprette databasen på nytt med .bacpac filen.

Den gjenskapte databasen er en uavhengig database fra den opprinnelige databasen og gjenspeiler tilstanden til dataene på tidspunktet for eksportoperasjonen.

Hensyn til failback

Den gjenskapte databasen er en uavhengig database. Data som legges til i den gjenskapte databasen, gjenspeiles ikke i den opprinnelige databasen. Hvis du planlegger å failback til den opprinnelige databasen når hjemmeområdet blir tilgjengelig, må du vurdere å avstemme data manuelt fra den gjenopprettede databasen til den opprinnelige databasen.

Plattform

Plattform refererer til de underliggende delte tjenestene og arkitekturen som gjelder for alle arbeidsbelastninger. Denne delen beskriver gjenopprettingsprosedyrer for delte Fabric-kapabiliteter.

Overvåking av arbeidsområde

Overvåking av arbeidsområdet samler logger om aktivitet i arbeidsområdet der du aktiverer det. Etter at du har gjenopprettet arbeidsområdet ditt som C2. W2, aktiver arbeidsområdeovervåking på W2. Den begynner å samle inn overvåkingsdata for det gjenopprettede arbeidsområdet.

Overvåkingsdata fra det opprinnelige arbeidsområdet (C1. W1) overføres ikke, fordi overvåking reflekterer aktiviteten i arbeidsområdet den kjører på.

Variabelt bibliotek

Microsoft Fabric Variable-biblioteker gjør det mulig for utviklere å tilpasse og dele elementkonfigurasjoner i et arbeidsområde, noe som effektiviserer innholdslivssyklusen. Fra et nødgjenopprettingssynspunkt må brukere av variable biblioteker proaktivt beskytte mot en regional katastrofe. Dette kan gjøres gjennom Fabric Git-integrasjon, som sikrer at etter en regional katastrofe forblir brukerens Variable-bibliotek tilgjengelig. Hvis du vil gjenopprette et variabelbibliotek, anbefaler vi følgende:

• Bruk Fabric Git-integrasjon for å synkronisere Variable-biblioteket ditt med ADO-repoet. I tilfelle katastrofe kan du bruke repositoriet til å gjenoppbygge variabelbiblioteket i det nye arbeidsområdet du opprettet. Bruk følgende fremgangsmåte:

  1. Koble arbeidsområdet til Git-repositoriet som beskrevet her.
  2. Sørg for å holde WS og repositoriet synkronisert med Commit and Update.
  3. Gjenoppretting – I tilfelle katastrofe kan du bruke repositoriet til å gjenoppbygge variabelbiblioteket i et nytt arbeidsområde:

• I det nyopprettede arbeidsområdet, koble til og synkroniser til Azure ADO-repoet ditt igjen.

• Alle Fabric-elementer i dette arkivet lastes automatisk ned til ditt nye arbeidsområde.

• Når du har synkronisert elementene fra Git, åpner du variabelbibliotekene i det nye arbeidsområdet og velger ønsket aktivt verdisett manuelt.

Kundestyrte nøkler for Fabric-arbeidsområder

Du kan bruke kundestyrte nøkler (CMK) lagret i Azure Key Vault for å legge til et ekstra lag med kryptering oppå Microsoft-administrerte nøkler for data i hvile. Hvis Fabric blir utilgjengelig eller ubrukelig i et område, vil komponentene overføres til en backup-instans. Under failover støtter CMK-funksjonen skrivebeskyttede operasjoner. Så lenge Azure Key Vault-tjenesten forblir frisk og tillatelsene til hvelvet er intakte, vil Fabric fortsette å koble til nøkkelen din og la deg lese data normalt. Dette betyr at følgende operasjoner ikke støttes under failover: aktivering og deaktivering av CMK-innstillingen for arbeidsområdet og oppdatering av nøkkelen.

OneLake

Denne delen tar deg gjennom gjenopprettingsprosedyrene for OneLake-funksjoner. For mer informasjon om katastrofegjenoppretting for OneLake-data, se OneLake katastrofegjenoppretting.

Policyer for livssyklusbehandling

Dersom Fabric blir utilgjengelig eller ubrukelig i et område, kan din OneLake-livssykluspolicy fortsatt leses og oppdateres under failover. All data som flyttes til kjøle- eller kald-nivået vil forbli i det nivået. Du kan følge disse stegene for å anvende din eksisterende policy på ditt nye gjenopprettingsarbeidsområde:

1. Kall Eksportpolicy på ditt opprinnelige arbeidsområde og lagre hele livssykluspolicyen.
2. Kall Import Policy på ditt gjenopprettede arbeidsområde, med din eksportør-livssykluspolicy som forespørselsorgan.

Ressursinstansregler

Ressursinstansregler hjelper deg med å sikre tilgang til data i OneLake ved å bruke pålitelige Azure-ressursidentiteter. Under regional failover fortsetter systemet å håndheve eksisterende regler for lesetilgang. Du kan imidlertid ikke opprette, oppdatere eller slette ressursinstansregler før arbeidsområdet går tilbake til en skrivbar tilstand.

Beslektet informasjon

• Microsoft Fabric katastrofegjenopprettingsguide