Verwaltete Notfallwiederherstellung

Die verwaltete Notfallwiederherstellung (DR) repliziert Ihre Azure Databricks Bereitstellung in eine sekundäre Region, sodass Sie einen regionalen Ausfall in Minuten wiederherstellen können. Azure Databricks verwaltet die Replikationspipeline, den Status der replizierten Kataloge im sekundären und den Failoverprozess. Sie schreiben oder pflegen keine Replikationsskripte.

Informationen zum manuellen Ansatz für die Notfallwiederherstellung, einschließlich allgemeiner DR-Konzepte und bewährter Methoden, finden Sie unter Notfallwiederherstellung.

Wichtig

Managed DR ist eingeschränkt verfügbar. Beantragen Sie den Zugriff über Ihr Azure Databricks-Kontoteam. Azure Databricks aktiviert verwalteten DR auf Ihrem Konto, nachdem Sie akzeptiert wurden.

Was ist die verwaltete Notfallwiederherstellung?

Verwaltetes DR setzt auf den Workspaces und Metastores auf, die Sie bereits betreiben. Sie richten zwei Azure Databricks-Workspaces ein, einen in Ihrer primären Region und einen in Ihrer sekundären Region, sowie einen Metastore in jeder Region. Verwaltete DR damals:

  • Repliziert die von Ihnen ausgewählten Kategorien nach einem kontinuierlichen Zeitplan vom primären zum sekundären Standort. Beide Kategorien sind unabhängig voneinander optional: Unity-Katalogmetadaten und verwaltete Tabellendaten sowie Arbeitsbereichsressourcen wie Notizbücher, Aufträge, SQL-Lagerhäuser, Cluster und ACLs.
  • Stellt eine optionale stabile URL, eine einzelne Verbindungszeichenfolge bereit, die immer auf die aktuelle primäre Url verweist, sodass Clients nach dem Failover ohne Neukonfiguration weiterarbeiten.
  • Ermöglicht es Ihnen, bei Bedarf ein Failover für einen DR-Test oder einen tatsächlichen Ausfall auszulösen.

Die IDs der Workspace-Assets bleiben regionenübergreifend erhalten, sodass URLs, die über die ID auf ein Workspace-Asset verweisen, auch nach einem Failover weiterhin aufgelöst werden.

Was repliziert wird

Verwaltetes DR kann Folgendes in jedem Replikationszyklus replizieren. Beide Kategorien sind optional, sodass Sie entweder oder beides aktivieren können:

  • Unity Catalog-Metadaten und -Daten: von Unity Catalog verwaltete Tabellen in Delta Lake mit Daten, externe Tabellen und Volumes (nur Metadaten), Ansichten, Funktionen und alle Berechtigungsvergaben. Der Isolationsmodus des Katalogs wird repliziert. Wenn der Quellkatalog geöffnet ist, ist das Replikat geöffnet. Wenn die Quelle isoliert und an den primären Arbeitsbereich gebunden ist, ist das Replikat isoliert und an den sekundären Arbeitsbereich gebunden.
  • Arbeitsbereichsressourcen: Notizbücher, Aufträge, SQL-Lagerhäuser, Cluster, AI/BI-Dashboards, Dateien und Ordner sowie ihre ACLs. SQL-Warehouses werden im Status STOPPED repliziert, Cluster im Status TERMINATED. Job-Zeitpläne im sekundären Bereich werden angehalten.

Besitz von replizierten Objekten

Wenn die verwaltete DR ein repliziertes schützbares Objekt (Katalog, Schema, Tabelle, Ansicht, Funktion oder Volume) im sekundären Arbeitsbereich erstellt, ist der ursprüngliche Eigentümer die Azure Databricks-Dienstprincipal, die die Replikation ausführt, da Unity Catalog die Eigentumsrechte der Identität zuweist, die das Objekt erstellt. Die verwaltete DR überträgt anschließend die Eigentumsrechte an der Replik so, dass sie mit dem Eigentümer des entsprechenden schützbaren Objekts im primären Arbeitsbereich übereinstimmen.

Ist der Besitzer eines schützbaren Objekts im Primärsystem ein Benutzer, der aus dem Konto gelöscht wurde, kann Managed DR die Eigentumsrechte nicht an eine Prinzipal übertragen, die nicht mehr existiert. In diesem Fall behält das replizierte schützbare Objekt die Azure Databricks-Dienstprinzipal als Eigentümer. Um dies zu beheben, weisen Sie dem Sicherungsobjekt im Primärsystem einen gültigen Besitzer zu, und lassen Sie es von DR replizieren.

Requirements

  • Das Mission Critical Workspace-Add-On ist in beiden Arbeitsbereichen aktiviert. Siehe "Mission Critical aktivieren" in beiden Arbeitsbereichen.
  • Serverlose Rechenleistung ist in beiden Arbeitsbereichen aktiviert. Serverless Compute ist standardmäßig in den meisten Unity-Katalog-aktivierten Arbeitsbereichen verfügbar. Siehe Verbindung mit serverlosem Computing herstellen.
  • Die Rolle „Kontoadmin“ mit ALL PRIVILEGES für jeden externen Speicherort, der von den Katalogen genutzt wird, die Sie replizieren möchten.
  • SSO auf Kontoebene mit allen aktivierten Arbeitsbereichen und Identitäten, die über SCIM mit dem Konto synchronisiert wurden, sodass Benutzer, Gruppen und Dienstprinzipale in beiden Regionen vorhanden sind.
  • Für stabile URLs: eine benutzerdefinierte URL, die für Ihre Azure Databricks Domäne bereitgestellt wird (wenden Sie sich an Ihr Kontoteam) und OAuth auf Kontoebene.
  • Ein sekundärer Arbeitsbereich und ein Unity Catalog-Metastore in der sekundären Region, im selben Azure Databricks-Konto und in derselben Cloud wie Ihre primäre Umgebung. Der sekundäre Arbeitsbereich muss mit der Konfiguration des primären Netzwerks, Private Link und der vom Kunden verwalteten Schlüssel übereinstimmen. Der sekundäre Metastore darf keine Kataloge enthalten, die dieselben Namen wie replizierte Kataloge haben. Für die Replikation von Workspace-Assets löscht Azure Databricks alle vorhandenen Assets im sekundären Workspace, die unter die Replikation fallen, sobald die anfängliche Replikation abgeschlossen ist. Ressourcen außerhalb des Gültigkeitsbereichs sind nicht betroffen, sodass der sekundäre Arbeitsbereich nicht leer sein muss.
  • Einen entsprechenden externen Speicherort und entsprechende Anmeldeinformationen in der sekundären Region für jeden Speicherort, auf den Ihre primären Kataloge verweisen. Verwaltetes DR repliziert externe Speicherorte oder Speicheranmeldeinformationen nicht automatisch; Sie müssen sie in der sekundären Umgebung erstellen.

Da die serverlosen Compute-Ressourcen des sekundären Arbeitsbereichs bei der regionsübergreifenden Replikation aus dem Quellspeicher lesen, müssen sowohl der Quellspeicher als auch der sekundäre Speicher den serverlosen Netzwerkzugriff von Azure Databricks in beide Richtungen zulassen.

Wenn Sie den Netzwerkzugriff auf den Quellspeicher oder den DBFS-Stamm einschränken, lassen Sie auch die IP-Adressen der Kontrollebene der sekundären Region an der Quellspeicherfirewall und die IP-Adressen der primären Region an der sekundären DBFS-Firewall zu. Informationen zu den IP-Adressen der Steuerebene, die in den einzelnen Regionen zulässig sind, finden Sie unter "Eingehend zu Azure Databricks Steuerebene".

  • Einen Azure Databricks Access Connector in der sekundären Region mit der Rolle „Storage Blob Data Contributor“ für die sekundären Speicherkonten, der als Anmeldeinformation im sekundären Arbeitsbereich hinzugefügt wurde.
  • Eine Netzwerkkonnektivitätskonfiguration (Network Connectivity Configuration, NCC) in der sekundären Region, die dem sekundären Arbeitsbereich zugewiesen ist, sodass die serverlose Berechnung den Speicher über private Endpunkte erreichen kann. Weitere Informationen finden Sie unter Private Konnektivität zu Azure-Ressourcen konfigurieren.
  • Private Endpunkte für jedes Quell- und sekundäre Speicherkonto, auf das von Ihren replizierten Katalogen verwiesen wird. Erstellen Sie für ADLS Gen2-Speicher für jedes Konto einen privaten Endpunkt sowohl für die Unterressourcen dfs als auch blob. Genehmigen Sie sie im Azure-Portal.

Aktivieren Sie Mission Critical in beiden Arbeitsbereichen

Aktivieren Sie das Mission-Critical-Add-On sowohl in Ihren primären als auch in Ihren sekundären Arbeitsbereichen, bevor Sie eine Failover-Gruppe erstellen. Die Compute-Nutzung in jedem Arbeitsbereich, in dem Sie das Add-on aktivieren, wird zum Mission-Critical-Tarif abgerechnet. Wenden Sie sich an Ihr Azure Databricks Kontoteam für den aktuellen Preis.

  1. Klicken Sie in der Kontokonsole auf Arbeitsbereiche, und klicken Sie dann auf den Arbeitsbereich.
  2. Klicken Sie auf die Registerkarte "Add-Ons ".
  3. Aktivieren Sie auf der Mission Critical-Karte den Umschalter und bestätigen Sie.

Wiederholen Sie den Vorgang für den sekundären Arbeitsbereich.

Optional: statische URL

Azure Databricks empfiehlt die Verwendung der stabilen URL. Die stabile URL verweist immer auf den aktuellen primären Arbeitsbereich, sodass Clients, die sich über diese URL verbinden, nach einem Failover nicht neu konfiguriert werden müssen. Die ursprüngliche Arbeitsbereichs-URL bleibt für den direkten Zugriff auf diesen Arbeitsbereich gültig, aber nach einem Failover verweist sie weiterhin auf die alte primäre Instanz, die nun die sekundäre ist. Konfigurieren Sie die folgenden nachgelagerten Clients so, dass sie die stabile URL anstelle der ursprünglichen Workspace-URL verwenden:

  • Die Azure Databricks Web-UI.
  • JDBC- und ODBC-Verbindungen zu SQL-Data-Warehouses.
  • Direkte REST-API-Anforderungen.

Stabile URLs werden mit Front-End-Private Link (eingehend) unterstützt. Mit eingehendem Private Link wird für die stabile URL Ihre benutzerdefinierte URL mit einer stabilen Verbindungs-ID anstelle des standardmäßigen URL-Formats des Arbeitsbereichs verwendet.

Einrichten der Replikation

Eine neue Failover-Gruppe durchläuft die Phasen CREATING → INITIAL_REPLICATION → ACTIVE. Der erste Replikationszyklus kopiert alle relevanten Daten auf das Sekundärsystem. Bei großen Arbeitsbereichen kann der anfängliche Bootstrap-Vorgang für Arbeitsbereichsressourcen bis zu zwei Wochen dauern. Diese Wartezeit ist einmalig. Nach Abschluss des anfänglichen Bootstrap wird die Replikation kontinuierlich ausgeführt.

Während der Replikation sind sekundäre, im Umfang enthaltene Kataloge im Nur-Lesen verfügbar, und Compute-Kapazitäten stehen im sekundären Arbeitsbereich nicht zur Verfügung. Zum Ausführen von Überprüfungsabfragen ohne Schreiben in die sekundäre Region empfiehlt Azure Databricks einen separaten schreibgeschützten Monitorarbeitsbereich in der sekundären Region.

So erstellen Sie eine Failovergruppe:

  1. Klicken Sie in der Kontokonsole auf "Resilienz".
  2. Wenn Sie beabsichtigen, eine stabile URL zu verwenden, klicken Sie auf die Registerkarte "Stabile URLs " und dann auf "Stabile URL erstellen". Geben Sie einen Namen ein, wählen Sie den aktuellen primären Arbeitsbereich aus, und erstellen Sie die stabile URL. Verweisen Sie nachgelagerte Clients (JDBC, ODBC, die Azure Databricks-Webbenutzeroberfläche, direkte API-Anfragen) auf die stabile URL statt auf die ursprüngliche Workspace-URL.
  3. Klicken Sie auf die Registerkarte "Failovergruppen " und dann auf " Failovergruppe erstellen".
  4. Füllen Sie das Formular aus:
    • Failovergruppenname: Ein Name, den Sie für die Failovergruppe auswählen.
    • Primärer Arbeitsbereich: Der Arbeitsbereich, der als Ihr primärer Arbeitsbereich festgelegt ist.
    • Sekundärer Arbeitsbereich: Der Arbeitsbereich in der sekundären Region.
    • Replizieren von Arbeitsbereichsressourcen (optional): Standardmäßig deaktiviert. Aktivieren Sie das Replizieren von Notizbüchern, Aufträgen, SQL-Lagerhäusern, Clustern, Dashboards, Dateien und Ordnern (und deren ACLs) vom primären zum sekundären. Erfordert, dass beide Arbeitsbereiche das mission Critical-Add-On aktiviert haben. Wenn Sie die Replikation von Arbeitsbereichsobjekten aktivieren, löscht Azure Databricks nach Abschluss der initialen Replikation alle vorhandenen, vom Replikationsumfang erfassten Objekte im sekundären Arbeitsbereich. Assets außerhalb des Geltungsbereichs sind nicht betroffen.
    • Stabile URL (optional): Die stabile URL, die Sie in Schritt 2 erstellt haben.
    • Replikationsbereich: Die zu replizierenden Kataloge. Sie müssen einen primären Arbeitsbereich auswählen, bevor dieses Feld verfügbar ist.
    • Speicherzuordnungen: Fügen Sie für jeden externen Speicherort, den Ihre replizierten Kataloge in der primären Region verwenden, einen Eintrag hinzu, der seinen Speicherpfad dem entsprechenden externen Speicherort zuordnet, den Sie in der sekundären Region erstellt haben (siehe Anforderungen). Sie können als Wildcard zum Präfixabgleich verwenden * .
  5. Klicken Sie auf "Failovergruppe erstellen".

Beispielsweise könnte eine Azure-Storage-Zuordnung abfss://data@primary.dfs.core.windows.net/* zu abfss://data@secondary.dfs.core.windows.net/* zuordnen.

Von verwaltetem DR erstellte Ressourcen

Wenn Sie eine Failovergruppe erstellen, stellt Managed DR zusätzliche Unity-Catalog-Ressourcen bereit, die die Replikationspipeline verwendet, um Daten zwischen Regionen zu kopieren. In den primären und sekundären Metaspeichern erstellt verwaltetes DR:

  • Eine Verbindung , die auf den Arbeitsbereich in der anderen Region verweist.
  • Ein fremder Katalog für jeden replizierten Katalog. Der Fremdkatalog verweist auf den entsprechenden Katalog in der anderen Region.

Diese Ressourcen werden zusammen mit Ihren eigenen Katalogen im Katalog-Explorer angezeigt. Sie können sie an ihrem Kommentar erkennen, aus dem hervorgeht, dass die Disaster Recovery von Azure Databricks sie erstellt und verwaltet.

Wichtig

Standardmäßig kann nur ein Metastoreadministrator diese Ressourcen ändern oder löschen. Löschen Sie nicht die Verbindungen oder Fremdkataloge, die von verwaltetem DR erstellt werden. Das Löschen einer der beiden unterbricht die Replikation für die Failover-Gruppe.

Replikation überwachen

Auf der Registerkarte "Failovergruppen " werden der aktuelle Status, der Replikationspunkt und alle aktiven Fehler jeder Failovergruppe angezeigt. Mögliche Zustände:

Staat Meaning
CREATING Die Failovergruppe wird bereitgestellt.
INITIAL_REPLICATION Der erste Replikationszyklus wird ausgeführt. Failover ist noch nicht verfügbar.
ACTIVE Die Replikation befindet sich im stabilen Zustand. Failover ist verfügbar.
FAILING_OVER Ein Failover ist im Gange.
FAILOVER_FAILED, CREATION_FAILEDDELETION_FAILED Der Vorgang wurde nicht abgeschlossen. Überprüfen Sie die Statusdetails der Failovergruppe, um Anleitungen zu erhalten.

Wählen Sie den Namen einer Failovergruppe aus, um die Detailseite zu öffnen. Die Replikation wird kontinuierlich ausgeführt, aber der Replikationspunkt gibt den letzten Zeitpunkt an, zu dem alle betroffenen Ressourcen gemeinsam kopiert wurden. Einzelne Ressourcen sind möglicherweise aktueller, aber nicht alle Daten nach dem Replikationszeitpunkt sind im sekundären Replikat vorhanden und können während des Failovers verloren gehen.

Um historische RPO-Trends zu überwachen und die Fehler anzuzeigen, die die Replikation blockieren, fragen Sie die system.replication.states Systemtabelle ab. Siehe Referenz zur Replikationssystemtabelle. Die am häufigsten verwendeten Fehlerklassen und deren Behebung finden Sie unter Referenz.

Failover und Failback

Dasselbe Verfahren umfasst geplante Failovers (DR-Tests, geplante Wartung) und ungeplante Failover (ein regionaler Ausfall). Um ein Failback durchzuführen, wiederholen Sie den Vorgang mit vertauschten Regionen.

Wenn Sie ein Failover auslösen, führt Azure Databricks Folgendes aus:

  • Verweist die stabile URL, falls vorhanden, auf die neue primäre Region.
  • Umkehrt die Richtung der Replikation.
  • Halten Sie die Job-Zeitpläne im ehemaligen Primärsystem an.
  • Überführt die Failovergruppe von FAILING_OVER in INITIAL_REPLICATION.

Failover ausführen:

  1. Benachrichtigen Sie Ihr Team, dass ein Failover gestartet wird.

  2. Nur für ein geplantes Failover:

    1. Beenden Sie im primären Arbeitsbereich alle ausgeführten Cluster, und beenden Sie alle SQL-Lagerhäuser.
    2. Vergewissern Sie sich, dass keine Schreibvorgänge mehr auf dem Primärsystem stattfinden, und warten Sie dann, bis die Replikation den Rückstand aufgeholt hat. Um dies zu überprüfen, öffnen Sie die Detailseite der Failover-Gruppe und vergewissern Sie sich, dass der Replikationspunkt nur wenige Sekunden von dem Zeitpunkt entfernt ist, zu dem Sie die Schreibvorgänge angehalten haben.

  3. Klicken Sie in der Kontokonsole auf Resilienz → Failovergruppen, und klicken Sie dann auf den Namen der Failovergruppe.

  4. Klicken Sie auf "Fail over".

  5. Wählen Sie den neuen primären Bereich aus, und bestätigen Sie es. Das Failover ist in wenigen Minuten abgeschlossen.

  6. Starten Sie auf dem neuen Primärserver die Datenverarbeitung, die vor dem Failover ausgeführt wurde. Replizierte Cluster und SQL-Warehouses kommen im neuen Primärsystem jeweils im Zustand TERMINATED bzw. STOPPED an.

  7. Setzen Sie die benötigten Job-Zeitpläne auf dem neuen Primärserver manuell fort. Die Zeitpläne des ehemaligen Primärservers sind bereits angehalten.

Clients, die über die stabile URL verbunden sind, funktionieren nach dem Failover weiterhin. Leiten Sie Clients, die noch den ursprünglichen Arbeitsbereichs-URL verwenden, entweder auf die stabile URL oder auf die Workspace-URL des neuen Primärservers um.

Wichtig

In einem ungeplanten Failover gehen möglicherweise Daten, die nach dem letzten Replikationspunkt in die primäre Datei geschrieben wurden, verloren. Vergewissern Sie sich, dass alle Verluste in Ihr RPO-Ziel fallen.

Tipp

Testen Sie das Failover regelmäßig, z. B. einmal pro Quartal, damit Ihr Team mit dem Verfahren vor einem tatsächlichen Ausfall vertraut ist.

Verwalte DR entfernen

  1. Klicken Sie in der Kontokonsole auf Resilienz → Failovergruppen, und klicken Sie dann auf den Namen der Failovergruppe, und löschen Sie sie. Sie können „Mission Critical“ nicht deaktivieren, während eine Failovergruppe im Arbeitsbereich aktiv ist.
  2. Um die Abrechnung zum Mission-Critical-Tarif zu beenden, deaktivieren Sie Mission Critical in jedem Workspace auf der Registerkarte Add-ons.

Limitations

Verwaltetes DR hat die folgenden Einschränkungen:

  • Nicht repliziert: materialisierte Ansichten, Streaming-Tabellen, Lakeflow-Pipelines, Daten in verwalteten Volumes (Metadaten werden repliziert), Geheimnisse in Unity Catalog und im Workspace, ML-Modelle, Endpunkte für die Modellbereitstellung, Vektorsuchindizes, Delta Shares, veröffentlichte KI-/BI-Dashboards (Entwürfe werden repliziert) und Spark Structured Streaming außerhalb von Lakeflow-Pipelines. Tabellen mit Zeilenfiltern oder Spaltenmasken sowie mit ABAC-Tags versehene Ressourcen werden in der Systemtabelle als Replikation fehlgeschlagen gekennzeichnet, und diese Fehler verzögern die RPO, bis Sie die Ressource aus dem Bereich der Failover-Gruppe entfernen.
  • Sekundäre Kataloge im Bereich sind schreibgeschützt. Die Schreibschutzfunktion gilt nur für replizierte Entitäten. Sie können weiterhin eine eigene Replikation für sicherbare Elemente außerhalb des Bereichs von Managed DR einrichten. Sie können jedoch im sekundären Arbeitsbereich keine Compute-Workloads ausführen, solange verwaltetes DR aktiviert ist, was den Betrieb einer selbst erstellten Replikationspipeline dort einschränkt.
  • Das Umbenennen eines „Unity Catalog“-Objekts löst im sekundären System ein Löschen und erneutes Erstellen aus. Bei verwalteten Tabellen repliziert die Umbenennung die Tabellendaten im nächsten Zyklus erneut. Vermeiden Sie Umbenennungen während einer stabilen Replikation.
  • UNDROP wird nicht an den sekundären Server weitergegeben.
  • Maximal 300 Kataloge pro Konto.
  • Maximal 100 Failovergruppen pro Konto.
  • Das anfängliche Bootstrapping von Workspace-Assets kann bei großen Workspaces bis zu zwei Wochen dauern.

Reference

Wenn eine Ressource nicht repliziert werden kann, zeigt die Failovergruppe eine Fehlerklasse in der system.replication.states Systemtabelle zusammen mit einer Meldung an, die die betroffene Ressource identifiziert. In den folgenden Abschnitten werden die am häufigsten verwendeten Fehlerklassen und deren Behebung behandelt. Die Replikation wird automatisch wiederhergestellt, nachdem Sie das zugrunde liegende Problem behoben haben.

DR_MISSING_DEPENDENCY

Ein Objekt verweist auf eine Abhängigkeit, die nicht in der sekundären Ressource vorhanden ist, sodass die Ressource nicht repliziert werden kann. Die Unterklasse identifiziert den fehlenden Abhängigkeitstyp und wird als DR_MISSING_DEPENDENCY.CATALOG, .SCHEMA, , .TABLEoder .RESOURCEangezeigt . Die Auflösung ist für alle identisch.

  1. Überprüfen Sie, ob die Ressource aufgrund der fehlenden Abhängigkeit auch im primären System fehlerhaft ist. Wenn dies der Grund ist, korrigieren oder entfernen Sie die Ressource im primären.
  2. Wenn die Ressource im primären Bereich gültig ist, befindet sich die Abhängigkeit entweder nicht im Replikationsbereich einer Failovergruppe, oder sie befindet sich im Bereich dieser oder einer anderen Failovergruppe, konnte aber nicht repliziert werden. Wenn sich die Abhängigkeit nicht im Bereich befindet, bearbeiten Sie den Replikationsbereich der Failovergruppe, um sie ebenfalls zu replizieren. Wenn die Abhängigkeit bereits im Geltungsbereich liegt, prüfen Sie in system.replication.states, welcher Fehler ihre Replikation blockiert, und beheben Sie diesen Fehler.
DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

Verwaltetes DR entscheidet, wo die einzelnen replizierten Ressourcen platziert werden sollen, indem die Speicherzuordnungen der Failovergruppe auf den Quellspeicherort der Ressource angewendet werden. Eine Zuordnung stimmt entweder genau mit einem Pfad überein oder mit einem Präfix, das auch untergeordnete Pfade abdeckt. Dieser Fehler bedeutet, dass keine Zuordnung einen Quellspeicherort abdeckt, sodass die verwaltete Notfallwiederherstellung nicht bestimmen kann, welchem Speicherort in der sekundären Umgebung das Objekt zugeordnet werden soll. Bei externen Tabellen und Volumes bedeutet eine fehlende Zuordnung, dass dieselbe Speicherort-URI für die Primär- und Sekundärinstanz verwendet wird. Das storage_location in der Nachricht ist der nicht zugeordnete Quellpfad.

  1. Wechseln Sie in der Kontokonsole zu Ausfallsicherheit → Failovergruppen , und bearbeiten Sie die Failovergruppe.
  2. Fügen Sie unter Speicherzuordnungen eine Zuordnung hinzu oder erweitern Sie eine vorhandene, sodass sie den in der Nachricht angegebenen Quellspeicherort abdeckt. Um untergeordnete Pfade abzudecken, ordnen Sie einen übergeordneten Pfad zu und fügen Sie das Suffix /* für den Präfixabgleich hinzu. Siehe Storage-Zuordnungen.
  3. Bestätigen Sie, dass ein externer Speicherort im sekundären Metastore bereits den Zielpfad der Zuordnung abdeckt. Die Failovergruppe lehnt eine Zuordnung ab, deren Ziel keinem vorhandenen externen Speicherort untergeordnet ist. Erstellen Sie daher zuerst diesen externen Speicherort, wenn er nicht vorhanden ist. Siehe Verbinden mit Cloudobjektspeicher mithilfe des Unity-Katalogs.
DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION

Eine Speicherzuordnung hat ein repliziertes Objekt einem Zielpfad in der Sekundärinstanz zugeordnet, aber kein externer Speicherort im sekundären Metastore deckt diesen Pfad ab, sodass Unity Catalog keinen Ort hat, an dem die Daten des Objekts abgelegt werden können. Das storage_location in der Nachricht ist der nicht abgedeckte sekundäre (Ziel-)Pfad.

Dies bedeutet in der Regel eines von zwei Dingen: ein externer Speicherort, der zuvor den Pfad abgedeckt hat, wurde entfernt oder eingeschränkt, oder eine neu replizierte Ressource wird in einen sekundären Pfad aufgelöst, der von keinem externen Speicherort abgedeckt wird. Der zweite Fall tritt z. B. auf, wenn Sie eine externe Tabelle in der Primären unter einem Speicherpfad erstellen, der von keiner Ihrer Speicherzuordnungen abgedeckt wird. Verwaltetes DR greift dann auf den ursprünglichen Pfad der Tabelle zurück, der keine externe Position im sekundären Metastore abdeckt, sodass die Daten nirgendwo landen können.

  1. Identifizieren Sie den nicht abgedeckten Sekundärpfad aus dem storage_location der Nachricht.
  2. Entscheiden Sie, welcher externe Speicherort im sekundären Metastore diesen Pfad abdecken soll: einen vorhandenen externen Speicherort, den Sie erweitern, oder einen neuen Speicherort, den Sie erstellen.
  3. Passen Sie entweder die Speicherzuordnungen der Failovergruppe an, damit der Pfad unter einem externen Speicherort aufgelöst wird, der bereits vorhanden ist, oder erstellen Sie den externen Speicherort (mit seinen Speicheranmeldeinformationen), und erweitern Sie die Zuordnung so, dass sie darauf verweist. Siehe Verbinden mit Cloudobjektspeicher mithilfe des Unity-Katalogs.
DR_INTERNAL_ERROR

Während der Replikation ist ein systemseitiger Fehler aufgetreten. Es ist keine Aktion erforderlich; das System wird automatisch wiederhergestellt. Wenden Sie sich an Azure Databricks Support, wenn das Problem nicht eigenständig behoben wird.

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

Managed DR repliziert die Ansicht zusammen mit ihren Berechtigungen, aber bei einer Ansicht, die auf Objekte in anderen Katalogen verweist, muss ihr Besitzer im Sekundärsystem auch Zugriff auf diese referenzierten Objekte haben, da die Ansicht mit den Berechtigungen des Besitzers ausgeführt wird. Dieser Fehler bedeutet, dass dem Besitzer dieser Zugriff auf dem sekundären System fehlt, sodass Sie ihn dort für die referenzierten Objekte gewähren müssen.

  1. Suchen Sie die von der Ansicht referenzierten Objekte und den Eigentümer der Ansicht. Referenzierte Objekte werden in der Definition als vollqualifizierte catalog.schema.object Namen angezeigt. Zuschüsse müssen zum Besitzer gehen, den Sie auch aus dem Feld "Besitzer " im Katalog-Explorer lesen können.

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

  2. Überprüfen Sie auf der sekundären Seite die aktuellen Berechtigungen des Besitzers für jedes referenzierte Objekt. Zum Lesen einer Tabelle sind USE CATALOG für ihren Katalog, USE SCHEMA für ihr Schema und SELECT für die Tabelle erforderlich.

    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. Gewähren Sie dem Ansichtsbesitzer alle fehlenden Berechtigungen für jedes referenzierte 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. Vergewissern Sie sich, dass jeder Katalog, in dem die Ansichtsverweise enthalten sind, im Replikationsbereich einer Failovergruppe enthalten ist, sodass er auch im sekundären Bereich vorhanden ist.

Weitere Informationen finden Sie unter Verwalten von Berechtigungen im Unity-Katalog.

DR_INVALID_CONFIGURATION.NETWORK_UNAUTHORIZED_ACCESS

Während der regionsübergreifenden Tabellendatenreplikation liest der serverlose Server des sekundären Arbeitsbereichs Daten aus dem Quellspeicher und der Speicher verweigert die Netzwerkverbindung: Eine Speicherfirewall oder Netzwerkregel hat sie blockiert, oder ein erforderlicher privater Endpunkt fehlt oder wurde nicht genehmigt.

Stellen Sie sicher, dass Ihr Quell- und sekundärer Speicher Azure Databricks serverlosen Netzwerkzugriff zulassen, wie in den Anforderungen beschrieben.

DR_INVALID_CONFIGURATION.SERVERLESS_COMPUTE_PERMISSION

Verwaltetes DR verwendet serverlose Berechnung im sekundären Arbeitsbereich, um Daten zu kopieren, und serverlose Berechnung ist dort nicht zulässig. Dies bedeutet in der Regel, dass Serverless für das Konto oder den Arbeitsbereich deaktiviert ist oder der Arbeitsbereich nicht berechtigt ist.

  1. Bestätigen Sie, dass der sekundäre Arbeitsbereich berechtigt ist. Serverless Compute ist standardmäßig in Unity Catalog-fähigen Arbeitsbereichen in einer unterstützten Region verfügbar. Siehe Verbindung mit serverlosem Computing herstellen.
  2. Suchen Sie nach einer kontoweiten Abmeldung. Wechseln Sie in der Kontokonsole zu "Einstellungen " → Featureaktivierung , und überprüfen Sie, ob der serverlose Umschalter vorhanden und deaktiviert ist.
  3. Aktivieren Sie Serverless für den gewünschten Umfang. Damit jeder berechtigte Arbeitsbereich aktiviert wird, aktiviert ein Kontoadministrator den serverlosen Schalter auf Kontoebene. Um nur den sekundären Arbeitsbereich zu aktivieren, lassen Sie den Umschalter auf Kontoebene aus, und lassen Sie einen Arbeitsbereichsadministrator serverlos aus der Vorschau des Arbeitsbereichs aktivieren.
  4. Wenn kein Schalter verfügbar ist oder Serverless auch dann nicht funktioniert, nachdem Sie es aktiviert haben, wenden Sie sich an Ihr Azure Databricks Account-Team.
DR_INVALID_CONFIGURATION.OVERLAPPING_EXTERNAL_LOCATIONS

Wenn verwaltete DR ein repliziertes Objekt an seinem zugeordneten Zielpfad in der sekundären Umgebung erstellt, lehnt Unity Catalog den Pfad ab, da er sich mit dort bereits vorhandenem Speicher überschneidet, z. B. mit einem vorhandenen externen Speicherort, einem zurückgebliebenen sicherbaren Objekt aus einer früheren oder unvollständigen Einrichtung, einem verwalteten Speicherort oder dem Standardspeicher des Arbeitsbereichs (DBFS).

  1. Identifizieren Sie, was den Pfad belegt.

    Überprüfen Sie im Katalog-Explorer Ihre externen Speicherorte, verwalteten Speicherorte und externen Tabellen und Volumes, um das Objekt zu finden, dessen Pfad den Zielpfad abdeckt oder überlappt.

  2. Wenn das widersprüchliche Objekt den Pfad nicht besitzen soll, entfernen Sie es. Eine häufige Ursache ist eine externe Tabelle oder ein externes Volume, das von einer vorherigen Konfiguration übrig geblieben ist; löschen Sie es, wenn es nicht mehr benötigt wird. Wenn es sich um einen externen Speicherort handelt, der den Pfad nicht abdecken soll, entfernen oder neu definieren.

  3. Andernfalls leiten Sie die Speicherzuordnung der Failovergruppe auf einen dedizierten, nicht überlappenden Zielpfad um. Bevorzugen Sie einen bestimmten Unterpfad anstelle eines allgemeinen Bucket-Stammverzeichnisses, und vermeiden Sie den Standardspeicher des Arbeitsbereichs (DBFS).

DR_UNSUPPORTED_FEATURE

Die Ressource verwendet ein Feature, das verwaltetes DR nicht replizieren kann. Die Unterklasse identifiziert die nicht unterstützte Funktion und erscheint beispielsweise als DR_UNSUPPORTED_FEATURE.ABAC_POLICY. Es gibt zwei Möglichkeiten, diesen Fehler zu beheben.

  1. Entfernen Sie das nicht unterstützte Feature aus der Ressource im primären Arbeitsbereich.
  2. Wenn Sie die Funktion nicht entfernen können, ziehen Sie in Erwägung, die Ressource aus dem Replikationsbereich der Failovergruppe zu entfernen.

Informationen zu DR-Konzepten und bewährten Methoden finden Sie unter Notfallwiederherstellung.

  • Last updated on