Ervaringsspecifieke richtlijnen voor herstel na noodgevallen

Dit artikel biedt ervaringsgerichte richtlijnen voor het terugvinden van uw Fabric-gegevens in het geval van een regionale ramp.

Voorbeeldscenario

Veel richtlijnen in dit artikel gebruiken het volgende voorbeeldscenario voor uitleg en illustratie. Raadpleeg dit scenario indien nodig.

Stel dat u een capaciteit C1 in regio A hebt met een werkruimte W1. Wanneer u herstel na noodgevallen heeft ingeschakeld voor capaciteit C1, worden de OneLake-gegevens gerepliceerd naar een back-up in regio B. Als regio A onderbrekingen ondervindt, schakelt de Fabric-service in C1 over naar regio B.

In de volgende afbeelding ziet u dit scenario. In het vak aan de linkerkant ziet u de verstoorde regio. Het vak in het midden vertegenwoordigt de voortdurende beschikbaarheid van de gegevens na een failover en het vak aan de rechterkant toont de volledig gedekte situatie nadat de klant heeft deelgenomen aan het herstellen van hun services naar volledige functie.

Dit is het algemene herstelplan:

1. Maak een nieuwe Fabric-netwerkcapaciteit C2 in een nieuwe regio.

2. Maak een nieuwe W2-werkruimte in C2, inclusief de bijbehorende items met dezelfde namen als in C1. W1.

3. Kopieer gegevens van de verstoorde C1.W1 naar C2.W2.

4. Volg de speciale instructies voor elk onderdeel om items te herstellen naar hun volledige functie.

In dit herstelplan wordt ervan uitgegaan dat de basisregio van de tenant operationeel blijft. Als de woonregio van de huurder een storing ervaart, zijn de in dit artikel beschreven stappen afhankelijk van het herstel ervan, dat eerst door Microsoft moet worden gestart en afgerond.

Ervaringsspecifieke herstelplannen

De volgende secties bieden stapsgewijze handleidingen voor elke Fabric-ervaring om je door het herstelproces te helpen.

Data-engineering

In deze handleiding wordt u begeleid bij de herstelprocedures voor de Data-engineer-ervaring. Het behandelt lakehouses, notebooks, Spark-jobdefinities, gebruikersdatafuncties en GraphQL-API's.

Lakehouse

Lakehouses uit de oorspronkelijke regio blijven niet beschikbaar voor klanten. Om een lakehouse te herstellen, kunnen klanten deze opnieuw maken in werkruimte C2. W2. We raden twee benaderingen aan voor het herstellen van lakehouses:

Benadering 1: Aangepast script gebruiken om Lakehouse Delta-tabellen en -bestanden te kopiëren

Klanten kunnen lakehouses opnieuw maken met behulp van een aangepast Scala-script.

1. Maak het lakehouse (bijvoorbeeld LH1) in de zojuist gemaakte werkruimte C2. W2.

2. Maak een nieuw notitieblok in de werkruimte C2. W2.

3. Als u de tabellen en bestanden uit het oorspronkelijke lakehouse wilt ophalen, raadpleegt u de gegevens met OneLake-paden zoals abfss (zie Connecting to Microsoft OneLake). U kunt het volgende codevoorbeeld (zie Introduction to Microsoft Spark Utilities) in het notebook gebruiken om de ABFS-paden van bestanden en tabellen op te halen uit het oorspronkelijke Lakehouse. (Vervang C1.W1 door de naam van de werkruimte)

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

4. Gebruik het volgende codevoorbeeld om tabellen en bestanden te kopiëren naar het zojuist gemaakte Lakehouse.

   1. Voor Delta-tabellen moet u de tabellen één voor één kopiëren om te herstellen in het nieuwe lakehouse. In het geval van Lakehouse-bestanden kunt u de volledige bestandsstructuur met alle onderliggende mappen kopiëren met één uitvoering.

   2. Neem contact op met het ondersteuningsteam voor de tijdstempel van failover die is vereist in het script.

   %%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. Nadat u het script hebt uitgevoerd, worden de tabellen weergegeven in het nieuwe lakehouse.

Benadering 2: gebruik Azure Storage Explorer om bestanden en tabellen te kopiëren

Gebruik Azure Storage Explorer om alleen specifieke Lakehouse-bestanden of -tabellen te herstellen uit het oorspronkelijke lakehouse. Raadpleeg Integrate OneLake met Azure Storage Explorer voor gedetailleerde stappen. Gebruik Benadering 1 voor grote gegevensgrootten.

Herstellen van Fabric gematerialiseerde lakeweergaven

Na failover kun je geen gematerialiseerde meeruitzichten vanuit het oorspronkelijke gebied bereiken. Het failoverproces repliceert geen verversschema's of uitvoeringsgeschiedenis naar de secundaire regio. Om deze items te herstellen, voltooit u de volgende stappen nadat u uw Lakehouse-gegevens hebt hersteld:

• Herstel de Lakehouse-tabellen door gebruik te maken van Approach 1 of Approach 2 zoals eerder in dit artikel beschreven. Kopieer alleen de brontabellen.
• Herstel de notebooks met uw MLV-definities. Voor herstelstappen, zie het Notitieboek-gedeelte .
• Voer de herstelde notebooks uit om de MLV's te reproduceren in het nieuwe Lakehouse. Zie Een gematerialiseerde Lake View maken voor meer informatie over het maken van MLV's. Als je MLV's hebt gekopieerd in de eerdere stap, voer dan CREATE OR REPLACE uit wanneer je ze opnieuw aanmaakt.
• Maak handmatig de MLV-verversschema's opnieuw aan in de nieuwe werkruimte. Je kunt de planningsgeschiedenis of uitvoeringsstatistieken niet herstellen.
• Als uw MLV's semantische modellen of rapporten voorzien, controleert en werkt u de verwijzingen naar de Lakehouse-ID en gegevensset-ID bij indien nodig. Maak opnieuw verbinding met het bijgewerkte semantische model en valideer de nieuwheid van gegevens.

Laptop

Notebooks uit de primaire regio blijven niet beschikbaar voor klanten, en de code in notebooks repliceert niet naar de secundaire regio. Om notebookcode in de nieuwe regio te herstellen, gebruik je een van de volgende methoden.

Benadering 1: door de gebruiker beheerde redundantie met Git-integratie (in openbare preview)

Gebruik Fabric Git integration om je notebook te synchroniseren met je Azure DevOps (ADO) repo. Nadat de service is overgezet naar een andere regio, gebruik je de repo om het notebook opnieuw op te bouwen in de nieuwe werkruimte die je hebt aangemaakt.

1. Configureer Git-integratie voor uw werkruimte en selecteer Verbinding maken en synchroniseren met ADO-opslagplaats.

   

   In de volgende afbeelding ziet u het gesynchroniseerde notitieblok.

   

2. Herstel het notitieblok uit de ADO-opslagplaats.

   1. Maak in de zojuist gemaakte werkruimte opnieuw verbinding met uw Azure ADO-opslagplaats.

      

   2. Selecteer de knop Broncodebeheer. Selecteer vervolgens de relevante branch van de repository. Selecteer daarna Alles bijwerken. Het oorspronkelijke notitieblok wordt weergegeven.

      

      

   3. Als het originele notitieboekje een standaard lakehouse heeft, raadpleeg dan de sectie Lakehouse om het lakehouse te bemachtigen en verbind vervolgens het nieuw teruggevonden lakehouse met het nieuw teruggevonden notitieboek.

      

   4. De Git-integratie biedt geen ondersteuning voor het synchroniseren van bestanden, mappen of momentopnamen van notebooks in de notebooks-resourceverkenner.

      1. Als het oorspronkelijke notitieblok bestanden bevat in de notitieblok-resourceverkenner:

         1. Sla bestanden of mappen op op een lokale schijf of op een andere locatie.

         2. Upload het bestand opnieuw vanaf uw lokale schijf of cloudstations naar het herstelde notebook.

      2. Als het oorspronkelijke notitieblok een momentopname van het notitieblok heeft, slaat u de momentopname van het notitieblok ook op in uw eigen versiebeheersysteem of lokale schijf.

         

         

Zie Inleiding tot Git-integratie voor meer informatie over Git-integratie.

Benadering 2: Handmatige benadering voor het maken van back-ups van code-inhoud

Als je niet de Git-integratiemethode kiest, sla dan de nieuwste versie van je code, bestanden op in de resource explorer en notebook snapshot in een versiebeheersysteem zoals Git. Herstel handmatig de inhoud van het notitieboek na een ramp:

1. Gebruik de functie Notitieboek importeren om de notitiecode te importeren die je wilt herstellen.

   

2. Ga na het importeren naar de gewenste werkruimte (bijvoorbeeld 'C2. W2") om er toegang toe te krijgen.

3. Als het oorspronkelijke notitieblok een standaard lakehouse heeft, raadpleegt u de Lakehouse-sectie. Verbind vervolgens het zojuist herstelde lakehouse (dat dezelfde inhoud heeft als de oorspronkelijke standaard lakehouse) met het zojuist herstelde notebook.

4. Als het oorspronkelijke notitieblok bestanden of mappen bevat in de resourceverkenner, uploadt u de bestanden of mappen die zijn opgeslagen in het versiebeheersysteem van de gebruiker.

Spark-taakdefinitie

Spark-taakdefinities (SJD) uit de primaire regio blijven onbeschikbaar, en OneLake repliceert het hoofddefinitiebestand en referentiebestand in het notitieboek naar de secundaire regio. Als je de SJD in de nieuwe regio wilt herstellen, volg dan de handmatige stappen die in deze sectie zijn beschreven. Historische uitvoeringen van de SJD worden niet hersteld.

U kunt de SJD-items herstellen door de code uit de oorspronkelijke regio te kopiëren met behulp van Azure Storage Explorer en na het noodgeval handmatig opnieuw verbinding te maken met Lakehouse-verwijzingen.

1. Maak een nieuw SJD-item aan (bijvoorbeeld SJD1) in de nieuwe werkruimte C2. W2, met dezelfde instellingen en configuraties als het originele SJD-item (bijvoorbeeld taal, omgeving, enzovoort).

2. Gebruik Azure Storage Explorer om bibliotheken, mains en momentopnamen van het oorspronkelijke SJD-item naar het nieuwe SJD-item te kopiëren.

   

3. De code-inhoud verschijnt in de nieuw aangemaakte SJD. Je moet handmatig de nieuw teruggevonden Lakehouse-referentie aan de klus toevoegen (zie de Lakehouse-herstelstappen). Gebruikers moeten de originele commandoregelargumenten handmatig opnieuw invoeren.

   

U kunt nu uw zojuist herstelde SJD uitvoeren of plannen.

Zie Integrate OneLake with Azure Storage Explorer voor meer informatie over Azure Storage Explorer.

Functies voor gebruikersgegevens

Om je gebruikersgegevensfuncties in een gezonde regio te herstellen, gebruik je een van de volgende methoden.

Benadering 1: Met Git-integratie (aanbevolen)

Het voorkeursherstelmechanisme is Fabric Git-integratie. Door gebruikersdatafunctieprojecten te synchroniseren met een Azure DevOps- of GitHub-repository, kun je ze snel reconstrueren in een nieuwe werkruimte na een failover.

Bereid je voor op een ramp

1. Configureer Fabric Git-integratie voor de werkruimte die de gebruikersdatafunctie host.
2. Verbind de werkruimte met een Azure DevOps- of GitHub-repository.
3. Zet alle gebruikersgegevensfuncties in de repository en synchroniseer wijzigingen regelmatig.
4. Sla omgevingsspecifieke instellingen apart op in variabele bibliotheken indien nodig.

Herstelstappen

Na een regionale ramp:

1. Creëer een nieuwe Fabric-capaciteit in een gezonde regio, zoals C2.
2. Maak een nieuwe werkruimte, zoals W2, in de nieuwe hoedanigheid.
3. Verbind de werkruimte met dezelfde Azure DevOps- of GitHub-repository.
4. Open Broncodebeheer en synchroniseer de inhoud van de opslagplaats met de werkruimte.
5. Maak alle afhankelijke Fabric-bronnen opnieuw aan of herstel ze, zoals lakehouses, SQL-databases in Fabric, warehouses en Business Events.
6. Implementeer de functies voor gebruikersgegevens opnieuw.
7. Valideer de functie-uitvoering en afhankelijkheidsconnectiviteit.
8. Werk downstreamapplicaties, datapijplijnen of andere geïntegreerde onderdelen bij zodat deze verwijzen naar de herstelde functies.
9. Volledige end-to-end validatie van al je scenario's.

Belangrijke overwegingen

• Git-integratie herstelt alleen broncode en projectassets.
• Historische executielogboeken worden niet teruggevonden.
• Downstream-systemen kunnen een herbinding van het eindpunt vereisen.

Raadpleeg voor meer informatie Broncodebeheer en implementatie van gebruikersgegevensfuncties.

Aanpak 2: Handmatig herstel

Als Git-integratie niet vóór de ramp was geconfigureerd, kun je handmatig gebruikersdatafuncties reconstrueren vanuit broncode-back-ups.

Bereid je voor op een ramp

Voer regelmatig de volgende taken uit en sla de items op in een externe source control-repository of back-uplocatie:

• Exporteer de broncode van de functie naar een GitHub-repository.
• Documenteer en bewaar afhankelijkheidsinformatie.
• Instellingen voor documentomgeving.

Herstelstappen

Na een regionale ramp:

1. Creëer een nieuwe Fabric-capaciteit in een gezonde regio, zoals C2.
2. Maak een nieuwe werkruimte aan, zoals W2.
3. Herstel alle resources die de functie nodig heeft, waaronder lakehouses, SQL-databases in Fabric, warehouses, eventhouses en externe diensten.
4. Maak een nieuw user data function project aan.
5. Importeer of maak de broncode van de functie opnieuw.
6. Pas de runtime-configuratie-instellingen opnieuw toe.
7. Installeer alle functieafhankelijkheden opnieuw.
8. Hergebruik de functie.
9. Herconfigureer authenticatie en autorisatie.
10. Maak Business Event-uitgevers of consumenten opnieuw aan, indien gebruikt.
11. Voltooi end-to-end validatietests voor je scenario's en integraties.

GraphQL

GraphQL-items uit de primaire regio zijn niet beschikbaar na een regionaal noodgeval en GraphQL-definities en -configuraties worden niet gerepliceerd naar de secundaire regio. Als u GraphQL in een nieuwe regio wilt herstellen, gebruikt u een van de volgende methoden.

Benadering 1: Gebruikersbeheerde redundantie met Git-integratie

De beste manier om dit proces eenvoudig en snel te maken, is door Fabric Git-integratie te gebruiken en uw GraphQL vervolgens te synchroniseren met uw ADO-opslagplaats. Nadat de service een failover naar een andere regio heeft uitgevoerd, kunt u de opslagplaats gebruiken om de GraphQL opnieuw te bouwen in de nieuwe werkruimte die u hebt gemaakt.

1. Maak een nieuwe werkruimte in de doelcapaciteit en regio.

2. Herstel alle afhankelijke gegevensbronnen, zoals Lakehouse, Warehouse of SQL-databases, door de bijbehorende herstelstappen te volgen.

3. Werk de GraphQL-definitie bij om te verwijzen naar de nieuw herstelde bronnen door omgevingsspecifieke referenties zoals bronwerkruimte-ID's, bron-item-ID's en verbindingsdetails aan te passen. Deze stap zorgt ervoor dat de juiste binding tijdens de implementatie wordt uitgevoerd.

4. Deploy GraphQL-items opnieuw uit de Git-repository naar de nieuwe werkruimte. Met deze stap maakt u de API-structuur en -configuratie opnieuw met behulp van de bijgewerkte definities.

5. Pas iteminstellingen opnieuw toe, waaronder rollen, toegangscontroles en authenticatieconfiguratie.

6. Pas eindpuntverwijzingen opnieuw toe door toepassingen of integraties bij te werken om het zojuist gemaakte GraphQL-eindpunt te gebruiken.

7. Werk bestaande implementatiepijplijnen bij die naar de oude werkruimte verwijzen om te verwijzen naar de zojuist gemaakte werkruimte.

8. Valideer end-to-end-functionaliteit van de API.

Benadering 2: Handmatige benadering

Als u niet de Git-integratiebenadering gebruikt, kunt u de volgende handmatige methode gebruiken om GraphQL te herstellen.

1. Maak een nieuwe werkruimte in de doelcapaciteit en regio.

2. Herstel alle afhankelijke gegevensbronnen, zoals Lakehouse, Warehouse of SQL-databases.

3. Maak de GraphQL-API handmatig opnieuw in de nieuwe werkruimte, inclusief schemadefinities, gegevensbronverbindingen en relaties.

4. Pas iteminstellingen opnieuw toe, waaronder rollen, toegangscontroles en authenticatieconfiguratie.

5. Pas eindpuntverwijzingen opnieuw toe door toepassingen of integraties bij te werken om het zojuist gemaakte GraphQL-eindpunt te gebruiken.

6. Werk bestaande implementatiepijplijnen bij die naar de oude werkruimte verwijzen om te verwijzen naar de zojuist gemaakte werkruimte.

7. Valideer end-to-end-functionaliteit van de API.

Belangrijke overwegingen

1. GraphQL is afhankelijk van externe afhankelijkheden (zoals Lakehouse, Warehouse en SQL), die u moet herstellen vóór de GraphQL-implementatie.

2. GraphQL API-definities bevatten omgevingsspecifieke verwijzingen (zoals sourceWorkspaceId en sourceItemId). Wanneer u herstelt in een nieuwe regio, kunnen deze verwijzingen ongeldig worden. Werk ze bij zodat ze verwijzen naar nieuw ingerichte resources.

3. Het automatisch koppelen van gegevensbronnen wordt niet gegarandeerd in scenario's voor herstel na noodgevallen, met name bij het gebruik van opgeslagen referenties of verbindingen tussen werkruimten.

4. Andere instellingen van items, zoals monitoring, autorisatie, RBAC, introspectie en meer, blijven na een failover niet behouden. U moet deze instellingen opnieuw instellen in de nieuwe regio.

References

• Overzicht van Fabric Git-integratie - Microsoft Fabric | Microsoft Learn

• Broncodebeheer- en implementatiepijplijnen in API voor GraphQL - Microsoft Fabric | Microsoft Learn 

App

Het systeem repliceert Fabric Apps, inclusief hun code, configuratie en metadata, niet naar secundaire regio's. Als de primaire regio faalt, blijft de app niet beschikbaar. Voor herstel sla je de broncode van de app buiten het systeem op in GitHub, Azure DevOps of een ander bronbeheersysteem. Herstel app-gegevens afzonderlijk door de disaster recovery-richtlijnen voor elke onderliggende Fabric-datawinkel te volgen.

Handmatige benadering

Je kunt een Fabric App handmatig herstellen na een regionale ramp door gebruik te maken van de broncode van de applicatie en de Rayfin CLI. 

Prerequisites 

Voordat er een ramp plaatsvindt:

• Sla de broncode van de Fabric App op in GitHub, Azure DevOps of een andere source control repository. 

• Documenteer het herstelproces.  

Herstelstappen 

1. Maak een nieuwe werkruimte in de doelcapaciteit en regio. 

2. Herstel afhankelijke resources voordat je de applicatie opnieuw uitrolt.  

3. Haal de nieuwste broncode van de Fabric App op uit je source control-repository of lokale back-up. 

4. Vanuit de applicatiebronmap deploy je de Fabric App in de herstelwerkruimte met behulp van Rayfin CLI. Voer rayfin up --workspace <new workspace>uit. 

5. Herstel het kinditem van de app (SQL-database in Fabric) door de respectievelijke herstelprocedures te volgen.  

6. Pas itemniveau-instellingen opnieuw toe, inclusief rollen en toegangscontroles indien nodig.  

7. Valideer de functionaliteit van de applicatie en zorg dat gebruikers de juiste rechten hebben.  

Belangrijk 

• Onderhoud de broncode van de Fabric App buiten de Fabric-regio om herstel mogelijk te maken.  

• Applicatiegegevens in de database worden niet teruggehaald als onderdeel van het Fabric App-implementatieproces en moeten apart worden hersteld.  Je kunt een Fabric App handmatig herstellen na een regionale ramp door gebruik te maken van de broncode van de applicatie en de Rayfin CLI. 

Azure Databricks Storage

Azure Databricks Storage slaat data op in OneLake. Om uw gegevens te beschermen tegen een regionale storing, schakelt u de disaster recovery-instelling in op de Fabric-capaciteit die het Azure Databricks Storage item bevat. Wanneer je deze instelling inschakelt, repliceert OneLake de data asynchroon naar de Azure-gekoppelde regio.

Als OneLake een regionale failover initieert, kunnen applicaties de gerepliceerde data blijven benaderen via het wereldwijde OneLake-eindpunt nadat de failover is voltooid. Voortdurende toegang via de OneLake publieke API's vereist niet het aanmaken van een ander Azure Databricks Storage item of het kopiëren van de data naar een andere werkruimte.

Bekijk OneLake Disaster Recovery and Data Protection voor informatie over het toepasselijke gedrag, de overwegingen en beperkingen.

Voor Azure Databricks-specifieke disaster recovery-planning, zie Disaster recovery - Azure Databricks.

Gegevenswetenschap

Deze handleiding leidt u door de herstelprocedés voor de Data Science-ervaring. Hierin worden ML-modellen en -experimenten behandeld.

ML-model en experiment

Data Science-items uit de primaire regio blijven onbeschikbaar voor klanten, en de inhoud en metadata in ML-modellen en experimenten repliceren niet naar de secundaire regio. Als u ze volledig wilt herstellen in de nieuwe regio, slaat u de code-inhoud op in een versiebeheersysteem (zoals Git) en voert u de code-inhoud handmatig opnieuw uit na het noodgeval.

1. Herstel het notitieblok. Raadpleeg de stappen voor notebookherstel.

2. Configuratie, historisch uitgevoerde metrics en metadata repliceren niet naar de gekoppelde regio. Je moet elke versie van je data science-code opnieuw uitvoeren om ML-modellen en experimenten volledig te herstellen na de ramp.

Gegevensmagazijn

Deze gids leidt je door de herstelprocedures voor de Fabric Data Warehouse werklast. Het dekt magazijnartikelen.

Magazijn

Je kunt geen magazijnen bereiken vanuit de oorspronkelijke regio. Gebruik de volgende twee stappen om magazijnen te herstellen.

1. Maak een nieuw tussentijds lakehouse aan in werkruimte C2. W2 voor de data die je kopieert van het originele warehouse.

2. Vul de Delta-tabellen van het warehouse in met behulp van de warehouse Explorer en de T-SQL-mogelijkheden (zie Tabellen in Fabric Data Warehouse).

Gegevensopname via Lakehouse en T-SQL-code

In nieuw gemaakte werkruimte C2. W2:

1. Maak een interim lakehouse "LH2" in C2. W2.

2. Herstel de Delta-tabellen in het interim lakehouse vanuit het oorspronkelijke magazijn door de Lakehouse-herstelstappen te volgen.

3. Maak een nieuw magazijn 'WH2' in C2. W2.

4. Verbind de interim lakehouse in uw warehouse explorer.

5. Afhankelijk van hoe je tabeldefinities implementeert vóór data-import, kan de daadwerkelijke T-SQL die voor imports wordt gebruikt variëren. Om Warehouse-tabellen uit lakehouses te halen, kun je de INSERT INTO, SELECT INTO, of CREATE TABLE AS SELECT methode gebruiken. In het volgende voorbeeld gebruiken we INSERT INTO. Als je de volgende code gebruikt, vervang dan voorbeelden door daadwerkelijke tabel- en kolomnamen.

   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. Verander de verbindingsreeks in applicaties die je Fabric-magazijn gebruiken.

Gespiegelde database

Klanten kunnen geen toegang krijgen tot gespiegelde databases vanuit de primaire regio, en de instellingen repliceren niet naar de secundaire regio. Om een gespiegelde database te herstellen na een regionale fout, moet je deze opnieuw aanmaken in een andere werkruimte uit een andere regio.

Data Factory

Klanten hebben vanuit de primaire regio geen toegang tot Data Factory-items en de instellingen en configuratie in pijplijnen of Dataflow Gen2-items worden niet gerepliceerd naar de secundaire regio. Om deze items na een regionale storing te herstellen, moet je je Data Integration-items opnieuw aanmaken in een andere werkruimte uit een andere regio. In de volgende secties worden de details beschreven.

Gegevensstromen Gen2

Om een Dataflow Gen2-item in de nieuwe regio te herstellen, exporteer je een .pqt bestand naar een versiebeheersysteem zoals Git en herstel je handmatig de Dataflow Gen2-inhoud na de ramp.

1. Vanuit je Dataflow Gen2-item, kies in het Home-tabblad van de Power Query-editor Template exporteren.

   

2. Voer in het dialoog Exporttemplate een naam in (verplicht) en beschrijving (optioneel) voor deze template. Selecteer OK als u klaar bent.

   

3. Maak na het noodgeval een nieuw Dataflow Gen2-item in de nieuwe werkruimte C2. W2".

4. Selecteer in het huidige weergavevenster van de Power Query-editor Import uit een Power Query-sjabloon.

   

5. In het openen-venster blader je naar je standaard downloadmap en selecteer je het .pqt bestand dat je in de vorige stappen hebt opgeslagen. Selecteer vervolgens Openen.

6. De sjabloon wordt vervolgens geïmporteerd in uw nieuwe Dataflow Gen2-item.

De Save As-functie voor Dataflows wordt niet ondersteund in geval van disaster recovery.

Pipelines

Klanten hebben geen toegang tot pijplijnen in het geval van regionale noodgevallen en de configuraties worden niet gerepliceerd naar de gekoppelde regio. Bouw je kritieke pijplijnen in meerdere werkruimtes in verschillende regio's.

Taak kopiëren

CopyJob-gebruikers moeten proactieve maatregelen nemen om te beschermen tegen een regionale ramp. De volgende aanpak zorgt ervoor dat na een regionale ramp de CopyJobs van een gebruiker beschikbaar blijven.

Door de gebruiker beheerde redundantie met Git-integratie (in openbare preview)

De beste manier om dit proces eenvoudig en snel te maken is door gebruik te maken van Fabric Git-integratie, waarna je CopyJob synchroniseert met je Azure DevOps-repo. Nadat de service een failover naar een andere regio heeft uitgevoerd, kunt u de opslagplaats gebruiken om de CopyJob opnieuw te bouwen in de nieuwe werkruimte die u hebt gemaakt.

1. Configureer de Git-integratie van je werkruimte en selecteer connect and sync with Azure DevOps repo.

   

   In de volgende afbeelding ziet u de gesynchroniseerde CopyJob.

   

2. Herstel de CopyJob uit de Azure DevOps-repository.

   1. Maak in de nieuw aangemaakte werkruimte verbinding en synchroniseer opnieuw met je Azure DevOps-repo. Alle Fabric-items in deze repository worden automatisch gedownload naar je nieuwe werkruimte.

      

   2. Als de oorspronkelijke CopyJob gebruikmaakt van een Lakehouse, kunnen gebruikers verwijzen naar de sectie Lakehouse om het Lakehouse te herstellen en vervolgens de zojuist herstelde CopyJob te verbinden met het zojuist herstelde Lakehouse.

Zie Inleiding tot Git-integratie voor meer informatie over Git-integratie.

Apache Airflow-taak

U moet proactieve maatregelen nemen om Apache Airflow-banen in Fabric te beschermen tegen een regionale ramp.

Beheer redundantie door gebruik te maken van Fabric Git-integratie. Synchroniseer eerst je Airflow-taak met je ADO repo. Als de service overgaat naar een andere regio, kun je de repository gebruiken om de Airflow-taak opnieuw op te bouwen in de nieuwe werkruimte die je hebt aangemaakt.

Volg deze stappen om dit doel te bereiken:

1. Configureer de Git-integratie van je werkruimte en selecteer Connect en synchroniseer met de ADO repo.

2. Daarna zie je je Airflow-taak gesynchroniseerd met je ADO repo.

3. Als u de Airflow-taak wilt herstellen vanuit de ADO-opslagplaats, maakt u een nieuwe werkruimte, maakt u verbinding en synchroniseert u deze opnieuw met uw Azure ADO-opslagplaats. Alle Fabric-items, inclusief Airflow, in deze repository worden automatisch gedownload naar je nieuwe werkruimte.

Realtime intelligentie

In deze handleiding wordt u begeleid bij de herstelprocedures voor de realtime intelligence-ervaring. Het behandelt KQL-databases, querysets en eventstream-items.

Activator

Activator-items uit de primaire regio blijven niet beschikbaar voor klanten en Activator-triggerdefinities worden niet gerepliceerd naar de secundaire regio. Activator-gebruikers moeten proactieve stappen ondernemen om zich voor te bereiden op regionaal herstel na noodgevallen.

Om ervoor te zorgen dat u Activator-items kunt herstellen in het geval van een regionaal noodgeval, stelt u Fabric Git-integratie in om een back-up te maken van triggerdefinities en deze te herstellen in een werkruimte in een andere regio.

1. Configureer Fabric Git-integratie voor de werkruimte die uw Activator-item bevat en synchroniseer uw triggerdefinities met uw Git-opslagplaats.
2. Zorg dat uw Activator-triggerdefinities regelmatig gecommit en gesynchroniseerd worden.
3. Maak tijdens het herstel een nieuwe werkruimte in de doelregio (C2). W2), verbind deze met dezelfde opslagplaats en synchroniseer om de triggerdefinities te herstellen.
4. Configureer en valideer alle Activator-gegevensbronnen en -afhankelijkheden in de nieuwe werkruimte.

Zie Inleiding tot Git-integratie voor meer informatie over Git-integratie.

Grafenmodel/queryset

Klanten kunnen geen toegang krijgen tot Graph model- en Graph queryset-items vanuit de primaire regio, en Fabric repliceert deze items niet naar de secundaire regio. Om te herstellen, maak of gebruik een capaciteit in een andere regio en maak daar het Graph model en de Graph queryset-items opnieuw aan.

1. Maak of gebruik een bestaande Fabric capaciteit in een andere regio die niet wordt beïnvloed door het noodgeval.

2. Maak een nieuwe werkruimte of gebruik een bestaande werkruimte in die capaciteit.

3. Maak het Graph model-item opnieuw aan in de secundaire werkruimte (genoemd in stap 2). Herconfigureer de modeldefinitie, inclusief knooppunten, randen en andere, zodat deze overeenkomt met het oorspronkelijke Graph-model.

4. Als het originele lakehouse zich in de falende regio bevindt, herstelt u het eerst door de instructies in de sectie Lakehouse op te volgen.

5. Verbind een lakehouse als de OneLake-gegevensbron voor het nieuw gemaakte Graph-modelitem. Gebruik het herstelde lakehouse als deze zich in de mislukte regio bevond of maak opnieuw verbinding met het bestaande lakehouse als deze beschikbaar blijft.

6. Herconfigureer alle datalaadschema's of verbindingen voor het Graph-model in de nieuwe werkruimte.

7. Maak het Graph-queryset-item opnieuw aan in de secundaire werkruimte. Voer handmatig de queries en opgeslagen queryconfiguraties opnieuw in vanuit de originele Graph-queryset.

KQL-database/queryset

Gebruikers van KQL-databases en querysets moeten proactieve stappen ondernemen om zich te beschermen tegen een regionale ramp. De volgende aanpak zorgt ervoor dat in het geval van een regionale ramp de gegevens in uw KQL-databases en querysets veilig en toegankelijk blijven.

Gebruik de volgende stappen om een effectieve oplossing voor herstel na noodgevallen te garanderen voor KQL-databases en querysets.

1. Stel onafhankelijke KQL-databases op: Configureer twee of meer onafhankelijke KQL-databases en querysets op speciale Fabric-capaciteiten. Zet deze databases op over twee verschillende Azure-regio's (bij voorkeur Azure-gekoppelde regio's) om de veerkracht te maximaliseren.

2. Repliceer beheeractiviteiten: Spiegel elke beheeractie die je uitvoert in de ene KQL-database in de andere. Deze aanpak houdt beide databases synchroon. Belangrijke activiteiten om te repliceren zijn:

   • Tabellen: Zorg ervoor dat de tabelstructuren en schemadefinities consistent zijn over de databases.

   • Toewijzing: eventuele vereiste toewijzingen dupliceren. Zorg ervoor dat databronnen en bestemmingen correct op elkaar afstemmen.

   • Beleid: Zorg ervoor dat beide databases vergelijkbare gegevensbehoud, toegang en andere relevante beleidsregels hebben.

3. Beheer authenticatie en autorisatie: Stel de vereiste rechten in voor elke replica. Zorg ervoor dat je de juiste autorisatieniveaus vastlegt, toegang verleent aan het benodigde personeel terwijl je de veiligheidsnormen handhaaft.

4. Parallelle gegevensopname: als u de gegevens consistent en gereed wilt houden in meerdere regio's, laadt u dezelfde gegevensset in elke KQL-database op hetzelfde moment als u deze opneemt.

Gebeurtenisstroom

Een eventstream is een gecentraliseerde plaats in het Fabric-platform voor het vastleggen, transformeren en routeren van realtime gebeurtenissen naar verschillende bestemmingen (bijvoorbeeld lakehouses, KQL-databases/querysets) met een ervaring zonder code. Zolang de bestemmingen disaster recovery ondersteunen, verliezen eventstreams geen data. Gebruik daarom de rampenherstelmogelijkheden van die bestemmingssystemen om de beschikbaarheid van data te garanderen.

Je kunt ook geo-redundantie bereiken door identieke eventstream-workloads in meerdere Azure-regio's te implementeren als onderdeel van een multi-site actief/actieve strategie. Met een multi-site active/active-aanpak kun je in elk van de geïmplementeerde regio's toegang krijgen tot je workload. Deze benadering is de meest complexe en kostbare benadering van herstel na noodgevallen, maar kan de hersteltijd in de meeste situaties verminderen tot bijna nul. Om volledig geo-redundant te zijn:

1. Maak replica's van je databronnen in verschillende regio's.

2. Maak eventstream-items aan in de bijbehorende regio's.

3. Verbind deze nieuwe items met de identieke gegevensbronnen.

4. Voeg identieke bestemmingen toe voor elke eventstream in verschillende regio's.

Zakelijke gebeurtenissen, Fabric-gebeurtenissen en Azure-gebeurtenissen

Hoewel Business Events, Fabric Events en Azure Events dezelfde Real-Time hubinfrastructuur in Microsoft Fabric delen, hebben ze verschillende oorsprongen, gedragingen en herstelbehoeften. Begrijp deze verschillen voordat je een plan maakt voor rampenherstel:

• Fabric Events zijn evenementabonnementen die reageren op activiteiten die door Fabric-bronnen zelf worden geproduceerd. Deze gebeurtenissen omvatten wijzigingen in de levenscyclus van werkruimteitems (zoals het aanmaken, updaten of verwijderen van lakehouses, notitieboeken of magazijnen), taken uitvoeren (zoals pipeline-runs of notebook-uitvoeringen), en OneLake-bestands- en mapoperaties. Deze abonnementen zijn push-based en kortstondig. De abonnementen worden niet gerepliceerd naar de secundaire regio.

• Azure gebeurtenissen zijn gebeurtenisabonnementen op activiteiten die worden geproduceerd door Azure Blob Storage accounts. Deze Azure resources bestaan onafhankelijk van elke Fabric capaciteit of regio. Hoewel de Azure Blob Storage resource zelf beschikbaar kan blijven tijdens een Fabric regionale storing, worden de abonnementen die in Real-Time hub zijn geconfigureerd niet gerepliceerd naar de secundaire regio en moeten ze opnieuw worden aangemaakt.

• Zakelijke gebeurtenissen zijn een unieke mogelijkheid in Fabric Real-Time Intelligence waarmee teams zinvolle signalen kunnen definiëren, publiceren en erop kunnen reageren. Zakelijke gebeurtenissen worden gegenereerd vanuit Fabric via Activator, Spark-notebooks of User Data Functions, en vervolgens gepubliceerd naar Real-Time hub waar downstreamgebruikers, zoals Activator, Eventhouse of Power Automate hierop kunnen reageren. Gebeurtenisschema's worden centraal beheerd via het schemaregister. Eventhouse slaat elke gepubliceerde zakelijke gebeurtenis automatisch op, zodat het herstel rechtstreeks van invloed is op de beschikbaarheid van de geschiedenis van zakelijke gebeurtenissen. Geen van de uitgevers- of consumentenconfiguraties, schemadefinities of abonnementen worden gerepliceerd naar de secundaire regio.

Gebruik de volgende stappen om Business Events, Fabric Events en Azure Events in de nieuwe werkruimte in de herstelregio te herstellen.

Voor zakelijke gebeurtenissen:

1. Maak de zakelijke gebeurtenis die wordt gebruikt door uitgevers en consumenten opnieuw door het artikel Zakelijke gebeurtenissen maken in Fabric Real-Time Hub te volgen. Tijdens het aanmaken van de businessgebeurtenis maakt u de resource Event Schema Set. De Eventhouse-resource is optioneel, afhankelijk van het scenario. Als je je event schema set hebt geback-upt met Git-integratie, herstel het dan eerst door het Event schema set-gedeelte te volgen en wijs daarna het business event naar het herstelde schema set.

2. Maak alle publisher-items die business events genereren, zoals Spark-notebooks of gebruikersgegevensfuncties, opnieuw aan in de nieuwe werkruimte door de volgende publisher-artikelen te volgen: Gebruikersgegevensfunctie als Business Events-publisher gebruiken, Activator als Business Events-publisher gebruiken, Notebook als Business Events-publisher gebruiken en Eventstream als Business Events-publisher gebruiken.

3. Maak de consumentenabonnementen opnieuw in Real-Time hub (bijvoorbeeld Activator-regels, notebooktriggers of Power Automate stromen) die oorspronkelijk reageerden op zakelijke gebeurtenissen in de betrokken regio door de artikelen Eventhouse en Real-Time Dashboard Integration with Business Events andConsume Business Events from Activator te volgen.

4. Controleer of gebeurtenissen van begin tot eind worden doorgegeven door na te gaan of subscriptions actief zijn en of gegevens aankomen op de verwachte bestemmingen in de herstelregio.

Voor Fabric gebeurtenissen:

1. Maak de abonnementen in Real-Time hub opnieuw aan die verwijzen naar de werkruimte-items, jobs of OneLake-paden die je in de herstelregio hebt teruggezet, en volg daarbij het artikel Explore Fabric events in Fabric Real-Time hub.

2. Controleer of gebeurtenissen van begin tot eind worden doorgegeven door na te gaan of subscriptions actief zijn en of gegevens aankomen op de verwachte bestemmingen in de herstelregio.

Voor Azure gebeurtenissen:

1. Azure Blob Storage-accounts worden niet beïnvloed door een regionale storing van Fabric. Maak de gebeurtenisabonnementen in Real-Time hub die naar dezelfde Azure Blob Storage-accounts verwijzen opnieuw door het artikel Waarschuwingen instellen voor Azure Blob Storage-gebeurtenissen in Real-Time hub te volgen.

2. Controleer of gebeurtenissen van begin tot eind worden doorgegeven door na te gaan of subscriptions actief zijn en of gegevens aankomen op de verwachte bestemmingen in de herstelregio.

Gebeurtenisschemaset

Een event schema set is het Fabric item dat event type en schema definities bevat in Real-Time Intelligence. Andere mogelijkheden bouwen hierop: uitgevers schrijven gebeurtenissen die voldoen aan hun schema's, en consumenten lezen volgens dezelfde definities.

Gebeurtenisschema-sets uit de primaire regio blijven niet beschikbaar voor klanten en worden niet gerepliceerd naar de secundaire regio. Omdat een set met gebeurtenisschema’s echter een duurzame, opgestelde definitie is en geen tijdelijk abonnement, kun je er vooraf een back-up van maken en deze terugzetten in plaats van deze handmatig opnieuw op te stellen.

Aanbevolen: back-up maken met Fabric Git-integratie

Om een event schema dat na een regionale ramp is ingesteld te herstellen, zet je Fabric Git-integratie op voordat er een ramp plaatsvindt, en synchroniseer je de werkruimte met je event schema-sets met je Git-repository.

1. Configureer Fabric Git-integratie voor de werkruimte die je event schema set bevat, en synchroniseer deze met je Git-repository.

2. Houd de event schema-set regelmatig gecommitteerd en gesynchroniseerd, vooral na het toevoegen van eventtypes of het publiceren van nieuwe schemaversies.

3. Tijdens het herstel maak je een nieuwe werkruimte aan in het doelgebied (C2. W2), verbind het met dezelfde repository en synchroniseer om de event schema set te herstellen. Omdat de nieuwe werkruimte leeg is, brengt Git sync de inhoud van de repository naar de werkruimte.

4. Maak alle uitgevers en consumenten die de schemaset gebruiken opnieuw aan, volgens de richtlijnen voor die itemtypes.

5. Valideer dat uitgevers kunnen publiceren tegen de herstelde gebeurtenistypes en dat consumenten gebeurtenissen ontvangen zoals verwacht.

De gesynchroniseerde definitie omvat de gebeurtenistypes in de schemaset, de schema's en de schemaversies. Het bevat geen uitgeversregistraties, consumentenabonnementen of evenementengeschiedenis. Herstel deze apart, volgens de richtlijnen voor de itemtypes die de schemaset gebruiken.

Alternatief: handmatig opnieuw aanmaken

Als je de Git-integratie vóór de ramp niet hebt geconfigureerd, maak dan de event schema set in de recovery region opnieuw aan door te volgen Create and manage event schema sets, en voeg dan de event types en schema's toe die de originele schemaset bevatte door te volgen Create and manage event schemas in schema sets.

Map

Kaartitems uit de primaire regio blijven onbeschikbaar voor klanten en de kaartitems worden niet naar de secundaire regio gerepliceerd.

Als u een kaartitem wilt herstellen wanneer er een noodgeval optreedt, stelt u Fabric Git-integratie in en synchroniseren uw kaartitem met uw Git-opslagplaats.

Tijdens het herstel, nadat de nieuwe regio/capaciteit in Fabric is ingesteld, kunt u de repository gebruiken om het Map-item opnieuw te bouwen in de nieuwe werkruimte die u hebt gemaakt. Omdat de nieuwe werkruimte leeg is, haalt Git sync de inhoud van de opslagplaats op in de lege werkruimte. Met deze stap wordt het kaartitem weer tot leven geschoven.

Ontologie

Ontology-gebruikers moeten proactieve stappen ondernemen om zich voor te bereiden op regionaal herstel na noodgevallen. De hieronder beschreven aanpak zorgt ervoor dat, na een regionale ramp, uw Ontology herstelbaar blijft en snel kan worden hersteld.

De eenvoudigste en snelste manier om herstel mogelijk te maken, is door Fabric Git-integratie te gebruiken en uw Ontology te synchroniseren met een Azure DevOps (ADO)-opslagplaats. Als de service een failover naar een andere regio uitvoert, kunt u deze opslagplaats gebruiken om de Ontology opnieuw te bouwen in een zojuist gemaakte werkruimte.

Ontologie-items in de primaire regio zijn niet beschikbaar voor klanten na een regionale ramp en Ontology-items worden niet gerepliceerd naar de secundaire regio.

Als u een Ontology-item tijdens een noodgeval wilt herstellen, configureert u Fabric Git-integratie en synchronize het Ontology-item met uw ADO-opslagplaats vooraf.

Wanneer de nieuwe regio en capaciteit in Fabric zijn ingesteld, kunt u tijdens het herstel de opslagplaats gebruiken om het Ontology-item opnieuw te bouwen in een nieuwe werkruimte. Omdat de nieuwe werkruimte leeg is, haalt Git sync de inhoud van de opslagplaats naar de werkruimte op, zodat het Ontology-item effectief wordt hersteld.

Ontologie-agent

Gebruikers van Ontology Agent moeten proactieve stappen ondernemen om zich voor te bereiden op regionaal rampenherstel. De in deze sectie beschreven aanpak zorgt ervoor dat na een regionale ramp uw Ontology Agent-ervaring kan worden hersteld in een nieuw aangemaakte werkruimte.

Ontology Agent is afhankelijk van het Ontologie-item en van alle databronnen die verbonden zijn met de Ontologie, zoals lakehouses. Klanten kunnen na een regionale ramp geen toegang krijgen tot Ontology Agent-sessies in de primaire regio, en Ontology Agent-sessies worden niet gerepliceerd naar de secundaire regio. Actieve chatsessies, lopende acties en gespreksgeschiedenis van de getroffen regio kunnen niet worden hervat.

Om de Ontology Agent-ervaring tijdens een ramp te herstellen, configureer je van tevoren Fabric Git-integratie en synchroniseer je het Ontology-item met je Azure DevOps (ADO)-repository.

Tijdens het herstel, zodra de nieuwe regio en capaciteit in Fabric zijn ingesteld, voltooi je de volgende stappen:

1. Creëer een nieuwe werkruimte in de nieuwe capaciteit.
2. Verbind de nieuwe werkruimte met dezelfde ADO-repository die het Ontology-item bevat.
3. Gebruik Git sync om het Ontology-item terug te brengen in de nieuwe werkruimte.
4. Herstel afhankelijke data-items, zoals lakehouses, door de richtlijnen voor die itemtypes te volgen.
5. Bevestig dat de teruggewonnen gegevens beschikbaar zijn in de gekoppelde regio. Voor OneLake-ondersteunde data ga je ervan uit dat de data wordt gerepliceerd naar de gekoppelde regio, maar ga niet uit van de volgorde van de gerepliceerde data tijdens het herstel.
6. Verbind het nieuw herstelde Ontology-item met de herstelde databronnen.
7. Start een nieuwe Ontology Agent-sessie en verifieer dat de agent verbinding kan maken met het herstelde Ontology-item en databronnen.

Planning

Dit artikel beschrijft de herstelprocedures voor de planningsfunctionaliteit in IQ. Het beschrijft de stappen die nodig zijn om belangrijke componenten te herstellen, waaronder planningsbladen, PowerTable-bladen, intelligentiebladen, InfoBridge en gerelateerde data-assets.

Git-integratie voor het herstellen van planitems

De voorkeursmethode is om alle planitems te synchroniseren met een Azure DevOps (ADO) of GitHub opslagplaats met behulp van Fabric Git-integratie. Na een failover gebruikt u de opslagplaats om de items in de nieuwe werkruimte te herstellen.

Vóór een ramp (proactieve stappen):

1. Ga in werkruimte W1 naar Werkruimte-instellingen en configureer Git-integratie.

2. Selecteer Verbinding maken en synchroniseren met uw ADO of GitHub opslagplaats.

3. Selecteer de planitems die u wilt uploaden naar de opslagplaats en selecteer Doorvoeren.

   

4. Controleer of de Git-status van planitems is gesynchroniseerd.

5. Hanteer een commitdiscipline: commit na elke belangrijke wijziging aan de plandefinitie, zodat de repository altijd de meest recente status weerspiegelt.

Herstelstappen:

1. Maak een nieuwe werkruimte W2 binnen capaciteit C2 in de gezonde regio.

2. Ga in werkruimte W2 naar Werkruimte-instellingen en maak opnieuw verbinding met dezelfde ADO/GitHub opslagplaats.

3. Selecteer Broncodebeheer. Selecteer de relevante opslagplaatsbranch en selecteer Alles bijwerken. Alle items van het plan worden naar W2 gedownload.

De volgende onderdelen worden hersteld na herstel:

• PowerTable-bladen: Brontabelinstellingen, kolomconfiguratie, rijtoegang, visuele eigenschappen (indeling, opmaak en meer), rijidentificatie, opmerkingeninstellingen, langzaam veranderende dimensies (SCD), goedkeuringen, automatiseringen en formulieren.
• Planningsbladen: Bladeigenschappen (opmaak, voorwaardelijke opmaak en meer), opmerkingeninstellingen, instellingen voor terugschrijven, kolommen voor gegevensinvoer, gegevensinvoerrijen, scenario's en bladwijzers.
• InfoBridge: InfoBridge-bronnen, InfoBridge-query's, transformatiestappen, writeback-bestemmingen, writeback-instellingen, gekoppelde querytoewijzingen, querygroepen, visuele eigenschappen (blend). Deze items kunnen niet worden hersteld: op bestanden gebaseerde bronnen (CSV, Excel), werkbladen voor meerdere werkbelastingen die gebruikmaken van bronnen op basis van bestanden.
• Intelligentie: Alle grafieken en matrices.

Fabric SQL-herstel voor planningsdoeleinden

Gegevens die worden ingevoerd in planningsbladen, tabellen die worden gebruikt in PowerTable en write-backgegevens, worden opgeslagen in SQL-databases en moeten worden beschouwd als onderdeel van uw strategie voor herstel na noodgevallen. Om SQL-databases te herstellen, zie de sectie SQL-database.

• Metagegevens van herstelplan: elk planitem is gekoppeld aan een __fabric_plan_sys-database waarin metagegevens worden opgeslagen voor planningsfuncties, waaronder opmerkingen, scenario's, gegevensinvoer en configuratie voor terugschrijven. De __fabric_plan_sys-database wordt niet automatisch hersteld en moet expliciet worden hersteld.

• Write-backdatabases herstellen: als uw plan GEBRUIKMAAKT van SQL-terugschrijfbestemmingen, moet u ook de bijbehorende databases handmatig herstellen. Geconfigureerde SQL-terugschrijfbestemmingen worden niet automatisch hersteld.

• Herstel tabellen die in PowerTable worden gebruikt: Alle tabellen die met PowerTable worden gemaakt, worden opgeslagen in een SQL-database in Fabric. U moet ook deze tabellen herstellen tijdens disaster recovery.

Operationsagenten

Gebruikers van operations-agents moeten proactieve stappen nemen om zich voor te bereiden op regionaal herstel na noodgevallen. Door de in deze sectie beschreven aanpak te volgen, kunt u ervoor zorgen dat uw agents snel kunnen worden hersteld na een regionale storing.

Gebruik Fabric Git-integratie om uw werkruimte te synchroniseren met een opslagplaats. Met deze methode kunt u agentconfiguraties in een nieuwe werkruimte reconstrueren als de service een failover naar een andere regio uitvoert.

Items van de Operations-agent in de primaire regio zijn niet beschikbaar tijdens een regionale ramp. Agentconfiguraties, gedragsmodellen en activiteitenlogboeken worden niet gerepliceerd naar de secundaire regio. Lopende bewerkingen, actieve chatsessies en eerder geïngeste gebeurtenissen op het moment van de ramp gaan ook verloren.

Als u zich wilt voorbereiden op herstel, configureert u Fabric Git-integratie en synchroniseert u uw agentitems met uw ADO-opslagplaats voordat er zich een noodgeval voordoet.

Wanneer u herstelt, stelt u uw nieuwe regio en capaciteit in Fabric in en gebruikt u vervolgens de gesynchroniseerde opslagplaats om agentconfiguraties te herstellen in een nieuwe werkruimte. Git-synchronisatie haalt de opgeslagen inhoud uit de repository op en zet die in de lege werkruimte, waarmee uw agentitems opnieuw worden aangemaakt.

Zodra de configuraties zijn hersteld, controleert u of eventuele KQL-databases (Eventhouse) of regiospecifieke gegevensbronnen toegankelijk zijn in de nieuwe regio. Werk indien nodig eindpuntverwijzingen bij in agentconfiguraties. Start ten slotte uw agents opnieuw op en laat gebruikers nieuwe chatsessies initiëren. Eerdere gesprekken kunnen niet worden hervat.

Databases

Deze gids beschrijft de herstelprocedures voor de ervaring van de database.

SQL database

Ter bescherming tegen regionale fouten kunnen gebruikers van SQL-databases proactieve maatregelen nemen om hun gegevens periodiek te exporteren en de geëxporteerde gegevens te gebruiken om de database in een nieuwe werkruimte opnieuw te maken wanneer dat nodig is.

Gebruik de SqlPackage CLI-tool die databaseportabiliteit biedt en database-implementaties faciliteert.

1. Gebruik het hulpprogramma SqlPackage om de database te exporteren naar een .bacpac bestand. Zie Een database exporteren met SqlPackage voor meer informatie.
2. Sla het .bacpac bestand op een veilige locatie die zich in een andere regio bevindt dan de database. Voorbeelden zijn het opslaan van het .bacpac bestand in een Lakehouse in een andere regio, het gebruik van een geo-redundant Azure Storage-account, of het gebruik van een ander beveiligd opslagmedium dat zich in een andere regio bevindt.
3. Als de SQL-database en -regio niet beschikbaar zijn, kunt u het .bacpac bestand met SqlPackage gebruiken om de database opnieuw te maken in een werkruimte in een nieuwe regio: Werkruimte C2. W2 in regio B, zoals beschreven in het bovenstaande scenario. Volg de stappen in Een database importeren met SqlPackage om de database opnieuw te maken met uw .bacpac bestand.

De opnieuw gemaakte database is een onafhankelijke database van de oorspronkelijke database en weerspiegelt de status van de gegevens op het moment van de exportbewerking.

Overwegingen voor failback

De opnieuw gemaakte database is een onafhankelijke database. Gegevens die aan de gerecreëerde database worden toegevoegd, worden niet weergegeven in de originele database. Als je van plan bent om terug te schakelen naar de originele database zodra de thuisregio beschikbaar is, moet je overwegen om gegevens handmatig van de gereproduceerde database te vergelijken met de oorspronkelijke database.

Platform

Platform verwijst naar de onderliggende gedeelde services en architectuur die van toepassing zijn op alle workloads. Deze sectie beschrijft herstelprocedures voor gedeelde Fabric-mogelijkheden.

Werkruimtebewaking

Workspace monitoring verzamelt logs over activiteit in de workspace waar je het inschakelt. Nadat je je werkruimte hebt hersteld als C2.W2, schakel je werkruimtemonitoring in op W2. Het begint monitoringgegevens te verzamelen voor de herstelde werkruimte.

Monitoringgegevens van de oorspronkelijke werkruimte (C1.W1) worden niet meegenomen, omdat monitoring de activiteit weerspiegelt van de werkruimte waarop deze wordt uitgevoerd.

Variabele bibliotheek

Microsoft Fabric Variabelenbibliotheken stellen ontwikkelaars in staat om itemconfiguraties binnen een werkruimte aan te passen en te delen, waardoor het levenscyclusbeheer van inhoud wordt stroomlijnd. Vanuit het oogpunt van rampherstel moeten gebruikers van een bibliotheek met variabelen proactief maatregelen nemen tegen een regionaal noodgeval. Deze bescherming kan worden gedaan via Fabric Git-integratie, die ervoor zorgt dat na een regionale ramp de Variable-bibliotheek van een gebruiker beschikbaar blijft. Om een variabelenbibliotheek te herstellen, volgt u deze stappen:

• Gebruik Fabric Git-integratie om uw variabelebibliotheek te synchroniseren met uw ADO-opslagplaats. In geval van nood kunt u de opslagplaats gebruiken om de variabelebibliotheek opnieuw te bouwen in de nieuwe werkruimte die u hebt gemaakt. Gebruik de volgende stappen:

  1. Verbind uw werkruimte met een Git-opslagplaats, zoals hier wordt beschreven.
  2. Zorg ervoor dat de WS en de opslagplaats zijn gesynchroniseerd met Doorvoeren en bijwerken.
  3. Herstel : in geval van nood gebruikt u de opslagplaats om de variabelebibliotheek opnieuw te bouwen in een nieuwe werkruimte:

• Maak in de zojuist gemaakte werkruimte opnieuw verbinding met uw Azure ADO-opslagplaats en synchroniseer deze.

• Alle Fabric items in deze opslagplaats worden automatisch gedownload naar uw nieuwe werkruimte.

• Nadat u uw items vanuit Git hebt gesynchroniseerd, opent u uw variabelenbibliotheken in de nieuwe werkruimte en selecteert u handmatig de gewenste actieve waardeset.

Implementatieplan

Een inzetplan is een item in een Fabric-werkruimte. Het groepeert items en bepaalt de volgorde om ze te plaatsen. Het kan acties uitvoeren voor of na elke inzet van elk item. De itemdefinitie slaat deze instellingen, invoer en itemreferenties op. Het plan heeft geen aparte opslag voor waarden die tijdens runtime worden gebruikt.

Bereid je voor op herstel door gebruik te maken van Fabric Git-integratie:

1. Verbind de werkruimte met het plan aan een Azure DevOps- of GitHub-repository.
2. Leg het plan vast en alle werkruimteonderdelen die door het plan worden gebruikt.
3. Commit elke wijziging zodat Git de nieuwste definities heeft.

Na een regionale ramp:

1. Creëer een werkruimte in de gezonde regio.
2. Verbind de werkruimte met dezelfde repository en branch.
3. Werk de werkruimte bij vanuit Git. Deze stap herstelt het plan en de bijbehorende items.

Git herstelt de volledige definitie van het plan. Het herstelt geen data en voert geen status uit voor de gekoppelde items. Gebruik de secties in dit artikel om die items terug te halen.

Door de klant beheerde sleutels voor Fabric werkruimten

Je kunt klantbeheerde sleutels (CMK) gebruiken die zijn opgeslagen in Azure Key Vault om een extra laag encryptie toe te voegen bovenop Microsoft-beheerde sleutels voor data in rust. Als Fabric in een regio ontoegankelijk of onbruikbaar wordt, schakelen de onderdelen ervan over naar een back-upinstantie. Tijdens een failover ondersteunt de CMK-functie alleen-lezenbewerkingen. Zolang de Azure Key Vault-service gezond blijft en de rechten voor de vault intact zijn, blijft Fabric verbinding maken met je sleutel en kun je data normaal lezen. Dit betekent dat de volgende bewerkingen niet worden ondersteund tijdens failover: de CMK-instelling van de werkruimte in- en uitschakelen en de sleutel bijwerken.

Fabric Migration Assistant voor SQL-databases in Fabric

De Fabric Migration Assistant kan een SQL Server-database in drie stappen in Fabric naar een SQL-database verplaatsen: de migratiewizard maakt de doeldatabase aan en start de migratie, de migratiemonitor volgt de voortgang terwijl het schema wordt uitgezet vanuit een DACPAC, de Migration Assistant helpt je scriptfouten te beoordelen en te corrigeren, de database voor te bereiden, data te kopiëren met een kopieeropdracht en de kopie af te ronden.

De migratievoortgang wordt niet gerepliceerd naar een andere regio, en een onderbroken deployment kan niet worden hervat. Deze storingen hebben geen invloed op de bron-SQL Server-database, dus je kunt de migratieassistent opnieuw uitvoeren. Als de oorspronkelijke regio niet beschikbaar is, volg dan eerst het algemene herstelplan in dit artikel om capaciteit C2 en werkruimte W2 in de gekoppelde regio te creëren, en voer vervolgens de migratie uit in W2. Als de oorspronkelijke regio herstelt, kun je de migratie opnieuw proberen in de oorspronkelijke workspace.

Een regionale verstoring kan ervoor zorgen dat een migratie op drie manieren mislukt:

• De doel-database wordt niet aangemaakt

  Als Fabric de doeldatabase niet kan aanmaken, toont de migratiewizard een foutmelding en start de migratie niet. Selecteer Start migratie om het opnieuw te proberen, of probeer het later opnieuw.

  De wizard probeert een onvolledige database te verwijderen, maar opruimen kan mislukken tijdens een onderbreking. Controleer in de werkruimte of er een database met de beoogde naam bestaat voordat je het opnieuw probeert. Bevestig dat het de onvolledige database is van de mislukte poging voordat je hem verwijdert.

• De uitrol mislukt

  Als de implementatie wordt onderbroken, stopt de migratiemonitor met het rapporteren van voortgang, opent de doel-database en toont een dialoogvenster dat aangeeft dat de implementatie is mislukt. Je kunt een mislukte implementatie niet hervatten, en de database die door de poging is aangemaakt blijft in de werkruimte.

  Ga als volgende te werk om te herstellen:

  1. Bevestig dat Fabric beschikbaar is en dat je de DACPAC hebt gebruikt voor de oorspronkelijke migratie.
  2. Identificeer de database die is aangemaakt door de mislukte poging. Verwijder het als het niets bevat wat je moet bewaren. Anders kun je het behouden en een andere naam gebruiken voor de nieuwe database.
  3. Voer een nieuwe migratie uit vanuit de bron-DACPAC. De migratie creëert een nieuwe database.

  Data wordt gekopieerd door een kopieeropdracht in Data Factory. Als je de kopieeropdracht vóór de onderbreking met Git hebt gesynchroniseerd, zie dan Kopieeropdracht in de Data Factory-richtlijnen. Maak anders een nieuwe kopieertaak aan als onderdeel van de nieuwe migratie.

• Migratiegeschiedenis laadt niet

  Als de Migration Assistant de migratiegeschiedenis niet kan ophalen, meldt hij dat migratieinformatie niet langer beschikbaar is. De voortgang die in de huidige browser is opgeslagen blijft behouden en de doeldatabase wordt niet beïnvloed. Ververs de pagina om de migratiegeschiedenis opnieuw te laden.

OneLake

In deze sectie wordt u begeleid bij de herstelprocedures voor OneLake-functies. Zie OneLake-herstel na noodgevallen voor OneLake-gegevens voor meer informatie over herstel na noodgevallen.

Beleid voor levenscyclusbeheer

Als Fabric ontoegankelijk of onbruikbaar wordt in een regio, kun je je OneLake-levenscyclusbeleid nog steeds lezen en bijwerken tijdens failover. Alle data die naar de koele of koude laag wordt verplaatst, blijft in die categorie. Om uw bestaande beleid toe te passen op uw nieuwe herstelwerkruimte, volgt u deze stappen:

1. Roep Exportbeleid aan in uw oorspronkelijke werkruimte en sla het volledige levenscyclusbeleid op.
2. Roep Import Policy aan op uw herstelde werkruimte, waarbij u het geëxporteerde levenscyclusbeleid als aanvraagtekst gebruikt.

Regels voor resource-exemplaren

Met resource-exemplaarregels kunt u de toegang tot gegevens in OneLake veilig beheren met behulp van vertrouwde Azure resource-identiteiten. Tijdens regionale failover blijft het systeem bestaande regels voor leestoegang afdwingen. U kunt echter geen regels voor het resource-exemplaar maken, bijwerken of verwijderen totdat de werkruimte terugkeert naar een beschrijfbare status.

Gerelateerde informatie

• Microsoft Fabric handleiding voor herstel na noodgevallen