Hanterad katastrofåterställning

Hanterad haveriåterställning (DR) replikerar din Azure Databricks-driftsättning till en sekundär region så att du kan återhämta dig efter ett regionalt avbrott på några minuter. Azure Databricks hanterar replikeringspipelinen, tillståndet för de replikerade katalogerna i den sekundära och redundansprocessen. Du skriver eller underhåller inte replikeringsskript.

För den manuella metoden för katastrofåterställning, inklusive allmänna DR-begrepp och bästa praxis, se Katastrofåterställning.

Important

Hanterad DR är begränsad. Ansök om åtkomst via ditt Azure Databricks-kontoteam. Azure Databricks möjliggör hanterad DR för ditt konto när du har godkänts.

Vad är hanterad katastrofåterställning?

Hanterad dr finns ovanpå de arbetsytor och metaarkiv som du redan använder. Du tar med två Azure Databricks arbetsytor, en i din primära region och en i den sekundära regionen och ett metaarkiv i varje region. Hanterad DR då:

  • Replikerar de kategorier som du väljer att inkludera från den primära till den sekundära enligt ett löpande schema. Båda kategorierna är oberoende valfria: Unity Catalog-metadata och hanterade tabelldata och arbetsytetillgångar som notebook-filer, jobb, SQL-lager, kluster och ACL:er.
  • Tillhandahåller en valfri stabil URL, en enda anslutningssträng som alltid pekar på den aktuella primärnoden, så att klienterna fortsätter att fungera efter en redundansväxling utan omkonfiguration.
  • Gör att du kan utlösa redundans när du vill, för ett DR-test eller ett verkligt avbrott.

Tillgångs-ID:n för arbetsytor bevaras över olika regioner, så URL:er som refererar till en arbetsytetillgång via dess ID fortsätter att fungera efter en redundansväxling.

Vad som replikeras

Managed DR kan replikera följande vid varje replikeringscykel. Båda kategorierna är valfria, så du kan aktivera antingen eller båda:

  • Metadata och data i Unity Catalog: Unity Catalog-hanterade tabeller i Delta Lake med data, externa tabeller och volymer (endast metadata), vyer, funktioner och alla beviljade behörigheter. Katalogens isoleringsläge replikeras. Om källkatalogen är öppen är repliken öppen. Om källan är isolerad och bunden till den primära arbetsytan isoleras repliken och binds till den sekundära arbetsytan.
  • Arbetsytetillgångar: Notebook-filer, jobb, SQL-lager, kluster, utkast till AI/BI-instrumentpaneler, filer och mappar samt deras ACL:er. SQL-lager replikeras i STOPPED tillstånd, kluster i TERMINATED tillstånd. Jobbscheman på den sekundära är pausade.

Ägarskap för replikerade objekt

När hanterad DR skapar ett replikerat skyddat objekt (katalog, schema, tabell, vy, funktion eller volym) i den sekundära miljön är den ursprungliga ägaren Azure Databricks-tjänstens tjänsthuvudnamn som utför replikeringen, eftersom Unity Catalog tilldelar ägarskap till den identitet som skapar objektet. Managed DR överför sedan ägarskapet för repliken så att det matchar ägaren till motsvarande skyddsbara objekt i primärinstansen.

Om ägaren till ett skyddbart objekt i den primära databasen är en användare som har tagits bort från kontot, kan Managed DR inte överföra ägarskapet till en säkerhetsprincipal som inte längre finns. I det här fallet behåller den replikskyddbara tjänstens huvudnamn Azure Databricks som ägare. Åtgärda detta genom att tilldela en giltig ägare till det skyddsbara objektet i den primära miljön och låta DR replikera det.

Requirements

  • En arbetsyta i Premium-planen i både de primära och sekundära regionerna.
  • Tillägget Verksamhetskritisk arbetsyta är aktiverat på båda arbetsytorna. Se Aktivera verksamhetskritisk på båda arbetsytorna.
  • Serverlös beräkning aktiverad på båda arbetsytorna. Serverlös beräkning är tillgänglig som standard på de flesta Unity Catalog-aktiverade arbetsytor. Se Ansluta till serverlös beräkning.
  • Rollen som kontoadministratör med alla behörigheter för varje extern lagringsplats som används av de kataloger som du planerar att replikera.
  • Enkel inloggning på kontonivå med alla arbetsytor aktiverade och identiteter som synkroniserats med kontot via SCIM så att användare, grupper och tjänstens huvudnamn finns i båda regionerna.
  • För stabila URL:er: en anpassad URL som har etablerats för din Azure Databricks domän (kontakta ditt kontoteam) och OAuth på kontonivå.
  • En sekundär arbetsyta och Unity Catalog-metaarkiv i den sekundära regionen, i samma Azure Databricks konto och i samma moln som ditt primära. Den sekundära arbetsytan måste matcha den primäras nätverks-, Private Link- och kundhanterade nyckelkonfiguration. Det sekundära metaarkivet får inte innehålla kataloger som delar namn med replikerade kataloger. För replikering av arbetsytans tillgångar tar Azure Databricks bort alla befintliga tillgångar i omfånget på den sekundära arbetsytan när den inledande replikeringen slutförs. Tillgångar utanför omfånget påverkas inte, så den sekundära arbetsytan behöver inte vara tom.
  • En motsvarande extern plats och lagringsautentisering i den sekundära regionen för var och en av dem som refereras i dina primära kataloger. Hanterad DR replikerar inte externa platser eller lagringsautentiseringsuppgifter automatiskt; du måste skapa dem i den sekundära miljön.

Eftersom den sekundära arbetsytans serverlösa beräkning läser från källlagringen under replikering mellan regioner måste både käll- och sekundärlagringen tillåta Azure Databricks serverlös nätverksåtkomst i båda riktningarna.

Om du begränsar nätverksåtkomsten till källlagringen eller DBFS-roten tillåter du även den sekundära regionens IP-adresser för kontrollplanet i källlagringsbrandväggen och den primära regionens IP-adresser för kontrollplanet i den sekundära DBFS-brandväggen. Information om vilka IP-adresser för kontrollplanet som ska tillåtas i varje region finns i Inkommande till Azure Databricks kontrollplan.

  • En Azure Databricks Access Connector i den sekundära regionen med rollen Storage Blob Data Contributor på de sekundära lagringskontona, som lagts till som lagringsautentiseringsuppgift i den sekundära arbetsytan.
  • En nätverksanslutningskonfiguration (NCC) i den sekundära regionen, tilldelad till den sekundära arbetsytan, så att serverlös beräkning kan nå lagring över privata slutpunkter. Se Konfigurera privat anslutning till Azure-resurser.
  • Privata slutpunkter till varje käll- och sekundärt lagringskonto som refereras av dina replikerade kataloger. För ADLS Gen2-lagring skapar du en privat slutpunkt för både underresurserna dfs och blob på varje konto. Godkänn dem i Azure-portalen.

Aktivera verksamhetskritisk på båda arbetsytorna

Aktivera tillägget Verksamhetskritisk på både dina primära och sekundära arbetsytor innan du skapar en redundansgrupp. På varje arbetsyta där du aktiverar tillägget debiteras användning av beräkningsresurser enligt priset för Mission Critical. Kontakta ditt Azure Databricks kontoteam för den aktuella kursen.

  1. I kontokonsolen klickar du på Arbetsytor och sedan på arbetsytan.
  2. Klicka på fliken Tillägg .
  3. På kortet Verksamhetskritisk slår du på reglaget och bekräftar.

Upprepa för den sekundära arbetsytan.

Valfritt: stabil URL

Azure Databricks rekommenderar att du använder den stabila URL:en. Den stabila URL:en matchar alltid den aktuella primära arbetsytan, så klienter som ansluter via den behöver inte konfigureras om efter en redundansväxling. Den ursprungliga arbetsytans URL är fortfarande giltig för direkt åtkomst till den arbetsytan, men efter en redundansväxling pekar den fortfarande på den gamla primära, nu den sekundära. Peka om följande nedströmsklienter till den stabila URL:en i stället för den ursprungliga URL:en för arbetsytan:

  • Webbgränssnittet för Azure Databricks.
  • JDBC- och ODBC-anslutningar till SQL-lager.
  • Direkta REST API-begäranden.

Stabila URL-adresser stöds med frontenddelen (inkommande) i Private Link. Med inkommande Private Link använder den stabila URL:en din anpassade URL med ett stabilt anslutnings-ID i stället för arbetsytans vanliga URL-format.

Konfigurera replikering

En ny redundansgrupp övergår via CREATING → INITIAL_REPLICATION → ACTIVE. Den första replikeringscykeln kopierar alla data i omfånget till den sekundära. För stora arbetsytor kan den inledande initialiseringen av arbetsytans tillgångar ta upp till två veckor. Den här väntan sker bara en gång. När den första bootstrap har slutförts körs replikeringen kontinuerligt.

Under replikering är sekundära kataloger som omfattas skrivskyddade, och beräkningsresurser är inte tillgängliga i den sekundära arbetsytan. Om du vill köra valideringsfrågor utan att skriva till den sekundära, rekommenderar Azure Databricks en separat skrivskyddad övervakararbetsyta i den sekundära regionen.

Så här skapar du en redundansgrupp:

  1. I kontokonsolen klickar du på Motståndskraft.
  2. Om du planerar att använda en stabil URL klickar du på fliken Stabila URL:er och sedan på Skapa en stabil URL. Ange ett namn, välj den aktuella primära arbetsytan och skapa den stabila URL:en. Låt efterföljande klienter (JDBC, ODBC, Azure Databricks-webbgränssnittet, direkta API-begäranden) använda den stabila URL:en i stället för den ursprungliga arbetsytans URL.
  3. Klicka på fliken Redundansgrupper och sedan på Skapa redundansgrupp.
  4. Fyll i formuläret:
    • Namn på redundansgrupp: Ett namn som du väljer för redundansgruppen.
    • Primär arbetsyta: Den arbetsyta som är din primära.
    • Sekundär arbetsyta: Arbetsytan i den sekundära regionen.
    • Replikera arbetsytetillgångar (valfritt): Inaktivera som standard. Aktivera för att replikera anteckningsböcker, jobb, SQL-datalager, kluster, instrumentpaneler, filer och mappar (och deras ACL:er) från den primära arbetsytan till den sekundära arbetsytan. Kräver att båda arbetsytorna har tillägget Verksamhetskritisk aktiverat. Om du aktiverar replikering av arbetsytetillgångar tas alla befintliga tillgångar som omfattas bort i den sekundära arbetsytan av Azure Databricks när den inledande replikeringen har slutförts. Tillgångar utanför omfånget påverkas inte.
    • Stabil URL (valfritt): Den stabila URL som du skapade i steg 2.
    • Replikeringsomfång: Katalogerna som ska replikeras. Du måste välja en primär arbetsyta innan det här fältet är tillgängligt.
    • Lagringsmappningar: För varje extern plats som dina replikerade kataloger använder i den primära regionen lägger du till en post som mappar dess lagringssökväg till motsvarande externa plats som du skapade i den sekundära regionen (se Krav). Du kan använda * som jokertecken för prefixmatchning.
  5. Klicka på Skapa redundansgrupp.

En Azure lagringsmappning kan till exempel mappa abfss://data@primary.dfs.core.windows.net/* till abfss://data@secondary.dfs.core.windows.net/*.

Resurser som skapats av hanterad DR

När du skapar en redundansväxlingsgrupp etablerar Managed DR ytterligare Unity Catalog-resurser som replikeringspipelinen använder för att kopiera data mellan regioner. I både det primära och det sekundära metastoret skapar hanterad DR:

  • En anslutning som pekar på arbetsytan i den andra regionen.
  • En extern katalog för varje replikerad katalog. Den externa katalogen refererar till motsvarande katalog i den andra regionen.

Dessa resurser visas tillsammans med dina egna kataloger i Katalogutforskaren. Du kan identifiera dem på kommentaren, som anger att Azure Databricks haveriåterställning har skapat och hanterar dem.

Important

Som standard kan endast en metaarkivadministratör ändra eller ta bort dessa resurser. Ta inte bort de anslutningar eller externa kataloger som skapas av hanterad DR. Om du tar bort någon av dem bryts replikeringen för redundansgruppen.

Stabilt arbetsyte-ID

Vissa verktyg identifierar en arbetsyta med dess arbetsyte-ID i stället för dess URL, inklusive Databricks Terraform-providern och Databricks-tillgångspaketen. Varje stabil URL har ett stabilt arbetsyte-ID som matchar den aktuella primära, så dessa verktyg fortsätter att rikta in sig på den aktiva arbetsytan efter en redundansväxling. Använd det stabila arbetsyte-ID:t varhelst ett verktyg ber om ett arbetsyte-ID, på samma sätt som du använder ett vanligt arbetsyte-ID.

Om du vill hitta det stabila arbetsyte-ID:t listar du de stabila URL:erna för ditt konto med Databricks CLI och läser fältet för stable_workspace_id den relevanta stabila URL:en:

databricks api get /api/disaster-recovery/v1/accounts/<account-id>/stable-urls

Distribuera med Databricks-tillgångspaket och Terraform

Databricks Asset Bundles (DAB) och Databricks Terraform-providern riktar in sig på en arbetsyta antingen efter dess värd-URL för arbetsytan eller genom en kombination av den anpassade URL:en för Azure Databricks-kontot och arbetsytans ID. Om du vill fortsätta att distribuera till den aktuella primära resursen efter en redundansväxling anger du värden till din anpassade URL – värddelen av den stabila URL:en, inte den ursprungliga URL:en per arbetsyta – och anger det stabila arbetsyte-ID: t i workspace_id fältet. Tillsammans matchar de den aktuella primära, så dina CI/CD-pipelines fortsätter att distribueras till den aktiva arbetsytan efter en redundansväxling, utan någon konfigurationsändring.

  • Nya distributioner: Använd den anpassade URL:en och ett stabilt arbetsyte-ID från den första distributionen.
  • Befintliga distributioner: Importera tillståndet från ditt tidigare Terraform-projekt till ett nytt projekt som konfigurerats med den anpassade URL:en och ett stabilt arbetsyte-ID och ta sedan bort det tidigare projektet. Placera inte ett befintligt projekt på plats igen – distributionen identifierar inte längre de resurser som skapades mot den ursprungliga URL:en per arbetsyta, så en omdistribution förstör och återskapar dem.
  • DABs: aktivera replikering av arbetsytetillgångar för redundansgruppen. Ett paket lagrar sitt distributionstillstånd i arbetsytan, och detta tillstånd når den nya primära noden endast som en del av replikeringen av arbetsytans resurser.

Note

Efter en växling vid fel återskapar den första omdistributionen alla resurser som hanterad DR inte replikerar, eftersom de inte finns på den nya primära noden. Replikerade resurser finns kvar. Se Begränsningar för vad hanterad dr gör och inte replikerar.

Övervaka replikering

Fliken Redundansgrupper visar varje redundansgrupps aktuella tillstånd, replikeringspunkt och eventuella aktiva fel. Möjliga tillstånd:

State Meaning
CREATING Redundansgruppen etableras.
INITIAL_REPLICATION Den första replikeringscykeln pågår. Redundansväxling är inte tillgänglig ännu.
ACTIVE Replikeringen är i stabilt tillstånd. Redundansväxling är tillgänglig.
FAILING_OVER En redundansväxling pågår.
FAILOVER_FAILED, CREATION_FAILED, DELETION_FAILED Åtgärden slutfördes inte. Se statusinformationen för redundansgruppen för att få vägledning.

Välj namnet på en redundansgrupp för att öppna informationssidan. Replikeringen körs kontinuerligt, men replikeringspunkten visar den senaste gången alla resurser i omfånget kopierades tillsammans. Enskilda resurser kan vara mer aktuella, men inte alla data efter replikeringspunkten kan finnas i den sekundära och kan gå förlorade under redundansväxlingen.

När en replikationspunkt visas har allt som inte täcks av ett fel replikerats fram till den punkten. Under den inledande replikeringen, innan den första replikeringspunkten har skapats, kan failovergruppen fortfarande visa blockerande fel, men den mäter ännu inte fullständigheten. Tillgångstyper som hanterad DR inte stödjer alls visas inte i system.replication.states systemtabellen. Se Begränsningar. För att verifiera en specifik tillgång, inspektera den i sekundären (se Sätt upp replikering).

Om du vill övervaka historiska RPO-trender och se de fel som blockerar replikeringen, kör du en fråga mot systemtabellen system.replication.states. Se Tabellreferens för replikeringssystem. De vanligaste felklasserna och hur du löser dem finns i Referens.

Automatisk omkoppling och återkoppling

Samma procedur omfattar planerade redundansväxlingar (DR-tester, schemalagt underhåll) och oplanerade redundansväxlingar (ett regionalt avbrott). Om du vill återställa igen upprepar du proceduren med de omvända regionerna.

När du utlöser en redundansväxling i Azure Databricks:

  • Pekar den stabila URL:en, om den är kopplad, till den nya primära regionen.
  • Ändrar replikeringsriktningen.
  • Pausar jobbscheman i den tidigare primära.
  • Överför redundansgruppen från FAILING_OVER till INITIAL_REPLICATION.

Så här växlar du över vid fel:

  1. Meddela ditt team att en redundans startar.

  2. Endast för en planerad redundans:

    1. På den primära arbetsytan avslutar du alla kluster som körs och stoppar alla SQL-lager.
    2. Kontrollera att skrivningarna till primärnoden har upphört och vänta sedan på att replikeringen ska komma ikapp. För att kontrollera detta öppnar du redundansväxlingsgruppens detaljsida och bekräftar att replikeringspunkten ligger inom några sekunder från tidpunkten då du stoppade skrivningar.

  3. I kontokonsolen klickar du på Resiliens → redundansgrupper och sedan på redundansgruppens namn.

  4. Klicka på Växla över.

  5. Välj den nya primära regionen och bekräfta. Failoveren är klar på några minuter.

  6. Starta den beräkning som kördes före redundansväxlingen i den nya primära. Replikerade kluster och SQL-datalager hamnar på den nya primära noden i tillstånden TERMINATED respektive STOPPED.

  7. Återuppta de jobbscheman som du behöver i den nya primära tjänsten manuellt. Schemaläggningarna för den tidigare primära är redan pausade.

Klienter som är anslutna via den stabila URL:en fortsätter att fungera efter redundansväxlingen. Peka om de klienter som fortfarande använder URL:en för den ursprungliga arbetsytan till antingen den stabila URL:en eller URL:en för den nya primära arbetsytan.

Important

Vid en oplanerad redundansväxling kan data som skrivits till den primära efter det senaste replikeringstillfället gå förlorade. Kontrollera att all eventuell förlust ryms inom ditt RPO-mål.

Tip

Testa redundans regelbundet, till exempel en gång per kvartal, så att ditt team är bekant med proceduren före ett verkligt avbrott.

Avveckla hanterad DR

  1. I kontokonsolen klickar du på Resiliens → redundansgrupper, klickar sedan på redundansgruppens namn och tar bort den. Du kan inte inaktivera Verksamhetskritisk när en redundansgrupp är aktiv på arbetsytan.
  2. Om du vill stoppa faktureringen enligt Mission Critical-taxan stänger du av Mission Critical för varje arbetsyta på fliken Tillägg.

Limitations

Managed DR har följande begränsningar:

  • Replikeras inte: materialiserade vyer, streamingtabeller, Lakeflow-pipelines, data i hanterade volymer (metadata replikeras), hemligheter i Unity Catalog och arbetsytan, ML-modeller, slutpunkter för modellservering, vektorsökningsindex, Delta-delningar, publicerade AI/BI-dashboards (utkast replikeras) och Spark Structured Streaming utanför Lakeflow-pipelines. Tabeller med radfilter eller kolumnmaskering och ABAC-taggade resurser markeras som Det gick inte att replikera i systemtabellen, och dessa misslyckanden fördröjer uppnåendet av RPO tills du tar bort resursen från det som redundansgruppen omfattar.
  • Hanterade tabellskrivningar från externa motorer har begränsad identifieringsbarhet. Hanterad DR upptäcker ändringar i Unity Catalog-hanterade tabeller vid skrivningar som utförs av Azure Databricks-beräkningsresurser. Skrivningar till en replikerad hanterad tabell från en extern (icke-Azure Databricks-)motor via öppna API:er, till exempel Iceberg REST Catalog, kanske inte upptäcks. Därför kanske dessa skrivningar inte replikeras till den sekundära repliken och kan gå förlorade vid redundansväxling. För tabeller som du replikerar med hanterad DR skriver du via Azure Databricks beräkning.
  • Sekundära kataloger som omfattas är skrivskyddade. Skrivskydd gäller bara för replikerade entiteter. Du kan fortfarande konfigurera din egen replikering för skyddsbara värden utanför det hanterade DR-omfånget. Du kan dock inte köra beräkningar på den sekundära arbetsytan medan hanterad DR är aktiverad, vilket begränsar möjligheten att driva en egen replikeringspipeline där.
  • Att byta namn på ett säkerhetsobjekt i Unity Catalog leder till att det tas bort och återskapas i den sekundära. För hanterade tabeller replikerar namnbytet tabelldata på nytt i nästa cykel. Undvik att ändra namn under steady state-replikering.
  • UNDROP propageras inte till den sekundära noden.
  • Den inledande initieringen av arbetsytans resurser kan ta upp till två veckor för stora arbetsytor.
  • Att använda arbetsytans lagringsbrandvägg på de lagringskonton för arbetsytan som används med hanterad DR kräver manuell konfiguration. Du måste tillåta relevanta IP-adresser för kontrollplanet i lagringsbrandväggen så att Azure Databricks kan replikera data. Se kraven.

Reference

När en resurs inte kan replikeras visar redundansgruppen en felklass i systemtabellen system.replication.states , tillsammans med ett meddelande som identifierar den berörda resursen. Följande avsnitt beskriver de vanligaste felklasserna och hur du löser dem. Replikeringen återställs automatiskt när du har korrigerat det underliggande problemet.

DR_MISSING_DEPENDENCY

En tillgång refererar till ett beroende som inte finns i den sekundära, så tillgången kan inte replikeras. Underklassen identifierar den saknade beroendetypen och visas som DR_MISSING_DEPENDENCY.CATALOG, .SCHEMA, .TABLEeller .RESOURCE. Resolutionen är densamma för dem alla.

  1. Kontrollera om resursen också är trasig i den primära miljön på grund av det saknade beroendet. Om så är fallet kan du åtgärda eller ta bort tillgången i den primära.
  2. Om tillgången är giltig i den primära är beroendet antingen inte i replikeringsomfånget för någon redundansgrupp, eller så finns den i omfånget för den här eller en annan redundansgrupp men kunde inte replikeras. Om beroendet inte omfattas av omfånget redigerar du redundansgruppens replikeringsomfång så att det också replikeras. Om beroendet redan omfattas, kontrollera system.replication.states för det fel som blockerar dess replikering och åtgärda det felet.
DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

Hanterad dr bestämmer var varje replikerad tillgång ska placeras genom att redundansgruppens lagringsmappningar tillämpas på tillgångens källlagringsplats. En mappning matchar en plats exakt, eller som ett prefix som även omfattar underordnade sökvägar. Det här felet innebär att ingen mappning omfattar en källlagringsplats, så hanterad dr kan inte avgöra var i sekundären tillgången ska placeras. För externa tabeller och volymer innebär en saknad mappning att samma plats-URI används på den primära och sekundära platsen. storage_location i meddelandet är den omappade källsökvägen.

  1. I kontokonsolen går du till Resilience → Redundansgrupper och redigerar redundansgruppen.
  2. Under Lagringsmappningar lägger du till eller breddar en mappning så att den täcker källplatsen i meddelandet. Om du vill omfatta underordnade sökvägar mappar du en överordnad sökväg och lägger till suffixet /* för prefixmatchning. Se lagringsmappningar.
  3. Kontrollera att en extern plats i det sekundära metadatalagret redan täcker mappningens målsökväg. Redundansgruppen avvisar en mappning vars mål inte finns på en befintlig extern plats, så skapa den externa platsen först om den inte finns. Se Ansluta till molnobjektlagring med Unity Catalog.
DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION

En lagringsmappning mappade en replikerad resurs till en målsökväg i den sekundära metastoren, men ingen extern plats i den sekundära metastoren omfattar den sökvägen, så Unity Catalog har ingenstans att placera resursens data. storage_location i meddelandet är den otäckta sekundära målsökvägen.

Detta innebär vanligtvis en av följande två saker: en extern plats som tidigare täckte sökvägen togs bort eller snävades in, eller så pekar en nyligen replikerad resurs på en sekundär sökväg som ingen extern plats täcker. Det andra fallet inträffar till exempel när du skapar en extern tabell i den primära under en lagringssökväg som ingen av dina lagringsmappningar omfattar. Managed DR återgår då till tabellens ursprungliga sökväg, som ingen extern lagringsplats i det sekundära metastore täcker, så data har ingenstans att hamna.

  1. Identifiera den otäckta sekundära sökvägen i meddelandets storage_location.
  2. Bestäm vilken extern plats i det sekundära metaarkivet som ska omfatta den sökvägen: en befintlig extern plats som du utökar eller en ny som du skapar.
  3. Justera antingen redundansgruppens lagringsmappningar så att sökvägen matchas under en extern plats som redan finns, eller skapa den externa platsen (med dess lagringsautentiseringsuppgifter) och utöka mappningen så att den pekar på den. Se Ansluta till molnobjektlagring med Unity Catalog.
DR_INTERNAL_ERROR

Ett fel på systemsidan inträffade under replikeringen. Ingen åtgärd krävs. systemet återställs automatiskt. Kontakta Azure Databricks support om problemet inte löser sig på egen hand.

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

Managed DR replikerar vyn tillsammans med dess behörigheter, men en vy som refererar till objekt i andra kataloger kräver också att dess ägare har åtkomst till dessa refererade objekt i den sekundära miljön, eftersom vyn körs med ägarens behörigheter. Det här felet innebär att ägaren saknar den åtkomsten på den sekundära, så du måste bevilja den för de refererade objekten där.

  1. Hitta objekten som vyn refererar till och vyns ägare. Refererade objekt visas som fullständiga catalog.schema.object-namn i definitionen; behörigheter måste beviljas ägaren, vilket du också kan se i fältet Owner i Catalog Explorer.

    SHOW CREATE TABLE <catalog>.<schema>.<view>;

  2. På den sekundära noden kontrollerar du ägarens aktuella behörigheter för varje objekt som refereras. För att kunna läsa en tabell krävs USE CATALOG i katalogen, USE SCHEMA i schemat och SELECT i tabellen.

    SHOW GRANTS `<view_owner>` ON CATALOG <ref_catalog>;
SHOW GRANTS `<view_owner>` ON SCHEMA <ref_catalog>.<ref_schema>;
SHOW GRANTS `<view_owner>` ON TABLE <ref_catalog>.<ref_schema>.<ref_table>;

  3. Ge vyägaren eventuella behörigheter som saknas för varje refererat objekt.

    GRANT USE CATALOG ON CATALOG <ref_catalog> TO `<view_owner>`;
GRANT USE SCHEMA ON SCHEMA <ref_catalog>.<ref_schema> TO `<view_owner>`;
GRANT SELECT ON TABLE <ref_catalog>.<ref_schema>.<ref_table> TO `<view_owner>`;

  4. Bekräfta att alla kataloger som vyreferenserna ingår i replikeringsomfånget för en redundansgrupp, så att de också finns i den sekundära.

Mer information finns i Hantera privilegier i Unity Catalog.

DR_INVALID_CONFIGURATION.NETWORK_UNAUTHORIZED_ACCESS

Under replikering av tabelldata mellan regioner läser den sekundära arbetsytans serverlösa beräkning data från källlagringen och lagringen nekade nätverksanslutningen: en lagringsbrandvägg eller nätverksregel blockerade den eller en obligatorisk privat slutpunkt saknas eller godkänns inte.

Kontrollera att källan och den sekundära lagringen tillåter Azure Databricks serverlös nätverksåtkomst enligt beskrivningen i Krav.

DR_INVALID_CONFIGURATION.SERVERLESS_COMPUTE_PERMISSION

Hanterad DR använder serverlös datorkraft i den sekundära arbetsytan för att kopiera data, och serverlös datorkraft är inte tillåten där. Det innebär vanligtvis att serverless är inaktiverat för kontot eller arbetsytan, eller att arbetsytan inte är kvalificerad.

  1. Bekräfta att den sekundära arbetsytan är berättigad. Serverlös beräkning är som standard tillgänglig i Unity Catalog-aktiverade arbetsytor i en region som stöds. Se Ansluta till serverlös beräkning.
  2. Sök efter ett kontoomfattande undantag. I kontokonsolen går du till Inställningar → Funktionsaktivering och kontrollerar om den serverlösa växlingsknappen finns och inaktiveras.
  3. Aktivera serverlös för det omfång du behöver. För att aktivera alla arbetsytor som uppfyller kraven slår en kontoadministratör på växeln för serverlös på kontonivå. Om du endast vill aktivera den sekundära arbetsytan lämnar du växlingsknappen på kontonivå avstängd och låter en arbetsyteadministratör aktivera serverless under arbetsytans Förhandsversioner.
  4. Om ingen växlingsknapp är tillgänglig eller om serverlös fortfarande inte körs när du har aktiverat den kontaktar du ditt Azure Databricks kontoteam.
DR_INVALID_CONFIGURATION.OVERLAPPING_EXTERNAL_LOCATIONS

När hanterad DR skapar ett replikerat objekt på den mappade målsökvägen i den sekundära miljön avvisar Unity Catalog sökvägen eftersom den överlappar med lagring som redan finns där, till exempel en befintlig extern lagringsplats, ett kvarlämnat skyddat objekt från en tidigare eller partiell konfiguration, en hanterad plats eller arbetsytans standardlagring (DBFS).

  1. Identifiera vad som upptar sökvägen.

    I Katalogutforskaren granskar du dina externa platser, hanterade lagringsplatser och externa tabeller och volymer för att hitta objektet vars sökväg täcker eller överlappar målsökvägen.

  2. Om det motstridiga objektet inte ska äga sökvägen tar du bort den. En vanlig orsak är en kvarvarande extern tabell eller extern volym från en tidigare installation; ta bort den om den inte längre behövs. Om det är en extern plats som inte ska täcka sökvägen tar du bort eller omdefinierar den.

  3. Annars pekar du om redundansgruppens lagringsmappning till en dedikerad, icke-överlappande målsökväg. Föredra en specifik undersökväg framför en bred bucketrot och undvik arbetsytans standardlagring (DBFS).

DR_UNSUPPORTED_FEATURE

Resursen använder en funktion som inte kan replikeras av hanterad DR. Underklassen identifierar funktionen som inte stöds och visas till exempel som DR_UNSUPPORTED_FEATURE.ABAC_POLICY. Det finns två sätt att lösa det här felet.

  1. Ta bort funktionen som inte stöds från tillgången på den primära arbetsytan.
  2. Om du inte kan ta bort funktionen, överväg att ta bort resursen från redundansgruppens replikeringsomfång.

Dr-begrepp och metodtips finns i Haveriberedskap.

  • Last updated on