Beheerd herstel na noodgevallen

Met managed disaster recovery (DR) wordt uw Azure Databricks-implementatie gerepliceerd naar een secundaire regio, zodat u binnen enkele minuten kunt herstellen na een regionale storing. Azure Databricks beheert de replicatiepijplijn, de status van de gerepliceerde catalogi in de secundaire catalogus en het failoverproces. U schrijft of onderhoudt geen replicatiescripts.

Voor de handmatige benadering van herstel na noodgevallen, inclusief algemene concepten en best practices voor herstel na noodgevallen, raadpleegt u Herstel na noodgevallen.

Important

Beheerde DR is afgeschermd. Aanvragen voor toegang via uw Azure Databricks accountteam. Azure Databricks schakelt beheerd noodherstel voor uw account in nadat u bent toegelaten.

Wat is beheerde disaster recovery?

Beheerde disaster recovery bouwt voort op de workspaces en metastores die u al beheert. U hebt twee Azure Databricks-werkruimtes, één in uw primaire regio en één in uw secundaire regio, en een metastore in elke regio. Beheerd disaster recovery toen:

  • Repliceert de categorieën waarvoor u kiest van de primaire naar de secundaire, op doorlopende basis. Beide categorieën zijn onafhankelijk optioneel: Metagegevens van Unity Catalog en beheerde tabelgegevens, en werkruimteassets zoals notebooks, taken, SQL-magazijnen, clusters en ACL's.
  • Biedt een optionele stabiele URL, één verbindingsreeks die altijd verwijst naar de huidige primaire, zodat clients blijven werken na een failover zonder opnieuw te configureren.
  • Hiermee kunt u failover activeren wanneer u wilt, voor een DR-test of een echte storing.

De ID's van werkruimte-assets blijven in alle regio's behouden, dus URL's die met een ID naar een werkruimte-asset verwijzen, worden na een failover nog steeds correct opgelost.

Wat wordt gerepliceerd

Beheerde DR kan het volgende repliceren tijdens elke replicatiecyclus. Beide categorieën zijn optioneel, zodat u beide of beide kunt inschakelen:

  • Unity Catalog-metagegevens en -gegevens: beheerde tabellen in Unity Catalog in Delta Lake met gegevens, externe tabellen en volumes (alleen metagegevens), weergaven, functies en alle machtigingen. De isolatiemodus van de catalogus wordt gerepliceerd. Als de broncatalogus is geopend, is de replica geopend. Als de bron is geïsoleerd en is gebonden aan de primaire werkruimte, wordt de replica geïsoleerd en gebonden aan de secundaire werkruimte.
  • Assets van de werkruimte: Notebooks, jobs, SQL-warehouses, clusters, concept-AI/BI-dashboards, bestanden en mappen, samen met hun ACL's. SQL-warehouses worden gerepliceerd in STOPPED staat, clusters in TERMINATED staat. Taakplanningen in de secundaire worden onderbroken.

Eigendom van gerepliceerde objecten

Wanneer beheerde disaster recovery een gerepliceerd beveiligbaar object (catalogus, schema, tabel, weergave, functie of volume) maakt in de secundaire omgeving, is de oorspronkelijke eigenaar de Azure Databricks-service-principal die de replicatie uitvoert, omdat Unity Catalog het eigendom toewijst aan de identiteit die het object maakt. Beheerd DR draagt vervolgens het eigendom van de replica over, zodat de replica dezelfde eigenaar krijgt als het bijbehorende beveiligbare object in de primaire omgeving.

Als de eigenaar van een beveiligbaar object in de primaire database een gebruiker is die uit het account is verwijderd, kan beheerd noodherstel het eigenaarschap niet overdragen aan een beveiligingsprincipal die niet meer bestaat. In dit geval heeft het beveiligbare replica-object de Azure Databricks-service-principal als eigenaar. Om dit op te lossen, wijst u een geldige eigenaar toe aan het beveiligbare object in het primaire systeem en laat u DR dit repliceren.

Requirements

  • Een werkruimte in het Premium-abonnement in zowel de primaire als de secundaire regio's.
  • De Mission Critical-add-on is ingeschakeld voor beide werkruimten. Zie Bedrijfskritiek inschakelen voor beide werkruimten.
  • Serverloze rekenkracht ingeschakeld voor beide werkruimten. Serverloze rekenkracht is standaard beschikbaar in de meeste werkruimten met Unity Catalog. Zie Verbinding maken met serverloze berekeningen.
  • Rol van accountbeheerder met ALLE BEVOEGDHEDEN voor elke externe locatie die wordt gebruikt door de catalogussen die u wilt repliceren.
  • SSO op accountniveau, ingeschakeld voor alle werkruimten, en identiteiten die via SCIM naar het account zijn gesynchroniseerd, zodat gebruikers, groepen en serviceprincipals in beide regio's bestaan.
  • Voor stabiele URL's: een aangepaste URL die is ingericht voor uw Azure Databricks-domein (neem contact op met uw accountteam) en OAuth op accountniveau.
  • Een secundaire werkruimte en Unity Catalog-metastore in de secundaire regio, in hetzelfde Azure Databricks-account en in dezelfde cloud als uw primaire. De secundaire werkruimte moet overeenkomen met het primaire netwerk, Private Link en door de klant beheerde sleutelconfiguratie. De secundaire metastore mag geen catalogi bevatten die namen delen met gerepliceerde catalogi. Voor replicatie van werkruimteassets verwijdert Azure Databricks alle bestaande assets binnen het bereik in de secundaire werkruimte wanneer de initiële replicatie is voltooid. Assets buiten het bereik worden niet beïnvloed, dus de secundaire werkruimte hoeft niet leeg te zijn.
  • Een bijbehorende externe locatie en opslagreferentie in de secundaire regio voor elke locatie waarnaar wordt verwezen door uw primaire catalogi. Beheerd noodherstel repliceert externe locaties of opslagaanmeldgegevens niet automatisch; u moet deze in de secundaire omgeving aanmaken.

Omdat de serverloze berekeningen van de secundaire werkruimte tijdens replicatie tussen regio's worden gelezen uit de bronopslag, moeten zowel de bron- als de secundaire opslag Azure Databricks serverloze netwerktoegang in beide richtingen toestaan.

Als u de netwerktoegang tot de bronopslag of de DBFS-hoofdmap beperkt, moet u ook de IP-adressen van het besturingsvlak van de secundaire regio toestaan in de firewall van de bronopslag, en de IP-adressen van het besturingsvlak van de primaire regio in de firewall van de secundaire DBFS. Zie Inkomend verkeer naar het Azure Databricks-beheervlak voor de IP-adressen van het beheervlak die in elke regio moeten worden toegestaan.

  • Een Azure Databricks Access Connector in de secundaire regio met de rol Inzender van blobgegevens voor opslag voor de secundaire opslagaccounts, toegevoegd als opslagreferentie in de secundaire werkruimte.
  • Een netwerkconnectiviteitsconfiguratie (NCC) in de secundaire regio, toegewezen aan de secundaire werkruimte, zodat serverloze berekeningen opslag kunnen bereiken via privé-eindpunten. Zie Privéconnectiviteit met Azure-resources configureren.
  • Privé-eindpunten naar alle bron- en secundaire opslagaccounts waarnaar uw gerepliceerde catalogi verwijzen. Voor ADLS Gen2-opslag maakt u een privé-eindpunt voor zowel de dfs als blob subbronnen voor elk account. Keur ze goed in de Azure-portal.

Bedrijfskritiek inschakelen voor beide werkruimten

Schakel de invoegtoepassing Mission Critical in op zowel uw primaire als secundaire werkruimten voordat u een failovergroep maakt. Rekengebruik voor elke werkruimte waarin u de invoegtoepassing inschakelt, wordt gefactureerd met het bedrijfskritieke tarief. Neem contact op met uw Azure Databricks accountteam voor het huidige tarief.

  1. Klik in de accountconsole op Werkruimten en klik vervolgens op de werkruimte.
  2. Klik op het tabblad Invoegtoepassingen .
  3. Schakel op de kaart Mission Critical de schakelaar in en bevestig.

Herhaal dit voor de secundaire werkruimte.

Optioneel: stabiele URL

Azure Databricks raadt het gebruik van de stabiele URL aan. De stabiele URL wordt altijd omgezet in de huidige primaire werkruimte, zodat clients die er verbinding mee maken niet opnieuw hoeven te worden geconfigureerd na een failover. De oorspronkelijke werkruimte-URL blijft geldig voor directe toegang tot die werkruimte, maar na een failover blijft deze verwijzen naar de oude primaire, nu de secundaire. Wijs de volgende downstream-clients aan op de stabiele URL in plaats van de oorspronkelijke werkruimte-URL:

  • De Azure Databricks webgebruikersinterface.
  • JDBC- en ODBC-verbindingen met SQL-warehouses.
  • Directe REST API-aanvragen.

Stabiele URL's worden ondersteund met front-end (inkomend) Private Link. Bij binnenkomende Private Link gebruikt de stabiele URL uw aangepaste URL met een stabiele verbindings-id in plaats van de standaardindeling van de werkruimte-URL.

Replicatie instellen

Een nieuwe failovergroep gaat over naar CREATING → INITIAL_REPLICATION → ACTIVE. De eerste replicatiecyclus kopieert alle gegevens binnen het bereik naar de secundaire. Voor grote werkruimten kan de initiële initialisatie van de assets van de werkruimte tot twee weken duren. Deze wachttijd is eenmalig. Nadat de eerste bootstrap is voltooid, wordt de replicatie continu uitgevoerd.

Tijdens replicatie zijn secundaire catalogi binnen het bereik alleen-lezen en is rekenkracht niet beschikbaar in de secundaire werkruimte. Als u validatiequery's wilt uitvoeren zonder naar de secundaire regio te schrijven, raadt Azure Databricks een afzonderlijke monitorwerkruimte met alleen-lezen toegang in de secundaire regio aan.

Een failovergroep maken:

  1. Klik in de accountconsole op Tolerantie.
  2. Als u van plan bent een stabiele URL te gebruiken, klikt u op het tabblad Stabiele URL's en vervolgens op Stabiele URL maken. Voer een naam in, selecteer de huidige primaire werkruimte en maak de stabiele URL. Wijs downstream-clients (JDBC, ODBC, de Azure Databricks-webgebruikersinterface, rechtstreekse API-aanvragen) naar de stabiele URL in plaats van naar de oorspronkelijke werkruimte-URL.
  3. Klik op het tabblad Failovergroepen en vervolgens op Failovergroep maken.
  4. Vul het formulier in:
    • Naam van failovergroep: een naam die u kiest voor de failovergroep.
    • Primaire werkruimte: de werkruimte die uw primaire werkruimte is.
    • Secundaire werkruimte: de werkruimte in de secundaire regio.
    • Resources van de werkruimte repliceren (optioneel): Standaard uitgeschakeld. Schakel dit in om notebooks, taken, SQL-magazijnen, clusters, dashboards, bestanden en mappen (en hun ACL's) van de primaire naar de secundaire te repliceren. Vereist dat in beide werkruimtes de invoegtoepassing Mission Critical is ingeschakeld. Als u replicatie van assets in de werkruimte inschakelt, verwijdert Azure Databricks alle bestaande assets die binnen het bereik vallen in de secundaire omgeving wanneer de initiële replicatie is voltooid. Assets buiten het bereik worden niet beïnvloed.
    • Stabiele URL (optioneel): de stabiele URL die u in stap 2 hebt gemaakt.
    • Replicatiebereik: de catalogi die moeten worden gerepliceerd. U moet een primaire werkruimte selecteren voordat dit veld beschikbaar is.
    • Opslagtoewijzingen: Voor elke externe locatie die uw gerepliceerde catalogi gebruiken in de primaire regio, voegt u een vermelding toe die het opslagpad toe wijst aan de bijbehorende externe locatie die u in de secundaire regio hebt gemaakt (zie Vereisten). U kunt dit als jokerteken gebruiken * voor het vergelijken van voorvoegsels.
  5. Klik op Failovergroep maken.

Een Azure-opslagtoewijzing kan bijvoorbeeld abfss://data@primary.dfs.core.windows.net/* koppelen aan abfss://data@secondary.dfs.core.windows.net/*.

Resources die zijn gemaakt door beheerd noodherstel

Wanneer u een failovergroep maakt, richt beheerd noodherstel aanvullende Unity Catalog-resources in die de replicatiepijplijn gebruikt om gegevens tussen regio's te kopiëren. In zowel de primaire als de secundaire metastore zorgt beheerd noodherstel voor het volgende:

  • Een verbinding die verwijst naar de werkruimte in de andere regio.
  • Een externe catalogus voor elke gerepliceerde catalogus. De externe catalogus verwijst naar de bijbehorende catalogus in de andere regio.

Deze resources worden samen met uw eigen catalogi weergegeven in Catalog Explorer. U kunt ze herkennen aan hun opmerking, waarin staat dat ze zijn gemaakt en worden beheerd door Azure Databricks-noodherstel.

Important

Standaard kan alleen een metastore-beheerder deze resources wijzigen of verwijderen. Verwijder niet de verbindingen of externe catalogi die door beheerde DR worden aangemaakt. Als u een van beide verwijdert, wordt de replicatie voor de failovergroep verbroken.

Stabiele werkruimte-ID

Sommige hulpprogramma's identificeren een werkruimte op basis van de werkruimte-id in plaats van de URL, waaronder de Databricks Terraform-provider en Databricks Asset Bundles. Elke stabiele URL heeft een stabiele werkruimte-id die wordt omgezet in de huidige primaire, zodat deze hulpprogramma's zich blijven richten op de actieve werkruimte na een failover. Gebruik de stabiele werkruimte-id waar een hulpprogramma om een werkruimte-id vraagt, op dezelfde manier als u een normale werkruimte-id zou gebruiken.

Als u de stabiele werkruimte-id wilt vinden, vermeldt u de stabiele URL's voor uw account met de Databricks CLI en leest u het stable_workspace_id veld van de relevante stabiele URL:

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

Implementeren met Databricks Asset Bundles en Terraform

Databricks Asset Bundles (DABs) en de Databricks Terraform-provider richten zich op een werkruimte op de host-URL van de werkruimte of op een combinatie van de aangepaste URL van het Azure Databricks-account en de werkruimte-id. Als u wilt blijven implementeren op de huidige primaire na een failover, stelt u de host in op uw aangepaste URL ( het hostgedeelte van de stabiele URL, niet de oorspronkelijke URL per werkruimte) en geeft u de stabiele werkruimte-id in het workspace_id veld op. Samen worden ze omgezet in de huidige primaire, zodat uw CI/CD-pijplijnen na een failover blijven implementeren in de actieve werkruimte, zonder configuratiewijziging.

  • Nieuwe implementaties: gebruik de aangepaste URL en de stabiele werkruimte-id van de eerste implementatie.
  • Bestaande implementaties: importeer de status van uw vorige Terraform-project in een nieuw project dat is geconfigureerd met de aangepaste URL en de stabiele werkruimte-id, en verwijder vervolgens het vorige project. Wijs een bestaand project niet opnieuw aan. De implementatie herkent niet langer de resources die zijn gemaakt op basis van de oorspronkelijke URL per werkruimte, zodat een herimplementatie ze vernietigt en opnieuw maakt.
  • DABs: schakel replicatie van de assets van de werkruimte in op de failovergroep. Een bundel slaat de implementatiestatus in de werkruimte op en die status bereikt de nieuwe primaire alleen als onderdeel van de replicatie van werkruimteassets.

Note

Na een failover worden bij de eerste herimplementatie alle resources opnieuw gemaakt die door beheerd noodherstel niet worden gerepliceerd, omdat ze niet bestaan op de nieuwe primaire omgeving. Gerepliceerde resources blijven aanwezig. Zie Beperkingen voor wat beheerde DR wel en niet repliceert.

Replicatie controleren

Op het tabblad Failovergroepen ziet u de huidige status, het replicatiepunt en eventuele actieve fouten van elke failovergroep. Mogelijke statussen:

State Meaning
CREATING De failovergroep wordt ingericht.
INITIAL_REPLICATION De eerste replicatiecyclus wordt uitgevoerd. Failover is nog niet beschikbaar.
ACTIVE Replicatie heeft een stabiele status. Failover is beschikbaar.
FAILING_OVER Er wordt een failover uitgevoerd.
FAILOVER_FAILED, CREATION_FAILED, DELETION_FAILED De bewerking is niet voltooid. Controleer de statusdetails van de failovergroep voor meer informatie.

Selecteer de naam van een failovergroep om de detailpagina te openen. Replicatie wordt continu uitgevoerd, maar het replicatiepunt toont het laatste moment waarop alle resources die binnen het bereik vallen tegelijk zijn gekopieerd. Afzonderlijke resources zijn mogelijk actueler, maar niet alle gegevens na het replicatiepunt zijn mogelijk aanwezig in de secundaire omgeving en kunnen verloren gaan tijdens een failover.

Als u historische RPO-trends wilt bewaken en de fouten wilt zien die replicatie blokkeren, voert u een query uit op de system.replication.states systeemtabel. Zie Naslaginformatie voor replicatiesysteemtabellen. Zie Naslaginformatie voor de meest voorkomende foutklassen en hoe u deze kunt oplossen.

Failover en failback

Dezelfde procedure omvat geplande failovers (DR-tests, gepland onderhoud) en ongeplande failovers (een regionale storing). Als u een failback wilt uitvoeren, herhaalt u de procedure met de regio's omgekeerd.

Wanneer u een failover activeert, Azure Databricks:

  • Verwijst de stabiele URL, indien gekoppeld, aan de nieuwe primaire regio.
  • Hiermee wordt de richting van replicatie omgekeerd.
  • Onderbreekt taakplanningen in de vorige primaire.
  • Hiermee wordt de failovergroep overgezet van FAILING_OVER naar INITIAL_REPLICATION.

Overschakelen naar het reservesysteem:

  1. Informeer uw team dat er een failover wordt gestart.

  2. Alleen voor een geplande failover:

    1. Beëindig alle actieve clusters in de primaire werkruimte en stop alle SQL-warehouses.
    2. Controleer of schrijfbewerkingen naar de primaire zijn gestopt en wacht vervolgens tot de replicatie is bijgewerkt. U kunt dit controleren door de detailpagina van de failovergroep te openen en te bevestigen dat het replicatiepunt binnen een paar seconden na het stoppen van schrijfbewerkingen ligt.

  3. Klik in de accountconsole op Resilience → Failover-groepen en klik vervolgens op de naam van de failovergroep.

  4. Klik op Fail over.

  5. Selecteer de nieuwe primaire regio en bevestig dit. De failover wordt binnen enkele minuten voltooid.

  6. Start in de nieuwe primaire versie de berekening die vóór de failover werd uitgevoerd. Gerepliceerde clusters en SQL-warehouses komen respectievelijk binnen in de nieuwe primaire TERMINATED en STOPPED status.

  7. Hervat handmatig de taakplanningen die u nodig hebt in de nieuwe primaire. De planningen van de vorige primaire zijn al onderbroken.

Clients die zijn verbonden via de stabiele URL blijven werken na de failover. Leid clients die nog steeds de oorspronkelijke werkruimte-URL gebruiken om naar de stabiele URL of de werkruimte-URL van de nieuwe primaire.

Important

Bij een ongeplande failover kunnen gegevens die na het laatste replicatiepunt naar de primaire omgeving zijn geschreven, verloren gaan. Controleer of verlies binnen uw RPO-doel valt.

Tip

Test de failover regelmatig, bijvoorbeeld elk kwartaal, zodat uw team vertrouwd is met de procedure voordat er daadwerkelijk een storing optreedt.

Beheerde DR verwijderen

  1. Klik in de accountconsole op Resilience → Failover-groepen en klik vervolgens op de naam van de failovergroep en verwijder deze. U kunt Bedrijfskritiek niet uitschakelen terwijl een failovergroep actief is in de werkruimte.
  2. Als u de facturering wilt stoppen met het bedrijfskritieke tarief, schakelt u Mission Critical uit op elke werkruimte vanaf het tabblad Invoegtoepassingen .

Limitations

Beheerde disaster recovery heeft de volgende beperkingen:

  • Niet gerepliceerd: gerealiseerde weergaven, streamingtabellen, Lakeflow-pijplijnen, beheerde volumegegevens (metagegevens repliceren), Unity Catalog- en werkruimtegeheimen, ML-modellen, model voor eindpunten, vectorzoekindexen, Delta-shares, gepubliceerde AI/BI-dashboards (concepten repliceren) en Spark Structured Streaming buiten Lakeflow-pijplijnen. Tabellen met rijfilters of kolommaskers en ABAC-gelabelde resources worden gemarkeerd als Kan niet worden gerepliceerd in de systeemtabel en deze fouten houden RPO in totdat u de resource verwijdert uit het bereik van de failovergroep.
  • Schrijfbewerkingen van beheerde tabellen van externe engines hebben beperkte detectiemogelijkheden. Beheerd noodherstel detecteert wijzigingen in door Unity Catalog beheerde tabellen als gevolg van schrijfbewerkingen die worden uitgevoerd door Azure Databricks-compute. Schrijfbewerkingen naar een gerepliceerde beheerde tabel vanuit een externe engine (niet-Azure Databricks) via open API's, zoals de Iceberg REST-catalogus, worden mogelijk niet gedetecteerd, dus deze schrijfbewerkingen kunnen mogelijk niet worden gerepliceerd naar de secundaire en kunnen verloren gaan tijdens de failover. Voor tabellen die u repliceert met beheerd noodherstel, schrijft u via Azure Databricks-rekenresources.
  • Secundaire catalogi die binnen het bereik vallen, zijn alleen-lezen. Alleen-lezen is alleen van toepassing op gerepliceerde entiteiten. U kunt nog steeds uw eigen replicatie configureren voor beveiligbare objecten buiten de reikwijdte van beheerd noodherstel. U kunt echter geen compute uitvoeren in de secundaire werkruimte zolang beheerd noodherstel is ingeschakeld, wat het draaien van een doe-het-zelf-replicatiepijplijn daar beperkt.
  • Het wijzigen van de naam van een beveiligbaar object in Unity Catalog leidt ertoe dat het in de secundaire wordt verwijderd en opnieuw wordt gemaakt. Voor beheerde tabellen zorgt de naamwijziging ervoor dat de tabelgegevens in de volgende cyclus opnieuw worden gerepliceerd. Vermijd hernoemen tijdens replicatie in stabiele toestand.
  • UNDROP wordt niet doorgegeven aan het secundaire systeem.
  • Maximaal 300 catalogi per account.
  • Maximaal 100 failovergroepen per account.
  • Maximaal 10 catalogi per failovergroep.
  • Het opstarten van eerste werkruimte-asset kan tot 2 weken duren voor grote werkruimten.
  • Voor het gebruik van firewall voor werkruimteopslag op de werkruimteopslagaccounts die worden gebruikt met beheerd noodherstel, is handmatige configuratie vereist. U moet de relevante IP-adressen van het besturingsvlak toestaan bij de opslagfirewall, zodat Azure Databricks gegevens kan repliceren. Raadpleeg Vereisten.

Reference

Wanneer een resource niet kan worden gerepliceerd, wordt in de failovergroep een foutklasse in de system.replication.states systeemtabel weergegeven, samen met een bericht waarin de betrokken resource wordt geïdentificeerd. In de volgende secties worden de meest voorkomende foutklassen beschreven en hoe u deze kunt oplossen. Replicatie wordt automatisch hersteld nadat u het onderliggende probleem hebt gecorrigeerd.

DR_MISSING_DEPENDENCY

Een asset verwijst naar een afhankelijkheid die niet bestaat in de secundaire, zodat de asset niet kan worden gerepliceerd. De subklasse identificeert het ontbrekende afhankelijkheidstype en wordt weergegeven als DR_MISSING_DEPENDENCY.CATALOG, .SCHEMAof .TABLE.RESOURCE. De resolutie is voor hen allemaal hetzelfde.

  1. Controleer of de asset in de primaire omgeving ook defect is vanwege de ontbrekende afhankelijkheid. Als dat zo is, herstel of verwijder de asset in het primaire exemplaar.
  2. Als de asset geldig is in de primaire, bevindt de afhankelijkheid zich niet in het replicatiebereik van een failovergroep of bevindt deze zich binnen het bereik van deze of een andere failovergroep, maar kan niet worden gerepliceerd. Als de afhankelijkheid niet binnen het bereik valt, bewerkt u het replicatiebereik van de failovergroep om deze ook te repliceren. Als de afhankelijkheid al binnen het bereik is, controleer system.replication.states op de fout die de replicatie ervan blokkeert en los die fout op.
DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

Beheerde DR bepaalt waar elk gerepliceerd onderdeel wordt geplaatst door de opslagtoewijzingen van de failovergroep toe te passen op de bronopslaglocatie van het onderdeel. Een toewijzing komt exact overeen met een locatie of als een voorvoegsel dat ook onderliggende paden omvat. Deze fout betekent dat geen enkele toewijzing van toepassing is op een bronopslaglocatie, waardoor beheerd noodherstel niet kan bepalen waar in de secundaire locatie het item moet worden geplaatst. Voor externe tabellen en volumes betekent een ontbrekende toewijzing dat dezelfde locatie-URI wordt gebruikt op de primaire en secundaire locatie. De storage_location in het bericht is het niet-toegewezen bronpad.

  1. Ga in de accountconsole naar Resilience → Failover-groepen en bewerk de failovergroep.
  2. Voeg onder Opslagtoewijzingen een toewijzing toe of verbreed zodat deze de bronlocatie in het bericht behandelt. Als u onderliggende paden wilt behandelen, wijst u een bovenliggend pad toe en voegt u het /* achtervoegsel toe voor overeenkomende voorvoegsels. Zie opslagtoewijzingen.
  3. Controleer of een externe locatie in de secundaire metastore al het doelpad van de toewijzing dekt. De failovergroep weigert een toewijzing waarvan het doel zich niet onder een bestaande externe locatie bevindt, dus maak eerst die externe locatie als deze niet bestaat. Zie Verbinding maken met cloudobjectopslag met behulp van Unity Catalog.
DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION

Een opslagtoewijzing heeft een gerepliceerde asset vertaald naar een doelpad in de secundaire metastore, maar geen externe locatie in de secundaire metastore omvat dat pad, dus Unity Catalog kan de gegevens van de asset nergens plaatsen. De storage_location in het bericht is het onbedekte secundaire (doel)-pad.

Dit betekent meestal een van twee dingen: een externe locatie die het pad eerder omvatte, is verwijderd of verkleind, of een nieuw gerepliceerde asset verwijst naar een secundair pad dat door geen enkele externe locatie wordt omvat. Het tweede geval treedt bijvoorbeeld op wanneer u een externe tabel maakt in de primaire tabel onder een opslagpad waarop geen van uw opslagtoewijzingen betrekking heeft. Beheerde disaster recovery valt dan terug op het oorspronkelijke pad van de tabel, dat door geen enkele externe locatie in de secundaire metastore wordt gedekt, waardoor de gegevens nergens terechtkunnen.

  1. Identificeer het onopgedekte secundaire pad van het bericht storage_location.
  2. Bepaal welke externe locatie in de secundaire metastore dat pad moet omvatten: een bestaande externe locatie die u uitbreidt of een nieuwe locatie die u maakt.
  3. Pas de opslagtoewijzingen van de failovergroep zo aan dat het pad verwijst naar een bestaande externe locatie, of maak de externe locatie (met de bijbehorende storage credential) en breid de toewijzingen uit zodat deze daarnaar verwijzen. Zie Verbinding maken met cloudobjectopslag met behulp van Unity Catalog.
DR_INTERNAL_ERROR

Er is een fout aan de systeemzijde opgetreden tijdens de replicatie. Er is geen actie vereist; het systeem wordt automatisch hersteld. Neem contact op met Azure Databricks ondersteuning als het probleem niet zelfstandig wordt opgelost.

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

Beheerde disaster recovery repliceert de weergave samen met de bijbehorende verleende rechten, maar een weergave die verwijst naar objecten in andere catalogi vereist ook dat de eigenaar in de secundaire omgeving toegang heeft tot die objecten waarnaar wordt verwezen, omdat de weergave draait met de rechten van de eigenaar. Deze fout betekent dat de eigenaar die toegang op de secundaire server mist, dus moet u deze verlenen op de objecten waarnaar wordt verwezen.

  1. Zoek de objecten waarnaar de weergave verwijst en de eigenaar van de weergave. Objecten waarnaar wordt verwezen, worden weergegeven als volledig gekwalificeerde catalog.schema.object namen in de definitie. Subsidies moeten naar de eigenaar gaan, die u ook kunt lezen in het veld Eigenaar in Catalog Explorer.

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

  2. Controleer op de secundaire versie de huidige bevoegdheden van de eigenaar voor elk object waarnaar wordt verwezen. Voor het lezen van een tabel is USE CATALOG op de catalogus, USE SCHEMA op het schema en SELECT op de tabel vereist.

    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. Verleen de eigenaar van de weergave alle ontbrekende machtigingen op elk object waarnaar wordt verwezen.

    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. Controleer of elke catalogus waarnaar de weergave verwijst, is opgenomen in het replicatiebereik van een failovergroep, zodat deze ook in de secundaire bestaat.

Zie Bevoegdheden beheren in Unity Catalog voor meer informatie.

DR_INVALID_CONFIGURATION.NETWORK_UNAUTHORIZED_ACCESS

Tijdens replicatie van tabelgegevens in meerdere regio's leest de serverloze berekening van de secundaire werkruimte gegevens uit de bronopslag en heeft de opslag de netwerkverbinding geweigerd: een opslagfirewall of netwerkregel heeft deze geblokkeerd, of een vereist privé-eindpunt ontbreekt of is niet goedgekeurd.

Controleer of uw bron- en secundaire opslag Azure Databricks serverloze netwerktoegang toestaan, zoals beschreven in Vereisten.

DR_INVALID_CONFIGURATION.SERVERLESS_COMPUTE_PERMISSION

Beheerde disaster recovery gebruikt serverloze rekenkracht in de secundaire werkruimte om gegevens te kopiëren, en serverloze rekenkracht is daar niet toegestaan. Dit betekent meestal dat serverless is uitgeschakeld voor het account of de werkruimte, of dat de werkruimte niet in aanmerking komt.

  1. Controleer of de secundaire werkruimte in aanmerking komt. Serverloze berekeningen zijn standaard beschikbaar in werkruimten met Unity Catalog in een ondersteunde regio. Zie Verbinding maken met serverloze berekeningen.
  2. Controleer op een accountbrede opt-out. Ga in de accountconsole naar Instellingen → Functie inschakelen en controleer of de serverloze wisselknop aanwezig en uitgeschakeld is.
  3. Schakel serverloos in voor het bereik dat u nodig hebt. Als u elke in aanmerking komende werkruimte wilt inschakelen, schakelt een accountbeheerder de serverloze wisselknop op accountniveau in. Als u alleen de secundaire werkruimte wilt inschakelen, laat u de schakelaar op accountniveau uitgeschakeld en laat u een werkruimtebeheerder serverless inschakelen via Previews in de werkruimte.
  4. Als er geen wisselknop beschikbaar is of serverloos nog steeds niet wordt uitgevoerd nadat u deze hebt ingeschakeld, neemt u contact op met uw Azure Databricks accountteam.
DR_INVALID_CONFIGURATION.OVERLAPPING_EXTERNAL_LOCATIONS

Wanneer beheerde disaster recovery een gerepliceerd object aanmaakt op het toegewezen doelpad in de secundaire omgeving, wijst Unity Catalog het pad af omdat het overlapt met opslag die daar al bestaat, zoals een bestaande externe locatie, een overgebleven beveiligbaar object van een eerdere of gedeeltelijke configuratie, een beheerde locatie of de standaardopslag van de werkruimte (DBFS).

  1. Bepaal wat het pad in beslag neemt.

    Controleer in Catalog Explorer uw externe locaties, beheerde opslaglocaties en externe tabellen en volumes om het object te vinden waarvan het pad het doelpad bedekt of overlapt.

  2. Als het conflicterende object geen eigenaar mag zijn van het pad, verwijdert u het. Een veelvoorkomende oorzaak is een overgebleven externe tabel of extern volume van een eerdere configuratie; verwijder deze als die niet langer nodig is. Als het een externe locatie is die het pad niet moet bedekken, verwijdert of herdefinieert u het.

  3. Anders moet u de opslagkoppeling van de failovergroep omleiden naar een afzonderlijk doelpad zonder overlap. Geef de voorkeur aan een specifiek subpad boven een brede buckethoofdmap en vermijd de standaardopslag van de werkruimte (DBFS).

DR_UNSUPPORTED_FEATURE

Het onderdeel maakt gebruik van een functie die beheerd noodherstel niet kan nabootsen. De subklasse identificeert de niet-ondersteunde functie en wordt bijvoorbeeld weergegeven als DR_UNSUPPORTED_FEATURE.ABAC_POLICY. Er zijn twee manieren om deze fout op te lossen.

  1. Verwijder de niet-ondersteunde functie uit de asset in de primaire werkruimte.
  2. Als u de functie niet kunt verwijderen, kunt u overwegen de asset te verwijderen uit het replicatiebereik van de failovergroep.

Zie Disaster recovery voor DR-concepten en best practices.

  • Last updated on