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 facoltative, quindi è possibile abilitare o entrambe le categorie:

  • Metadati e dati di Unity Catalog: tabelle gestite di Unity Catalog in Delta Lake con dati, tabelle esterne e volumi (solo metadati), viste, funzioni e tutte le autorizzazioni concesse. La modalità di isolamento del catalogo viene replicata. Se il catalogo di origine è aperto, la replica è aperta. Se l'origine è isolata e associata all'area di lavoro primaria, la replica è isolata e associata all'area di lavoro secondaria.
  • Risorse dell'area di lavoro: notebook, job, warehouse SQL, cluster, dashboard AI/BI in bozza, file e cartelle, insieme alle relative ACL. I warehouse SQL vengono replicati nello STOPPED stato, i cluster nello TERMINATED stato. Le pianificazioni dei processi nel database secondario vengono sospese.

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

  • 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.
  • SSO a livello di account con tutte le aree di lavoro abilitate e identità sincronizzate con l'account tramite SCIM in modo che gli utenti, i gruppi e le entità servizio esistano in entrambe le aree.
  • 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.
  • 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. L'area di lavoro secondaria deve avere la stessa configurazione di rete, di collegamento privato e della chiave gestita dal cliente dell'area di lavoro primaria. Il metastore secondario non deve contenere cataloghi che condividono nomi con cataloghi replicati. Per la replica delle risorse dell'area di lavoro, Azure Databricks elimina tutte le risorse esistenti incluse nell'ambito della replica 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.
  • 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 le posizioni esterne né le credenziali di accesso allo storage; è necessario crearle nell’ambiente secondario.

Poiché le operazioni di calcolo serverless dell'area di lavoro secondaria vengono lette dall'archiviazione di origine durante la replica tra aree, sia l'archiviazione di origine che quella secondaria devono consentire Azure Databricks accesso alla rete serverless in entrambe le direzioni.

Se si limita l'accesso di rete all'archiviazione di origine o alla radice DBFS, consentire anche gli indirizzi IP del piano di controllo dell'area secondaria nel firewall di archiviazione di origine e gli indirizzi IP del piano di controllo dell'area primaria nel firewall DBFS secondario. Per gli indirizzi IP del piano di controllo da consentire in ogni area, vedere Inbound to Azure Databricks control plane.

  • 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 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.
  • Endpoint privati per ogni account di archiviazione primario e secondario a cui fanno riferimento i cataloghi replicati. Per l'archiviazione ADLS Gen2, creare un endpoint privato per entrambe le sottorisorse dfs e blob per ogni account. Approvarli nel portale di Azure.

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.

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 i workspace di grandi dimensioni, l'inizializzazione iniziale delle risorse del workspace può richiedere fino a due settimane. 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. Attivare per replicare notebook, processi, sql warehouse, cluster, dashboard, file e cartelle (e i relativi elenchi di controllo di accesso) dal database primario al database secondario. Richiede che entrambe le aree di lavoro dispongano del componente aggiuntivo Mission Critical abilitato. 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.

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 replicato: viste materializzate, tabelle di streaming, pipeline lakeflow, dati del volume gestito (repliche di metadati), segreti del catalogo e dell'area di lavoro di Unity, modelli di Machine Learning, endpoint di gestione dei modelli, indici di ricerca vettoriali, condivisioni Delta, dashboard di intelligenza artificiale/BI pubblicati (repliche di bozze) e Spark Structured Streaming all'esterno delle pipeline Lakeflow. 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.
  • 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.
  • Massimo di 300 cataloghi per account.
  • Massimo 100 gruppi di failover per account.
  • L'inizializzazione iniziale delle risorse dell'area di lavoro può richiedere fino a 2 settimane per aree di lavoro di grandi dimensioni.
  • 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.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.

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

  • Last updated on