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, dus je kunt Unity Catalog-metadata en -gegevens en/of werkruimte-assets inschakelen.

Unity Catalog metadata en data

Object Opmerkingen
Unity Catalog beheerde tabellen in Delta Lake Data en metadata. Zie Beperkingen.
Externe tabellen Alleen metadata. Zie Beperkingen.
Externe volumes Alleen metadata.
Views
Functions
Toestemmingen
Streamingtabellen In privépreview. Neem contact op met uw Azure Databricks-accountteam voor meer informatie.
Gematerealiseerde weergaven In Private Preview. Neem contact op met uw Azure Databricks-accountteam voor meer informatie.
Rijfilters, kolommaskers en attribuutgebaseerde toegangscontrole (ABAC) beleidsregels In Private Preview. Neem contact op met uw Azure Databricks-accountteam voor meer informatie.
Buitenlandse catalogi In Private Preview. Neem contact op met uw Azure Databricks-accountteam voor meer informatie.

De isolatiemodus van de catalogus wordt ook gerepliceerd. Als de broncatalogus open is, is de replica ervan open. Als de broncatalogus geïsoleerd is en gebonden aan de primaire werkruimte, is de replica geïsoleerd en gebonden aan de secundaire werkruimte.

Werkruimte-assets

Werkruimteassets worden gerepliceerd samen met hun ACL's.

Object Opmerkingen
Notebooks
Jobs Taakplanningen in de secundaire worden onderbroken.
SQL-magazijnen Gerepliceerd in de status STOPPED.
Clusters Gerepliceerd in de status TERMINATED. Bevat ook compute-beleid, instanceprofielen en globale init-scripts.
Instancegroepen Capaciteitsreserveringen zijn regio-specifiek en moeten in de secundaire regio worden geconfigureerd.
Als je failover-groep vóór 17 september 2026 is aangemaakt, neem dan contact op met je Azure Databricks-accountteam om instance pools toe te voegen aan je failover-groep.
Concept-AI/BI-dashboards
Bestanden
Mappen Bevat geen Git-mappen.
Queries Bevat queries die zijn gemaakt en opgeslagen in de SQL-editor.
Libraries
Bestemmingen voor meldingen
Genie agenten In privépreview. Neem contact op met uw Azure Databricks-accountteam voor meer informatie.
Lakeflow-pijplijnen In Private Preview. Neem contact op met uw Azure Databricks-accountteam voor meer informatie.

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

Om beheerde DR op te zetten, moet je het volgende hebben:

  • Een werkruimte in het Premium-abonnement in zowel de primaire als de secundaire regio's.

Configuratievereisten

Om managed DR te gebruiken, zorg ervoor dat de volgende instellingen en bronnen zijn geconfigureerd.

Categorie Details
Secundaire werkruimte en metastore
  • Een secundaire werkruimte en Unity Catalog-metastore in de secundaire regio, in hetzelfde Azure Databricks-account en in dezelfde cloud als uw primaire.
  • Let op de volgende kanttekeningen bij het configureren van je secundaire wapen:
    • De secundaire metastore mag geen catalogi bevatten die namen delen met gerepliceerde catalogi.
    • Voor replicatie van werkruimteassets verwijdert Azure Databricks alle bestaande in-scope assets 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.
Identiteit
  • Accountniveau SSO met alle werkruimtes ingeschakeld en identiteiten gesynchroniseerd met het account via AIM of SCIM , zodat gebruikers, groepen en servicehoofden 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.
Opslag en gegevenstoegang
  • 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 bijbehorende externe locatie en opslagreferentie in de secundaire regio voor elke locatie waarnaar wordt verwezen door uw primaire catalogi. Managed DR repliceert externe locaties of opslaggegevens niet automatisch. Je moet ze creëren in de secundaire sector.
Netwerken
  • Zorg ervoor dat de volgende accountniveau-objecten gekoppeld zijn aan zowel je primaire als secundaire werkruimtes: Network Connectivity Configuration (NCC), Network policy (serverless egress), Private access settings (PAS) en IP-toegangslijst.
  • Zowel bron- als secundaire opslag moeten Azure Databricks serverloze netwerktoegang in beide richtingen toestaan.
  • 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.
  • Als je privé-connectiviteit gebruikt met de opslagaccounts die je bron- of gerepliceerde data bevatten, hebben zowel de primaire als secundaire werkruimtes privé-endpoints nodig voor zowel de primaire als secundaire opslagaccounts. Maak privé-endpoints aan voor zowel de blob- als dfs-subresources op elk account. Keur ze goed in de Azure-portal.
Kosten en bestuur
  • Koppel het beleid voor serverless-gebruik op accountniveau (voorheen serverless-budgetbeleid) aan de primaire en secundaire werkruimte.
Tabelinstellingen
  • Voor tabellen die je op timestamp bevraagt, met tijdreizen of de change data-feed, raadt Databricks aan om in-commit timestamps (delta.enableInCommitTimestamps = true) in te schakelen voordat je replicatie opzet. Catalogusbeheerde tabellen beheren in-commit tijdstempels voor je, dus je kunt deze eigenschap niet op hen zetten. Zie Beperkingen.

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.

Bijvoorbeeld, de stabiele URL neemt de vorm <my-custom-url>.azuredatabricks.net/?w=stable_connection_idaan . Zie Inbound Private Link configureren voor werkruimtes met beheerd disaster recovery.

Verbind clients met de stabiele URL

Clients verbinden via de stabiele URL op dezelfde manier als ze verbinding maken met een werkruimte-URL, met twee verschillen: gebruik de host van de stabiele URL in plaats van de oorspronkelijke werkruimte-URL, en identificeer de werkruimte met de stabiele verbindings-ID in de w queryparameter. Authenticeer jezelf met OAuth op accountniveau.

JDBC- en ODBC-verbindingen met SQL-warehouses

Stel de hostnaam van de server in op de host van de stabiele URL en voeg vervolgens toe aan het warehouse-?w=stable_connection_id:

/sql/1.0/warehouses/<warehouse-id>?w=stable_connection_id

Haal de warehouse-ID op via het HTTP-pad op het tabblad Connection details van het warehouse (zie Get connection details voor een Azure Databricks computeresource). Gebruik dezelfde poort- en driverinstellingen die u zou gebruiken met de originele workspace-URL.

Direct REST API-verzoeken

Stuur verzoeken naar de host van de stabiele URL en voeg de queryparameter w=stable_connection_id toe aan het verzoek. Bijvoorbeeld, om clusters op te sommen:

GET https://<my-custom-url>/api/2.0/clusters/list?w=stable_connection_id

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 werkruimtes kan de eerste workspace asset bootstrap tot vijf dagen 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. Zet het aan om werkruimte-assets en hun ACL's van de primaire naar de secundaire te repliceren. Beide werkruimtes moeten de Mission Critical-add-on ingeschakeld hebben. 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.

Wanneer een replicatiepunt wordt getoond, is alles wat niet door een fout wordt gedekt tot dat punt gerepliceerd. Tijdens de initiële replicatie, voordat het eerste replicatiepunt bestaat, kan de failovergroep nog steeds blokkeringsfouten tonen, maar meet deze de volledigheid nog niet. Assettypen die door beheerde DR helemaal niet worden ondersteund, verschijnen niet in de system.replication.states systeemtabel. Zie Beperkingen. Om een specifiek asset te controleren, inspecteer het in de secundaire omgeving (zie Replicatie instellen).

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: beheerde volumes, Unity Catalog en werkruimtegeheimen, ML-modellen, model-serving endpoints, vectorzoekindexen, Delta shares, gepubliceerde AI/BI-dashboards (concepten worden wel gerepliceerd), en Spark Structured Streaming buiten Lakeflow-pijplijnen. Tabellen met Delta Lake-archiefondersteuning (delta.timeUntilArchived) worden in de systeemtabel als 'Failed to replicate' gemarkeerd, en deze fouten houden RPO vast totdat je de resource uit het bereik van de failover-groep verwijdert. Metadata-replicatie wordt niet ondersteund voor niet-Delta Lake-externe tabellen die partitiemetadata gebruiken.
  • Replicatie voor gematerialiseerde weergaven, streamingtabellen en Lakeflow-pijplijnen is als privépreview beschikbaar. Neem contact op met uw Azure Databricks-accountteam voor meer informatie.
  • 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. Replicatie voor deze bronnen vindt plaats in Private Preview. Neem contact op met uw Azure Databricks-accountteam voor meer informatie.
  • 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.
  • Voor tabellen zonder in-commit tijdstempels kan tijdreizen via tijdstempel de verkeerde versie teruggeven. In deze tabellen neemt Delta Lake de tijdstempel van elke commit van de wijzigingstijd van het commitbestand, en gerepliceerde commitbestanden dragen de tijd waarop ze zijn gekopieerd in plaats van de oorspronkelijke committijd. Daardoor kunnen time travel-query's en change data feed-lezingen op basis van een tijdstempel verwijzen naar een andere versie dan in de brontabel, zonder foutmelding. Dit beïnvloedt het secundaire exemplaar zodra een tabel repliceert, en het primaire exemplaar na een failover of failback. Tijdreizen per versie wordt niet beïnvloed. Om dit te voorkomen, schakel in-commit timestamps in op deze tabellen in voordat je replicatie opzet. Zie Configuratievereisten.
  • De eerste bootstrap van de asset van de werkruimte kan tot vijf dagen duren voor grote werkruimtes.
  • 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.MISSING_STORAGE_PRIVATE_ENDPOINT

Managed DR kopieert tabelgegevens over privé-endpoints wanneer je opslag gebruikmaakt van private connectiviteit. De privé-eindpunten op de bron- en secundaire opslagaccounts moeten overeenkomen. Ofwel heeft geen van beide accounts een privé-endpoint, of beide accounts hebben een blob en een dfs privé-endpoint. Deze fout betekent dat ze niet overeenkomen. Het bericht vermeldt de ontbrekende eindpunten.

  1. Voor elk opslagaccount dat in het bericht wordt genoemd, maak je de ontbrekende blob en dfs private endpoints aan zodat beide zijden overeenkomen. De primaire en secundaire werkruimtes hebben beide privé-endpoints nodig voor beide opslagaccounts. Zie Privéconnectiviteit met Azure-resources configureren.
  2. Keur de nieuwe private endpoints goed in het Azure-portaal. Zie Configuratievereisten.
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.
DR_UNSUPPORTED_FEATURE.TABLE_ARCHIVED_FILES

De tabel heeft Delta Lake-archiveringsondersteuning ingeschakeld (delta.timeUntilArchived). Beheerde DR kloont elk databestand, dus gearchiveerde objecten moeten worden hersteld naar een hot storage tier en de tabeleigenschap moet op de primaire worden verwijderd voordat replicatie kan doorgaan. Zie Archival-ondersteuning in Azure Databricks.

  1. Schakel het archiveringsbeleid voor de cloudlevenscyclus uit op de opslaglocatie van de tabel zodat er geen extra bestanden worden gearchiveerd nadat je ze hebt weergegeven.

  2. Geef bestanden weer die hersteld moeten worden:

    SHOW ARCHIVED FILES FOR <table_name>;

  3. Herstel die objecten in je cloudprovider en wacht dan tot het herstel is voltooid. Zie Gearchiveerde bestanden herstellen.

  4. Schakel de delta.timeUntilArchived tabeleneigenschap uit. Hiermee worden alleen metagegevens bijgewerkt zodat Databricks archivering niet langer in de tabel bijhoudt:

    ALTER TABLE <table_name> UNSET TBLPROPERTIES ('delta.timeUntilArchived');

  5. Bevestig dat bijvoorbeeld een volledige leesbewerking succesvol is, SELECT COUNT(*) FROM <table_name>;. Daarna kan replicatie de tabel klonen.

Wees ervan bewust dat het verwijderen van de eigenschap geen objecten herstelt. Het herstellen van objecten is een cloudprovider-operatie die handmatig moet worden uitgevoerd met behulp van cloudprovider-mechanismen.

Zie Disaster recovery voor DR-concepten en best practices.

  • Laatst bijgewerkt om