Reprise après sinistre gérée

La reprise après sinistre gérée (DR) réplique votre déploiement Databricks vers une région secondaire afin que vous puissiez récupérer d'une panne régionale en quelques minutes. Databricks gère le pipeline de réplication, l'état des catalogues répliqués dans le secondaire et le processus de basculement. Vous n’écrivez ni ne maintenez de scripts de réplication.

Pour l'approche manuelle de la reprise après sinistre, y compris les concepts généraux et les meilleures pratiques en matière de reprise après sinistre, consultez Reprise après sinistre.

important

Managed DR est soumise à une sélection. Demandez l'accès auprès de votre équipe de compte Databricks. Databricks active Managed DR sur votre compte une fois que vous êtes accepté.

Qu’est-ce que la reprise après sinistre gérée ?

Managed DR se superpose aux workspaces et metastores que vous gérez déjà. Vous apportez deux workspaces Databricks, un dans votre région principale et un dans votre région secondaire, et un metastore dans chaque région. Managed DR puis :

• Réplique les catégories auxquelles vous souscrivez du primaire au secondaire selon un calendrier continu. Les deux catégories sont facultatives indépendamment : les métadonnées Unity Catalog et les données de table gérées, et les assets du Workspace tels que les Notebooks, les Job, les SQL Warehouse, les clusters et les ACL.
• Fournit une **URL stable** facultative, une chaîne de connexion unique qui pointe toujours vers le primaire actuel, afin que les clients continuent de fonctionner après le basculement sans reconfiguration.
• Vous permet de Trigger un basculement quand vous le souhaitez, pour un test de reprise d’activité ou une panne réelle.

Les identifiants d'asset de Workspace sont conservés dans toutes les régions, de sorte que les URL qui référencent un asset de Workspace par identifiant sont toujours résolues après un basculement.

Ce qui est répliqué

Managed DR peut répliquer les éléments suivants à chaque cycle de réplication. Les deux catégories sont facultatives, vous pouvez donc activer l'une ou l'autre, ou les deux :

• Métadonnées et données Unity Catalog : tables gérées Unity Catalog dans Delta Lake avec données, tables externes et volumes (métadonnées uniquement), vues, fonctions et tous les octrois de permissions. Le mode d’isolation du catalogue est répliqué. Si le catalogue source est ouvert, la réplique est ouverte. Si la source est isolée et liée au workspace principal, la réplique est isolée et liée au workspace secondaire.
• Assets de Workspace : Notebooks, jobs, SQL Warehouses, clusters, brouillons de tableaux de bord AI/BI, fichiers et dossiers, ainsi que leurs ACL. Les SQL warehouses sont répliqués dans l’état STOPPED, les clusters dans l’état TERMINATED. Les calendriers de Job dans le secondaire sont suspendus.

Propriété des objets répliqués

Lorsque le DR géré crée un élément sécurisable répliqué (catalogue, schéma, table, vue, fonction ou volume) dans le secondaire, le propriétaire initial est le Service Principal Databricks qui exécute la réplication, car Unity Catalog attribue la propriété à l'identité qui crée l'objet. Managed DR transfère ensuite la propriété de la réplique pour correspondre au propriétaire de la ressource sécurisable correspondante dans le primaire.

Si le propriétaire d’un élément sécurisable dans le principal est un utilisateur qui a été supprimé du compte, le DR géré ne peut pas transférer la propriété à un principal qui n’existe plus. Dans ce cas, l'élément sécurisable répliqué conserve le Service Principal Databricks comme propriétaire. Pour résoudre ce problème, attribuez un propriétaire valide à l'élément sécurisable dans le primaire et laissez DR le répliquer.

Exigences

• Un Workspace sur le plan Enterprise dans les régions primaire et secondaire.

• Le module complémentaire de Workspace Mission Critical est activé sur les deux Workspaces. Voir activer Mission Critical sur les deux Workspace.

• Compute Serverless activé sur les deux workspaces. Le compute Serverless est disponible par default dans la plupart des workspaces compatibles avec Unity Catalog. Consulter Se connecter au compute serverless.

• Rôle d’administrateur de compte avec TOUS LES PRIVILÈGES sur chaque emplacement externe utilisé par les catalogues que vous prévoyez de répliquer.

• SSO au niveau du compte avec **tous les Workspace** activés, et les identités synchronisées au compte via SCIM afin que les utilisateurs, les groupes et les Service Principal existent dans les deux régions.

• Pour des URL stables : une URL personnalisée provisionnée pour votre domaine Databricks (contactez l'équipe de votre compte) et OAuth au niveau du compte.

• Un Workspace secondaire et un métastore Unity Catalog dans la région secondaire, dans le même compte Databricks et sur le même cloud que votre Workspace principal. Le Workspace secondaire doit correspondre au réseau, au Private Link et à la configuration de clé gérée par le client du primaire. Le metastore secondaire ne doit pas contenir de catalogues qui partagent des noms avec des catalogues répliqués. Pour la réplication des assets du workspace, Databricks supprime tous les assets existants dans le périmètre dans le workspace secondaire une fois la réplication initiale terminée. Les assets hors de portée ne sont pas affectés, donc le Workspace secondaire n'a pas besoin d'être vide.

• Un emplacement externe et un identifiant de stockage correspondants dans la région secondaire pour chacun de ceux référencés par vos catalogues primaires. Managed DR ne réplique pas automatiquement les emplacements externes ou les identifiants de stockage ; vous devez les créer dans la région secondaire.

Étant donné que le compute serverless du Workspace secondaire lit à partir du stockage source lors de la réplication interrégionale, le stockage source et le stockage secondaire doivent autoriser l'accès réseau serverless de Databricks dans les deux directions.

Si vous restreignez l'accès réseau à votre stockage source ou à la racine DBFS, autorisez également les adresses IP du plan de contrôle de la région secondaire au niveau du pare-feu du stockage source, et les adresses IP du plan de contrôle de la région primaire au niveau du pare-feu DBFS secondaire. Pour les adresses IP du plan de contrôle à autoriser dans chaque région, consultez Adresses IP entrantes.

• TOUS LES PRIVILÈGES sur toutes les localisations externes référencées par vos catalogues répliqués, accordées aux rôles IAM utilisés par le Workspace secondaire.

Activez Mission Critical sur les deux Workspace.

Activez le module complémentaire Mission Critical sur vos workspaces principal et secondaire avant de créer un groupe de basculement. L'utilisation du compute sur chaque Workspace où vous activez le module complémentaire est facturée au tarif Mission Critical. Contactez votre équipe de compte Databricks pour connaître le tarif actuel.

1. Dans la console du compte, cliquez sur Workspaces , puis cliquez sur le Workspace.
2. Cliquez sur l'onglet Modules complémentaires .
3. Sur la carte **Mission Critical**, activez le curseur et confirmez.

Répétez l'opération pour le workspace secondaire.

Facultatif : URL stable

Databricks vous recommande d'utiliser l'URL stable. L'URL stable se résout toujours en le Workspace principal actuel, de sorte que les clients qui s'y connectent n'ont pas besoin d'être reconfigurés après un basculement. L'URL d'origine du Workspace reste valide pour un accès direct à ce Workspace, mais après un basculement, elle continue de pointer vers l'ancien primaire, désormais le secondaire. Faites pointer les clients en aval suivants vers l'URL stable plutôt que vers l'URL d'origine du Workspace :

• L’interface utilisateur Web de Databricks.
• Connexions JDBC et ODBC aux SQL Warehouse.
• Requêtes API REST directes.

Les URL stables sont prises en charge avec Private Link front-end (entrant). Avec Private Link entrant, l'URL stable utilise votre URL personnalisée avec un ID de connexion stable plutôt que le format d'URL de workspace standard.

Par exemple, l'URL stable prend la forme <my-custom-url>.databricks.com/?c=stable_connection_id. Consultez Configurer le Link privé entrant pour les Workspace avec récupération d'urgence gérée.

Configurer la réplication

Un nouveau groupe de basculement transite par CREATING → INITIAL_REPLICATION → ACTIVE. Le premier cycle de réplication copie toutes les données concernées vers le secondaire. Pour les grands Workspaces, l'amorçage initial des assets du Workspace peut prendre jusqu'à deux semaines. Cette attente est unique. Une fois l'amorçage initial terminé, la réplication s'exécute en continu.

Pendant la réplication, les catalogues secondaires inclus dans le périmètre sont en lecture seule et le compute est indisponible dans le workspace secondaire. Pour exécuter des queries de validation sans écrire vers le secondaire, Databricks recommande un workspace de surveillance distinct en lecture seule dans la région secondaire.

Pour créer un groupe de basculement :

1. Dans la console du compte, cliquez sur Résilience .

2. Si vous prévoyez d’utiliser une URL stable, cliquez sur l’onglet URL stables , puis sur Créer une URL stable . Saisissez un nom, sélectionnez le workspace principal actuel, et créez l’URL stable. Pointez les clients en aval (JDBC, ODBC, l’interface utilisateur web Databricks, requêtes API directes) vers l’URL stable au lieu de l’URL du workspace d’origine.

3. Cliquez sur l'onglet Failover groups tab, puis sur Créer un groupe de basculement .

4. Remplissez le formulaire :

   • Nom du groupe de basculement : un nom que vous choisissez pour le groupe de basculement.
   • Workspace principal : Le workspace qui est votre principal.
   • Workspace secondaire : Le workspace dans la région secondaire.
   • Répliquer les assets du Workspace (facultatif) : Désactivé par default. Activez la réplication des notebooks, jobs, SQL Warehouse, clusters, tableaux de bord, fichiers et dossiers (et leurs ACL) du principal au secondaire. Nécessite que les deux workspaces aient l'add-on Mission Critical activé. Si vous activez la réplication des ressources du workspace, Databricks supprime toutes les ressources existantes dans la portée du secondaire une fois la réplication initiale terminée. Les actifs hors du champ d'application ne sont pas affectés.
   • URL stable (facultatif) : L'URL stable que vous avez créée à l'étape 2.
   • Étendue de la réplication : les catalogues à répliquer. Vous devez sélectionner un workspace principal avant que ce champ ne soit disponible.
   • Mappages de stockage : pour chaque emplacement externe utilisé par vos catalogues répliqués dans la région principale, ajoutez une entrée qui associe son chemin de stockage à l'emplacement externe correspondant que vous avez créé dans la région secondaire (voir Requirements). Vous pouvez utiliser * comme caractère générique pour la correspondance de préfixe.

5. Cliquez sur Créer un groupe de basculement .

Par exemple, un mappage de stockage AWS pourrait mapper s3://primary-bucket/data/* à s3://secondary-bucket/data/*.

Ressources créées par DR géré

Lorsque vous créez un groupe de basculement, la reprise après sinistre gérée provisionne des ressources Unity Catalog auxiliaires que le pipeline de réplication utilise pour copier des données entre les régions. Dans les métastores primaire et secondaire, la DR gérée crée :

• Une connexion qui pointe vers le workspace dans l'autre région.
• Un catalogue étranger pour chaque catalogue répliqué. Le catalogue étranger référence le catalogue correspondant dans l'autre région.

Ces ressources apparaissent à côté de vos propres catalogues dans l'Explorateur de catalogue. Vous pouvez les identifier par leur commentaire, qui indique que la reprise après sinistre de Databricks les a créés et les gère.

important

Par default, seul un administrateur de metastore peut modifier ou supprimer ces Ressources. Ne supprimez pas les connexions ou les catalogues étrangers créés par le DR géré. La suppression de l'un ou l'autre interrompt la réplication pour le groupe de basculement.

ID de Workspace stable

Certains outils identifient un workspace par son ID de workspace au lieu de son URL, y compris le fournisseur Terraform Databricks et les bundles d'actifs Databricks. Chaque URL stable possède un ID de workspace stable qui se résout au primaire actuel, de sorte que ces outils continuent à cibler le workspace actif après un basculement. Utilisez l'ID stable du Workspace partout où un outil demande un ID de Workspace, de la même manière que vous utiliseriez un ID de Workspace normal.

Pour trouver l'ID du workspace stable, listez les URL stables de votre compte avec la Databricks CLI et lisez le champ stable_workspace_id de l'URL stable pertinente :

Bash

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

Déployer avec des Databricks Asset Bundles et Terraform

Les Databricks Asset Bundles (DAB) et le fournisseur Databricks Terraform ciblent un workspace soit par son URL d'hôte de workspace, soit par une combinaison de l'URL personnalisée du compte Databricks et de l'ID du workspace. Pour continuer à déployer vers le principal actuel après un basculement, définissez l'hôte sur votre URL personnalisée — la partie hôte de l'URL stable, et non l'URL d'origine par workspace — et spécifiez l'ID de workspace stable dans le champ workspace_id. Ensemble, ils se résolvent en principal actuel, de sorte que vos pipelines CI/CD continuent de se déployer sur le workspace actif après un basculement, sans modification de la configuration.

• Nouveaux déploiements : utilisez l'URL personnalisée et l'ID de workspace stable du premier déploiement.
• **Déploiements existants** : importez l'état de votre précédent projet Terraform dans un nouveau projet configuré avec l'URL personnalisée et l'ID de Workspace stable, puis supprimez le projet précédent. Ne redéfinissez pas un projet existant sur place — le déploiement ne reconnaît plus les ressources qu'il a créées par rapport à l'URL de Workspace d'origine, donc un redéploiement les détruit et les recrée.
• DABs : activez la réplication des Workspace asset sur le groupe de basculement. Un bundle stocke son état de déploiement dans le Workspace, et cet état n'atteint le nouveau principal que dans le cadre de la réplication des assets du Workspace.

remarque

Après un basculement, le premier redéploiement recrée toutes les ressources que la DR gérée ne réplique pas, car elles n'existent pas sur le nouveau primaire. Les ressources répliquées sont laissées en place. Consultez Limitations pour savoir ce que la DR gérée réplique et ne réplique pas.

Surveiller la réplication

La tab Groupes de basculement affiche l'état actuel de chaque groupe de basculement, le point de réplication et les erreurs actives éventuelles. États possibles :

État	Signification
CREATING	Le groupe de basculement est en cours de provisionnement.
INITIAL_REPLICATION	Le premier cycle de réplication est en cours. Le basculement n'est pas encore disponible.
ACTIVE	La réplication est en état stable. Le basculement est disponible.
FAILING_OVER	Un basculement est en cours.
FAILOVER_FAILED, CREATION_FAILED, DELETION_FAILED	L'opération n'a pas abouti. Vérifiez les détails de l'état du groupe de basculement pour obtenir des conseils.

État	Signification
CREATING	Le groupe de basculement est en cours de provisionnement.
INITIAL_REPLICATION	Le premier cycle de réplication est en cours. Le basculement n'est pas encore disponible.
ACTIVE	La réplication est en état stable. Le basculement est disponible.
FAILING_OVER	Un basculement est en cours.
FAILOVER_FAILED, CREATION_FAILED, DELETION_FAILED	L'opération n'a pas abouti. Vérifiez les détails de l'état du groupe de basculement pour obtenir des conseils.

Sélectionnez le nom d'un groupe de basculement pour ouvrir sa page de détails. La réplication s'exécute en continu, mais le point de réplication indique la dernière fois que toutes les ressources concernées ont été copiées ensemble. Les ressources individuelles peuvent être plus à jour, mais pas toutes les données après le point de réplication pourraient exister sur le site secondaire et être perdues lors du basculement.

Pour surveiller les tendances RPO historiques et voir les erreurs qui bloquent la réplication, interrogez la table système system.replication.states. Consultez Référence de la table système de réplication. Pour les classes d'erreurs les plus courantes et comment les résoudre, consultez la Référence.

Basculer et restaurer

La même procédure couvre les basculements planifiés (tests de reprise après sinistre, maintenance programmée) et les basculements non planifiés (une panne régionale). Pour la récupération, répétez la procédure avec les régions inversées.

Lorsque vous trigger un basculement, Databricks :

• Pointe l'URL stable, si elle est attachée, vers la nouvelle région principale.
• Inverse le sens de la réplication.
• Met en pause les planifications de Job dans le primaire précédent.
• Fait passer le groupe de basculement de FAILING_OVER à INITIAL_REPLICATION.

Pour basculer en mode de secours :

1. Avertissez votre équipe qu'un basculement est en cours.

2. Pour un basculement planifié uniquement :

   1. Dans le Workspace principal, mettez fin à tous les clusters en cours d'exécution et arrêtez tous les SQL Warehouse.
   2. Confirmez que les écritures vers le primaire ont cessé, puis attendez que la réplication se rattrape. Pour vérifier, ouvrez la page de détails du groupe de basculement et confirmez que le point de réplication est à quelques secondes du moment où vous avez arrêté les écritures.

3. Dans la console du compte, cliquez sur Résilience → Groupes de basculement , puis cliquez sur le nom du groupe de basculement.

4. Cliquez sur **Basculer**.

5. Sélectionnez la nouvelle région principale et confirmez. Le basculement se termine en quelques minutes.

6. Dans le nouveau primaire, start le compute qui était en cours d'exécution avant le basculement. Les clusters répliqués et les SQL Warehouse arrivent dans le nouveau primaire dans l'état TERMINATED et STOPPED, respectivement.

7. Reprenez manuellement les planifications de Job dont vous avez besoin dans le nouveau serveur principal. Les anciens plannings principaux sont déjà en pause.

Les clients connectés via l'URL stable continuent de fonctionner après le basculement. Réorientez les clients qui utilisent toujours l'URL d'origine du Workspace vers l'URL stable ou l'URL du nouveau Workspace principal.

important

Lors d'un basculement non planifié, les données écrites sur le site principal après le dernier point de réplication pourraient être perdues. Confirmez que toute perte est conforme à votre objectif de RPO.

astuce

Testez régulièrement le basculement, par exemple une fois par trimestre, afin que votre équipe connaisse la procédure avant une panne réelle.

Désactiver la récupération d'urgence gérée

1. Dans la console du compte, cliquez sur Résilience → Groupes de basculement , puis cliquez sur le nom du groupe de basculement et supprimez-le. Vous ne pouvez pas désactiver Mission Critical tant qu'un groupe de basculement est actif sur le Workspace.
2. Pour arrêter la facturation au tarif Mission Critical, désactivez Mission Critical sur chaque Workspace depuis l'onglet **tab**.

Limitations

Managed DR présente les limites suivantes :

• Non répliqués : vues matérialisées, tables de streaming, LakeFlow Pipelines, données de volume gérées (les métadonnées sont répliquées), Unity Catalog et Workspace secrets, modèles ML, Endpoint de service de modèles, index de recherche vectorielle, partages Delta, tableaux de bord AI/BI publiés (les brouillons sont répliqués) et le Spark Structured Streaming en dehors des LakeFlow Pipelines. Les tables avec des filtres de ligne ou des masques de colonne et les ressources marquées ABAC sont signalées comme Échec de la réplication dans la table système, et ces échecs retardent le RPO jusqu'à ce que vous supprimiez la ressource du périmètre du groupe de basculement.
• Les catalogues secondaires dans le périmètre sont en lecture seule. La lecture seule s'applique uniquement aux entités répliquées. Vous pouvez toujours configurer votre propre réplication pour les éléments sécurisables en dehors de la portée de la reprise après sinistre gérée. Cependant, vous ne pouvez pas exécuter de compute sur le Workspace secondaire lorsque la DR gérée est activée, ce qui limite l'exploitation d'un pipeline de réplication do-it-yourself à cet endroit.
• Le renommage d'un élément sécurisable de Unity Catalog Trigger une suppression et une recréation dans le secondaire. Pour les tables gérées, le renommage ré-réplique les données de la table au prochain cycle. Évitez de renommer pendant la réplication à l'état stable.
• UNDROP n'est pas propagé vers le secondaire.
• Maximum 300 catalogues par compte.
• Maximum 100 groupes de basculement par compte.
• L'amorçage initial des assets du Workspace peut prendre jusqu'à 2 semaines pour les grands Workspaces.

Référence

Lorsqu'une ressource ne peut pas être répliquée, le groupe de basculement affiche une classe d'erreur dans la table système system.replication.states, ainsi qu'un message identifiant la ressource affectée. Les sections suivantes abordent les classes d'erreurs les plus courantes et la manière de les résoudre. La réplication se rétablit automatiquement après que vous ayez corrigé le problème sous-jacent.

DR_MISSING_DEPENDENCY

Un asset référence une dépendance qui n'existe pas dans le secondaire, donc l'asset ne peut pas être répliqué. La sous-classe identifie le type de dépendance manquant et apparaît sous la forme DR_MISSING_DEPENDENCY.CATALOG, .SCHEMA, .TABLE, ou .RESOURCE. La résolution est la même pour tous.

1. Vérifiez si l'asset est également défaillant dans le principal à cause de la dépendance manquante. Si c'est le cas, corrigez ou supprimez l'asset dans le principal.
2. Si l'asset est valide dans le primaire, la dépendance n'est soit pas dans la portée de réplication d'un groupe de basculement, soit elle est dans la portée de ce groupe ou d'un autre groupe de basculement, mais n'a pas pu être répliquée. Si la dépendance n'est pas dans le périmètre, modifiez le périmètre de réplication du groupe de basculement pour la répliquer également. Si la dépendance est déjà dans le cadre, vérifiez system.replication.states pour l'erreur qui bloque sa réplication et résolvez cette erreur.

DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

Managed DR détermine où placer chaque asset répliqué en appliquant les mappages de stockage du groupe de basculement à l'emplacement de stockage source de l'asset. Un mappage correspond à un emplacement exactement, ou en tant que préfixe qui couvre également les chemins enfants. Cette erreur signifie qu'aucun mappage ne couvre un emplacement de stockage source, de sorte que Managed DR ne peut pas déterminer où placer l'asset dans l'emplacement secondaire. Pour les tables et volumes externes, un mappage manquant signifie que le même URI d'emplacement est utilisé sur le primaire et le secondaire. Le storage_location dans le message est le chemin source non mappé.

1. Dans la console du compte, accédez à Résilience → Groupes de basculement et modifiez le groupe de basculement.
2. Sous **Mappages de stockage**, ajoutez ou élargissez un mappage afin qu'il couvre l'emplacement source dans le message. Pour couvrir les chemins enfants, mappez un chemin parent et ajoutez le suffixe /* pour la correspondance de préfixes. Voir mappages de stockage.
3. Confirmez qu'un emplacement externe dans le métastore secondaire couvre déjà le chemin cible du mappage. Le groupe de basculement rejette un mappage dont la cible ne se trouve pas sous un emplacement externe existant. Créez donc cet emplacement externe en premier s'il n'existe pas. Consultez Connectez-vous au stockage d'objets cloud à l'aide de Unity Catalog.

DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION

Un mappage de stockage a résolu un asset répliqué vers un chemin cible dans le secondaire, mais aucun emplacement externe dans le metastore secondaire ne couvre ce chemin, de sorte qu'Unity Catalog n'a aucun endroit où placer les données de l'asset. Le storage_location dans le message est le chemin secondaire (cible) non couvert.

Cela signifie généralement l'une des deux choses suivantes : un emplacement externe qui couvrait précédemment le chemin a été supprimé ou restreint, ou un asset nouvellement répliqué résout un chemin secondaire qu'aucun emplacement externe ne couvre. Le deuxième cas se produit, par exemple, lorsque vous créez une table externe dans le principal sous un chemin de stockage qu’aucun de vos mappages de stockage ne couvre. Managed DR revient ensuite au chemin d'origine de la table, qu'aucun emplacement externe dans le métastore secondaire ne couvre, de sorte que les données n'ont nulle part où atterrir.

1. Identifiez le chemin secondaire non couvert du message storage_location.
2. Décidez quel emplacement externe dans le metastore secondaire devrait couvrir ce chemin : un emplacement externe existant que vous étendez, ou un nouveau que vous créez.
3. Vous pouvez soit ajuster les mappages de stockage du groupe de basculement afin que le chemin se résolve sous un emplacement externe existant, soit créer l'emplacement externe (avec ses identifiants de stockage) et étendre le mappage pour qu'il pointe vers celui-ci. Consultez Se connecter au stockage d’objets cloud à l’aide de Unity Catalog.

DR_INTERNAL_ERROR

Une erreur système s'est produite lors de la réplication. Aucune action n’est requise ; le système récupère automatiquement. Contactez l'assistance Databricks si le problème ne se résout pas de lui-même.

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

Managed DR réplique la vue ainsi que ses autorisations, mais une vue qui référence des objets dans d'autres catalogues nécessite également que son propriétaire ait accès à ces objets référencés dans le secondaire, car la vue s'exécute avec les privilèges du propriétaire. Cette erreur signifie que le propriétaire n'a pas cet accès sur le secondaire, vous devez donc l'accorder sur les objets référencés à cet endroit.

1. Trouvez les objets que la vue référence et le propriétaire de la vue. Les objets référencés apparaissent sous forme de noms catalog.schema.object entièrement qualifiés dans la définition ; les subventions doivent être attribuées au propriétaire, que vous pouvez également lire dans le champ Propriétaire de Catalog Explorer.

   SQL

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

2. Sur la secondaire, vérifiez les privilèges actuels du propriétaire sur chaque objet référencé. La lecture d'une table nécessite USE CATALOG sur son catalogue, USE SCHEMA sur son schéma et SELECT sur la table.

   SQL

   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. Octroyez au propriétaire de la vue tous les privilèges manquants sur chaque objet référencé.

   SQL

   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. Confirmez que chaque catalogue auquel la vue fait référence est inclus dans le périmètre de réplication d'un groupe de basculement, afin qu'il existe également dans le secondaire.

Pour plus d'informations, consultez Gérer les privilèges dans Unity Catalog.

DR_INVALID_CONFIGURATION.NETWORK_UNAUTHORIZED_ACCESS

Lors de la réplication de données de table interrégionale, le compute Serverless du Workspace secondaire lit les données du stockage source, et le stockage a refusé la connexion réseau : un pare-feu de stockage ou une règle réseau l'a bloquée, ou un Endpoint privé requis est manquant ou non approuvé.

Vérifiez que votre stockage source et secondaire permettent l’accès réseau Serverless de Databricks, comme décrit dans Exigences.

DR_INVALID_CONFIGURATION.SERVERLESS_COMPUTE_PERMISSION

Managed DR utilise le compute serverless dans le workspace secondaire pour copier les données, et le compute serverless n’y est pas autorisé. Cela signifie généralement que le serverless est désactivé pour le compte ou le workspace, ou que le workspace n'est pas éligible.

1. Confirmez que le workspace secondaire est éligible. Le compute Serverless est disponible par default dans les workspaces compatibles avec Unity Catalog dans une région prise en charge. Consulter Se connecter au compute serverless.
2. Rechercher une désactivation à l'échelle du compte. Dans la console du compte, accédez à Paramètres → Activation des fonctionnalités et vérifiez si la bascule Serverless est présente et désactivée.
3. Activez Serverless pour l'étendue dont vous avez besoin. Pour activer chaque workspace éligible, un administrateur de compte active le commutateur serverless au niveau du compte. Pour activer uniquement le workspace secondaire, laissez le commutateur au niveau du compte désactivé et demandez à un administrateur de workspace d'activer le serverless à partir des Aperçus du workspace.
4. Si aucun interrupteur n'est disponible, ou si le mode Serverless ne s'exécute toujours pas après l'avoir activé, contactez l'équipe de votre compte Databricks.

DR_INVALID_CONFIGURATION.OVERLAPPING_EXTERNAL_LOCATIONS

Quand la DR gérée crée un objet répliqué sur son chemin cible mappé dans le secondaire, Unity Catalog rejette le chemin parce qu’il chevauche un stockage qui existe déjà, tel qu’un emplacement externe existant, une ressource sécurisable résiduelle d’une configuration antérieure ou partielle, un emplacement géré, ou le stockage par default (DBFS) du Workspace.

1. Identifier ce qui occupe le chemin.

   Consultez Résoudre les conflits de chemin de stockage.

2. Si l'objet en conflit ne doit pas posséder le chemin, supprimez-le. Une cause courante est une table externe ou un volume externe restants d'une configuration précédente ; supprimez-le si ce n'est plus nécessaire. S’il s’agit d’un emplacement externe qui ne devrait pas couvrir le chemin, supprimez-le ou redéfinissez-le.

3. Sinon, redéfinissez le mappage de stockage du groupe de basculement vers un chemin cible dédié et sans chevauchement. Préférez un sous-chemin spécifique plutôt qu'une racine de compartiment générique, et évitez le stockage par default (DBFS) du Workspace.

DR_UNSUPPORTED_FEATURE

L’asset utilise une fonctionnalité que le DR géré ne peut pas répliquer. La sous-classe identifie la fonctionnalité non prise en charge et apparaît, par exemple, sous la forme DR_UNSUPPORTED_FEATURE.ABAC_POLICY. Il existe deux façons de résoudre cette erreur.

1. Supprimez la fonctionnalité non prise en charge de l'asset dans le Workspace principal.
2. Si vous ne pouvez pas supprimer la fonctionnalité, envisagez de supprimer l'asset de l'étendue de réplication du groupe de basculement.

Pour en savoir plus sur les concepts et les meilleures pratiques de reprise après sinistre, consultez Récupération après sinistre.