Käyttökokemukseen liittyvät järjestelmäpalautuksen ohjeet

Tämä asiakirja tarjoaa kokemuskohtaisia ohjeita Fabric-datan palauttamiseen alueellisen katastrofin sattuessa.

Näyteskenaario

Monissa tämän asiakirjan ohjeosioissa käytetään seuraavaa esimerkkiskenaariota selityksenä ja havainnollistamisena. Palaa tähän skenaarioon tarpeen mukaan.

Oletetaan, että sinulla on kapasiteetti C1 alueella A, jossa on työtila W1. Jos olet kytkenyt katastrofipalautuksen käyttöön C1-kapasiteetilla, OneLake-data replikoidaan varmuuskopioon alueella B. Jos alue A kohtaa häiriöitä, Fabric-palvelu C1:ssä siirtyy alueelle B.

Muistiinpano

Tämä palautusohje koskee vain, kun pääalueella on Azure-paritettu toissijainen alue ja Fabric on tuettu paritetun alueen sisällä.

Seuraava kuva havainnollistaa tätä skenaariota. Vasemmalla oleva laatikko näyttää häiriintyneen alueen. Keskellä oleva ruutu edustaa tietojen jatkuvaa käytettävyyttä vikasietoisuuden jälkeen ja oikealla olevassa ruudussa näkyy täysin käsitelty tilanne sen jälkeen, kun asiakas on palauttanut palvelunsa täyteen toimintaan.

Tässä on yleinen palautussuunnitelma:

1. Luo uusi Fabric-kapasiteetti C2 uudella alueella.

2. Luo uusi W2-työtila C2:ssa, mukaan lukien sitä vastaavat kohteet, joilla on samat nimet kuin C1:llä. W1.

3. Kopioi tiedot häirinnästä C1:stä. W1–C2. W2.

4. Palauta kohteet täyteen toimintoonsa noudattamalla kunkin komponentin erillisiä ohjeita.

Tämä elvytyssuunnitelma olettaa, että vuokralaisen kotialue pysyy toiminnassa. Jos vuokralaisen kotialueella esiintyy katko, tässä asiakirjassa kuvatut vaiheet riippuvat sen palauttamisesta, joka on ensin aloitettava ja suoritettava Microsoft:n toimesta.

Käyttökokemuskohtaiset palautussuunnitelmat

Seuraavat osiot tarjoavat vaiheittaiset oppaat jokaiselle Fabric-kokemukselle, jotka auttavat asiakkaita toipumisprosessin läpi.

Tietotekniikka

Tässä oppaassa käydään läpi tietotekniikkakokemuksen palautusmenettelyt. Se kattaa järvenrakennukset, muistikirjat, Spark-tehtävämäärittelyt, käyttäjätietotoiminnot ja GraphQL-rajapinnat.

Lakehouse

Lakehouset alkuperäiseltä alueelta eivät ole saatavilla asiakkaille. Lakehousen palauttamiseksi asiakkaat voivat luoda sen uudelleen työtilassa C2. W2. Suosittelemme kahta lähestymistapaa lakehousen toipumiseen:

Menetelmä 1: Lakehouse Delta -taulukoiden ja -tiedostojen kopioiminen mukautetun komentosarjan avulla

Asiakkaat voivat luoda lakehouse-taloja uudelleen käyttämällä mukautettua Scala-komentosarjaa.

1. Luo Lakehouse (esimerkiksi LH1) juuri luodussa työtilassa C2. W2.

2. Luo uusi muistikirja työtilaan C2. W2.

3. Alkuperäisen järvenrakennuksen taulukoiden ja tiedostojen palauttamiseksi katso OneLake-polkujen dataa, kuten abfss (katso Connecting to Microsoft OneLake). Voit käyttää seuraavaa koodiesimerkkiä (katso Johdatus Microsoft Spark Utilitiesiin) muistikirjassa saadaksesi ABFS-polut tiedostoista ja taulukoista alkuperäisestä lakehousesta. (Korvaa C1. W1, jolla on työtilan todellinen nimi)

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

4. Käytä seuraavaa koodiesimerkkiä taulukoiden ja tiedostojen kopioimiseen juuri luotuun Lakehouse-järjestelmään.

   1. Delta-taulukoiden tapauksessa sinun on kopioitava taulukko yksi kerrallaan, jotta voit palauttaa sen uudessa Lakehousessa. Lakehouse-tiedostojen tapauksessa voit kopioida koko tiedostorakenteen ja kaikki pohjana olevat kansiot yhdellä suorituksella.

   2. Ota yhteyttä tukitiimiin komentosarjassa vaaditun vikasietoisuuden aikaleiman osalta.

   %%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. Kun olet suorittanut komentosarjan, taulukot tulevat näkyviin uuteen lakehouseen.

Lähestymistapa 2: Käytä Azure Storage Explorer tiedostojen ja taulukoiden kopioimiseen

Jos haluat palauttaa vain tietyt Lakehouse-tiedostot tai -taulukot alkuperäisestä Lakehousesta, käytä Azure Storage Explorer -ohjelmaa. Katso Integrate OneLake with Azure Storage Explorer yksityiskohtia varten. Jos tietokoko on suuri, käytä menetelmää 1.

Muistiinpano

Yllä kuvatut kaksi menetelmää palauttavat sekä Delta-muotoisten taulukoiden metatiedot että tiedot, koska metatiedot sijaitsevat yhdessä onelake-tietojen kanssa. Muissa kuin Delta-muotoilluissa taulukoissa (esimerkiksi CSV, Parquet jne.), jotka on luotu Spark Data Definition Language (DDL) -komentosarjoilla/-komennoilla, käyttäjä on vastuussa Spark DDL -komentosarjojen/komentojen ylläpidosta ja suorittamisesta uudelleen niiden palauttamiseksi.

Restoring Fabric materialisoituja järvinäkymiä

Alkuperäisen alueen materialisoidut Lake View -kuvat ovat edelleen asiakkaiden saatavilla failoverin jälkeen. Päivitysaikataulut ja suoritushistoria eivät toistu toissijaiselle alueelle. Palauttaaksesi ne, suorita seuraavat vaiheet sen jälkeen, kun olet palauttanut Lakehouse-tietosi.

• Palauta Lakehouse-taulukot käyttämällä yllä kuvattua lähestymistapaa 1 tai lähestymistapa 2. Kopioi vain lähdetaulukot.
• Palauta muistikirjat, jotka sisältävät MLV-määritelmäsi. Katso Notebook-osiosta palautusvaiheet.
• Suorita palautetut muistikirjat luodaksesi MLV:t uudelleen uudessa Lakehousessa. Lisätietoja MLV:iden luomisesta löytyy kohdasta Create a Materialized Lake View. Jos MLV:t kopioitiin myös aiemmassa vaiheessa, suorita CREATE OR REPLACE samalla kun luo ne uudelleen.
• Luo MLV-päivitysaikataulut uudelleen uudessa työtilassa. Aikatauluhistoriaa ja suoritusmittareita ei voi palauttaa.
• Jos MLV:si syöttävät semanttisia malleja tai raportteja, varmista ja päivitä Lakehouse-tunnuksen ja datasetin ID-viittaukset tarpeen mukaan. Yhdistä raportit päivitettyyn semanttiseen malliin ja varmista datan tuoreus.

Vinkki

Minimoidaksesi koodin muutokset muistikirjojen ajamisessa failoverin jälkeen, käytä samoja työtila- ja Lakehouse-nimiä uudessa alueessa (erityisesti kun käytetään Workspace- tai Lakehouse-nimeä nimityksissä). Päivitysaikataulut, toteutushistoria ja operatiiviset mittarit alkavat puhtaalta pöydältä palautetulla alueella. Suunnittele lähtöaika uusien seurantakynnysten määrittämiseen.

Muistikirja

Ensisijaisen alueen muistikirjat eivät ole asiakkaiden käytettävissä, eikä muistikirjojen koodia replikoida toissijaiselle alueelle. Muistikirjakoodin palauttamiseksi uudella alueella on kaksi tapaa saada muistikirjakoodisisältöä takaisin.

Lähestymistapa 1: Käyttäjän hallitsema redundanssi Git-integroinnin avulla (julkisessa esikatselussa)

Paras tapa tehdä tästä helppoa ja nopeaa on käyttää Fabric Git -integraatiota ja synkronoida kannettavasi ADO-reposi kanssa. Kun palvelu ei siirry toiselle alueelle, voit säilön avulla rakentaa muistikirjan uudelleen uuteen luomaasi työtilaan.

1. Määritä työtilan Git-integrointi ja valitse Yhdistä ja synkronoi ADO-säilön kanssa.

   

   Seuraavassa kuvassa näkyy synkronoitu muistikirja.

   

2. Palauta muistikirja ADO-säilöstä.

   1. Yhdistä uudelleen Azure ADO -repositioon uudessa työtilassa.

      

   2. Valitse Lähde-ohjausobjektin painike. Valitse sitten säilön asianmukainen haara. Valitse sitten Päivitä kaikki. Alkuperäinen muistikirja tulee näkyviin.

      

      

   3. Jos alkuperäisessä muistikirjassa on oletus lakehouse, käyttäjät voivat viitata Lakehouse-osaan lakehouse-kohdan palauttamiseksi ja sitten yhdistää äskettäin parantuneen lakehousen äskettäin palautettuun muistikirjaan.

      

   4. Git-integrointi ei tue muistikirjan resurssienhallinnan tiedostojen, kansioiden tai muistikirjojen tilannevedosten synkronointia.

      1. Jos alkuperäisessä muistikirjassa on tiedostoja muistikirjan resurssienhallinnassa:

         1. Muista tallentaa tiedostot tai kansiot paikalliselle levylle tai johonkin muuhun paikkaan.

         2. Lataa tiedosto uudelleen paikalliselta levykkeeltä tai pilviasemista palautettuun muistikirjaan.

      2. Jos alkuperäisessä muistikirjassa on muistikirjasta tilannevedos, tallenna muistikirjatilannevedos myös omaan versiontarkistusjärjestelmääsi tai paikalliseen levyyn.

         

         

Lisätietoja Git-integroinnista on artikkelissa Johdanto Git-integrointiin.

Lähestymistapa 2: Koodisisällön varmuuskopiointi manuaalinen lähestymistapa

Jos et käytä Git-integrointimenetelmää, voit tallentaa koodisi uusimman version, tiedostot resurssienhallintaan ja muistikirjatilannevedoksen versiontarkistusjärjestelmään, kuten Git, ja palauttaa muistikirjan sisällön manuaalisesti katastrofin jälkeen:

1. Tuo muistikirjakoodi, jonka haluat palauttaa, Tuontimuistikirja-ominaisuuden avulla.

   

2. Tuonnin jälkeen siirry haluamaasi työtilaan (esimerkiksi "C2. W2") siihen pääsemiseksi.

3. Jos alkuperäisessä muistikirjassa on oletus lakehouse, katso Lakehouse-osaa. Yhdistä sitten äskettäin löydetty lakehouse (jolla on sama sisältö kuin alkuperäisellä oletusjärvitalolla) äskettäin palautettuun muistikirjaan.

4. Jos alkuperäisessä muistikirjassa on tiedostoja tai kansioita resurssienhallinnassa, lataa käyttäjän versionhallintajärjestelmään tallennetut tiedostot tai kansiot uudelleen.

Spark-työn määritelmä

Ensisijaisen alueen Spark-työmääritykset eivät ole edelleenkään asiakkaiden käytettävissä, ja muistikirjassa oleva päämääritelmätiedosto ja viitetiedosto replikoidaan toissijaisille alueille OneLaken kautta. Jos haluat palauttaa SJD:n uudella alueella, voit palauttaa SJD:n noudattamalla alla kuvattuja manuaalisia vaiheita. SJD:n historiallisia juoksuja ei palauteta.

Voit palauttaa SJD-kohteet kopioimalla koodin alkuperäiseltä alueelta käyttämällä Azure Storage Explorer -ohjelmaa ja yhdistämällä Lakehouse-viitteet manuaalisesti uudelleen katastrofin jälkeen.

1. Luo uusi SJD-kohde (esimerkiksi SJD1) uuteen työtilaan C2. W2, samoilla asetuksilla ja määrityksillä kuin alkuperäisellä SJD-kohteella (esimerkiksi kieli, ympäristö jne.).

2. Käytä Azure Storage Explorer -ohjelmaa kopioimaan Libs, Mains ja Snapshots alkuperäisestä SJD-alkiosta uuteen SJD-kohteeseen.

   

3. Koodin sisältö näkyy juuri luodussa SJD:ssä. Sinun on lisättävä äskettäin palautettu Lakehouse-viittaus työhön manuaalisesti (katso Lakehousen palautusvaiheet). Käyttäjien on annettava alkuperäiset komentoriviargumentit uudelleen manuaalisesti.

   

Nyt voit ajaa tai ajoittaa äskettäin toipuneet SJD: si.

Lisätietoja Azure Storage Explorer:sta löytyy kohdasta Integrate OneLake with Azure Storage Explorer.

Käyttäjätietojen toiminnot

Palauttaaksesi käyttäjätietosi toiminnot terveellä alueella, käytä jotakin seuraavista tavoista.

Lähestymistapa 1: Git-integraatiolla (suositeltava)

Suosituin palautusmekanismi on Fabric Git -integraatio. Synkronoimalla käyttäjätietofunktioprojektit Azure DevOps- tai GitHub-repositorion kanssa voit nopeasti rekonstruoida ne uudessa työtilassa failoverin jälkeen.

Valmistaudu ennen katastrofia

1. Määritä Fabric Git -integraatio työtilalle, jossa käyttäjätietotoiminto toimii.
2. Yhdistä työtila Azure DevOps- tai GitHub-repositorioon.
3. Sitou kaikki käyttäjätietotoiminnot repositorioon ja synkronoi muutokset säännöllisesti.
4. Tallenna ympäristökohtaiset asetukset erikseen muuttuviin kirjastoihin tarvittaessa.

Toipumisvaiheet

Alueellisen katastrofin jälkeen:

1. Luo uusi Fabric-kapasiteetti terveellä alueella, kuten C2.
2. Luo uusi työtila, kuten W2, uudessa kapasiteetissa.
3. Yhdistä työtila samaan Azure DevOps- tai GitHub-repositorioon.
4. Avaa lähdekoodin hallinta ja synkronoi tietovaraston sisältö työtilaan.
5. Luo tai palauta kaikki riippuvaiset Fabric-resurssit, kuten järvenrakennukset, SQL-tietokannat Fabric:ssa, varastot ja liiketoimintatapahtumat.
6. Palauta käyttäjätietofunktiot.
7. Validoi funktioiden suoritus ja riippuvuusyhteydet.
8. Päivitä alavirran sovelluksia, dataputkia tai muita integroituja, jotka viittaavat palautettuihin toimintoihin.
9. Täydellinen kaikkien skenaarioiden täydellinen validointi.

Tärkeitä huomioon otettavia seikkoja

• Git-integraatio palauttaa vain lähdekoodin ja projektin resurssit.
• Historiallisia teloituslokkeja ei löydetä.
• Alavirran järjestelmät saattavat vaatia päätepisteiden uudelleensitomista.

Lisätietoja löytyy käyttäjätietofunktioiden lähdekoodin hallinnasta ja käyttöönotosta.

Lähestymistapa 2: Manuaalinen palautus

Jos Git-integraatiota ei ole konfiguroitu ennen katastrofia, voit manuaalisesti rekonstruoida käyttäjädatan toiminnot lähdekoodin varmuuskopioista.

Valmistaudu ennen katastrofia

Suorita säännöllisesti seuraavat tehtävät ja tallenna artefaktit ulkoiseen lähdekoodin hallintavarastoon tai varapaikkaan:

• Vie funktion lähdekoodi GitHub-repositorioon.
• Dokumentoi ja säilytä riippuvuustiedot.
• Dokumentointiympäristön asetukset.

Toipumisvaiheet

Alueellisen katastrofin jälkeen:

1. Luo uusi Fabric-kapasiteetti terveellä alueella, kuten C2.
2. Luo uusi työtila, kuten W2.
3. Palauta kaikki toiminnon vaatimat resurssit, mukaan lukien järvirakennukset, SQL-tietokannat Fabric-ohjelmassa, varastot, tapahtumapaikat ja ulkoiset palvelut.
4. Luo uusi käyttäjätietofunktioprojekti.
5. Tuo tai luo uudelleen funktion lähdekoodi.
6. Aseta ajonaikaiset konfiguraatioasetukset uudelleen.
7. Asenna kaikki funktio-riippuvuudet uudelleen.
8. Ota toiminto uudelleen käyttöön.
9. Uudelleenmääritä tunnistautuminen ja valtuutus.
10. Recreate Business Event -julkaisijat tai kuluttajat, jos niitä käytetään.
11. Suorita kokonaisvaltainen validointitestaus skenaarioillesi ja integraatioillesi.

GraphQL

GraphQL:n kohteet ensisijaiselta alueelta eivät ole saatavilla alueellisen katastrofin jälkeen, eikä GraphQL:n määritelmiä ja konfiguraatioita replikoidu toissijaiselle alueelle. GraphQL:n palauttamiseksi uudella alueella käytä jotakin seuraavista menetelmistä.

Lähestymistapa 1: Käyttäjän hallinnoima redundanssi Git-integraation avulla

Paras tapa tehdä tästä prosessista helppo ja nopea on käyttää Fabric Git -integraatiota ja synkronoida GraphQL ADO-reposi kanssa. Kun palvelu siirtyy toiselle alueelle, voit käyttää repositoa rakentaaksesi GraphQL:n uudelleen uudessa työtilassa, jonka luot.

1. Luo uusi työtila tavoitekapasiteetille ja alueelle.

2. Palauta kaikki riippuvaiset tietolähteet, kuten Lakehouse-, Warehouse- tai SQL-tietokannat, noudattamalla niiden palautusvaiheita.

3. Päivitä GraphQL:n määritelmä osoittamaan juuri palautettuihin resursseihin muuttamalla ympäristökohtaisia viittauksia, kuten lähdetyötilan ID:itä, lähdeartifaktin tunnisteita ja yhteystietoja. Tämä vaihe varmistaa oikean sitomisen käyttöönoton yhteydessä.

4. Palauta GraphQL-artefaktit Git-varastosta uuteen työtilaan. Tämä vaihe luo API-rakenteen ja konfiguroinnin uudelleen käyttämällä päivitettyjä määritelmiä.

5. Ota artefaktiasetukset uudelleen käyttöön, mukaan lukien roolit, käyttöoikeudet ja tunnistautumisen asetukset.

6. Käytä päätepisteviittauksia uudelleen päivittämällä sovellukset tai integraatiot käyttämään juuri luotua GraphQL-päätelaitetta.

7. Päivitä kaikki olemassa olevat käyttöönottoputket, jotka osoittivat vanhaan työtilaan, viittaamaan uuteen työtilaan.

8. Validoi API:n päästä päähän -toiminnallisuus.

Lähestymistapa 2: Manuaalinen lähestymistapa

Jos et käytä Git-integraatiomenetelmää, voit käyttää seuraavaa manuaalista lähestymistapaa GraphQL:n palauttamiseen.

1. Luo uusi työtila tavoitekapasiteetille ja alueelle.

2. Palauta kaikki riippuvaiset tietolähteet, kuten Lakehouse-, Warehouse- tai SQL-tietokannat.

3. Luo GraphQL API manuaalisesti uudessa työtilassa, mukaan lukien skeemamäärittelyt, tietolähteiden yhteydet ja suhteet.

4. Ota artefaktiasetukset uudelleen käyttöön, mukaan lukien roolit, käyttöoikeudet ja tunnistautumisen asetukset.

5. Käytä päätepisteviittauksia uudelleen päivittämällä sovellukset tai integraatiot käyttämään juuri luotua GraphQL-päätelaitetta.

6. Päivitä kaikki olemassa olevat käyttöönottoputket, jotka osoittivat vanhaan työtilaan, viittaamaan uuteen työtilaan.

7. Validoi API:n päästä päähän -toiminnallisuus.

Tärkeitä huomioon otettavia seikkoja

1. GraphQL perustuu ulkoisiin riippuvuuksiin (kuten Lakehouse, Warehouse ja SQL), jotka täytyy palauttaa ennen GraphQL:n käyttöönottoa.

2. GraphQL API -määritelmät sisältävät ympäristökohtaisia viittauksia (kuten sourceWorkspaceId ja sourceItemId). Toipuessa uudella alueella nämä viittaukset voivat menettää merkityksensä. Päivitä ne osoittamaan juuri varattuja resursseja.

3. Tietolähteiden automaattinen uudelleensitominen ei ole taattua katastrofipalautustilanteissa, erityisesti tallennettujen tunnuksia tai työtilan välisiä yhteyksiä käytettäessä.

4. Muut artefaktiasetukset, kuten valvonta, valtuutus, RBAC, itsetutkiskelu ja muut, eivät siirry failoverin jälkeen. Sinun täytyy palauttaa nämä asetukset uudessa alueessa.

Viitteet

• Yleiskatsaus Fabric Git -integraatioon - Microsoft Fabric | Microsoft Learn

• Lähdekoodin hallinta ja käyttöönottoputket API:ssa GraphQL:lle - Microsoft Fabric | Microsoft Learn 

Sovellus

Järjestelmä ei kopioi Fabric-sovelluksia, mukaan lukien niiden koodi, kokoonpano ja metatiedot, toissijaisille alueille. Jos pääalue epäonnistuu, sovellus pysyy poissa käytöstä. Palautusta varten tallenna sovelluksen lähdekoodi järjestelmän ulkopuolelle GitHub:iin, Azure DevOps:iin tai muuhun ohjelmistonhallintajärjestelmään. Palauta sovellustiedot erikseen noudattamalla katastrofipalautusohjeita jokaiselle taustalla olevalle Fabric-datavarastolle.

Manuaalinen lähestymistapa

Voit manuaalisesti palauttaa Fabric-sovelluksen alueellisen katastrofin jälkeen käyttämällä sovelluksen lähdekoodia ja Rayfin CLI:tä. 

Edellytykset 

Ennen kuin katastrofi tapahtuu:

• Tallenna Fabric App -lähdekoodi GitHub:iin, Azure DevOps:iin tai muuhun lähdekoodin hallintavarastoon. 

• Dokumentoi toipumisprosessi.  

Toipumisvaiheet 

1. Luo uusi työtila tavoitekapasiteetille ja alueelle. 

2. Palauta riippuvaiset resurssit ennen sovelluksen uudelleenkäyttöönottoa.  

3. Hae uusin Fabric App -lähdekoodi ohjelmistosi tai paikallisesta varmuuskopiosta. 

4. Sovelluksen lähdehakemistosta Fabric-sovellus otetaan käyttöön palautustyötilassa käyttämällä Rayfin CLI:tä. Suorita rayfin up --workspace <new workspace>. 

5. Palauta sovelluksen lapsikohde (Fabric SQL Database) noudattamalla sen vastaavia palautusmenettelyjä.  

6. Lisää artefaktitason asetuksia, mukaan lukien roolit ja käyttöoikeudet tarpeen mukaan.  

7. Varmista sovelluksen toiminnallisuus ja varmista, että käyttäjillä on oikeat oikeudet.  

Tärkeää 

• Pidä Fabric App -lähdekoodi Fabric-alueen ulkopuolella palautuksen mahdollistamiseksi.  

• Sovellustietoja tietokannasta ei palauteta osana Fabric App -käyttöönottoprosessia, vaan ne on palautettava erikseen.  Voit manuaalisesti palauttaa Fabric-sovelluksen alueellisen katastrofin jälkeen käyttämällä sovelluksen lähdekoodia ja Rayfin CLI:tä. 

Datatiede

Tässä oppaassa käydään läpi tietojenkäsittelykokemuksen palautusmenettelyt. Se kattaa koneoppimismallit ja -kokeet.

Koneoppimismalli ja -kokeilu

Ensisijaisen alueen datatieteen kohteet eivät ole edelleenkään saatavilla asiakkaille, eikä koneoppimismallien ja kokeilujen sisältöä ja metatietoja replikoida toissijaisille alueille. Jos haluat palauttaa ne täysin uudella alueella, tallenna koodisisältö versiontarkistusjärjestelmään (kuten Git) ja suorita koodisisältö manuaalisesti uudelleen katastrofin jälkeen.

1. Palauta muistikirja. Katso muistikirjan palautusvaiheet.

2. Määritystä, suoritusmittareita ja metatietoja ei replikoida pariksi määritetylle alueelle. Sinun täytyy päivittää jokainen datatiedekoodin versio, jotta voit palauttaa täysin koneoppimismallit ja tehdä kokeita katastrofin jälkeen.

tietovarasto

Tämä opas käy läpi tietovarasto-kokemuksen palautusprosessit. Se kattaa varastot.

Varasto

Alkuperäisen alueen varastot eivät ole saatavilla asiakkaille. Jos haluat palauttaa varastoja, suorita seuraavat kaksi vaihetta.

1. Luo uusi väliaikainen lakehouse työtilaan C2. W2 tiedoille, jotka kopioit alkuperäisestä varastosta.

2. Täytä varaston Delta-taulukot hyödyntämällä varaston Explorer- ja T-SQL-ominaisuuksia (ks. Taulukot tietovarastossa Microsoft Fabric).

Muistiinpano

On suositeltavaa, että pidät Varaston koodin (rakenne, taulukko, näkymä, tallennettu toimintosarja, funktiomääritykset ja suojauskoodit) versioina ja tallennettuina turvalliseen sijaintiin (kuten Git) kehityskäytäntöjesi mukaisesti.

Tietojen käsittely Lakehousen ja T-SQL-koodin kautta

Juuri luodussa työtilassa C2. W2:

1. Luo väliaikainen lakehouse "LH2" C2:ssa. W2.

2. Palauta väliaikaisessa lakehouse-varastossa olevat Delta-taulukot alkuperäisestä varastosta Lakehousen palautusvaiheiden mukaisesti.

3. Luo uusi varasto "WH2" C2:ssa. W2.

4. Yhdistä väliaikainen lakehouse varastosi hallinnassa.

5. Sen mukaan, miten aiot ottaa taulukkomääritykset käyttöön ennen tietojen tuontia, tuonnissa käytettävä todellinen T-SQL voi vaihdella. Voit käyttää LISÄÄ KOHTEESEEN-, VALITSE KOHTEESEEN- tai LUO TAULUKKO NIMELLÄ SELECT -menetelmällä palauttaaksesi Warehouse-taulukot lakehouseista. Tässä esimerkissä käytettäisiin lisää-lisäosaa maun mukaan. (Jos käytät alla olevaa koodia, korvaa näytteet todellisilla taulukon ja sarakkeiden nimillä)

   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. Lopuksi, vaihda yhteysmerkkijono sovelluksissa, joissa käytetään Fabric-varastoasi.

Muistiinpano

Asiakkaille, jotka tarvitsevat alueellista katastrofipalautusta ja täysin automatisoitua liiketoiminnan jatkuvuutta, suosittelemme pitämään kaksi Fabric Warehouse -asetusta erillisillä Fabric-alueilla ja ylläpitämään koodin ja datan pariteettia tekemällä säännöllisiä käyttöönottoja ja tiedon vastaanottoa molemmille paikoille.

Peilattu tietokanta

Ensisijaisen alueen peilatut tietokannat eivät ole edelleenkään asiakkaiden käytettävissä, eivätkä asetukset replikoida toissijaisille alueille. Jos haluat palauttaa sen alueellisen epäonnistumisen tapauksessa, sinun on luotava peilattu tietokanta uudelleen toisessa työtilassa eri alueelta.

Data Factory

Ensisijaisen alueen Data Factory kohteet eivät ole asiakkaiden käytettävissä, eikä putkien tai tietovuon gen2-kohteiden asetuksia ja määrityksiä replikoida toissijaiselle alueelle. Jos haluat palauttaa nämä kohteet, jos kyseessä on alueellinen virhe, sinun on luotava tietojen integroinnin kohteet uudelleen toisessa työtilassa eri alueelta. Seuraavissa osissa on esitelty yksityiskohtaiset tiedot.

Tietovuot Gen2

Jos haluat palauttaa tietovuon Gen2-kohteen uudella alueella, sinun on vietävä PQT-tiedosto versiontarkistusjärjestelmään, kuten Git, ja palautettava sitten tietovuon Gen2-sisältö manuaalisesti katastrofin jälkeen.

1. Dataflow Gen2 -kohteestasi, Power Query-editorin Home-välilehdeltä, valitse Export-mallipohja.

   

2. Kirjoita Vie malli -valintaikkunaan tämän mallin nimi (pakollinen) ja kuvaus (valinnainen). Kun olet valmis, valitse OK.

   

3. Luo katastrofin jälkeen uusi Tietovuo Gen2 -kohde uuteen työtilaan "C2. W2".

4. Power Query-editorin nykyisestä näkymäpaneelista valitse Tuo Power Query-pohjasta.

   

5. Siirry Avaa-valintaikkunassa oletuslatauskansioosi ja valitse .pqt-tiedosto, jonka tallensit edellisissä vaiheissa. Valitse sitten Avaa.

6. Malli tuodaan sitten uuteen Tietovuo Gen2 -kohteeseesi.

Tietovoiden Tallenna nimellä -ominaisuutta ei tueta järjestelmäpalautuksen yhteydessä.

Pipelines

Asiakkaat eivät voi käyttää putkia alueellisen katastrofin sattuessa, eikä määrityksiä replikoida pariksi liitetylle alueelle. Suosittelemme kriittisten putkien rakentamista useisiin työtiloihin eri alueilla.

Kopioi työ

CopyJob-käyttäjien on ryhdyttävä ennakoiviin toimiin alueelliselta katastrofilta suojautumiseksi. Seuraava lähestymistapa varmistaa, että alueellisen katastrofin jälkeen käyttäjän CopyJobs on edelleen käytettävissä.

Käyttäjän hallitsema redundanssi Git-integroinnin avulla (julkisessa esikatselussa)

Paras tapa tehdä tästä prosessista helppo ja nopea on käyttää Fabric Git -integraatiota ja synkronoida CopyJob ADO-repon kanssa. Kun palvelu ei siirry toiselle alueelle, voit säilön avulla luoda uuden työtilan CopyJob-objektin uudelleen.

1. Määritä työtilan Git-integrointi ja valitse muodosta yhteys ja synkronoi ADO-säilöllä.

   

   Seuraavassa kuvassa näkyy synkronoitu CopyJob.

   

2. Palauta CopyJob ADO-säilöstä.

   1. Uudessa työtilassa yhdistä ja synkronoi uudelleen Azure ADO -repositioosi. Kaikki tämän arkiston Fabric-kohteet ladataan automaattisesti uuteen työtilaasi.

      

   2. Jos alkuperäinen CopyJob käyttää Lakehousea, käyttäjät voivat viitata Lakehouse -osaan, lakehousen palauttamiseksi, ja sitten yhdistää äskettäin parantuneet CopyJob-tiedot äskettäin löydettyun Lakehouseen.

Lisätietoja Git-integroinnista on artikkelissa Johdanto Git-integrointiin.

Apache Airflow -työ

Apache Airflow Job in Fabric -käyttäjien on ryhdyttävä ennakoiviin toimiin suojautuakseen alueellista katastrofia vastaan.

Suosittelemme redundanssin hallintaa Fabric Git -integraation avulla. Synkronoi ensin ilmavirtaustyösi ADO-säilön kanssa. Jos palvelu siirtyy toiselle alueelle, voit käyttää arkistoa ilmavirtaustyön uudelleenrakentamiseen luomassasi uudessa työtilassa.

Tässä on vaiheet tämän saavuttamiseksi:

1. Määritä työtilasi Git-integrointi ja valitse "yhdistä ja synkronoi" ADO-säilön kanssa.

2. Tämän jälkeen näet, että Airflow-työsi on synkronoitu ADO-tietovarastoosi.

3. Jos sinun täytyy palauttaa Airflow-työ ADO-reposita, luo uusi työtila, yhdistä ja synkronoi uudelleen Azure ADO -repositioosi. Kaikki tämän arkiston Fabric-kohteet, mukaan lukien Airflow, ladataan automaattisesti uuteen työtilaasi.

Reaaliaikainen tieto

Tässä oppaassa käydään läpi reaaliaikaisten tiedustelutietojen palautusmenettelyt. Se kattaa KQL-tietokannat/kyselyjoukot ja tapahtumavirrat.

Activator

Ensisijaisen alueen aktivaattorituotteet pysyvät asiakkaiden käytettävissä, eikä aktivaattorin trigger-määritelmiä replikoidu toissijaiselle alueelle. Aktivaattorin käyttäjien on ryhdyttävä ennakoiviin toimiin valmistautuakseen alueelliseen katastrofipalautukseen.

Varmistaaksesi, että voit palauttaa Activator-esineet alueellisen katastrofin sattuessa, aseta Fabric Git -integraatio varmuuskopioimaan laukaisumäärittelyt ja palauttamaan ne työtilassa toisella alueella.

1. Konfiguroi Fabric Git -integraatio työtilalle, jossa Activator-esineesi on, ja synkronoi trigger-määrittelyt Git-repositoriosi kanssa.
2. Pidä aktivaattorin laukaisumääritelmät sitoutuneina ja synkronoituna säännöllisesti.
3. Palautuksen aikana luo uusi työtila kohdealueelle (C2. W2), yhdistä se samaan repositorioon ja synkronoi laukaisumääritelmien palauttamiseksi.
4. Uudelleenkonfiguroi ja validoi kaikki Activatorin tietolähteet ja riippuvuudet uudessa työtilassa.

Muistiinpano

Tavallinen Fabric-failover-prosessi ei koske Activator-tuotteita. Palautus rajoittuu Git-pohjaiseen varmuuskopiointiin ja laukaisumääritelmien palautukseen.

Lisätietoja Git-integroinnista on artikkelissa Johdanto Git-integrointiin.

Graafimalli/kyselyjoukko

Graafimalli- ja graafikyselysetin kohteet ensisijaiselta alueelta ovat asiakkaiden käytettävissä, eikä näitä tuotteita replikoita toissijaiselle alueelle. Palautusta varten luo tai käytä kapasiteettia eri alueella ja luo siellä uudelleen Graafimalli- ja Graafikyselysetin kohteet.

1. Luo tai käytä olemassa olevaa Fabric-kapasiteettia toisella alueella, johon katastrofi ei vaikuta.

2. Luo uusi työtila tai käytä olemassa olevaa työtilaa siinä tilassa.

3. Luo Graafimallin kohde uudelleen toissijaisessa työtilassa (viitattu vaiheessa 2). Muokkaa mallimäärittely, mukaan lukien solmut, reunat jne., vastaamaan alkuperäistä Graafimallia.

4. Jos alkuperäinen järvitalo on rappeutuvalla alueella, palauta se ensin seuraamalla Lakehouse-osuutta.

5. Yhdistä järvitalo OneLake-tietolähteeksi juuri luodulle Graph Model -kohteelle. Käytä palautettua järvitaloa, jos se oli rappeutuvalla alueella, tai yhdistä uudelleen olemassa olevaan järvimajaan, jos se on edelleen käytettävissä.

6. Määritä uudelleen kaikki datan latausaikataulut tai yhteydet graafimallille uudessa työtilassa.

7. Luo Graph Queryset -alkio uudelleen toissijaisessa työtilassa. Syötä kyselyt ja tallennetut kyselyasetukset manuaalisesti uudelleen alkuperäisestä Graph Querysetistä.

KQL-tietokanta/kyselyjoukko

KQL-tietokannan/kyselyjoukon käyttäjien on ryhdyttävä ennakoiviin toimiin alueelliselta katastrofilta suojautumiseksi. Seuraava lähestymistapa varmistaa, että alueellisen katastrofin sattuessa KQL-tietokantojen kyselyjoukkojen tiedot pysyvät suojattuina ja käytettävissä.

Seuraavien vaiheiden avulla voit taata KQL-tietokantojen ja kyselyjoukkojen tehokkaan järjestelmäpalautusratkaisun.

1. Perusta itsenäiset KQL-tietokannat: Määritä kaksi tai useampi itsenäinen KQL-tietokanta/kyselyjoukko omistetuille Fabric-kapasiteeteille. Nämä tulisi perustaa kahdelle eri Azure-alueelle (mieluiten Azure-paritettuihin alueisiin) maksimoivan resilienssin saavuttamiseksi.

2. Replikoimisen hallintatoiminnot: Yhdessä KQL-tietokannassa tehdyt hallintatoimet on peilattava myös toisessa tietokannassa. Tämä varmistaa, että molemmat tietokannat pysyvät synkronoituina. Tärkeimpiä replikointia koskevia toimintoja ovat seuraavat:

   • Taulukot: Varmista, että taulukon rakenteet ja rakenteen määritelmät ovat yhdenmukaiset kaikissa tietokannoissa.

   • Yhdistämismääritys: Monista kaikki vaaditut yhdistämismääritykset. Varmista, että tietolähteet ja kohteet tasataan oikein.

   • Käytännöt: Varmista, että molemmilla tietokannoilla on samanlaiset tietojen säilytys-, käyttöoikeus- ja muut asianmukaiset käytännöt.

3. Todennuksen ja käyttöoikeuksien myöntämisen hallinta: Määritä kullekin replikolle vaaditut käyttöoikeudet. Varmista, että asianmukaiset valtuutustasot on määritetty, niin että tarvittavat henkilöstön käyttöoikeudet myönnetään samalla kun säilytetään suojausstandardit.

4. Rinnakkaisten tietojen käsittely: Jotta tiedot pysyvät johdonmukaisena ja valmiina useilla alueilla, lataa sama tietojoukko kuhunkin KQL-tietokantaan samaan aikaan kuin käytät niitä.

Tapahtumavirta

Eventstream on keskitetty paikka Fabric-alustalla, jossa reaaliaikaisia tapahtumia voidaan tallentaa, muuntaa ja reitittää eri kohteisiin (esimerkiksi lakehouset, KQL-tietokannat/kyselysetit) no-code-kokemuksella. Niin kauan kuin järjestelmäpalautus tukee kohteita, tapahtumavirrat eivät menetä tietoja. Tämän vuoksi asiakkaiden tulee käyttää kyseisten kohdejärjestelmien järjestelmäpalautustoimintoja tietojen käytettävyyden takaamiseksi.

Asiakkaat voivat myös saavuttaa georedundanssia ottamalla käyttöön identtisiä Eventstream-työkuormia useissa Azure-alueissa osana monipaikkaista aktiivista ja aktiivista strategiaa. Usean sivuston aktiivisen/aktiivisen lähestymistavan avulla asiakkaat voivat käyttää kuormitustaan millä tahansa käyttöönotetulla alueella. Tämä lähestymistapa on järjestelmäpalautuksen monimutkaisin ja kalliin tapa, mutta useimmissa tilanteissa se voi lyhentää palautusajan lähelle nollaa. Asiakkaat voivat olla täysin maantieteellisesti vikasietoisia,

1. Luo replikoita niiden tietolähteistä eri alueilla.

2. Luo Eventstream-kohteita vastaavilla alueilla.

3. Yhdistä nämä uudet kohteet identtisiin tietolähteisiin.

4. Lisää identtiset kohteet kullekin eri alueilla olevan tapahtumavirran kohdalla.

Liiketoimintatapahtumat, Fabric-tapahtumat ja Azure-tapahtumat

Vaikka Business Events, Fabric Events ja Azure Events jakavat saman Real-Time-solmuinfrastruktuurin Microsoft Fabric, niillä on erilaiset alkuperät, käyttäytymismallit ja palautusvaatimukset, jotka on ymmärrettävä ennen katastrofipalautuksen suunnittelua:

• Fabric-tapahtumat ovat tapahtumatilauksia, jotka reagoivat Fabric-resurssien tuottamiin toimintoihin, mukaan lukien työtilan kohteiden elinkaaren muutokset (kuten järvitalojen, muistikirjojen tai varastojen luominen, päivittäminen tai poistaminen), tehtävien suoritukset (kuten putkisto- tai muistikirjasuoritukset) sekä OneLake-tiedostojen ja kansioiden toiminnot. Nämä tilaukset ovat push-pohjaisia ja lyhytaikaisia. Tilauksia ei ole toissijaisella alueella.

• Azure Events ovat tapahtumatilauksia Azure Blob Storage -tilien tuottamille toiminnoille. Nämä Azure-resurssit ovat olemassa itsenäisesti mistään Fabric-kapasiteetista tai alueesta. Vaikka Azure Blob Storage resurssi itsessään saattaa pysyä käytettävissä Fabric alueellisen katkon aikana, Real-Time hubissa konfiguroituja tilauksia ei replikoita toissijaiselle alueelle ja ne on luotava uudelleen.

• Liiketoimintatapahtumat ovat erillinen ominaisuus Fabric Real-Time Intelligencessa, jonka avulla tiimit voivat määritellä, julkaista ja toimia merkityksellisten liiketoimintasignaalien mukaisesti. Liiketoimintatapahtumat luodaan Fabric sisältä Activatorin, Spark-muistikirjojen tai User Data Functionsin kautta, ja julkaistaan sitten Real-Time hubissa, jossa alavirran kuluttajat kuten Activator, Eventhouse tai Power Automate voivat reagoida niihin. Tapahtumaskeemat ohjataan keskitetysti Schema-rekisterin kautta. Eventhouse tallentaa automaattisesti jokaisen julkaistun liiketoimintatapahtuman, joten sen palauttaminen vaikuttaa suoraan liiketoimintatapahtumahistorian saatavuuteen. Yhtään julkaisija- tai kuluttajakonfiguraatiota, skeemamäärittelyä tai tilauksia ei replikoidu toissijaiselle alueelle.

Käytä seuraavia vaiheita palauttaaksesi Business Eventsin, Fabric Eventsin ja Azure Eventsin uudessa työtilassa palautusalueella.

Liiketoimintatapahtumia varten:

1. Luo uudelleen julkaisijoiden ja kuluttajien käyttämä liiketoimintatapahtuma seuraamalla artikkelia Luo liiketoimintatapahtumia Fabric Real-Time Hubissa. Liiketoimintatapahtuman luomisen yhteydessä luot Event Schema Set -resurssin. Eventhouse-resurssi on vapaaehtoinen riippuen tilanteesta. Jos varmuuskopioit tapahtumaskeeman Git-integraatiolla, palauta se ensin seuraamalla Tapahtumaskeemajoukko-osiota ja osoita sitten liiketoimintatapahtuma palautettuun skeemajoukkoon.

2. Luo uudelleen kaikki publisher-kohteet, jotka tuottavat liiketoimintatapahtumia, kuten Spark-muistikirjat tai User Data -toiminnot, uudessa työtilassa seuraamalla publisher-artikkeleita: Käytä User Data -toimintoa Business Events Publisher'na, Käytä Activatoria Business Events Publisher'na, Käytä Notebookia liiketoimintatapahtumina Publisher, ja käytä Eventstreamia Business Events Publisher.

3. Luo uudelleen kuluttajatilaukset Real-Time hubissa (esimerkiksi Aktivaattorin säännöt, muistikirjan laukaisimet tai Power Automate-virrat), jotka alun perin reagoivat liiketoimintatapahtumiin kyseisellä alueella, seuraamalla Activatorinartikkeleita Eventhouse ja Real-Time Dashboard Integration with Business Events sekä Consume Business Events.

4. Varmista, että tapahtumat etenevät kokonaisvaltaisesti varmistamalla, että tilaukset ovat aktiivisia ja että data saapuu odotettuihin kohteisiin palautusalueella.

Fabric-tapahtumista:

1. Luo tilaukset uudelleen Real-Time hubissa, joka osoittaa työtilan kohteisiin, töihin tai OneLake-polkuihin, jotka palautettiin palautusalueella, seuraamalla artikkelia Explore Fabric events in Fabric Real-Time hub.

2. Varmista, että tapahtumat etenevät kokonaisvaltaisesti varmistamalla, että tilaukset ovat aktiivisia ja että data saapuu odotettuihin kohteisiin palautusalueella.

Azure-tapahtumille:

1. Azure Blob Storage -tileihin ei vaikuta Fabric-alueellinen katko. Luo tapahtumatilaukset uudelleen Real-Time hubissa, joka osoittaa samoihin Azure Blob Storage-tileihin seuraamalla artikkelia Aseta hälytykset Azure Blob Storage tapahtumista Real-Time hubissa.

2. Varmista, että tapahtumat etenevät kokonaisvaltaisesti varmistamalla, että tilaukset ovat aktiivisia ja että data saapuu odotettuihin kohteisiin palautusalueella.

Muistiinpano

Business Eventsin tapahtumahistoria riippuu tapahtumatalon palauttamisesta. Business Events, Fabric Events ja Azure Events ovat push-pohjaisia ja katoavaisia, joten näille tyypeille ei voi palauttaa historiallisia tapahtumia. Vain toipumisen jälkeen tuotetut tapahtumat ovat saatavilla uudella alueella.

Tapahtumarakenteen joukko

Tapahtumaskeemajoukko on Fabric kohde, joka sisältää tapahtumatyypin ja skeeman määritelmät Real-Time älykkyydessä. Muut ominaisuudet rakentuvat sen päälle: julkaisijat kirjoittavat tapahtumia, jotka noudattavat sen skeemoja, ja kuluttajat lukevat samoja määritelmiä vastaan.

Tapahtumaskeemajoukot pääalueelta pysyvät asiakkaiden käytettävissä, eikä niitä replikoita toissijaiselle alueelle. Koska tapahtumaskeemajoukko on kestävä tekijämääritelmä eikä lyhytaikainen tilaus, voit varmuuskopioida sen etukäteen ja palauttaa sen käsin uudelleenkirjoittamisen sijaan.

Suositellaan: varmuuskopioi Fabric Git -integraatiolla

Alueellisen katastrofin jälkeen tapahtumaskeeman palauttamiseksi aseta Fabric Git -integraatio ennen katastrofia ja synkronoi tapahtumaskeemaset sisältävä työtila Git-varastosi kanssa.

1. Konfiguroi Fabric Git -integraatio työtilalle, joka sisältää tapahtumaskeemasarjasi, ja synkronoi se Git-repositoriosi kanssa.

2. Pidä tapahtumaskeemajoukko sitoutuneena ja synkronoituna säännöllisesti, erityisesti tapahtumatyyppien lisäämisen tai uusien skeemaversioiden julkaisemisen jälkeen.

3. Palautuksen aikana luo uusi työtila kohdealueelle (C2. W2), yhdistää se samaan varastoon ja synkronoi tapahtumaskeeman palauttamiseksi. Koska uusi työtila on tyhjä, Git Sync tuo sisällön arkistosta työtilaan.

4. Luo uudelleen kaikki julkaisijat ja kuluttajat, jotka käyttävät skeemasarjaa, noudattaen näiden tuotetyyppien ohjeita.

5. Varmista, että julkaisijat voivat julkaista palautettuja tapahtumatyyppejä vastaan ja että kuluttajat saavat tapahtumat odotetusti.

Synkronoitu määritelmä sisältää skeemajoukon tapahtumatyypit, skeemat ja skeemaversiot. Se ei sisällä julkaisijoiden rekisteröitymisiä, kuluttajatilauksia tai tapahtumahistoriaa. Palauta ne erikseen, noudattaen ohjeita skeemajoukkoa käyttäville kohdetyypeille.

Vaihtoehto: luo uudelleen manuaalisesti

Jos et konfiguroinut Git-integraatiota ennen katastrofia, luo tapahtumaskeema uudelleen palautusalueella seuraamalla Luo ja hallitse tapahtumaskeemaset, ja lisää sitten alkuperäisen skeeman sisältämät tapahtumatyypit ja skeemat seuraamalla Luo ja hallitse tapahtumaskeemoja skeemasarjoissa.

Muistiinpano

Tapahtumaskeemasarjat jaetaan usein useiden julkaisijoiden ja kuluttajien kesken. Palauta skeemajoukko ennen kuin luot uudelleen niistä riippuvat kohteet, jotta näillä esineillä on tapahtumatyyppejä, joihin sitoutua.

Kartta

Pääalueen karttaesineet pysyvät asiakkaiden käytettävissä, eikä karttaesineitä replikoita toissijaiselle alueelle.

Jos haluat palauttaa karttakohteen katastrofin sattuessa, aseta Fabric Git-integraatio ja synchronize karttaesineesi Git-repon kanssa.

Palautuksen aikana, kun uusi alue/kapasiteetti Fabric:ssa on asetettu, voit käyttää repositoa rakentaaksesi kartta-alimon uudelleen uudessa työtilassa, jonka loit. Koska uusi työtila on tyhjä, Git sync siirtää sisällön repositosta tyhjään työtilaan. Tämä vaihe herättää kartta-esineen takaisin eloon.

Muistiinpano

Jos alkuperäisessä kartta-alkiossa on järvitalo tai KQL-kyselyjoukko konfiguroituna, katso ensin Lakehouse-osio ja KQL-kyselyjoukko-osio palauttaaksesi ne. Kun nämä ongelmat on hoidettu, yhdistä juuri palautettu järvitalo ja kyselyjoukko juuri palautettuun karttakohteeseen.

Ontologia

Ontologian käyttäjien on ryhdyttävä ennakoiviin toimiin valmistautuakseen alueelliseen katastrofipalautukseen. Alla kuvattu lähestymistapa varmistaa, että alueellisen katastrofin jälkeen ontologiasi pysyy palautettavissa ja voidaan palauttaa nopeasti.

Yksinkertaisin ja nopein tapa ottaa palautus käyttöön on käyttää Fabric Git -integraatiota ja synkronoida Ontologiasi Azure DevOps (ADO) -varaston kanssa. Jos palvelu siirtyy toiselle alueelle, voit käyttää tätä tietovarastoa rakentaaksesi Ontologian uudelleen uudessa työtilassa.

Ontologian kohteet ensisijaisella alueella eivät ole asiakkaiden saatavilla alueellisen katastrofin jälkeen, eikä ontologian tuotteita siirretä toissijaiselle alueelle.

Ontology-alkion palauttamiseksi katastrofin aikana konfiguroi Fabric Git-integraatio ja synchronize Ontology-kohde ADO-tietovarastosi kanssa etukäteen.

Palautuksen aikana, kun uusi alue ja kapasiteetti Fabric:ssa on asetettu, voit käyttää varastoa rakentaaksesi Ontologian kohteen uudelleen uudessa työtilassa. Koska uusi työtila on tyhjä, Git sync vetää sisällön varastosta työtilaan, palauttaen käytännössä Ontologian kohteen.

Muistiinpano

Jos alkuperäisessä ontologian kohteessa on järvirakennus konfiguroituna, katso ensin järvitalo-osiosta saadaksesi järvenrakennuksen takaisin. Kun nämä riippuvuudet on hoidettu, yhdistä juuri löydetty järvenrakennus juuri löydettyyn ontologiakohteeseen.

Suunnittelu

Tässä artikkelissa kuvataan toipumismenettelyt IQ:n suunnitelmakokemuksessa. Se kuvaa vaiheet, jotka tarvitaan keskeisten komponenttien, kuten suunnittelun, PowerTablen, Intelligencen, InfoBridgen ja niihin liittyvien tietoresurssien palauttamiseksi.

Git-integraatio suunnitelman kohteiden palauttamiseksi

Suositeltu lähestymistapa on synkronoida kaikki suunnitelman kohteet Azure DevOps (ADO) tai GitHub -tietovaraston kanssa käyttämällä Fabric Git -integraatiota. Failoverin jälkeen käytä varastoa palauttamaan kohteet uuteen työtilaan.

Predisaster (ennakoivat toimenpiteet):

1. Workspace W1:ssä mene Workspace Settings -kohtaan ja määritä Git-integraatio .

2. Valitse Yhdistä ja synkronoi ADO- tai GitHub-repositoriosi kanssa.

3. Valitse suunnitelman kohteet, jotka voit ladata repositoryyn, ja valitse Commit.

   

4. Varmista, että suunnitelman kohteiden Git-tila on synkronoitu.

5. Luo sitoutumiskurinalaisuus – sitoudu jokaisen merkittävän muutoksen jälkeen suunnitelmamääritelmään niin, että arkisto heijastaa aina viimeisintä tilaa.

Toipumisvaiheet:

1. Luo uusi työtila W2 kapasiteettiin C2 terveelle alueelle.

2. Workspace W2:ssa mene Workspace Settings -kohtaan ja yhdistä uudelleen samaan ADO/GitHub-repositorioon.

3. Valitse Lähdeohjausobjekti. Valitse asianmukainen repositorion haara ja valitse Päivitä kaikki. Kaikki suunnitelman tuotteet ladataan W2:een.

Tärkeää

Vain suunnittelulomakkeen rakenne ja asetukset palautuvat Git-integraation avulla. Suunnittelulomakkeeseen syötetyt tiedot, kuten syötearvot, muistiinpanot ja kommentit, eivät palautu automaattisesti. Se vaatii Fabric SQL -palautuksen. Semanttinen mallidata täytyy myös palauttaa erikseen.

Seuraavat komponentit palautuvat toipumisen jälkeen:

• PowerTable-lomakkeet: Lähdetaulun asetukset, sarakkeen konfiguraatio, rivien käyttö, visuaaliset ominaisuudet (asettelu, muodot ja muuta), rivien tunnistus, kommenttiasetukset, hitaasti muuttuvat mitat (SCD), hyväksynnät, automaatio ja lomakkeet.
• Suunnittelulomakkeet: Taulukon ominaisuudet (muotoilu, ehdollinen muotoilu ja muuta), kommenttiasetukset, takaisinkirjoitusasetukset, tiedonsyöttösarakkeet, syöterivit, skenaariot ja kirjanmerkit.
• InfoBridge: InfoBridge-lähteet, InfoBridge-kyselyt, muunnosvaiheet, takaisinkirjoituskohteet, takaisinkirjoitusasetukset, linkitetyt kyselykartoitukset, kyselyryhmät, visuaaliset ominaisuudet (sekoitus). Näitä kohteita ei voi palauttaa: tiedostopohjaiset lähteet (CSV, Excel), monikäyttöiset työtehtävälomakkeet, jotka käyttävät tiedostopohjaisia lähteitä.
• Älykkyys: Kaikki kaaviot ja matriisit.

Fabric SQL restore for plan

Suunnittelutaulukoihin, PowerTablessa käytettyihin taulukoihin ja takaisinkirjoitusdataan syötetyt tiedot tallennetaan SQL-tietokantoihin ja ne on otettava huomioon osana katastrofipalautusstrategiaasi. SQL-tietokantojen palauttamiseksi katso SQL-tietokanta-osio .

• Suunnitelman palautusmetatiedot: Jokainen suunnitelman kohde liittyy __fabric_plan_sys tietokantaan, joka tallentaa suunnitteluominaisuuksien metatiedot, mukaan lukien kommentit, skenaariot, tiedonsyötteet ja takaisinkirjoitusasetukset. __fabric_plan_sys tietokantaa ei palauteta automaattisesti, vaan se täytyy nimenomaisesti palauttaa.

• Palauta takaisinkirjoitustietokannat: Jos suunnitelmasi käyttää SQL-kirjoituskohteita, sinun täytyy myös palauttaa niihin liittyvät tietokannat manuaalisesti. Konfiguroidut SQL-kirjoituskohteet eivät palautu automaattisesti.

• PowerTablessa käytetyt palautustaulukot: Kaikki PowerTablella luodut taulut tallennetaan Fabric SQL -tietokantaan. Sinun täytyy myös palauttaa nämä taulukot DR:n aikana.

Operatiiviset agentit

Operaatioagenttien käyttäjien tulisi ryhtyä ennakoiviin toimiin valmistautuakseen alueelliseen katastrofipalautukseen. Tässä osiossa kuvatun lähestymistavan noudattaminen auttaa varmistamaan, että agenttisi voidaan palauttaa nopeasti alueellisen sähkökatkon jälkeen.

Käytä Fabric Git -integraatiota synkronoidaksesi työtilasi repositorion kanssa. Tämä lähestymistapa mahdollistaa agenttiasetusten rekonstruoinnin uudessa työtilassa, jos palvelu siirtyy toiselle alueelle.

Operatiivisia agentteja ensisijaisella alueella ei ole saatavilla alueellisen katastrofin aikana. Agentin konfiguraatiot, käyttäytymismallit ja aktiivisuuslokit eivät replikoidu toissijaiselle alueelle. Keskeneräiset toiminnot, aktiiviset chat-sessiot ja aiemmin katastrofin aikaan vastaanotetut tapahtumat katoavat.

Valmistautuaksesi palautukseen, konfiguroi Fabric Git -integraatio ja synkronoi agenttielementit ADO-varastosi kanssa ennen katastrofia.

Kun palautat, aseta uusi alueesi ja kapasiteetti Fabric-ohjelmaan, ja käytä synkronoitua varastoa agenttikonfiguraatioiden palauttamiseen uuteen työtilaan. Git Sync vetää tallennetut sisällöt varastosta tyhjään työtilaan, luoden agenttielementit uudelleen.

Kun konfiguraatiot on palautettu, varmista, että kaikki viitatut Eventhouse (KQL) -tietokannat tai aluekohtaiset tietolähteet ovat saatavilla uudella alueella. Päivitä päätepisteviitteet agenttikonfiguraatioissa tarpeen mukaan. Lopuksi, käynnistä agentit uudelleen ja anna käyttäjien aloittaa uudet keskustelusessiot. Aiempia keskusteluja ei voi jatkaa.

Tapahtumatietokanta

Tässä oppaassa kuvataan tapahtumatietokantakokemuksen palautusmenettelyt.

SQL-tietokanta

Suojautuakseen alueelliselta virheeltä SQL-tietokantojen käyttäjät voivat ryhtyä ennakoiviin toimenpiteisiin ja viedä tietonsa säännöllisesti ja käyttää vietyjä tietoja tietokannan luomiseen uudelleen uudessa työtilassa tarvittaessa.

Tämä voidaan saavuttaa käyttämällä SqlPackage CLI -työkalua, joka tarjoaa tietokannan siirrettävyyden ja helpottaa tietokannan käyttöönottoa.

1. SqlPackage-työkalun avulla voit viedä tietokannan tiedostoon .bacpac . Katso lisätietoja kohdasta Tietokannan vieminen SqlPackagen avulla .
2. Tallenna .bacpac tiedosto suojattuun sijaintiin, joka on eri alueella kuin tietokanta. Esimerkkejä ovat .bacpac-tiedoston tallentaminen Lakehouseen, joka sijaitsee eri alueella, käyttäen georedundanttia Azure-tallennus-tiliä tai käyttämällä toista turvallista tallennusvälinettä, joka sijaitsee eri alueella.
3. Jos SQL-tietokanta ja -alue eivät ole käytettävissä, voit käyttää SqlPackage-tiedostoa .bacpac luodaksesi tietokannan uudelleen työtilassa uudella alueella – työtilassa C2. W2 alueella B yllä olevan skenaarion mukaisesti. Luo tietokanta uudelleen tiedoston kanssa noudattamalla kohdassa .bacpac annettuja ohjeita.

Uudelleen luotu tietokanta on alkuperäisestä tietokannasta riippumaton tietokanta ja heijastaa tietojen tilaa vientitapahtuman aikana.

Vikasietoisuuden huomioon ottamista

Uudelleen luotu tietokanta on itsenäinen tietokanta. Uudelleen luotuun tietokantaan lisätyt tiedot eivät näy alkuperäisessä tietokannassa. Jos aiot palauttaa palautuksen alkuperäiseen tietokantaan, kun kotialue tulee saataville, sinun on harkittava uudelleen luodun tietokannan tietojen manuaalista täsmäyttämistä alkuperäiseen tietokantaan.

Ympäristö

Alusta viittaa taustalla oleviin jaettuihin palveluihin ja arkkitehtuuriin, jotka koskevat kaikkia työkuormia. Tässä osiossa kuvataan palautusmenettelyt jaetuille Fabric-ominaisuuksille.

Työtilan seuranta

Työtilan seuranta kerää lokkeja toiminnasta siinä työtilassa, jossa sen otat käyttöön. Kun palautat työtilasi C2-muodossa. W2, ota työtilan valvonta käyttöön W2:ssa. Se alkaa kerätä seurantatietoja palautetun työtilan osalta.

Datan valvonta alkuperäisestä työtilasta (C1. W1) ei siirry mukanaan, koska valvonta heijastaa sen työtilan toimintaa, jolla se toimii.

Muuttujakirjasto

Microsoft Fabric Variable -kirjastot mahdollistavat kehittäjille tehtäväkonfiguraatioiden mukauttamisen ja jakamisen työtilassa, mikä virtaviivaistaa sisällön elinkaaren hallintaa. Katastrofipalautuksen näkökulmasta muuttujakirjastojen käyttäjien on suojauduttava ennakoivasti alueelliselta katastrofilta. Tämä voidaan tehdä Fabric Git -integraation avulla, joka varmistaa, että alueellisen katastrofin jälkeen käyttäjän muuttujakirjasto pysyy käytettävissä. Muuttujakirjaston palauttamiseksi suosittelemme seuraavaa:

• Käytä Fabric Git -integraatiota synkronoidaksesi Variable-kirjastosi ADO-reposi kanssa. Katastrofin sattuessa voit käyttää arkistoa muuttujakirjaston rakentamiseen uudelleen luomassasi uudessa työtilassa. Toimi seuraavasti:

  1. Yhdistä työtilasi Git-säilöön tässä kuvatulla tavalla.
  2. Varmista, että WS ja säilö on synkronoitu toimituksen ja päivityksen kanssa.
  3. Palautus – Katastrofin sattuessa voit rakentaa muuttujakirjaston uudelleen uudessa työtilassa säilön avulla:

• Uudessa työtilassa yhdistä ja synkronoi uudelleen Azure ADO -repositioosi.

• Kaikki tämän arkiston Fabric-kohteet ladataan automaattisesti uuteen työtilaasi.

• Kun olet synkronoinut kohteet Gitistä, avaa muuttujakirjastot uudessa työtilassa ja valitse manuaalisesti haluamasi aktiivinen arvojoukko.

Asiakkaan hallinnoimat avaimet Fabric-työtiloille

Voit käyttää asiakkaan hallinnoimia avaimia (CMK), jotka on tallennettu Azure Key Vault:iin, lisätäksesi lisäsalauskerroksen Microsoftin hallinnoimien avainten päälle lepotilassa oleville datalle. Jos Fabric muuttuu alueella saavuttamattomaksi tai toimimattomaksi, sen komponentit siirtyvät varmuuskopioinstanssiin. Vikasietoisuuden aikana CMK-ominaisuus tukee vain luku -toimintoja. Niin kauan kuin Azure Key Vault -palvelu pysyy kunnossa ja holvin käyttöoikeudet ovat voimassa, Fabric jatkaa yhteyden muodostamista avaimesi ja antaa sinun lukea dataa normaalisti. Tämä tarkoittaa sitä, että seuraavia toimintoja ei tueta vikasietoisuuden aikana: työtilan CMK-asetuksen ottaminen käyttöön ja poistaminen käytöstä sekä avaimen päivittäminen.

OneLake

Tämä osio opastaa sinua OneLake-ominaisuuksien palautusmenettelyissä. Lisätietoja OneLake-datan katastrofipalautuksesta löytyy kohdasta OneLake disaster recovery.

Elinkaaren hallintakäytännöt

Jos Fabric muuttuu alueella käyttökelvottomaksi tai toimimattomaksi, OneLake-elinkaaren politiikkasi voidaan silti lukea ja päivittää varayhteyden aikana. Kaikki viileälle tai kylmälle tasolle siirretty data jää siihen tasoon. Voit noudattaa näitä vaiheita soveltaaksesi nykyistä käytäntöäsi uuteen palautustyötilaasi:

1. Soita vientipolitiikkaan alkuperäisellä työtilallasi ja tallenna koko elinkaaripolitiikka.
2. Soita Import-politiikkaan palautetulla työtilallasi, ja vienti elinkaaripolitiikka toimii pyyntökappaleena.

Resurssi-instanssisäännöt

Resurssiinstanssisäännöt auttavat sinua turvallisesti hallitsemaan pääsyä OneLakessa luotettavien Azure-resurssien identiteettien avulla. Alueellisen vikasion aikana järjestelmä jatkaa olemassa olevien lukuoikeuksien sääntöjen noudattamista. Kuitenkaan et voi luoda, päivittää tai poistaa resurssiinstanssisääntöjä ennen kuin työtila palaa kirjoitettavaan tilaan.

Liittyvät tiedot

• Microsoft Fabric katastrofipalautusopas