Récupération d’urgence managée

La récupération d’urgence managée réplique votre déploiement de Azure Databricks vers une région secondaire afin de pouvoir récupérer à partir d’une panne régionale en quelques minutes. Azure Databricks gère le pipeline de réplication, l’état des catalogues répliqués dans le serveur secondaire et le processus de basculement. Vous n’écrivez pas ou ne gérez pas de scripts de réplication.

Pour connaître l’approche manuelle de la récupération d’urgence, notamment les concepts généraux de récupération d’urgence et les meilleures pratiques, consultez la récupération d’urgence.

Important

La reprise après sinistre gérée est soumise à des restrictions. Demandez l’accès auprès de votre équipe de compte Azure Databricks. Azure Databricks active la reprise après sinistre gérée pour votre compte une fois votre demande acceptée.

Qu’est-ce que la récupération d’urgence managée ?

La reprise après sinistre gérée s’appuie sur les espaces de travail et les métastores que vous utilisez déjà. Vous apportez deux espaces de travail Azure Databricks, un dans votre région primaire et un dans votre région secondaire et un metastore dans chaque région. Reprise après sinistre gérée ensuite :

  • Réplique en continu les catégories que vous choisissez du primaire vers le secondaire. Les deux catégories sont facultatives indépendamment : métadonnées du catalogue Unity et données de table managées et ressources d’espace de travail telles que les notebooks, les travaux, les entrepôts SQL, les clusters et les listes de contrôle d’accès.
  • Fournit une URL stable facultative, une seule chaîne de connexion qui pointe toujours vers le serveur principal actuel, afin que les clients continuent de travailler après le basculement sans reconfiguration.
  • Permet de déclencher un basculement quand vous le souhaitez, pour un test de reprise après sinistre ou une interruption de service réelle.

Les ID des ressources d’espace de travail sont conservés d’une région à l’autre. Les URL qui pointent vers une ressource d’espace de travail par ID continuent de fonctionner après le basculement.

Ce qui est répliqué

La reprise après sinistre gérée peut répliquer les éléments suivants à chaque cycle de réplication. Les deux catégories sont facultatives, ce qui vous permet d’activer l’une ou l’autre des deux :

  • Métadonnées et données du catalogue Unity : tables gérées par Unity Catalog dans Delta Lake avec des données, des tables externes et des volumes (métadonnées uniquement), des vues, des fonctions et toutes les autorisations accordées. 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 à l’espace de travail principal, le réplica est isolé et lié à l’espace de travail secondaire.
  • Ressources de l’espace de travail : blocs-notes, travaux, entrepôts SQL, clusters, tableaux de bord IA/BI brouillons, fichiers et dossiers, ainsi que leurs listes de contrôle d’accès. Les entrepôts SQL sont répliqués à l’état STOPPED, les clusters à l’état TERMINATED. Les planifications des tâches sur le secondaire sont suspendues.

Propriété des objets répliqués

Lorsque la reprise après sinistre gérée crée dans l’environnement secondaire un objet sécurisable répliqué (catalogue, schéma, table, vue, fonction ou volume), le propriétaire initial est le principal de service Azure Databricks qui exécute la réplication, car Unity Catalog attribue la propriété à l’identité qui crée l’objet. La reprise après sinistre gérée transfère ensuite la propriété de la réplique afin qu’elle corresponde à celle du propriétaire de l’élément sécurisable correspondant dans l’instance primaire.

Si le propriétaire d'un élément sécurisable dans le primaire est un utilisateur qui a été supprimé du compte, la reprise après sinistre gérée ne peut pas transférer la propriété à un principal qui n'existe plus. Dans ce cas, la réplique sécurisable conserve le principal du service Azure Databricks comme propriétaire. Pour résoudre cela, affectez un propriétaire valide à l’objet sécurisable sur le système principal et laissez DR le répliquer.

Requirements

  • Un espace de travail sur le plan Premium dans les régions primaires et secondaires.
  • Le module complémentaire Mission Critical de l’espace de travail est activé sur les deux espaces de travail. Consultez Activer Mission Critical sur les deux espaces de travail.
  • Calcul sans serveur activé dans les deux espaces de travail. Le calcul serverless est disponible par défaut dans la plupart des espaces de travail avec catalogue Unity. Voir Connexion à l'informatique sans serveur.
  • Rôle d’administrateur de compte avec TOUS LES PRIVILÈGES sur chaque emplacement externe utilisé par les catalogues que vous envisagez de répliquer.
  • SSO au niveau du compte avec tous les espaces de travail activés, et les identités synchronisées avec le compte via SCIM afin que les utilisateurs, les groupes et les principaux de service existent dans les deux régions.
  • Pour les URL stables : URL personnalisée approvisionnée pour votre domaine Azure Databricks (contactez l’équipe de votre compte) et OAuth au niveau du compte.
  • Un espace de travail secondaire et un metastore Unity Catalog dans la région secondaire, dans le même compte Azure Databricks et sur le même cloud que votre espace de travail principal. L'espace de travail secondaire doit correspondre au réseau, aux Private Link et à la configuration de clé gérée par le client. Le metastore secondaire ne doit pas contenir de catalogues qui partagent des noms avec des catalogues répliqués. Pour la réplication des ressources d’espace de travail, Azure Databricks supprime les ressources existantes dans l’étendue de l’espace de travail secondaire une fois la réplication initiale terminée. Les ressources hors portée ne sont pas affectées. L’espace de travail secondaire n’a donc 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 principaux. La reprise après sinistre gérée ne réplique pas automatiquement les emplacements externes ni les informations d’identification de stockage ; vous devez les créer dans l’environnement secondaire.

Étant donné que le calcul sans serveur de l’espace de travail secondaire lit les données du stockage source pendant la réplication interrégion, les stockages source et secondaire doivent tous deux autoriser l’accès réseau sans serveur d’Azure Databricks dans les deux sens.

Si vous limitez l’accès réseau à votre stockage source ou racine DBFS, autorisez également les adresses IP du plan de contrôle de la région secondaire au pare-feu de stockage source et les adresses IP du plan de contrôle de la région primaire au pare-feu DBFS secondaire. Pour connaître les adresses IP du plan de contrôle à autoriser dans chaque région, consultez Trafic entrant vers le plan de contrôle Azure Databricks.

  • Un connecteur d’accès Azure Databricks dans la région secondaire avec le rôle Contributeur aux données Blob du stockage sur les comptes de stockage secondaires, ajouté comme information d’identification de stockage dans l’espace de travail secondaire.
  • Une configuration de connectivité réseau (CCN) dans la région secondaire, associée à l’espace de travail secondaire, afin de permettre aux ressources de calcul sans serveur d’accéder au stockage via des points de terminaison privés. Consultez Configurer la connectivité privée aux ressources Azure.
  • Points de terminaison privés pour chaque compte de stockage source et chaque compte de stockage secondaire référencés par vos catalogues répliqués. Pour le stockage ADLS Gen2, créez un point de terminaison privé pour les sous-ressources dfs et blob sur chaque compte. Approuvez-les dans le portail Azure.

Activer Mission Critical sur les deux espaces de travail

Activez le module complémentaire Mission Critical sur vos espaces de travail principaux et secondaires avant de créer un groupe de basculement. L’utilisation du calcul sur chaque espace de travail où vous activez le module complémentaire est facturée au taux critique de mission. Contactez votre équipe de compte Azure Databricks pour connaître le taux actuel.

  1. Dans la console de compte, cliquez sur Espaces de travail, puis sur l’espace de travail.
  2. Cliquez sur l’onglet Modules complémentaires .
  3. Sur la carte Mission Critique, activez l’interrupteur et confirmez.

Répétez cette opération pour l’espace de travail secondaire.

Facultatif : URL stable

Azure Databricks recommande d’utiliser l’URL stable. L’URL stable se résout toujours vers l’espace de travail principal actuel, de sorte que les clients qui se connectent via celui-ci n’ont pas besoin d’être reconfigurés après un basculement. L’URL d’origine de l’espace de travail reste valide pour accéder directement à cet espace de travail, mais après un basculement, elle continue de pointer vers l’ancien serveur principal, désormais serveur secondaire. Pointez les clients en aval suivants à l’URL stable au lieu de l’URL d’espace de travail d’origine :

  • Interface utilisateur web Azure Databricks.
  • Connexions JDBC et ODBC aux entrepôts SQL.
  • Demandes d’API REST directes.

Les URL stables sont prises en charge avec le Private Link frontal (entrant). Avec le 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 l’espace de travail standard.

Configurer la réplication

Un nouveau groupe de basculement passe par CREATING → INITIAL_REPLICATION → ACTIVE. Le premier cycle de réplication copie toutes les données concernées vers la base de données secondaire. Pour les espaces de travail de grande taille, l’initialisation des ressources de l’espace de travail peut prendre jusqu’à deux semaines. Cette attente est ponctuelle. Une fois le démarrage initial terminé, la réplication s’exécute en continu.

Pendant la réplication, les catalogues secondaires concernés sont en lecture seule, et les ressources de calcul ne sont pas disponibles dans l’espace de travail secondaire. Pour exécuter des requêtes de validation sans écrire dans la base de données secondaire, Azure Databricks recommande un espace de travail de surveillance en lecture seule distinct dans la région secondaire.

Pour créer un groupe de basculement :

  1. Dans la console de compte, cliquez sur Résilience.
  2. Si vous envisagez d’utiliser une URL stable, cliquez sur l’onglet URL stables , puis créez une URL stable. Entrez un nom, sélectionnez l’espace de travail principal actuel et créez l’URL stable. Pointez les clients en aval (JDBC, ODBC, l’interface utilisateur web Azure Databricks, les requêtes d’API directes) à l’URL stable au lieu de l’URL d’espace de travail d’origine.
  3. Cliquez sur l’onglet Groupes de basculement , puis créez un groupe de basculement.
  4. Renseignez le formulaire :
    • Nom du groupe de basculement : nom que vous choisissez pour le groupe de basculement.
    • Espace de travail principal : espace de travail qui est votre espace de travail principal.
    • Espace de travail secondaire : espace de travail dans la région secondaire.
    • Répliquer les ressources de l’espace de travail (facultatif) : désactivée par défaut. Activez cette option pour répliquer des notebooks, des travaux, des entrepôts SQL, des clusters, des tableaux de bord, des fichiers et des dossiers (et leurs ACL) du serveur principal au serveur secondaire. Nécessite que les deux espaces de travail aient activé le module complémentaire Mission Critical. Si vous activez la réplication des ressources de l’espace de travail, Azure Databricks supprime toutes les ressources existantes comprises dans le périmètre dans l’environnement secondaire une fois la réplication initiale terminée. Les ressources hors portée ne sont pas affectées.
    • URL stable (facultatif) : URL stable que vous avez créée à l’étape 2.
    • Étendue de réplication : les catalogues à répliquer. Vous devez sélectionner un espace de travail principal avant que ce champ soit disponible.
    • Mappages de stockage : pour chaque emplacement externe que vos catalogues répliqués utilisent dans la région primaire, ajoutez une entrée qui mappe son chemin de stockage à l’emplacement externe correspondant que vous avez créé dans la région secondaire (voir Conditions requises). Vous pouvez utiliser * comme caractère générique pour la correspondance de préfixes.
  5. Cliquez sur Créer un groupe de basculement.

Par exemple, un mappage de stockage Azure peut associer abfss://data@primary.dfs.core.windows.net/* à abfss://data@secondary.dfs.core.windows.net/*.

Ressources créées par la reprise après sinistre gérée

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

  • Une connexion qui pointe vers l’espace de travail dans l’autre région.
  • Catalogue étranger pour chaque catalogue répliqué. Le catalogue étranger fait référence au catalogue correspondant dans l’autre région.

Ces ressources apparaissent en même temps que vos propres catalogues dans l’Explorateur de catalogues. Vous pouvez les identifier à leur commentaire, qui indique que la reprise d’activité après sinistre d’Azure Databricks les a créés et les gère.

Important

Par défaut, seul un administrateur de metastore peut modifier ou supprimer ces ressources. Ne supprimez pas les connexions ou les catalogues étrangers créés par la reprise après sinistre gérée. La suppression de l’un ou l’autre rompt la réplication pour le groupe de basculement.

ID d’espace de travail stable

Certains outils identifient un espace de travail par son ID d’espace de travail au lieu de son URL, y compris le fournisseur Databricks Terraform et les bundles de ressources Databricks. Chaque URL stable possède un identifiant stable de l’espace de travail qui pointe vers l’instance principale actuelle, de sorte que ces outils continuent donc à viser l’espace de travail actif après un basculement. Utilisez l’ID d’espace de travail stable partout où un outil demande un ID d’espace de travail, de la même façon que vous utiliseriez un ID d’espace de travail standard.

Pour rechercher l’ID d’espace de travail stable, répertoriez les URL stables de votre compte avec l’interface CLI Databricks et lisez le stable_workspace_id champ de l’URL stable appropriée :

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

Déployer avec databricks Asset Bundles et Terraform

Databricks Asset Bundles (DABs) et le fournisseur Databricks Terraform ciblent un espace de travail soit par son URL d’hôte d’espace de travail, soit par une combinaison de l’URL personnalisée du compte Azure Databricks et de l’ID d’espace de travail. Pour continuer à effectuer le déploiement sur le serveur 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 espace de travail) et spécifiez l’ID d’espace de travail stable dans le workspace_id champ. Ensemble, ils se résolvent vers le principal actuel, de sorte que vos pipelines CI/CD continuent de se déployer sur l’espace de travail actif après un basculement, sans modification de configuration.

  • Nouveaux déploiements : utilisez l’URL personnalisée et l’ID d’espace de travail stable à partir du premier déploiement.
  • Déploiements existants : importez l’état de votre projet Terraform précédent dans un nouveau projet configuré avec l’URL personnalisée et l’ID d’espace de travail stable, puis supprimez le projet précédent. Ne redirigez pas directement un projet existant — le déploiement ne reconnaît plus les ressources qu’il a créées et associées à l’URL d’origine propre à l’espace de travail ; un redéploiement les détruit donc avant de les recréer.
  • DABs: activez la réplication des ressources de l’espace de travail dans le groupe de basculement. Un package enregistre son état de déploiement dans l’espace de travail, et cet état n’est transmis au nouveau nœud principal que lors de la réplication des ressources de l’espace de travail.

Note

Après un basculement, le premier redéploiement recrée les ressources que la récupération d’urgence managée ne réplique pas, car elles n’existent pas sur le nouveau serveur principal. Les ressources répliquées sont laissées en place. Consultez les limitations relatives à ce que fait la récupération d’urgence managée et ne se réplique pas.

Surveiller la réplication

L’onglet Groupes de basculement affiche l’état actuel, le point de réplication et les erreurs actives de chaque groupe de basculement. États possibles :

State Meaning
CREATING Le groupe de basculement est en cours d’approvisionnement.
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 terminé. Consultez les informations détaillées sur l’état du groupe de basculement pour vous guider.

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 le dernier moment où 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 ne sont nécessairement présentes dans la base de données secondaire et peuvent être perdues lors d’un basculement.

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

Basculement et restauration automatique

La même procédure couvre les basculements planifiés (tests de récupération d’urgence, maintenance planifiée) et les basculements non planifiés (panne régionale). Pour effectuer une restauration automatique, répétez la procédure en inversant les régions.

Lorsque vous déclenchez un basculement, Azure Databricks :

  • Pointe l’URL stable, si elle est attachée, à la nouvelle région primaire.
  • Inverse la direction de la réplication.
  • Suspend les planifications des travaux dans l’ancien serveur principal.
  • Fait passer le groupe de basculement de FAILING_OVER à INITIAL_REPLICATION.

Pour effectuer un basculement :

  1. Informez votre équipe qu’un basculement démarre.

  2. Pour un basculement planifié uniquement :

    1. Dans l’espace de travail principal, arrêtez tous les clusters en cours d’exécution et arrêtez tous les entrepôts SQL.
    2. Vérifiez que les écritures sur le serveur principal ont cessé, puis attendez que la réplication rattrape son retard. Pour vérifier, ouvrez la page de détails du groupe de basculement et confirmez que le point de réplication se situe à quelques secondes près du moment où vous avez arrêté les écritures.

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

  4. Cliquez sur Effectuer un basculement.

  5. Sélectionnez la nouvelle région primaire et confirmez. Le basculement s'effectue en quelques minutes.

  6. Dans le nouveau serveur principal, démarrez le calcul en cours d’exécution avant le basculement. Les clusters répliqués et les entrepôts SQL arrivent dans la nouvelle instance primaire à l’état TERMINATED et STOPPED, respectivement.

  7. Reprenez manuellement les planifications des tâches nécessaires sur le nouveau serveur principal. Les horaires de l’ancien primaire sont déjà suspendus.

Les clients connectés via l’URL stable continuent de fonctionner après le basculement. Redirigez les clients qui utilisent encore l’URL de l’espace de travail d’origine vers l’URL stable ou vers l’URL de l’espace de travail de la nouvelle instance principale.

Important

Lors d’un basculement non planifié, les données écrites sur le serveur principal après le dernier point de réplication peuvent être perdues. Vérifiez que toute perte de données respecte votre objectif de point de reprise (RPO).

Tip

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

Détruire la reprise après sinistre gérée

  1. Dans la console du compte, cliquez sur Résilience → groupes de basculement, puis sur le nom du groupe de basculement et supprimez-le. Vous ne pouvez pas désactiver Mission Critical pendant qu’un groupe de basculement est actif sur l’espace de travail.
  2. Pour arrêter la facturation au taux critique de mission, désactivez Mission Critical sur chaque espace de travail à partir de l’onglet Modules complémentaires .

Limites

La reprise après sinistre gérée présente les limitations suivantes :

  • Non répliqués : les vues matérialisées, les tables de streaming, les pipelines Lakeflow, les données des volumes gérés (seules les métadonnées sont répliquées), les secrets Unity Catalog et de l’espace de travail, les modèles de ML, les points de terminaison de mise en service des modèles, les index de recherche vectorielle, les partages Delta, les tableaux de bord IA/BI publiés (les brouillons sont répliqués) et Spark Structured Streaming en dehors des pipelines Lakeflow. Les tables avec des filtres au niveau des lignes ou des masques de colonnes, ainsi que les ressources étiquetées ABAC, sont signalées comme Échec de la réplication dans la table système, et ces échecs empêchent d’atteindre l’objectif de point de reprise (RPO) tant que vous n’avez pas retiré la ressource du périmètre du groupe de basculement.
  • Les écritures de tables gérées à partir de moteurs externes ont une détectabilité limitée. La récupération d’urgence gérée détecte les modifications apportées aux tables gérées du catalogue Unity à partir des écritures effectuées par Azure Databricks calcul. Les écritures dans une table managée répliquée à partir d’un moteur externe (non Azure Databricks) via des API ouvertes, telles que le catalogue REST Iceberg, peuvent ne pas être détectées, de sorte que ces écritures peuvent ne pas être répliquées sur le serveur secondaire et peuvent être perdues pendant le basculement. Pour les tables que vous répliquez avec la reprise d’activité (DR) gérée, effectuez les écritures via les ressources de calcul Azure Databricks.
  • Les catalogues secondaires relevant du périmètre sont en lecture seule. Le mode lecture seule s’applique uniquement aux entités répliquées. Vous pouvez néanmoins configurer votre propre réplication pour les ressources sécurisées en dehors du périmètre de la reprise après sinistre gérée. Toutefois, vous ne pouvez pas exécuter de charges de calcul sur l’espace de travail secondaire lorsque la reprise après sinistre gérée est activée, ce qui limite la possibilité d’y exploiter un pipeline de réplication personnalisé.
  • Le changement de nom d'un objet sécurisable Unity Catalog déclenche une suppression et une recréation dans le secondaire. Pour les tables gérées, le changement de nom entraîne une nouvelle réplication des données de la table lors du cycle suivant. Évitez de renommer pendant la réplication à l’état stable.
  • UNDROP n’est pas propagé au secondaire.
  • 300 catalogues maximum par compte.
  • 100 groupes de basculement maximum par compte.
  • Maximum 10 catalogues par groupe de basculement.
  • La configuration initiale des ressources d'un espace de travail peut prendre jusqu'à deux semaines pour les espaces de travail de grande taille.
  • L’utilisation du pare-feu du stockage de l’espace de travail sur les comptes de stockage de l’espace de travail utilisés avec la reprise d’activité managée nécessite une configuration manuelle. Vous devez autoriser les adresses IP du plan de contrôle pertinentes sur le pare-feu de stockage afin que Azure Databricks puissiez répliquer des données. Consultez Spécifications.

Reference

Lorsqu’une ressource ne peut pas être répliquée, le groupe de basculement signale une classe d’erreur dans la table système system.replication.states, ainsi qu’un message identifiant la ressource affectée. Les sections suivantes couvrent les classes d’erreur les plus courantes et expliquent comment les résoudre. La réplication récupère automatiquement après avoir corrigé le problème sous-jacent.

DR_MISSING_DEPENDENCY

Une ressource fait référence à une dépendance qui n’existe pas dans la base de données secondaire, de sorte que la ressource ne peut pas être répliquée. La sous-classe identifie le type de dépendance manquant et apparaît sous DR_MISSING_DEPENDENCY.CATALOG, .SCHEMAou .TABLE.RESOURCE. La résolution est la même pour tous.

  1. Vérifiez si la ressource ne fonctionne pas également dans l’environnement principal à cause de la dépendance manquante. Si c’est le cas, corrigez ou supprimez la ressource dans le serveur principal.
  2. Si la ressource est valide sur le site principal, la dépendance n’entre soit pas dans le périmètre de réplication d’un groupe de basculement, soit dans celui de ce groupe de basculement ou d’un autre, mais sa réplication a échoué. Si la dépendance n’est pas incluse dans le périmètre, modifiez l’étendue de réplication du groupe de basculement afin de la répliquer elle aussi. Si la dépendance est déjà dans la portée, consultez system.replication.states pour identifier l’erreur qui empêche sa réplication et corrigez-la.
DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

La récupération d’urgence gérée décide où placer chaque ressource répliquée en appliquant les mappages de stockage du groupe de basculement à l’emplacement de stockage source de la ressource. Un mappage correspond exactement à un emplacement 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 ; la reprise d’activité gérée ne peut donc pas déterminer où placer la ressource dans l’environnement secondaire. Pour les tables et volumes externes, un mappage manquant signifie que le même URI d’emplacement est utilisé sur le serveur principal et secondaire. Le storage_location dans le message correspond au 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 une correspondance par préfixe. Consultez les mappages de stockage.
  3. Vérifiez qu’un emplacement externe dans le metastore secondaire englobe déjà le chemin cible du mappage. Le groupe de basculement rejette un mappage dont la cible ne se trouve pas dans un emplacement externe existant ; créez donc d’abord cet emplacement externe s’il n’existe pas. Consultez Se connecter au stockage d’objets cloud à l’aide du catalogue Unity.
DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION

Un mappage de stockage a associé une ressource répliquée à un chemin cible dans le secondaire, mais aucun emplacement externe dans le métastore secondaire ne couvre ce chemin ; Unity Catalog n’a donc aucun emplacement où stocker les données de la ressource. Le storage_location dans le message correspond au chemin secondaire (cible) non couvert.

Cela signifie généralement l’une des deux opérations suivantes : un emplacement externe qui a précédemment couvert le chemin d’accès a été supprimé ou réduit, ou une ressource nouvellement répliquée se résout vers 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 serveur principal sous un chemin de stockage qu’aucun de vos mappages de stockage ne couvre. Le DR géré revient alors au chemin d’origine de la table, que ne couvre aucun emplacement externe dans le metastore secondaire ; les données n’ont donc aucun emplacement où être écrites.

  1. Identifiez le chemin secondaire découvert à partir du storage_locationmessage.
  2. Déterminez l’emplacement externe dans le metastore secondaire qui doit couvrir ce chemin : un emplacement externe existant que vous étendez ou un nouvel emplacement que vous créez.
  3. Ajustez les mappages de stockage du groupe de basculement afin que le chemin d’accès soit résolu sous un emplacement externe qui existe déjà, soit créez l’emplacement externe (avec ses informations d’identification de stockage) et étendez le mappage pour qu’il pointe vers celui-ci. Consultez Se connecter au stockage d’objets cloud à l’aide du catalogue Unity.
DR_INTERNAL_ERROR

Une erreur côté système s’est produite pendant la réplication. Aucune action n’est requise ; le système récupère automatiquement. Contactez Azure Databricks support si le problème ne se résout pas par lui-même.

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

La reprise après sinistre gérée réplique la vue ainsi que ses autorisations, mais une vue qui référence des objets dans d’autres catalogues exige également que son propriétaire ait accès à ces objets référencés dans l’environnement secondaire, car la vue s’exécute avec les privilèges du propriétaire. Cette erreur signifie que le propriétaire n’a pas accès à la base de données secondaire. Vous devez donc l’accorder sur les objets référencés.

  1. Recherchez les objets auxquels la vue fait référence et le propriétaire de la vue. Les objets référencés apparaissent sous forme de noms complets catalog.schema.object dans la définition ; les autorisations doivent être accordées au propriétaire, que vous pouvez également consulter dans le champ Owner de Catalog Explorer.

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

  2. Sur le serveur 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.

    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. Accordez au propriétaire de l’affichage tous les privilèges manquants sur chaque objet référencé.

    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. Vérifiez que chaque catalogue auquel la vue fait référence est inclus dans l’étendue 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 le catalogue Unity.

DR_INVALID_CONFIGURATION.NETWORK_UNAUTHORIZED_ACCESS

Lors de la réplication inter-régions des données de table, le moteur de calcul serverless de l’espace de travail secondaire lit les données à partir du stockage source, mais 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 point de terminaison privé requis manque ou n’est pas approuvé.

Vérifiez que votre stockage source et votre stockage secondaire autorisent l’accès réseau serverless d’Azure Databricks, comme décrit dans Configuration requise.

DR_INVALID_CONFIGURATION.SERVERLESS_COMPUTE_PERMISSION

La reprise après sinistre gérée s’appuie sur le calcul sans serveur dans l’espace de travail secondaire pour copier les données ; or, le calcul sans serveur n’y est pas autorisé. Cela signifie généralement que serverless est désactivé pour le compte ou l’espace de travail, ou que l’espace de travail n’est pas éligible.

  1. Vérifiez que l’espace de travail secondaire est éligible. Le calcul serverless est disponible par défaut dans les espaces de travail avec catalogue Unity dans une région prise en charge. Voir Connexion à l'informatique sans serveur.
  2. Vérifiez s’il existe une désactivation au niveau du compte. Dans la console du compte, accédez à Paramètres → Activation des fonctionnalités et vérifiez si le bouton d’activation/désactivation du mode serverless est affiché et désactivé.
  3. Activez serverless pour l’étendue dont vous avez besoin. Pour activer tous les espaces de travail éligibles, un administrateur du compte active l’option serverless au niveau du compte. Pour activer uniquement l’espace de travail secondaire, laissez désactivé le commutateur au niveau du compte et demandez à un administrateur de l’espace de travail d’activer le mode sans serveur dans Aperçus de l’espace de travail.
  4. Si aucun interrupteur n’est disponible, ou si le mode serverless ne fonctionne toujours pas après l’avoir activé, contactez votre équipe de compte Azure Databricks.
DR_INVALID_CONFIGURATION.OVERLAPPING_EXTERNAL_LOCATIONS

Lorsque la reprise après sinistre gérée crée un objet répliqué à son chemin cible mappé dans l’environnement secondaire, Unity Catalog rejette ce chemin, car il chevauche un stockage déjà présent à cet emplacement, tel qu’un emplacement externe existant, un objet sécurisable résiduel issu d’une configuration antérieure ou partielle, un emplacement géré ou le stockage par défaut de l’espace de travail (DBFS).

  1. Identifiez ce qui occupe le chemin d’accès.

    Dans l’Explorateur de catalogues, passez en revue vos emplacements externes, emplacements de stockage gérés, tables et volumes externes pour rechercher l’objet dont le chemin couvre ou chevauche le chemin cible.

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

  3. Sinon, redirigez le mappage de stockage du groupe de basculement vers un chemin cible dédié et non superposé. Préférez un sous-chemin spécifique à une racine de compartiment large et évitez le stockage DBFS par défaut de l’espace de travail.

DR_UNSUPPORTED_FEATURE

La ressource utilise une fonctionnalité que la récupération d’urgence managée ne peut pas répliquer. La sous-classe identifie la fonctionnalité non prise en charge et apparaît, par exemple, en tant que DR_UNSUPPORTED_FEATURE.ABAC_POLICY. Il existe deux façons de résoudre cette erreur.

  1. Supprimez la fonctionnalité non prise en charge de la ressource dans l’espace de travail principal.
  2. Si vous ne pouvez pas supprimer la fonctionnalité, envisagez de retirer la ressource du périmètre de réplication du groupe de basculement.

Pour connaître les concepts de récupération d’urgence et les meilleures pratiques, consultez la récupération d’urgence.

  • Last updated on