Ripristino di emergenza gestito

Il ripristino di emergenza gestito replica la distribuzione Azure Databricks in un'area secondaria in modo da poter eseguire il ripristino da un'interruzione a livello di area in pochi minuti. Azure Databricks gestisce la pipeline di replica, lo stato dei cataloghi replicati nel database secondario e il processo di failover. Non scrivi né gestisci gli script di replica.

Per l'approccio manuale al ripristino di emergenza, inclusi i concetti generali sul ripristino di emergenza e le procedure consigliate, vedere Ripristino di emergenza.

Importante

Il DR gestito è soggetto a restrizioni di accesso. Richiedi l'accesso tramite il team dell'account di Azure Databricks. Azure Databricks abilita il ripristino di emergenza gestito per il tuo account dopo che la tua richiesta è stata approvata.

Che cos'è il ripristino di emergenza gestito?

Il disaster recovery gestito si basa sui workspace e sui metastore che già gestisci. Si configurano due aree di lavoro di Azure Databricks, una nell'area geografica primaria e una nell'area geografica secondaria, oltre a un metastore in ciascuna area geografica. Disaster recovery gestito in passato:

  • Replica le categorie che si accettano dal database primario al secondario in base a una pianificazione continua. Entrambe le categorie sono facoltative in modo indipendente: i metadati di Unity Catalog e i dati delle tabelle gestite; e gli asset dell'area di lavoro, ad esempio notebook, processi, warehouse SQL, cluster e ACL.
  • Fornisce un URL stabile opzionale, un'unica stringa di connessione che punta sempre all'istanza primaria corrente, in modo che i client continuino a funzionare dopo il failover senza necessità di riconfigurazione.
  • Consente di avviare il failover quando desiderato, per un test di disaster recovery o un'interruzione effettiva.

Gli ID degli asset dell'area di lavoro vengono mantenuti in più aree, quindi gli URL che fanno riferimento a un asset dell'area di lavoro in base all'ID vengono comunque risolti dopo il failover.

Cosa viene replicato

Il disaster recovery gestito può replicare i seguenti elementi a ogni ciclo di replica. Entrambe le categorie sono opzionali, quindi puoi abilitare l'una, l'altra oppure entrambe: i metadati e i dati di Unity Catalog e gli asset dello spazio di lavoro.

Metadati e dati del Catalogo Unity

Object Notes
Tabelle gestite di Unity Catalog in Delta Lake Dati e metadati. Vedere Limitazioni.
Tabelle esterne Solo metadati. Vedere Limitazioni.
Volumi esterni Solo metadati.
Views
Functions
Autorizzazioni concesse
Tabelle di streaming In anteprima privata. Per maggiori informazioni, contattare il team dell'account di Azure Databricks.
Viste materializzate In anteprima privata. Per maggiori informazioni, contattare il team dell'account di Azure Databricks.
Filtri di riga, maschere di colonna e criteri di controllo dell'accesso basati su attributi (ABAC) In anteprima privata. Per maggiori informazioni, contattare il team dell'account di Azure Databricks.
Cataloghi esteri In anteprima privata. Per maggiori informazioni, contattare il team dell'account di Azure Databricks.

Anche la modalità di isolamento del catalogo viene replicata. Se il catalogo sorgente è aperto, la sua replica è aperta. Se il catalogo sorgente è isolato e associato allo spazio di lavoro primario, la replica viene isolata e legata allo spazio di lavoro secondario.

Risorse dello spazio di lavoro

Gli asset dello spazio di lavoro vengono replicati insieme alle loro ACL.

Object Notes
Notebooks
Jobs Le pianificazioni dei processi nel database secondario vengono sospese.
Magazzini SQL Replicato nello stato STOPPED.
Clusters Replicato nello stato TERMINATED. Include anche criteri di calcolo, profili di istanza e script init globali.
Gruppi di istanze Le prenotazioni di capacità sono specifiche per regione e devono essere configurate nell'area secondaria.
Se il tuo gruppo di failover è stato creato prima del 17 settembre 2026, contatta il team account Azure Databricks per aggiungere pool di istanze al tuo gruppo di failover.
Bozze di dashboard AI/BI
File
Cartelle Non include le cartelle Git.
Queries Comprende le query create e salvate nell'editor SQL.
Libraries
Destinazioni delle notifiche
Agenti Genie In anteprima privata. Per maggiori informazioni, contattare il team dell'account di Azure Databricks.
Pipeline di Lakeflow In anteprima privata. Per maggiori informazioni, contattare il team dell'account di Azure Databricks.

Proprietà degli oggetti replicati

Quando il DR gestito crea un oggetto proteggibile replicato (catalogo, schema, tabella, vista, funzione o volume) nell'istanza secondaria, il proprietario iniziale è il service principal di Azure Databricks che esegue la replica, perché Unity Catalog assegna la proprietà all'identità che crea l'oggetto. Il DR gestito trasferisce quindi la proprietà della replica in modo che corrisponda a quella del proprietario del corrispondente oggetto a protezione diretta nel database primario.

Se il proprietario di un oggetto a protezione diretta in quello primario è un utente eliminato dall'account, il DR gestito non può trasferire la proprietà a un'entità di sicurezza che non esiste più. In questo caso, l'oggetto a protezione diretta della replica mantiene l'entità servizio di Azure Databricks come proprietario. Per risolvere questo problema, assegnare un proprietario valido all'oggetto proteggibile nel primario e lasciare che DR lo replichi.

Requisiti

Per configurare la gestione gestita della DR, devi avere quanto segue:

  • Un'area di lavoro nel piano Premium sia nelle aree primarie che secondarie.
  • Componente aggiuntivo dell'area di lavoro Mission Critical abilitato in entrambe le aree di lavoro. Vedere Abilitare Mission Critical in entrambe le aree di lavoro.
  • Calcolo serverless abilitato in entrambe le aree di lavoro. L'ambiente di calcolo serverless è disponibile per impostazione predefinita nella maggior parte delle aree di lavoro abilitate per il catalogo Unity. Vedi Connettersi al calcolo serverless.
  • Ruolo di amministratore account con TUTTI I PRIVILEGI per ogni posizione esterna utilizzata dai cataloghi che intendi replicare.

Prerequisiti di configurazione

Per utilizzare la gestione gestita della DR, assicurati che le seguenti impostazioni e risorse siano configurate.

Categoria dettagli
Area di lavoro secondaria e metastore
  • Un workspace secondario e un metastore di Unity Catalog nell'area geografica secondaria, nello stesso account Azure Databricks e sullo stesso cloud di quello primario.
  • Nota le seguenti avvertenze quando configuri il tuo secondario:
    • Il metastore secondario non deve contenere cataloghi che condividono nomi con cataloghi replicati.
    • Per la replica degli asset dell'area di lavoro, Azure Databricks elimina tutti gli asset inclusi nell'ambito esistenti nell'area di lavoro secondaria al completamento della replica iniziale. Gli asset fuori ambito non sono coinvolti, quindi l'area di lavoro secondaria non deve essere necessariamente vuota.
Identity
  • SSO a livello di account con tutti gli spazi di lavoro abilitati e identità sincronizzate all'account tramite AIM o SCIM, così che utenti, gruppi e responsabili di servizio esistano in entrambe le regioni.
  • Per gli URL stabili: un URL personalizzato configurato per il dominio Azure Databricks (contatta il team responsabile dell’account) e OAuth a livello di account.
Archiviazione e accesso ai dati
  • Un connettore di accesso di Azure Databricks nell'area geografica secondaria con il ruolo Collaboratore dati BLOB di archiviazione per gli account di archiviazione secondari, aggiunto come credenziale di archiviazione nell'area di lavoro secondaria.
  • Una posizione esterna e una credenziale di archiviazione corrispondenti nella regione secondaria per ciascuna di quelle a cui fanno riferimento i cataloghi principali. Il disaster recovery gestito non replica automaticamente i percorsi esterni o le credenziali di archiviazione. Devi crearli nella secondaria.
Networking
  • Assicurati che i seguenti oggetti a livello di account siano associati sia agli spazi di lavoro principali che secondari: Configurazione della Connettività di Rete (NCC), Politica di Rete (uscita serverless), Impostazioni di accesso privato (PAS) e Lista di accesso IP.
  • Sia la memoria sorgente che quella secondaria devono consentire l'accesso serverless di rete Azure Databricks in entrambe le direzioni.
  • Una configurazione di connettività di rete (NCC) nell'area secondaria, assegnata all'area di lavoro secondaria, in modo che le risorse di calcolo serverless possano raggiungere l'archiviazione tramite endpoint privati. Vedere Configurare la connettività privata alle risorse di Azure.
  • Se usi la connettività privata con gli account di storage che contengono i dati di origine o replicati, sia lo spazio di lavoro primario che quello secondario necessitano di endpoint privati sia per il conto di archiviazione primario che per quello secondario. Crea endpoint privati per entrambe le sottorisorse dfs e blob di ciascun account. Approvarli nel portale di Azure.
Costi e governance
  • Associa la politica di utilizzo serverless a livello di account (precedentemente politica di budget serverless) allo spazio di lavoro primario e a quello secondario.
Impostazioni tabella
  • Per le tabelle che si interrogano tramite timestamp, utilizzando il viaggio nel tempo o il feed dei dati di modifica, Databricks raccomanda di abilitare i timestamp in-commit (delta.enableInCommitTimestamps = true) prima di configurare la replica. Le tabelle gestite dal catalogo gestiscono i timestamp in-commit per te, quindi non puoi impostare questa proprietà. Vedere Limitazioni.

Abilitare Mission Critical in entrambe le aree di lavoro

Abilitare il componente aggiuntivo Mission Critical nelle aree di lavoro primarie e secondarie prima di creare un gruppo di failover. L'utilizzo del calcolo in ogni area di lavoro in cui si abilita il componente aggiuntivo viene fatturato alla tariffa Mission Critical. Per ottenere la tariffa corrente, contattare il team dell'account Azure Databricks.

  1. Nella console dell'account fare clic su Aree di lavoro, quindi fare clic sull'area di lavoro.
  2. Fare clic sulla scheda Componenti aggiuntivi .
  3. Nella scheda Mission Critical, attivare l’interruttore e confermare.

Ripetere per l'area di lavoro secondaria.

Facoltativo: URL stabile

Azure Databricks consiglia di usare l'URL stabile. L'URL stabile punta sempre all'area di lavoro primaria corrente, quindi i client che si connettono tramite tale URL non devono essere riconfigurati dopo un failover. L'URL originale dell'area di lavoro rimane valida per l'accesso diretto a quell'area di lavoro, ma dopo un failover continua a puntare al nodo primario precedente, ora quello secondario. Indirizzare i seguenti client downstream all'URL stabile invece che all'URL originale dell'area di lavoro:

  • Interfaccia utente Web Azure Databricks.
  • Connessioni JDBC e ODBC ai data warehouse SQL.
  • Richieste API REST dirette.

Gli URL stabili sono supportati con collegamento privato front-end (in ingresso). Con il collegamento privato in ingresso, l'URL stabile usa l'URL personalizzato con un ID di connessione stabile anziché il formato URL dell'area di lavoro standard.

Ad esempio, l'URL stabile assume la forma <my-custom-url>.azuredatabricks.net/?w=stable_connection_id. Vedi Configura inbound collegamento privato per spazi di lavoro con managed disaster recovery.

Collega i client all'URL stabile

I client si connettono tramite l'URL stabile nello stesso modo in cui si collegano a un URL dello spazio di lavoro, con due differenze: usano l'host dell'URL stabile invece dell'URL originale dello spazio di lavoro e identificano lo spazio con l'ID di connessione stabile nel parametro di query w. Autentica con OAuth a livello account.

Connessioni JDBC e ODBC ai warehouse SQL

Imposta il nome host del server sull'host dell'URL stabile, poi aggiungi ?w=stable_connection_id al percorso HTTP del warehouse:

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

Ottieni l'ID del warehouse dal percorso HTTP nella scheda Dettagli di connessione del warehouse (vedi Ottenere dettagli di connessione per una risorsa di calcolo Azure Databricks). Usa le stesse impostazioni di porta e driver che useresti con l'URL originale dello spazio di lavoro.

Richieste dirette di API REST

Invia le richieste all'host dell'URL stabile e aggiungi il parametro w=stable_connection_id di query alla richiesta. Ad esempio, per elencare i cluster:

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

Configura la replicazione

Un nuovo gruppo di failover passa attraverso CREATING → INITIAL_REPLICATION → ACTIVE. Il primo ciclo di replicazione copia tutti i dati inclusi nell'ambito nel secondario. Per workspace di grandi dimensioni, il bootstrap iniziale degli asset del workspace può richiedere fino a cinque giorni. Questa attesa è una tantum. Al termine del bootstrap iniziale, la replica viene eseguita in modo continuo.

Durante la replicazione, i cataloghi secondari che rientrano nell'ambito di applicazione sono di sola lettura e le risorse di calcolo non sono disponibili nell'area di lavoro secondaria. Per eseguire query di convalida senza scrivere nel database secondario, Azure Databricks consiglia un'area di lavoro di monitoraggio di sola lettura separata nell'area secondaria.

Per creare un gruppo di failover:

  1. Nella console dell'account fare clic su Resilienza.
  2. Se si prevede di usare un URL stabile, fare clic sulla scheda URL stabili e quindi su Crea URL stabile. Immettere un nome, selezionare l'area di lavoro primaria corrente e creare l'URL stabile. Indirizza i client downstream (JDBC, ODBC, l'interfaccia web di Azure Databricks, richieste API dirette) all'URL stabile anziché all'URL originale dell'area di lavoro.
  3. Fare clic sulla scheda Gruppi di failover e quindi su Crea gruppo di failover.
  4. Compilare il modulo:
    • Nome del gruppo di failover: nome scelto per il gruppo di failover.
    • Area di lavoro principale: l'area di lavoro principale.
    • Area di lavoro secondaria: area di lavoro nell'area secondaria.
    • Replicare gli asset dell'area di lavoro (facoltativo): disattivato per impostazione predefinita. Attivalo per replicare gli asset dell'area di lavoro e le loro ACL dal primario al secondario. Richiede che entrambi gli spazi di lavoro abbiano abilitato l'add-on Mission Critical . Se si attiva la replicazione degli asset dell'area di lavoro, Azure Databricks elimina eventuali asset esistenti inclusi nell'ambito nell'area di lavoro secondaria al completamento della replica iniziale. Gli asset al di fuori dell'ambito non sono interessati.
    • URL stabile (facoltativo): URL stabile creato nel passaggio 2.
    • Ambito di replica: cataloghi da replicare. È necessario selezionare un'area di lavoro primaria prima che questo campo sia disponibile.
    • Mapping di archiviazione: per ogni posizione esterna usata dai cataloghi replicati nell'area primaria, aggiungere una voce che esegue il mapping del percorso di archiviazione alla posizione esterna corrispondente creata nell'area secondaria (vedere Requisiti). È possibile usare * come wildcard per la corrispondenza per prefisso.
  5. Fare clic su Crea il gruppo di failover.

Ad esempio, un mapping di archiviazione di Azure potrebbe associare abfss://data@primary.dfs.core.windows.net/* a abfss://data@secondary.dfs.core.windows.net/*.

Risorse create dal Disaster Recovery gestito

Quando si crea un gruppo di failover, il DR gestito esegue il provisioning delle risorse ausiliarie di Unity Catalog usate dalla pipeline di replica per copiare i dati tra regioni. Sia nei metastore primari sia in quelli secondari, il disaster recovery gestito crea:

  • Una connessione che punta all'area di lavoro nell'altra area geografica.
  • Catalogo esterno per ogni catalogo replicato. Il catalogo esterno fa riferimento al catalogo corrispondente nell'altra area.

Queste risorse vengono visualizzate insieme ai propri cataloghi in Esplora cataloghi. È possibile identificarli dal commento, che indica che sono stati creati e sono gestiti dal ripristino di emergenza di Azure Databricks.

Importante

Per impostazione predefinita, solo un amministratore del metastore può modificare o eliminare queste risorse. Non eliminare le connessioni o i cataloghi esterni creati da DR gestito. L'eliminazione di uno dei due interrompe la replica per il gruppo di failover.

ID stabile dell'area di lavoro

Alcuni strumenti identificano un'area di lavoro in base all'ID dell'area di lavoro anziché all'URL, inclusi il provider Databricks Terraform e i bundle di asset di Databricks. Ogni URL stabile ha un ID stabile dell'area di lavoro che punta al primario corrente, quindi questi strumenti continuano a puntare all'area di lavoro attiva dopo un failover. Usare l'ID dell'area di lavoro stabile ovunque uno strumento richieda un ID area di lavoro, nello stesso modo in cui si usa un ID area di lavoro normale.

Per trovare l'ID stabile del workspace, elencare gli URL stabili del proprio account con Databricks CLI e leggere il campo stable_workspace_id dell'URL stabile corrispondente:

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

Distribuire con Databricks Asset Bundles e Terraform

I bundle di asset di Databricks e il provider Databricks Terraform sono destinati a un'area di lavoro tramite l'URL host dell'area di lavoro o tramite una combinazione dell'URL personalizzato dell'account Azure Databricks e dell'ID dell'area di lavoro. Per continuare la distribuzione nel nodo primario corrente dopo un failover, imposta l'host sul tuo URL personalizzato, ovvero la parte host dell'URL stabile, non l'URL originale specifico dell'area di lavoro, e specifica l'ID dell'area di lavoro stabile nel campo workspace_id. Insieme si risolvono nel database primario corrente, quindi le pipeline CI/CD continuano a eseguire la distribuzione nell'area di lavoro attiva dopo un failover, senza alcuna modifica di configurazione.

  • Nuove distribuzioni: usare l'URL personalizzato e l'ID dell'area di lavoro stabile dalla prima distribuzione.
  • Distribuzioni esistenti: importare lo stato dal progetto Terraform precedente in un nuovo progetto configurato con l'URL personalizzato e l'ID dell'area di lavoro stabile, quindi rimuovere il progetto precedente. Non reindirizzare sul posto un progetto esistente: la distribuzione non riconosce più le risorse che ha creato associate all'URL originale specifico dell'area di lavoro, quindi una nuova distribuzione le elimina e le ricrea.
  • DAB: abilitare la replicazione degli asset dell'area di lavoro nel gruppo di failover. Un pacchetto memorizza il proprio stato di distribuzione nell’area di lavoro e tale stato raggiunge il nuovo nodo primario solo nell’ambito della replica delle risorse dell’area di lavoro.

Note

Dopo un failover, la prima nuova distribuzione ricrea le eventuali risorse che il DR gestito non replica, perché non esistono nel nuovo primario. Le risorse replicate vengono lasciate sul posto. Consulta Limitazioni per sapere cosa il ripristino di emergenza gestito replica e cosa non replica.

Monitoraggio della replicazione

La scheda Gruppi di failover mostra lo stato corrente, il punto di replica e gli eventuali errori attivi di ogni gruppo di failover. Stati possibili:

Stato Meaning
CREATING Viene effettuato il provisioning del gruppo di failover.
INITIAL_REPLICATION Il primo ciclo di replica è in corso. Il failover non è ancora disponibile.
ACTIVE La replicazione è in stato stazionario. Il failover è disponibile.
FAILING_OVER È in corso un failover.
FAILOVER_FAILED, CREATION_FAILED, DELETION_FAILED Operazione non completata. Per indicazioni, vedere i dettagli sullo stato del gruppo di failover.

Selezionare il nome di un gruppo di failover per aprire la relativa pagina dei dettagli. La replica viene eseguita in modo continuo, ma il punto di replica mostra l'ultima volta che tutte le risorse nell'ambito sono state copiate insieme. Le singole risorse potrebbero essere più aggiornate, ma non tutti i dati successivi al punto di replica potrebbero essere presenti nell'istanza secondaria e potrebbero andare persi durante il failover.

Quando viene mostrato un punto di replicazione, tutto ciò che non è coperto da un errore è stato replicato fino a quel punto. Durante la replicazione iniziale, prima che esista il primo punto di replicazione, il gruppo di failover può ancora mostrare errori di blocco, ma non misura ancora la completezza. I tipi di asset che la DR gestita non supporta affatto non compaiono nella system.replication.states tabella di sistema. Vedere Limitazioni. Per verificare un asset specifico, ispezionalo nel secondario (vedi Configurare la replicazione).

Per monitorare le tendenze RPO cronologiche e visualizzare gli errori che bloccano la replica, eseguire una query sulla tabella di system.replication.states sistema. Vedere Informazioni di riferimento sulla tabella di sistema di replica. Per le classi di errore più comuni e come risolverle, vedere Informazioni di riferimento.

Effettuare il failover e il failback

La stessa procedura riguarda i failover pianificati (test di ripristino di emergenza, manutenzione pianificata) e i failover non pianificati (interruzione a livello di area). Per eseguire il failback, ripetere la procedura con le aree invertite.

Quando si attiva un failover, Azure Databricks:

  • Indirizza l'URL stabile, se associato, alla nuova regione primaria.
  • Inverte la direzione della replica.
  • Sospende le pianificazioni dei processi nel database primario precedente.
  • Fa passare il gruppo di failover da FAILING_OVER a INITIAL_REPLICATION.

Per eseguire il failover:

  1. Avvisa il team che sta per iniziare un failover.

  2. Solo per un failover pianificato:

    1. Nell'area di lavoro primaria terminare tutti i cluster in esecuzione e arrestare tutti i warehouse SQL.
    2. Verificare che le scritture nel database primario siano state arrestate, quindi attendere il recupero della replica. Per verificare, apri la pagina dei dettagli del gruppo di failover e conferma che il punto di replica sia a pochi secondi dall'ora in cui hai interrotto le operazioni di scrittura.

  3. Nella console dell'account fare clic su Resilienza → Gruppi di failover, quindi fare clic sul nome del gruppo di failover.

  4. Fare clic su Fail over.

  5. Selezionare la nuova area primaria e confermare. Il failover si completa in pochi minuti.

  6. Nel nuovo primario, avvia l'elaborazione che era in esecuzione prima del failover. I cluster replicati e i warehouse SQL arrivano nel nuovo primario rispettivamente nello stato TERMINATED e STOPPED.

  7. Riprendi manualmente le pianificazioni dei processi necessarie nel nuovo nodo primario. Le pianificazioni dell'ex primaria sono già sospese.

I client connessi tramite l'URL stabile continuano a funzionare dopo il failover. Riconfigurare i client che utilizzano ancora l'URL dell'area di lavoro originale in modo che puntino all'URL stabile oppure all'URL dell'area di lavoro della nuova area di lavoro primaria.

Importante

In un failover non pianificato, i dati scritti nel database primario dopo l'ultimo punto di replica potrebbero andare persi. Confermare che eventuali perdite rientrino nell'obiettivo RPO.

Tip

Testate regolarmente il failover, ad esempio una volta per trimestre, in modo che il team acquisisca familiarità con la procedura prima di un'interruzione reale.

Smantellare il disaster recovery gestito

  1. Nella console dell'account fare clic su Resilienza → Gruppi di failover, quindi fare clic sul nome del gruppo di failover ed eliminarlo. Non è possibile disattivare Mission Critical mentre un gruppo di failover è attivo nell'area di lavoro.
  2. Per interrompere la fatturazione alla tariffa Mission Critical, disattivare Mission Critical in ogni area di lavoro dalla scheda Componenti aggiuntivi .

Limitations

Il disaster recovery gestito ha le seguenti limitazioni:

  • Non vengono replicati: volumi gestiti, segreti del catalogo e dello spazio di lavoro di Unity, modelli ML, endpoint che servono modelli, indici di ricerca vettoriale, condivisioni Delta, dashboard AI/BI pubblicate (le bozze vengono replicate) e Spark Structured Streaming fuori dalle pipeline Lakeflow. Le tabelle con supporto archivistico Delta Lake (delta.timeUntilArchived) sono contrassegnate come Replica non riuscita nella tabella di sistema, e questi guasti bloccano l'RPO finché non rimuovi la risorsa dall'ambito del gruppo di failover. La replica dei metadati non è supportata per le tabelle esterne non Delta Lake che utilizzano metadati di partizione.
  • La replica per visualizzazioni materializzate, tabelle di streaming e pipeline Lakeflow è disponibile in Anteprima Privata. Per maggiori informazioni, contattare il team dell'account di Azure Databricks.
  • Le tabelle con filtri di riga o maschere di colonna e le risorse con tag ABAC vengono contrassegnate come Replica non riuscita nella tabella di sistema e questi errori impediscono il raggiungimento dell'RPO finché non si rimuove la risorsa dall'ambito del gruppo di failover. La replica di queste risorse è disponibile in Anteprima Privata. Per maggiori informazioni, contattare il team dell'account di Azure Databricks.
  • Le operazioni di scrittura nelle tabelle gestite da motori esterni sono rilevabili solo in misura limitata. Il DR gestito rileva le modifiche alle tabelle gestite di Unity Catalog in seguito alle scritture effettuate dalle risorse di calcolo di Azure Databricks. Le scritture in una tabella gestita replicata da un motore esterno (non Azure Databricks) tramite API aperte, ad esempio il catalogo REST di Iceberg, potrebbero non essere rilevate, quindi tali scritture potrebbero non essere replicate nel database secondario e possono andare perse durante il failover. Per le tabelle replicate con disaster recovery gestito, scrivere tramite le risorse di calcolo di Azure Databricks.
  • I cataloghi secondari rientranti nell'ambito sono di sola lettura. La modalità di sola lettura si applica esclusivamente alle entità replicate. Puoi comunque configurare una tua replicazione per gli oggetti proteggibili al di fuori dell'ambito del DR gestito. Tuttavia, non è possibile eseguire carichi di calcolo nell'area di lavoro secondaria mentre il disaster recovery gestito è abilitato, il che limita l'esecuzione di una pipeline di replica fai-da-te in tale area di lavoro.
  • La ridenominazione di un oggetto proteggibile in Unity Catalog comporta l'eliminazione e la ricreazione nel secondario. Per le tabelle gestite, la ridenominazione replica i dati della tabella nel ciclo successivo. Evitare di rinominare durante la replicazione in regime stazionario.
  • UNDROP non viene propagato al secondario.
  • Per le tabelle senza timestamp in-commit, il viaggio nel tempo tramite timestamp può restituire la versione errata. Su queste tabelle, Delta Lake prende il timestamp di ogni commit dal tempo di modifica del file di commit, e i file di commit replicati portano il tempo in cui sono stati copiati anziché il tempo di commit originale. Di conseguenza, le query time travel e le letture change data feed tramite timestamp possono risolversi in una versione diversa rispetto alla tabella sorgente, senza generare errori. Ciò interessa il secondario non appena una tabella si replica, e il primario dopo un failover o failback. Lo spostamento temporale per versione non subisce modifiche. Per evitare questo, abilita i timestamp in-commit su queste tabelle prima di impostare la replica. Vedi i prerequisiti di configurazione.
  • Il bootstrap iniziale della risorsa dell'area di lavoro può richiedere fino a cinque giorni per aree di lavoro grandi.
  • L'uso del firewall di archiviazione dell'area di lavoro negli account di archiviazione dell'area di lavoro usati con ripristino di emergenza gestito richiede la configurazione manuale. È necessario consentire gli indirizzi IP pertinenti del piano di controllo nel firewall di archiviazione, in modo che Azure Databricks possa replicare i dati. Vedere Requisiti.

Riferimenti

Quando non è possibile replicare una risorsa, il gruppo di failover visualizza una classe di errore nella system.replication.states tabella di sistema, insieme a un messaggio che identifica la risorsa interessata. Le sezioni seguenti illustrano le classi di errore più comuni e come risolverle. La replica viene ripristinata automaticamente dopo aver corretto il problema sottostante.

DR_MISSING_DEPENDENCY

Un asset fa riferimento a una dipendenza che non esiste nel database secondario, pertanto l'asset non può essere replicato. La sottoclasse identifica il tipo di dipendenza mancante e viene visualizzata come DR_MISSING_DEPENDENCY.CATALOG, .SCHEMA.TABLE, o .RESOURCE. La risoluzione è la stessa per tutte.

  1. Controllare se l'asset viene interrotto anche nel database primario a causa della dipendenza mancante. In caso affermativo, correggere o rimuovere l'asset nel database primario.
  2. Se l'asset è valido nell'istanza primaria, la dipendenza non rientra nell'ambito di replicazione di alcun gruppo di failover oppure rientra nell'ambito di questo o di un altro gruppo di failover, ma la replicazione non è riuscita. Se la dipendenza non rientra nell'ambito, modificare l'ambito di replica del gruppo di failover in modo da replicare anche tale dipendenza. Se la dipendenza è già nell'ambito, controllare system.replication.states per individuare l'errore che ne blocca la replica e risolverlo.
DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

Il ripristino di emergenza gestito stabilisce dove collocare ogni asset replicato applicando le mappature di archiviazione del gruppo di failover al percorso di archiviazione di origine dell'asset. Una mappatura corrisponde esattamente a una posizione oppure a un prefisso che copre anche i percorsi figli. Questo errore indica che nessuna mappatura copre una posizione di archiviazione sorgente, quindi il disaster recovery gestito non può determinare dove collocare la risorsa nell'ambiente secondario. Per tabelle e volumi esterni, un mapping mancante indica che viene usato lo stesso URI di posizione nel database primario e secondario. Il storage_location nel messaggio è il percorso di origine non mappato.

  1. Nella console dell'account passare a Resilienza → Gruppi di failover e modificare il gruppo di failover.
  2. In Mapping di archiviazione, aggiungi o amplia una mappatura in modo che includa la posizione di origine nel messaggio. Per coprire i percorsi figlio, mappare un percorso padre e aggiungere il suffisso /* per la corrispondenza per prefisso. Vedi mappature di archiviazione.
  3. Confermare che una posizione esterna nel metastore secondario copra già il percorso di destinazione della mappatura. Il gruppo di failover rifiuta un mapping la cui destinazione non si trova in una posizione esterna esistente, quindi creare prima tale posizione esterna se non esiste. Vedete Connettersi all'archiviazione di oggetti cloud usando Unity Catalog.
DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION

Una mappatura di archiviazione ha associato un asset replicato a un percorso di destinazione nel secondario, ma nessuna posizione esterna nel metastore secondario copre tale percorso, quindi Unity Catalog non ha alcuna posizione in cui collocare i dati dell'asset. Nel messaggio, storage_location indica il percorso secondario (di destinazione) non protetto.

Ciò in genere significa una delle due cose: una posizione esterna che in precedenza copriva il percorso è stata rimossa o limitata, oppure una risorsa replicata di recente rimanda a un percorso secondario non coperto da alcuna posizione esterna. Il secondo caso si verifica, ad esempio, quando si crea una tabella esterna nel database primario in un percorso di archiviazione che nessuno dei mapping di archiviazione copre. Managed DR torna quindi al percorso originale della tabella, che non è coperto da alcuna posizione esterna nel metastore secondario, quindi i dati non hanno dove essere scritti.

  1. Individuare il percorso secondario non coperto dal storage_location del messaggio.
  2. Decidere quale posizione esterna nel metastore secondario deve coprire tale percorso: una posizione esterna esistente estesa o una nuova creata.
  3. Modificare i mapping di archiviazione del gruppo di failover in modo che il percorso venga risolto in una posizione esterna già esistente, oppure creare la posizione esterna (con la relativa credenziale di archiviazione) ed estendere il mapping in modo che punti a tale posizione. Vedete Connettersi all'archiviazione di oggetti cloud usando Unity Catalog.
DR_INTERNAL_ERROR

Si è verificato un errore sul lato sistema durante la replica. Non è necessaria alcuna azione; il sistema viene ripristinato automaticamente. Contattare Azure Databricks supporto tecnico se il problema non viene risolto autonomamente.

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

Il DR gestito replica la vista insieme alle relative autorizzazioni, ma una vista che fa riferimento a oggetti in altri cataloghi richiede anche che il relativo proprietario abbia accesso a tali oggetti di riferimento nel database secondario, perché la vista viene eseguita con i privilegi del proprietario. Questo errore indica che il proprietario non dispone dell'accesso sul database secondario, pertanto è necessario concederlo agli oggetti a cui si fa riferimento.

  1. Trovare gli oggetti a cui fa riferimento la vista e il proprietario della vista. Gli oggetti a cui si fa riferimento vengono visualizzati nella definizione come nomi completi con qualificatore catalog.schema.object; le autorizzazioni devono essere concesse al proprietario, che puoi anche leggere dal campo Proprietario in Catalog Explorer.

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

  2. Nel database secondario controllare i privilegi correnti del proprietario per ogni oggetto a cui si fa riferimento. La lettura di una tabella richiede USE CATALOG nel catalogo, USE SCHEMA nello schema e SELECT nella tabella.

    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. Concedere al proprietario della visualizzazione eventuali privilegi mancanti per ogni oggetto a cui si fa riferimento.

    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. Verificare che ogni catalogo a cui fa riferimento la vista sia incluso nell'ambito di replica di un gruppo di failover, in modo che esista anche nella secondaria.

Per altre informazioni, vedere Gestire i privilegi in Unity Catalog.

DR_INVALID_CONFIGURATION.NETWORK_UNAUTHORIZED_ACCESS

Durante la replicazione dei dati delle tabelle tra aree geografiche, il servizio di calcolo serverless dell'area di lavoro secondaria legge i dati dall'archiviazione di origine, ma il servizio di archiviazione ha negato la connessione di rete: un firewall di archiviazione o una regola di rete l'ha bloccata, oppure manca un endpoint privato obbligatorio o questo non è stato approvato.

Verificare che l'archiviazione di origine e secondaria consenta l'accesso alla rete serverless Azure Databricks, come descritto in Requisiti.

DR_INVALID_CONFIGURATION.MISSING_STORAGE_PRIVATE_ENDPOINT

La DR gestita copia i dati delle tabelle su endpoint privati quando lo storage utilizza connettività privata. Gli endpoint privati sugli account di archiviazione sorgente e secondario devono corrispondere. O nessuno degli account ha un endpoint privato, oppure entrambi gli account hanno un endpoint privato blob e un endpoint privato dfs. Questo errore significa che non corrispondono. Il messaggio elenca gli endpoint mancanti.

  1. Per ogni account di archiviazione indicato nel messaggio, crea gli endpoint privati mancanti blob e dfs in modo che i due lati siano allineati. Sia lo spazio di lavoro primario che quello secondario necessitano di endpoint privati per entrambi gli account di archiviazione. Vedere Configurare la connettività privata alle risorse di Azure.
  2. Approvare i nuovi endpoint privati nel portale di Azure. Vedi i prerequisiti di configurazione.
DR_INVALID_CONFIGURATION.SERVERLESS_COMPUTE_PERMISSION

Il disaster recovery gestito usa l'elaborazione serverless nell'area di lavoro secondaria per copiare i dati e l'elaborazione serverless non è consentita in tale area. Ciò significa in genere che serverless è disattivato per l'account o l'area di lavoro oppure l'area di lavoro non è idonea.

  1. Verificare che l'area di lavoro secondaria sia idonea. Il calcolo serverless è disponibile per impostazione predefinita nelle aree di lavoro abilitate per il catalogo Unity in un'area supportata. Vedi Connettersi al calcolo serverless.
  2. Verificare la presenza di un rifiuto esplicito a livello di account. Nella console dell'account passare a Impostazioni → abilitazione della funzionalità e verificare se l'interruttore serverless è presente e disattivato.
  3. Attiva serverless per l'ambito desiderato. Per abilitare ogni area di lavoro idonea, un amministratore dell'account attiva l'interruttore serverless a livello di account. Per abilitare solo l'area di lavoro secondaria, lascia disattivato il toggle a livello di account e fai in modo che un amministratore dell'area di lavoro abiliti serverless da Previews dell'area di lavoro.
  4. Se non è disponibile alcuna opzione oppure serverless continua a non funzionare dopo l'attivazione, contatta il team dell'account Azure Databricks.
DR_INVALID_CONFIGURATION.OVERLAPPING_EXTERNAL_LOCATIONS

Quando il DR gestito crea un oggetto replicato nel percorso di destinazione mappato nell’ambiente secondario, Unity Catalog rifiuta il percorso perché si sovrappone a uno spazio di archiviazione già esistente, ad esempio una posizione esterna esistente, un oggetto securable residuo di una configurazione precedente o parziale, una posizione gestita o lo spazio di archiviazione predefinito (DBFS) dell’area di lavoro.

  1. Identificare ciò che occupa il percorso.

    In Esplora cataloghi, esamina le posizioni esterne, le posizioni di archiviazione gestite, le tabelle esterne e i volumi per trovare l'oggetto il cui percorso include o si sovrappone al percorso di destinazione.

  2. Se l'oggetto in conflitto non deve essere proprietario del percorso, rimuoverlo. Una causa comune è una tabella esterna o un volume esterno lasciato da una configurazione precedente; eliminarlo se non è più necessario. Se si tratta di una posizione esterna che non deve coprire il percorso, rimuoverlo o ridefinirlo.

  3. In caso contrario, reindirizzare il mapping di archiviazione del gruppo di failover a un percorso di destinazione dedicato e non sovrapposto. Preferisci un sottopercorso specifico anziché una radice ampia del bucket ed evita l'archiviazione predefinita dell'area di lavoro (DBFS).

DR_UNSUPPORTED_FEATURE

La risorsa usa una funzionalità che il disaster recovery gestito non può replicare. La sottoclasse identifica la funzionalità non supportata e viene visualizzata, ad esempio, come DR_UNSUPPORTED_FEATURE.ABAC_POLICY. Esistono due modi per risolvere l'errore.

  1. Rimuovere la funzionalità non supportata dall'asset nell'area di lavoro primaria.
  2. Se non è possibile rimuovere la funzionalità, è consigliabile rimuovere l'asset dall'ambito di replica del gruppo di failover.
DR_UNSUPPORTED_FEATURE.TABLE_ARCHIVED_FILES

La tabella ha abilitato il supporto di archiviazione di Delta Lake (delta.timeUntilArchived). La DR gestita clona ogni file di dati, quindi gli oggetti archiviati devono essere ripristinati in un livello di archiviazione calda e la proprietà della tabella deve essere disattivata sul primario prima che la replica possa continuare. Vedere Supporto dell'archiviazione in Azure Databricks.

  1. Disabilita la politica di archiviazione del ciclo di vita cloud nella posizione di archiviazione della tabella così che i file aggiuntivi non vengano archiviati dopo averli elencati.

  2. Elenco dei file da ripristinare:

    SHOW ARCHIVED FILES FOR <table_name>;

  3. Ripristina quegli oggetti nel tuo provider cloud, poi aspetta che il ripristino sia completato. Consulta Ripristino dei file archiviati.

  4. Annulla l'impostazione della proprietà delta.timeUntilArchived tabella. Questo aggiorna solo i metadati in modo che Databricks non tenga più traccia dello stato di archiviazione sulla tabella:

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

  5. Conferma che una lettura completa abbia successo, ad esempio SELECT COUNT(*) FROM <table_name>;. Dopodiché, la replicazione può clonare la tabella.

Tieni presente che la disattivazione della proprietà non ripristina gli oggetti. Il ripristino degli oggetti è un'operazione di provider cloud che deve essere effettuata manualmente utilizzando i meccanismi del provider cloud.

Per i concetti e le procedure consigliate per il ripristino di emergenza, vedere Ripristino di emergenza.

  • Ultimo aggiornamento: