Zarządzane odzyskiwanie po awarii

Zarządzane odzyskiwanie po awarii (DR) replikuje wdrożenie Azure Databricks do regionu zapasowego, dzięki czemu można przywrócić działanie po awarii regionalnej w ciągu kilku minut. Azure Databricks zarządza potokiem replikacji, stanem replikowanych katalogów w środowisku pomocniczym oraz procesem przełączania awaryjnego. Skrypty replikacji nie są zapisywane ani obsługiwane.

Aby zapoznać się z ręcznym podejściem do odzyskiwania po awarii, w tym ogólnymi pojęciami odzyskiwania po awarii i najlepszymi rozwiązaniami, zobacz Odzyskiwanie po awarii.

Ważne

Zarządzane odzyskiwanie po awarii jest objęte ograniczeniem dostępu. Złóż wniosek o dostęp za pośrednictwem zespołu obsługującego Twoje konto Azure Databricks. Azure Databricks umożliwia zarządzane odzyskiwanie po awarii dla Twojego konta po zaakceptowaniu Twojego zgłoszenia.

Co to jest zarządzane odzyskiwanie po awarii?

Zarządzane odzyskiwanie po awarii bazuje na przestrzeniach roboczych i magazynach metadanych, którymi już zarządzasz. Masz dwa obszary robocze usługi Azure Databricks, jeden w regionie podstawowym i jeden w regionie pomocniczym, oraz magazyn metadanych w każdym z regionów. Następnie: zarządzane odzyskiwanie po awarii:

  • Replikuje kategorie, do których decydujesz się z podstawowego do pomocniczego zgodnie z harmonogramem ciągłym. Obie kategorie są niezależnie opcjonalne: metadane Unity Catalog i dane tabel zarządzanych oraz zasoby obszaru roboczego, takie jak notatniki, zadania, magazyny SQL, klastry i listy ACL.
  • Udostępnia opcjonalny stabilny adres URL — pojedynczy ciąg połączenia, który zawsze wskazuje bieżący węzeł podstawowy, dzięki czemu klienci nadal działają po przełączeniu awaryjnym bez konieczności ponownej konfiguracji.
  • Umożliwia uruchomienie przełączenia awaryjnego wtedy, gdy tego chcesz — na potrzeby testu odzyskiwania po awarii lub rzeczywistej awarii.

Identyfikatory zasobów obszaru roboczego są zachowywane we wszystkich regionach, więc adresy URL, które odwołują się do zasobu obszaru roboczego za pomocą identyfikatora, nadal działają po przełączeniu awaryjnym.

Co jest replikowane

Zarządzane odzyskiwanie po awarii może replikować następujące elementy w każdym cyklu replikacji. Obie kategorie są opcjonalne, więc można włączyć jedną lub obie kategorie:

  • Metadane i dane Unity Catalog: tabele zarządzane w Unity Catalog w Delta Lake wraz z danymi, tabele zewnętrzne i woluminy (tylko metadane), widoki, funkcje oraz wszystkie przyznane uprawnienia. Tryb izolacji katalogu jest replikowany. Jeśli katalog źródłowy jest otwarty, replika jest otwarta. Jeśli źródło jest izolowane i powiązane z podstawowym obszarem roboczym, replika jest izolowana i powiązana z pomocniczym obszarem roboczym.
  • Zasoby obszaru roboczego: notesy, zadania, magazyny SQL, klastry, wersje robocze pulpitów nawigacyjnych sztucznej inteligencji/analizy biznesowej, pliki i foldery wraz z listami ACL. Magazyny SQL są replikowane w STOPPED stanie, klastry w TERMINATED stanie. Harmonogramy zadań w pomocniczym są wstrzymane.

Własność replikowanych obiektów

Gdy zarządzane odzyskiwanie po awarii tworzy replikowany obiekt zabezpieczany (katalog, schemat, tabelę, widok, funkcję lub wolumin) w lokalizacji pomocniczej, początkowym właścicielem jest jednostka usługi Azure Databricks uruchamiająca replikację, ponieważ Unity Catalog przypisuje własność tożsamości, która tworzy obiekt. Następnie funkcja Managed DR przenosi własność repliki, tak aby odpowiadała ona właścicielowi odpowiadającego jej zabezpieczalnego obiektu w podstawowej bazie danych.

Jeśli właścicielem obiektu zabezpieczalnego w podstawowej bazie danych jest użytkownik, który został usunięty z konta, zarządzane odzyskiwanie po awarii nie może przenieść własności na podmiot zabezpieczeń, który już nie istnieje. W takim przypadku zabezpieczalny obiekt repliki zachowuje jednostkę usługi Azure Databricks jako właściciela. Aby rozwiązać ten problem, przypisz prawidłowego właściciela do zabezpieczanego obiektu w środowisku podstawowym i pozwól, aby środowisko DR go zreplikowało.

Requirements

Aby skonfigurować zarządzaną DR, musisz mieć następujące wymagania:

  • Obszar roboczy objęty planem Premium zarówno w regionie podstawowym, jak i pomocniczym.

Wymagania wstępne dotyczące konfiguracji

Aby korzystać z zarządzanego DR, upewnij się, że następujące ustawienia i zasoby są skonfigurowane.

Category Szczegóły
Pomocnicza przestrzeń robocza i magazyn metadanych
  • Zapasowy obszar roboczy i metastore usługi Unity Catalog w regionie zapasowym, na tym samym koncie Azure Databricks i w tej samej chmurze co podstawowy obszar roboczy.
  • Zwróć uwagę na następujące kwestie podczas konfigurowania elementu pomocniczego:
    • Pomocniczy magazyn metadanych nie może zawierać wykazów, które współużytkują nazwy z replikowanymi wykazami.
    • W przypadku replikacji zasobów obszaru roboczego Azure Databricks usuwa wszystkie istniejące zasoby objęte zakresem replikacji w pomocniczym obszarze roboczym po zakończeniu replikacji początkowej. Nie ma to wpływu na zasoby poza zakresem, więc pomocniczy obszar roboczy nie musi być pusty.
Identity
  • SSO na poziomie konta z włączonymi wszystkimi przestrzeniami roboczymi i tożsamościami synchronizowanymi z kontem przez AIM lub SCIM, tak aby użytkownicy, grupy i podmioty usługowe istnieli w obu regionach.
  • Dla stabilnych adresów URL: niestandardowy adres URL udostępniony dla domeny Azure Databricks (skontaktuj się z opiekunem konta) oraz uwierzytelnianie OAuth na poziomie konta.
Przechowywanie i dostęp do danych
  • Łącznik dostępu usługi Azure Databricks w regionie pomocniczym, z rolą Współautor danych obiektów blob usługi Storage na pomocniczych kontach magazynu, dodany jako poświadczenie magazynu w pomocniczym obszarze roboczym.
  • Odpowiadająca lokalizacja zewnętrzna i poświadczenie magazynu danych w regionie pomocniczym dla każdego elementu, do którego odwołują się katalogi podstawowe. Zarządzany DR nie replikuje automatycznie zewnętrznych lokalizacji ani poświadczeń dostępu do magazynu. Musisz je utworzyć w pomocniczym.
Sieć komputerowa
  • Upewnij się, że następujące obiekty na poziomie konta są powiązane zarówno z przestrzenią podstawową, jak i drugorzędną: Konfiguracja łączności sieciowej (NCC), Polityka sieciowa (wyjście bez serwera), Ustawienia dostępu prywatnego (PAS) oraz lista dostępu IP.
  • Zarówno źródłowy, jak i pomocniczy magazyn danych muszą zezwalać na bezserwerowy dostęp sieciowy usługi Azure Databricks w obu kierunkach.
  • Konfiguracja łączności sieciowej (NCC) w regionie pomocniczym, przypisana do pomocniczego obszaru roboczego, dzięki czemu bezserwerowe zasoby obliczeniowe mogą uzyskiwać dostęp do magazynu za pośrednictwem prywatnych punktów końcowych. Zobacz Konfigurowanie łączności prywatnej z zasobami platformy Azure.
  • Prywatne punkty końcowe do każdego źródłowego i pomocniczego konta magazynu, do których odwołuje się replikowane wykazy. W przypadku magazynu ADLS Gen2 utwórz prywatny punkt końcowy dla obu podzasobów, dfs i blob, dla każdego konta. Zatwierdź je w portalu Azure.
Koszty i zarządzanie
  • Powiąż zasadę korzystania z zasobów bezserwerowych na poziomie konta (dawniej zasadę budżetową dla zasobów bezserwerowych) z główną i pomocniczą przestrzenią roboczą.

Włączanie funkcji Mission Critical w obu obszarach roboczych

Przed utworzeniem grupy pracy awaryjnej włącz dodatek Mission Critical w obu przestrzeniach roboczych — podstawowej i pomocniczej. Użycie zasobów obliczeniowych w każdym obszarze roboczym, w którym włączono dodatek, jest rozliczane według współczynnika misji krytycznej. Skontaktuj się z zespołem ds. kont Azure Databricks, aby uzyskać bieżącą stawkę.

  1. W konsoli konta kliknij pozycję Obszary robocze, a następnie kliknij obszar roboczy.
  2. Kliknij kartę Dodatki .
  3. Na karcie Mission Critical włącz przełącznik i potwierdź.

Powtórz w przypadku pomocniczego obszaru roboczego.

Opcjonalnie: stabilny adres URL

Azure Databricks zaleca używanie stabilnego adresu URL. Stabilny adres URL zawsze wskazuje na aktualny podstawowy obszar roboczy, więc klienci łączący się za jego pośrednictwem nie wymagają ponownej konfiguracji po przełączeniu awaryjnym. Oryginalny adres URL obszaru roboczego pozostaje prawidłowy i nadal umożliwia bezpośredni dostęp do tego obszaru roboczego, ale po przełączeniu awaryjnym nadal wskazuje stary serwer podstawowy, który jest teraz serwerem pomocniczym. Skieruj następujących klientów podrzędnych na stabilny adres URL zamiast oryginalnego adresu URL obszaru roboczego:

  • Internetowy interfejs użytkownika Azure Databricks.
  • Połączenia JDBC i ODBC z magazynami SQL.
  • Bezpośrednie żądania interfejsu API REST.

Stabilne adresy URL są obsługiwane przez wejściowy front-end Private Link. W przypadku przychodzącego połączenia Private Link stabilny adres URL ma postać niestandardowego adresu URL ze stałym identyfikatorem połączenia zamiast standardowego formatu adresu URL obszaru roboczego.

Na przykład stabilny adres URL ma postać <my-custom-url>.azuredatabricks.net/?c=stable_connection_id. Zobacz Konfigurowanie przychodzącego połączenia Private Link dla obszarów roboczych z zarządzanym odzyskiwaniem po awarii.

Konfigurowanie replikacji

Nowa grupa przełączania awaryjnego przechodzi kolejno przez CREATING → INITIAL_REPLICATION → ACTIVE. Pierwszy cykl replikacji kopiuje wszystkie dane objęte zakresem replikacji do lokalizacji pomocniczej. W przypadku dużych obszarów roboczych początkowa inicjalizacja zasobów obszaru roboczego może potrwać do dwóch tygodni. To oczekiwanie jest jednorazowe. Po zakończeniu początkowego ładowania replikacja działa nieprzerwanie.

Podczas replikacji wtórne katalogi objęte zakresem są dostępne tylko do odczytu, a moc obliczeniowa jest niedostępna w wtórnym obszarze roboczym. Aby uruchamiać zapytania sprawdzania poprawności bez zapisywania w pomocniczej wersji, Azure Databricks zaleca oddzielny obszar roboczy monitora tylko do odczytu w regionie pomocniczym.

Aby utworzyć grupę przełączania awaryjnego:

  1. W konsoli konta kliknij pozycję Odporność.
  2. Jeśli planujesz użyć stabilnego adresu URL, kliknij kartę Stabilne adresy URL, a następnie utwórz stabilny adres URL. Wprowadź nazwę, wybierz bieżący podstawowy obszar roboczy i utwórz stabilny adres URL. Skieruj klientów podrzędnych (JDBC, ODBC, internetowy interfejs użytkownika Azure Databricks, bezpośrednie żądania API) na stabilny adres URL zamiast oryginalnego adresu URL obszaru roboczego.
  3. Kliknij kartę Grupy trybu failover, a następnie Utwórz grupę trybu failover.
  4. Wypełnij formularz:
    • Nazwa grupy przełączania awaryjnego: nazwa wybrana dla grupy przełączania awaryjnego.
    • Podstawowy obszar roboczy: obszar roboczy, który jest Twoim podstawowym obszarem roboczym.
    • Obszar roboczy pomocniczy: Obszar roboczy w regionie pomocniczym.
    • Replikowanie zasobów obszaru roboczego (opcjonalnie): domyślnie wyłączone. Włącz replikację notesów, zadań, magazynów SQL, klastrów, pulpitów nawigacyjnych, plików i folderów (oraz ich list ACL) z podstawowej do pomocniczej. Wymaga włączenia dodatku Mission Critical dla obu obszarów roboczych. Jeśli włączysz replikację zasobów obszaru roboczego, Azure Databricks usunie wszystkie istniejące zasoby w zakresie pomocniczym po zakończeniu replikacji początkowej. Nie ma to wpływu na zasoby poza zakresem.
    • Stabilny adres URL (opcjonalnie): stabilny adres URL utworzony w kroku 2.
    • Zakres replikacji: Katalogi do replikacji. Aby to pole było dostępne, musisz wybrać podstawowy obszar roboczy.
    • Mapowania pamięci masowej: Dla każdej lokalizacji zewnętrznej używanej przez replikowane katalogi w regionie podstawowym dodaj wpis, który mapuje jej ścieżkę pamięci masowej na odpowiadającą jej lokalizację zewnętrzną utworzoną w regionie wtórnym (zobacz Wymagania). Można użyć * jako symbolu wieloznacznego do dopasowania prefiksów.
  5. Kliknij pozycję Utwórz grupę przełączania awaryjnego.

Na przykład mapowanie usługi Azure Storage może przypisywać abfss://data@primary.dfs.core.windows.net/* do abfss://data@secondary.dfs.core.windows.net/*.

Zasoby utworzone przez zarządzane DR

Podczas tworzenia grupy przełączania awaryjnego funkcja zarządzanego odzyskiwania po awarii (DR) tworzy pomocnicze zasoby Unity Catalog, których potok replikacji używa do kopiowania danych między regionami. Zarówno w głównych, jak i pomocniczych repozytoriach metadanych zarządzane odzyskiwanie po awarii (DR) tworzy:

  • Połączenie wskazujące obszar roboczy w innym regionie.
  • Wykaz obcy dla każdego zreplikowanego wykazu. Wykaz obcy odwołuje się do odpowiedniego wykazu w innym regionie.

Te zasoby są wyświetlane obok własnych katalogów w Eksploratorze wykazu. Można je zidentyfikować po komentarzu, w którym zaznaczono, że są tworzone i zarządzane przez funkcję odzyskiwania po awarii w usłudze Azure Databricks.

Ważne

Domyślnie tylko administrator magazynu metadanych może modyfikować lub usuwać te zasoby. Nie usuwaj połączeń ani katalogów obcych utworzonych przez usługę Managed DR. Usunięcie którejkolwiek z nich powoduje przerwanie replikacji w grupie failover.

Stabilny identyfikator obszaru roboczego

Niektóre narzędzia identyfikują przestrzeń roboczą na podstawie jej identyfikatora zamiast adresu URL, w tym dostawcę Terraform dla Databricks i pakiety zasobów Databricks. Każdy stały adres URL ma stały identyfikator obszaru roboczego, który wskazuje na bieżący obszar podstawowy, dzięki czemu te narzędzia nadal kierują do aktywnego obszaru roboczego po przełączeniu awaryjnym. Użyj identyfikatora stabilnego obszaru roboczego wszędzie tam, gdzie narzędzie prosi o identyfikator obszaru roboczego, w taki sam sposób, jak w przypadku zwykłego identyfikatora obszaru roboczego.

Aby znaleźć identyfikator stabilnego obszaru roboczego, wyświetl listę stabilnych adresów URL dla konta przy użyciu interfejsu wiersza polecenia usługi Databricks i przeczytaj stable_workspace_id pole odpowiedniego stabilnego adresu URL:

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

Wdrażaj za pomocą pakietów zasobów Databricks i Terraform

Databricks Asset Bundles (DABs) i dostawca Terraform dla Databricks wskazują obszar roboczy za pomocą adresu URL hosta obszaru roboczego albo za pomocą kombinacji niestandardowego adresu URL konta Azure Databricks i identyfikatora obszaru roboczego. Aby nadal wdrażać na obecnym hoście podstawowym po przełączeniu awaryjnym, ustaw hosta na własny adres URL — czyli część hosta stabilnego adresu URL, a nie oryginalny adres URL przypisany do obszaru roboczego — i podaj w polu workspace_id. Oba wskazują na bieżący węzeł podstawowy, dzięki czemu potoki CI/CD nadal wdrażają do aktywnego obszaru roboczego po przełączeniu awaryjnym, bez zmiany konfiguracji.

  • Nowe wdrożenia: użyj niestandardowego adresu URL i stabilnego identyfikatora obszaru roboczego z pierwszego wdrożenia.
  • Istniejące wdrożenia: zaimportuj stan z poprzedniego projektu terraform do nowego projektu skonfigurowanego przy użyciu niestandardowego adresu URL i stabilnego identyfikatora obszaru roboczego, a następnie usuń poprzedni projekt. Nie należy ponownie określać istniejącego projektu — wdrożenie nie rozpoznaje już zasobów utworzonych względem oryginalnego adresu URL dla obszaru roboczego, więc ponowne wdrożenie niszczy je i tworzy je ponownie.
  • DABs: włącz replikację zasobów obszaru roboczego w grupie przełączenia awaryjnego. Pakiet przechowuje stan wdrożenia w obszarze roboczym, a stan ten osiąga nowy element podstawowy tylko w ramach replikacji zasobów obszaru roboczego.

Note

Po przełączeniu awaryjnym pierwsze ponowne wdrożenie odtwarza wszystkie zasoby, których zarządzane odzyskiwanie po awarii (DR) nie replikuje, ponieważ nie istnieją one w nowym środowisku podstawowym. Replikowane zasoby pozostają na miejscu. Zobacz Ograniczenia, aby dowiedzieć się, co jest, a co nie jest replikowane przez zarządzane odzyskiwanie po awarii.

Monitorowanie replikacji

Na karcie Grupy pracy awaryjnej są wyświetlane bieżący stan każdej grupy pracy awaryjnej, punkt replikacji oraz wszelkie aktywne błędy. Możliwe stany:

State Meaning
CREATING Grupa trybu failover jest aprowizowana.
INITIAL_REPLICATION Pierwszy cykl replikacji jest w toku. Tryb failover nie jest jeszcze dostępny.
ACTIVE Replikacja jest w stanie stabilnym. Tryb failover jest dostępny.
FAILING_OVER Trwa przełączanie awaryjne.
FAILOVER_FAILED, CREATION_FAILED, DELETION_FAILED Operacja nie została ukończona. Sprawdź szczegóły stanu grupy przełączania awaryjnego, aby uzyskać wskazówki.

Wybierz nazwę grupy trybu failover, aby otworzyć jej stronę szczegółów. Replikacja trwa nieprzerwanie, ale punkt replikacji wskazuje ostatni moment, w którym wszystkie zasoby objęte zakresem zostały skopiowane łącznie. Poszczególne zasoby mogą być bardziej aktualne, ale nie wszystkie dane po punkcie replikacji mogą istnieć w pomocniczej wersji i mogą zostać utracone podczas pracy w trybie failover.

Gdy pokazany jest punkt replikacji, wszystko, co nie jest objęte błędem, zostało do tego momentu zreplikowane. Podczas początkowej replikacji, zanim pojawi się pierwszy punkt replikacji, grupa failover może nadal wykazywać błędy blokowania, ale jeszcze nie mierzy kompletności. Typy zasobów, których zarządzane odzyskiwanie po awarii (DR) w ogóle nie obsługuje, nie pojawiają się w tabeli systemowej system.replication.states. Zobacz Ograniczenia. Aby sprawdzić konkretny zasób, sprawdź go w lokalizacji pomocniczej (zobacz sekcję Konfigurowanie replikacji).

Aby śledzić historyczne trendy RPO i sprawdzać błędy blokujące replikację, wykonaj zapytanie do tabeli systemowej system.replication.states. Zobacz informacje referencyjne dotyczące tabeli systemowej replikacji. Aby uzyskać najbardziej typowe klasy błędów i sposoby ich rozwiązywania, zobacz Dokumentacja.

Przechodzenie w tryb failover i powrót po awarii

Ta sama procedura obejmuje planowane przełączenia awaryjne (testy odzyskiwania po awarii, zaplanowana konserwacja) oraz nieplanowane przełączenia awaryjne (awaria w regionie). Aby powrócić po awarii, powtórz procedurę z odwróconymi regionami.

Po zainicjowaniu przełączenia awaryjnego platforma Azure Databricks:

  • Wskazuje stabilny adres URL, jeśli jest dołączony, do nowego regionu podstawowego.
  • Odwraca kierunek replikacji.
  • Wstrzymuje harmonogramy zadań w poprzednim podstawowym.
  • Przełącza grupę trybu failover z FAILING_OVER do INITIAL_REPLICATION.

Aby przełączyć się na system zapasowy:

  1. Powiadom zespół, że rozpoczyna się przełączenie awaryjne.

  2. Tylko w przypadku planowanego przejścia w tryb failover:

    1. W podstawowym obszarze roboczym zakończ wszystkie uruchomione klastry i zatrzymaj wszystkie magazyny SQL.
    2. Potwierdź, że zapisy do węzła podstawowego zostały wstrzymane, a następnie poczekaj, aż replikacja nadrobi opóźnienie. Aby to sprawdzić, otwórz stronę szczegółów grupy przełączania awaryjnego i upewnij się, że punkt replikacji różni się od chwili zatrzymania zapisów o najwyżej kilka sekund.

  3. W konsoli konta kliknij pozycję Odporność → Grupy przełączania awaryjnego, a następnie kliknij nazwę grupy przełączania awaryjnego.

  4. Kliknij Fail over.

  5. Wybierz nowy region podstawowy i potwierdź. Przejście w tryb failover zakończy się w ciągu kilku minut.

  6. Na nowym węźle podstawowym uruchom zasób obliczeniowy, który działał przed przełączeniem awaryjnym. Zreplikowane klastry i magazyny SQL pojawiają się w nowym środowisku podstawowym odpowiednio w stanie TERMINATED i STOPPED.

  7. Ręcznie wznów potrzebne harmonogramy zadań na nowym serwerze podstawowym. Harmonogramy byłego podstawowego są już wstrzymane.

Klienci połączeni za pośrednictwem stabilnego adresu URL kontynuują pracę po przejściu w tryb failover. Przekieruj klientów, którzy nadal używają oryginalnego adresu URL obszaru roboczego, tak aby korzystali ze stabilnego adresu URL lub adresu URL obszaru roboczego nowego podstawowego obszaru roboczego.

Ważne

Podczas nieplanowanego przełączenia awaryjnego dane zapisane w systemie podstawowym po ostatnim punkcie replikacji mogą zostać utracone. Upewnij się, że ewentualna utrata danych nie przekracza docelowej wartości RPO.

Tip

Regularnie testuj tryb failover, na przykład raz na kwartał, aby twój zespół zapoznał się z procedurą przed rzeczywistą awarią.

Zburzyć zarządzane odzyskiwanie po awarii

  1. W konsoli konta kliknij pozycję Odporność → Grupy trybu failover, a następnie kliknij nazwę grupy trybu failover i usuń ją. Nie można wyłączyć funkcji Mission Critical, gdy grupa trybu failover jest aktywna w obszarze roboczym.
  2. Aby zatrzymać naliczanie opłat według stawki Mission Critical, wyłącz Mission Critical na karcie Dodatki w każdym obszarze roboczym.

Limitations

Zarządzane odtwarzanie po awarii ma następujące ograniczenia:

  • Niezreplikowane: zmaterializowane widoki, tabele przesyłania strumieniowego, potoki Lakeflow, dane zarządzanego woluminu (replikowane metadane), wykaz aparatu Unity i wpisy tajne obszaru roboczego, modele uczenia maszynowego, model obsługujący punkty końcowe, indeksy wyszukiwania wektorów, udziały delta, opublikowane pulpity nawigacyjne sztucznej inteligencji/analizy biznesowej (replikowane wersje robocze) i przesyłanie strumieniowe ze strukturą platformy Spark poza potokami lakeflow. Tabele z filtrami wierszy lub maskami kolumn oraz zasoby oznaczone tagami ABAC są oznaczane w tabeli systemowej jako Replikacja nie powiodła się, a te niepowodzenia opóźniają realizację celu punktu odzyskiwania (RPO), dopóki nie usuniesz zasobu z zakresu działania grupy przełączania awaryjnego.
  • Zapisy do tabel zarządzanych z użyciem silników zewnętrznych są wykrywalne w ograniczonym stopniu. Zarządzane odzyskiwanie po awarii wykrywa zmiany w tabelach zarządzanych Unity Catalog wynikające z operacji zapisu wykonywanych przez zasoby obliczeniowe Azure Databricks. Zapisy do zreplikowanej tabeli zarządzanej z zewnętrznego silnika (spoza platformy Azure Databricks) za pośrednictwem otwartych interfejsów API, takich jak katalog REST Iceberg, mogą nie zostać wykryte, więc te operacje zapisu mogą nie zostać zreplikowane do repliki pomocniczej i mogą zostać utracone podczas przełączenia awaryjnego. W przypadku tabel replikowanych przy użyciu zarządzanego odzyskiwania po awarii (DR) zapisuj dane za pośrednictwem zasobów obliczeniowych Azure Databricks.
  • Drugorzędne katalogi objęte zakresem są tylko do odczytu. Tryb tylko do odczytu ma zastosowanie wyłącznie do replikowanych encji. Nadal możesz skonfigurować własną replikację dla zasobów podlegających zabezpieczeniu, które znajdują się poza zakresem zarządzanego odzyskiwania po awarii. Nie można jednak uruchamiać zadań obliczeniowych w pomocniczym obszarze roboczym, gdy włączone jest zarządzane odzyskiwanie po awarii, co ogranicza możliwość uruchomienia tam samodzielnie utworzonego potoku replikacji.
  • Zmiana nazwy obiektu zabezpieczanego w Unity Catalog powoduje usunięcie i ponowne utworzenie w systemie pomocniczym. W przypadku tabel zarządzanych zmiana nazwy ponownie replikuje dane tabeli w następnym cyklu. Unikaj zmieniania nazw podczas replikacji stanu stałego.
  • UNDROP nie jest propagowany do węzła pomocniczego.
  • Początkowa inicjalizacja zasobów obszaru roboczego może potrwać do 2 tygodni w przypadku dużych obszarów roboczych.
  • Korzystanie z zapory sieciowej magazynu obszaru roboczego na kontach magazynu obszaru roboczego używanych z funkcją zarządzanego odzyskiwania po awarii wymaga ręcznej konfiguracji. Należy zezwolić odpowiednim adresom IP płaszczyzny sterowania w zaporze magazynu, aby usługa Azure Databricks mogła replikować dane. Zobacz Wymagania.

Reference

Gdy nie można zreplikować zasobu, grupa trybu failover wyświetla klasę błędów w system.replication.states tabeli systemowej wraz z komunikatem identyfikującym dotknięty zasób. W poniższych sekcjach opisano najczęstsze klasy błędów i sposób ich rozwiązywania. Replikacja zostanie automatycznie wznowiona po usunięciu problemu leżącego u podstaw.

DR_MISSING_DEPENDENCY

Zasób odwołuje się do zależności, która nie istnieje w dokumentacji pomocniczej, więc nie można replikować zasobu. Podklasa identyfikuje brakujący typ zależności i jest wyświetlana jako DR_MISSING_DEPENDENCY.CATALOG, .SCHEMA, .TABLElub .RESOURCE. Rozdzielczość jest taka sama dla wszystkich z nich.

  1. Sprawdź, czy zasób jest również uszkodzony w głównym elemencie z powodu brakującej zależności. Jeśli tak jest, napraw lub usuń element zawartości w obiekcie podstawowym.
  2. Jeśli zasób jest prawidłowy w lokalizacji podstawowej, zależność albo nie znajduje się w zakresie replikacji żadnej grupy przełączania awaryjnego, albo znajduje się w zakresie replikacji tej lub innej grupy przełączania awaryjnego, ale nie została zreplikowana. Jeśli zależność nie jest objęta tym zakresem, zmodyfikuj zakres replikacji grupy trybu failover tak, aby również była replikowana. Jeśli zależność jest już w zakresie, sprawdź w elemencie system.replication.states, jaki błąd blokuje jego replikację, i rozwiąż ten błąd.
DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

Zarządzane odzyskiwanie po awarii określa, gdzie umieścić każdy zreplikowany zasób, na podstawie mapowań magazynu danych grupy przełączenia awaryjnego przypisanych do źródłowej lokalizacji magazynu danych zasobu. Mapowanie pasuje dokładnie do lokalizacji lub jako prefiks, który obejmuje również ścieżki podrzędne. Ten błąd oznacza, że żadne mapowanie nie obejmuje źródłowej lokalizacji magazynu danych, więc zarządzane odzyskiwanie po awarii (DR) nie może określić, gdzie w lokalizacji pomocniczej umieścić zasób. W przypadku tabel i woluminów zewnętrznych brakujące mapowanie oznacza, że ten sam identyfikator URI lokalizacji jest używany w podstawowej i pomocniczej wersji. Element storage_location w komunikacie to niezmapowana ścieżka źródła.

  1. W konsoli konta przejdź do pozycji Odporność → grupy przełączania awaryjnego i edytuj grupę przełączania awaryjnego.
  2. W sekcji Mapowania pamięci masowej dodaj lub rozszerz mapowanie, aby obejmowało lokalizację źródłową w komunikacie. Aby objąć ścieżki podrzędne, odwzoruj ścieżkę nadrzędną i dodaj sufiks /*, aby włączyć dopasowanie prefiksowe. Zobacz mapowania magazynu.
  3. Upewnij się, że lokalizacja zewnętrzna w pomocniczym magazynie metadanych już obejmuje ścieżkę docelową mapowania. Grupa przełączania awaryjnego odrzuca mapowanie, którego cel nie znajduje się w istniejącej lokalizacji zewnętrznej, dlatego jeśli ta lokalizacja jeszcze nie istnieje, najpierw ją utwórz. Zobacz Połączenie z magazynem obiektów w chmurze przy użyciu Unity Catalog.
DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION

Mapowanie magazynu danych przypisało zreplikowany zasób do ścieżki docelowej w pomocniczym metastorze, ale żadna lokalizacja zewnętrzna w pomocniczym metastorze nie obejmuje tej ścieżki, więc Unity Catalog nie ma gdzie umieścić danych tego zasobu. Element storage_location w komunikacie to nieosłonięta ścieżka pomocnicza (docelowa).

Zazwyczaj oznacza to jedną z dwóch rzeczy: lokalizacja zewnętrzna, która wcześniej obejmowała tę ścieżkę, została usunięta lub zawężona albo nowo zreplikowany zasób prowadzi do dodatkowej ścieżki, której nie obejmuje żadna lokalizacja zewnętrzna. Drugi przypadek występuje na przykład wtedy, gdy w katalogu głównym tworzysz tabelę zewnętrzną w ścieżce magazynu, której nie obejmuje żadne z mapowań magazynu. Zarządzany mechanizm DR przełącza się następnie z powrotem na oryginalną ścieżkę tabeli, której nie obejmuje żadna lokalizacja zewnętrzna w pomocniczym magazynie metadanych, więc dane nie mają gdzie trafić.

  1. Zidentyfikuj odkrytą ścieżkę pomocniczą z komunikatu storage_location.
  2. Zdecyduj, która lokalizacja zewnętrzna w pomocniczym metastore powinna obejmować tę ścieżkę: istniejąca lokalizacja zewnętrzna, którą rozszerzasz, czy nowa, którą tworzysz.
  3. Dostosuj mapowania magazynów grupy przełączania awaryjnego tak, aby ścieżka wskazywała istniejącą już lokalizację zewnętrzną, albo utwórz lokalizację zewnętrzną (wraz z poświadczeniem magazynu) i rozszerz mapowanie, aby na nią wskazywało. Zobacz Połączenie z magazynem obiektów w chmurze przy użyciu Unity Catalog.
DR_INTERNAL_ERROR

Wystąpił błąd po stronie systemu podczas replikacji. Nie jest wymagana żadna akcja; system zostanie automatycznie odzyskany. Skontaktuj się z pomocą techniczną Azure Databricks, jeśli problem nie zostanie rozwiązany samodzielnie.

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

Zarządzane odzyskiwanie po awarii replikuje widok wraz z nadanymi mu uprawnieniami, ale widok odwołujący się do obiektów w innych katalogach wymaga również, aby jego właściciel miał dostęp do tych obiektów, do których się odwołuje, w środowisku pomocniczym, ponieważ widok działa z uprawnieniami właściciela. Ten błąd oznacza, że właściciel nie ma tego uprawnienia na obiekcie podrzędnym, więc musisz nadać je na wskazanych tam obiektach.

  1. Znajdź obiekty, do których odwołuje się widok, oraz właściciela widoku. Obiekty, do których istnieją odwołania, są wyświetlane w definicji jako catalog.schema.object w pełni kwalifikowane nazwy; uprawnienia należy przyznać właścicielowi, którego można również odczytać z pola Właściciel w Eksploratorze wykazu.

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

  2. Na serwerze pomocniczym sprawdź aktualne uprawnienia właściciela do każdego obiektu, do którego się odwołano. Odczytanie tabeli wymaga uprawnienia USE CATALOG do katalogu, USE SCHEMA do schematu i SELECT do tabeli.

    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. Przyznaj właścicielowi widoku wszystkie brakujące uprawnienia do każdego obiektu, do którego istnieje odwołanie.

    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. Upewnij się, że każdy katalog, do którego odwołuje się widok, jest uwzględniony w zakresie replikacji grupy przełączania awaryjnego, tak aby istniał również w replice pomocniczej.

Aby uzyskać więcej informacji, zobacz Zarządzanie uprawnieniami w Unity Catalog.

DR_INVALID_CONFIGURATION.NETWORK_UNAUTHORIZED_ACCESS

Podczas replikacji danych tabel między regionami bezserwerowe zasoby obliczeniowe pomocniczego obszaru roboczego odczytują dane z magazynu źródłowego, ale magazyn odrzucił połączenie sieciowe: zapora magazynu lub reguły sieciowe zablokowały połączenie albo brakuje wymaganego prywatnego punktu końcowego lub nie został on zatwierdzony.

Sprawdź, czy podstawowy i pomocniczy magazyn danych zezwalają na bezserwerowy dostęp sieciowy Azure Databricks, zgodnie z opisem w sekcji Wymagania.

DR_INVALID_CONFIGURATION.SERVERLESS_COMPUTE_PERMISSION

Zarządzane odzyskiwanie po awarii używa zasobów obliczeniowych bezserwerowych w pomocniczym obszarze roboczym do kopiowania danych, a przetwarzanie bezserwerowe nie jest tam dozwolone. Zwykle oznacza to, że na koncie lub w obszarze roboczym tryb serverless jest wyłączony albo obszar roboczy się do tego nie kwalifikuje.

  1. Upewnij się, że pomocniczy obszar roboczy kwalifikuje się. Przetwarzanie bezserwerowe jest domyślnie dostępne w obszarach roboczych z włączonym Unity Catalog w obsługiwanym regionie. Zobacz Połącz się z bezserwerową chmurą obliczeniową.
  2. Sprawdź, czy nie ma zgody na całe konto. W konsoli konta przejdź do pozycji Ustawienia → Włączanie funkcji i sprawdź, czy przełącznik bezserwerowy jest obecny i wyłączony.
  3. Włącz tryb bezserwerowy dla wybranego zakresu. Aby włączyć każdy uprawniony obszar roboczy, administrator konta włącza przełącznik bezserwerowy na poziomie konta. Aby włączyć tylko drugi obszar roboczy, pozostaw przełącznik na poziomie konta wyłączony, a administrator obszaru roboczego powinien włączyć tryb bezserwerowy w sekcji Previews obszaru roboczego.
  4. Jeśli przełącznik nie jest dostępny lub po włączeniu tego przełącznika nadal nie działa bezserwerowy, skontaktuj się z zespołem ds. kont Azure Databricks.
DR_INVALID_CONFIGURATION.OVERLAPPING_EXTERNAL_LOCATIONS

Gdy zarządzane odzyskiwanie po awarii (DR) tworzy replikowany obiekt w mapowanej ścieżce docelowej w środowisku pomocniczym, Unity Catalog odrzuca tę ścieżkę, ponieważ pokrywa się ona z lokalizacją magazynu danych, która już tam istnieje, na przykład z istniejącą lokalizacją zewnętrzną, pozostałym zabezpieczanym obiektem z wcześniejszej lub częściowej konfiguracji, lokalizacją zarządzaną albo domyślnym magazynem obszaru roboczego (DBFS).

  1. Zidentyfikuj, co zajmuje ścieżkę.

    W Eksploratorze wykazu przejrzyj lokalizacje zewnętrzne, lokalizacje magazynu zarządzanego oraz tabele zewnętrzne i woluminy, aby znaleźć obiekt, którego ścieżka obejmuje lub nakłada się na ścieżkę docelową.

  2. Jeśli obiekt powodujący konflikt nie powinien być właścicielem ścieżki, usuń go. Częstą przyczyną jest tabela zewnętrzna lub wolumin zewnętrzny pozostałe po poprzedniej konfiguracji; usuń ten obiekt, jeśli nie jest już potrzebny. Jeśli jest to lokalizacja zewnętrzna, która nie powinna obejmować ścieżki, usuń ją lub ponownie zdefiniuj.

  3. W przeciwnym razie przekieruj mapowanie pamięci masowej grupy trybu failover do dedykowanej, niepokrywającej się ścieżki docelowej. Wybieraj konkretną podścieżkę zamiast ogólnego katalogu głównego zasobnika i unikaj domyślnej pamięci masowej obszaru roboczego (DBFS).

DR_UNSUPPORTED_FEATURE

Zasób korzysta z funkcji, której zarządzane odzyskiwanie po awarii nie może zreplikować. Podklasa identyfikuje nieobsługiwaną funkcję i pojawia się na przykład jako DR_UNSUPPORTED_FEATURE.ABAC_POLICY. Istnieją dwa sposoby rozwiązania tego błędu.

  1. Usuń nieobsługiwaną funkcjonalność z zasobu w głównym obszarze roboczym.
  2. Jeśli nie możesz usunąć tej funkcji, rozważ usunięcie zasobu z zakresu replikacji grupy awaryjnego przełączania.

Informacje o pojęciach DR i najlepszych praktykach można znaleźć w temacie Odzyskiwanie po awarii.

  • Last updated on