Recuperación ante desastres administrada

La recuperación ante desastres administrada (DR) replica la implementación de Azure Databricks en una región secundaria para que pueda recuperarse de una interrupción regional en cuestión de minutos. Azure Databricks administra la canalización de replicación, el estado de los catálogos replicados en la región secundaria y el proceso de conmutación por error. No redacta ni mantiene secuencias de comandos de replicación.

Para conocer el enfoque manual para la recuperación ante desastres, incluidos los conceptos generales de recuperación ante desastres y los procedimientos recomendados, consulte Recuperación ante desastres.

Importante

La DR administrada está restringida. Solicita acceso a través del equipo de cuenta de Azure Databricks. Azure Databricks habilita la recuperación ante desastres administrada en su cuenta una vez que se haya aprobado su solicitud.

¿Qué es la recuperación ante desastres administrada?

La DR administrada se sitúa sobre las áreas de trabajo y los metastores que usted ya opera. Puede traer dos áreas de trabajo de Azure Databricks, una en la región primaria y otra en la región secundaria, y una tienda de metadatos en cada región. A continuación, la DR administrada:

  • Replica las categorías que usted elige incluir desde la región principal a la secundaria según una programación continua. Ambas categorías son opcionales de forma independiente: metadatos del catálogo de Unity y datos de tabla administrados, y recursos de área de trabajo, como cuadernos, trabajos, almacenes de SQL, clústeres y ACL.
  • Proporciona una URL estable opcional, una única cadena de conexión que siempre apunta al nodo primario actual, por lo que los clientes siguen funcionando después de la conmutación por error sin necesidad de reconfiguración.
  • Le permite desencadenar la conmutación por error cuando lo desee, para una prueba de DR o para una interrupción real.

Los identificadores de recursos del área de trabajo se conservan entre regiones, por lo que las URL que hacen referencia a un recurso del área de trabajo por id. siguen resolviéndose después de la conmutación por error.

Qué se replica

La DR administrada puede replicar lo siguiente durante cada ciclo de replicación. Ambas categorías son opcionales, por lo que puedes habilitar uno o ambos metadatos y datos del Catálogo de Unity, así como los recursos del espacio de trabajo.

Metadatos y datos del Catálogo de Unity

Object Notas
Tablas gestionadas por Unity Catalog en Delta Lake Datos y metadatos. Consulte Limitaciones.
Tablas externas Solo metadatos. Consulte Limitaciones.
Volúmenes externos Solo metadatos.
Views
Functions
Permisos concedidos
Tablas de streaming En vista previa privada. Póngase en contacto con el equipo de la cuenta de Azure Databricks para obtener más información.
Vistas materializadas En vista previa privada. Póngase en contacto con el equipo de la cuenta de Azure Databricks para obtener más información.
Filtros de fila, máscaras de columna y políticas de control de acceso basadas en atributos (ABAC) En vista previa privada. Póngase en contacto con el equipo de la cuenta de Azure Databricks para obtener más información.
Catálogos extranjeros En vista previa privada. Póngase en contacto con el equipo de la cuenta de Azure Databricks para obtener más información.

También se replica el modo de aislamiento del catálogo. Si el catálogo fuente está abierto, su réplica está abierta. Si el catálogo fuente está aislado y vinculado al espacio de trabajo principal, la réplica queda aislada y vinculada al espacio de trabajo secundario.

Activos del espacio de trabajo

Los activos de espacio de trabajo se replican junto con sus ACLs.

Object Notas
Notebooks
Jobs Las programaciones de trabajos en la secundaria están en pausa.
Almacenes de SQL Replicado en el estado STOPPED.
Clusters Replicado en el estado TERMINATED. También incluye políticas de cómputo, perfiles de instancia y scripts globales de init.
Grupos de instancias Las reservas de capacidad son específicas de la región y deben configurarse en la secundaria.
Si tu grupo de failover se creó antes del 17 de septiembre de 2026, contacta con tu equipo de cuentas de Azure Databricks para añadir pools de instancias a tu grupo de failover.
Paneles de IA/BI en borrador
Archivos
Carpetas No incluye carpetas Git.
Queries Incluye consultas creadas y guardadas en el editor SQL.
Libraries
Destinos de notificaciones
Agentes de Genie En vista previa privada. Póngase en contacto con el equipo de la cuenta de Azure Databricks para obtener más información.
Canalizaciones de Lakeflow En vista previa privada. Póngase en contacto con el equipo de la cuenta de Azure Databricks para obtener más información.

Propiedad de objetos replicados

Cuando la recuperación ante desastres (DR) administrada crea un objeto protegible replicado (catálogo, esquema, tabla, vista, función o volumen) en el secundario, el propietario inicial es la entidad de servicio de Azure Databricks que ejecuta la replicación, porque Unity Catalog asigna la propiedad a la identidad que crea el objeto. A continuación, la DR administrada transfiere la propiedad de la réplica para que coincida con el propietario del elemento protegible correspondiente en el sistema primario.

Si el propietario de un elemento protegible en el primario es un usuario que se ha eliminado de la cuenta, la recuperación ante desastres administrada (Managed DR) no puede transferir la propiedad a un sujeto que ya no existe. En este caso, el elemento protegible de la réplica mantiene al sujeto de servicio de Azure Databricks como su propietario. Para resolverlo, asigne un propietario válido al objeto protegible en el primario y deje que DR lo replique.

Requirements

Para configurar una DR gestionada, debes tener lo siguiente:

  • Un área de trabajo del plan Premium en las regiones primarias y secundarias.
  • El complemento Mission Critical del área de trabajo habilitado en ambas áreas de trabajo. Consulte Habilitación de Mission Critical en ambas áreas de trabajo.
  • Cómputo sin servidor habilitado en ambas áreas de trabajo. La computación sin servidor está disponible de forma predeterminada en la mayoría de los espacios de trabajo con Unity Catalog habilitado. Véase Conexión a la computación sin servidor.
  • Rol de administrador de cuenta con TODOS los privilegios en cada ubicación externa usada por los catálogos que planea replicar.

Requisitos previos de configuración

Para usar la recuperación ante desastres administrada, asegúrese de que los siguientes ajustes y recursos estén configurados.

Categoría Detalles
Espacio de trabajo secundario y metastore
  • Un espacio de trabajo secundario y un metastore de Unity Catalog en la región secundaria, en la misma cuenta de Azure Databricks y en la misma nube que su principal.
  • Ten en cuenta las siguientes advertencias al configurar tu secundario:
    • El metastore secundario no debe contener catálogos que compartan nombres con catálogos replicados.
    • Para la replicación de activos de espacio de trabajo, Azure Databricks elimina cualquier activo existente dentro del alcance en el espacio de trabajo secundario cuando la replicación inicial se completa. Los recursos fuera del ámbito no se ven afectados, por lo que el área de trabajo secundaria no necesita estar vacía.
Identity
  • SSO a nivel de cuenta con todos los espacios de trabajo habilitados y las identidades sincronizadas con la cuenta mediante AIM o SCIM para que existan usuarios, grupos y principales de servicio en ambas regiones.
  • Para direcciones URL estables: una dirección URL personalizada aprovisionada para el dominio de Azure Databricks (póngase en contacto con el equipo de la cuenta) y OAuth de nivel de cuenta.
Almacenamiento y acceso a datos
  • Un conector de acceso de Azure Databricks en la región secundaria con el rol Storage Blob Data Contributor en las cuentas de almacenamiento secundarias, agregado como credencial de almacenamiento en el área de trabajo secundaria.
  • Una ubicación externa y una credencial de almacenamiento correspondientes en la región secundaria para cada una de las referencias de sus catálogos principales. La DR gestionada no replica automáticamente ubicaciones externas ni credenciales de almacenamiento. Debe crearlos en la secundaria.
Creación de redes
  • Asegúrate de que los siguientes objetos a nivel de cuenta estén asociados tanto a tu espacio de trabajo principal como secundario: Configuración de Conectividad de Red (NCC), Política de Red (salida sin servidor), Configuración de acceso privado (PAS) y Lista de acceso IP.
  • Tanto el almacenamiento de origen como el secundario deben permitir el acceso a redes serverless de Azure Databricks en ambas direcciones.
  • Una configuración de conectividad de red (NCC) en la región secundaria, asignada al área de trabajo secundaria, para que la computación sin servidor pueda acceder al almacenamiento a través de extremos privados. Consulte Configurar la conectividad privada con recursos Azure.
  • Si utiliza conectividad privada a las cuentas de almacenamiento que contienen sus datos de origen o replicados, tanto el espacio de trabajo primario como el secundario necesitan puntos de conexión privados tanto a la cuenta de almacenamiento primaria como a la secundaria. Crea endpoints privados para los subrecursos dfs y blob de cada cuenta. Apruébelos en el Portal de Azure.
Coste y gobernanza
  • Asociar la política de uso sin servidor de nivel de cuenta (anteriormente, política de presupuesto sin servidor) con los espacios de trabajo principal y secundario.
Disposición de la mesa
  • Para las tablas que consultas por marca de tiempo, usando viajes en el tiempo o el feed de datos de cambios, Databricks recomienda habilitar las marcas de tiempo en compromiso (delta.enableInCommitTimestamps = true) antes de configurar la replicación. Las tablas gestionadas por catálogo gestionan las marcas de tiempo de commit por ti, así que no puedes asignarles esta propiedad. Consulte Limitaciones.

Habilitación de Mission Critical en ambas áreas de trabajo

Habilite el complemento Mission Critical en sus áreas de trabajo principal y secundaria antes de crear un grupo de conmutación por error. El uso de cómputo en cada área de trabajo donde se habilite el complemento se factura a la tarifa Mission Critical. Póngase en contacto con el equipo de la cuenta de Azure Databricks para obtener la tarifa actual.

  1. En la consola de la cuenta, haga clic en Áreas de trabajo y, a continuación, haga clic en el área de trabajo.
  2. Haga clic en la pestaña Complementos .
  3. En la tarjeta Misión crítica, active el interruptor y confirme.

Repita el proceso para el área de trabajo secundaria.

Opcional: dirección URL estable

Azure Databricks recomienda usar la dirección URL estable. La URL estable siempre apunta al espacio de trabajo principal actual, por lo que los clientes que se conectan a través de ella no necesitan reconfigurarse después de una conmutación por error. La dirección URL del área de trabajo original sigue siendo válida para el acceso directo a esa área de trabajo, pero después de una conmutación por error sigue apuntando a la antigua principal, ahora la secundaria. Haga que los siguientes clientes posteriores apunten a la URL estable en lugar de a la URL original del espacio de trabajo:

  • Interfaz de usuario web de Azure Databricks.
  • Conexiones JDBC y ODBC a almacenes de datos SQL.
  • Solicitudes de API REST directas.

Las direcciones URL estables son compatibles con Private Link de front-end (de entrada). Con Private Link entrante, la URL estable utiliza su URL personalizada con un ID de conexión estable, en lugar del formato de URL estándar del espacio de trabajo.

Por ejemplo, la URL estable adopta la forma <my-custom-url>.azuredatabricks.net/?w=stable_connection_id. Consulta Configurar Private Link entrante para espacios de trabajo con recuperación ante desastres gestionada.

Conectar los clientes a la URL estable

Los clientes se conectan a través de la URL estable del mismo modo que se conectan a una URL de área de trabajo, con dos diferencias: utilice el host de la URL estable en lugar de la URL original del área de trabajo, e identifique el área de trabajo con el ID de conexión estable en el parámetro de consulta w. Autentica con OAuth a nivel de cuenta.

Conexiones JDBC y ODBC a almacenes de datos SQL

Establezca el Nombre de host del servidor en el host de la URL estable y, a continuación, anexe ?w=stable_connection_id a la Ruta HTTP del almacén:

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

Obtén el ID del almacén desde la ruta HTTP en la pestaña de Detalles de conexión del almacén (consulta Obtener detalles de conexión para un recurso informático de Azure Databricks). Usa el mismo puerto y configuraciones de controladores que usarías con la URL original del espacio de trabajo.

Solicitudes directas de API REST

Envía las peticiones al host de la URL estable y añade el w=stable_connection_id parámetro de consulta a la petición. Por ejemplo, para mostrar los clústeres:

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

Configuración de la replicación

Un nuevo grupo de conmutación por error pasa por CREATING → INITIAL_REPLICATION → ACTIVE. El primer ciclo de replicación copia todos los datos dentro del ámbito en la región secundaria. Para espacios de trabajo grandes, el bootstrap inicial del recurso del espacio de trabajo puede tardar hasta cinco días. Esta espera solo se produce una vez. Una vez completado el arranque inicial, la replicación se ejecuta continuamente.

Durante la replicación, los catálogos secundarios dentro del ámbito son de solo lectura y el proceso no está disponible en el área de trabajo secundaria. Para ejecutar consultas de validación sin escribir en la región secundaria, Azure Databricks recomienda usar un área de trabajo de supervisión independiente de solo lectura en la región secundaria.

Para crear un grupo de conmutación por error:

  1. En la consola de la cuenta, haga clic en Resistencia.
  2. Si tiene previsto usar una dirección URL estable, haga clic en la pestaña Direcciones URL estables y, a continuación, en Crear dirección URL estable. Escriba un nombre, seleccione el área de trabajo principal actual y cree la dirección URL estable. Dirija los clientes posteriores (JDBC, ODBC, la interfaz web de Azure Databricks y las peticiones directas a la API) a la dirección URL estable en lugar de a la dirección URL original del área de trabajo.
  3. Haga clic en la pestaña Grupos de conmutación por error y, a continuación, en Crear grupo de conmutación por error.
  4. Rellene el formulario:
    • Nombre del grupo de conmutación por error: Un nombre que usted elija para el grupo de conmutación por error.
    • Área de trabajo principal: El área de trabajo principal.
    • Área de trabajo secundaria: área de trabajo de la región secundaria.
    • Replicación de recursos del área de trabajo (opcional): desactivado de forma predeterminada. Activa para replicar los activos de espacio de trabajo y sus ACLs desde el principal hasta el secundario. Requiere que ambos espacios de trabajo tengan activado el complemento Misión Crítica . Si activa la replicación de recursos del área de trabajo, Azure Databricks elimina los recursos existentes en el ámbito secundario cuando se completa la replicación inicial. Los recursos fuera del ámbito no se ven afectados.
    • Dirección URL estable (opcional): la dirección URL estable que creó en el paso 2.
    • Ámbito de replicación: los catálogos que se van a replicar. Debe seleccionar un área de trabajo principal antes de que este campo esté disponible.
    • Asignaciones de almacenamiento: para cada ubicación externa que usan los catálogos replicados en la región primaria, agregue una entrada que asigne su ruta de acceso de almacenamiento a la ubicación externa correspondiente que creó en la región secundaria (consulte Requisitos). Puede usar * como carácter comodín para la coincidencia de prefijos.
  5. Haga clic en Crear grupo de conmutación por error.

Por ejemplo, una asignación de almacenamiento de Azure podría asignar abfss://data@primary.dfs.core.windows.net/* a abfss://data@secondary.dfs.core.windows.net/*.

Recursos creados por la recuperación ante desastres administrada

Al crear un grupo de conmutación por error, la recuperación ante desastres administrada aprovisiona recursos auxiliares de Unity Catalog que la canalización de replicación utiliza para copiar datos entre regiones. Tanto en el metastore principal como en el secundario, la recuperación ante desastres administrada crea:

  • Una conexión que apunta al espacio de trabajo de la otra región.
  • Un catálogo externo para cada catálogo replicado. El catálogo externo hace referencia al catálogo correspondiente en la otra región.

Estos recursos aparecen junto con sus propios catálogos en el Explorador de catálogos. Puede identificarlos por su comentario, en el que se indica que la recuperación ante desastres de Azure Databricks los crea y administra.

Importante

De forma predeterminada, solo un administrador de metastore puede modificar o eliminar estos recursos. No elimine las conexiones ni los catálogos externos que crea la DR administrada. La eliminación de cualquiera de ellos interrumpe la replicación del grupo de conmutación por error.

Identificador de área de trabajo estable

Algunas herramientas identifican un área de trabajo por su identificador de área de trabajo en lugar de su dirección URL, incluidos el proveedor de Terraform de Databricks y los conjuntos de recursos de Databricks. Cada URL estable tiene un ID de espacio de trabajo estable que apunta al espacio de trabajo principal actual, por lo que estas herramientas siguen apuntando al espacio de trabajo activo tras una conmutación por error. Use el identificador de área de trabajo estable siempre que una herramienta solicite un identificador de área de trabajo, de la misma manera que usaría un identificador de área de trabajo normal.

Para buscar el identificador de área de trabajo estable, enumere las direcciones URL estables de su cuenta con la CLI de Databricks y lea el stable_workspace_id campo de la dirección URL estable pertinente:

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

Implementar con Databricks Asset Bundles y Terraform

Los paquetes de activos de Databricks (DAB) y el proveedor de Databricks para Terraform se dirigen a un espacio de trabajo bien mediante la URL del host de dicho espacio, bien mediante una combinación de la URL personalizada de la cuenta de Azure Databricks y el ID del espacio de trabajo. Para seguir realizando implementaciones en el primario actual después de una conmutación por error, configure el host con su URL personalizada —la parte del host de la URL estable, no la URL original de cada espacio de trabajo— y especifique el ID del espacio de trabajo estable en el campo workspace_id. Juntos apuntan al espacio de trabajo principal actual, por lo que sus canalizaciones de CI/CD siguen realizándose en el espacio de trabajo activo tras una conmutación por error, sin necesidad de cambiar la configuración.

  • Nuevas implementaciones: use la dirección URL personalizada y el identificador de área de trabajo estable de la primera implementación.
  • Implementaciones existentes: importe el estado del proyecto de Terraform anterior en un nuevo proyecto configurado con la dirección URL personalizada y el identificador de área de trabajo estable y, a continuación, quite el proyecto anterior. No cambie la dirección de un proyecto existente: la implementación ya no reconoce los recursos que creó con la URL original de cada espacio de trabajo, por lo que una nueva implementación los destruye y los vuelve a crear.
  • DAB: habilite la replicación de activos del espacio de trabajo en el grupo de conmutación por error. Un paquete almacena su estado de implementación en el área de trabajo, y solo llega al nuevo nodo principal como parte de la replicación de recursos del área de trabajo.

Note

Tras una conmutación por error, la primera reimplementación recrea cualquier recurso que la recuperación ante desastres administrada no replique, ya que no existen en el nuevo primario. Los recursos replicados quedan en su lugar. Consulta Limitaciones para saber qué replica y qué no replica la recuperación ante desastres administrada.

Supervisión de la replicación

La pestaña Grupos de conmutación por error muestra, para cada grupo de conmutación por error, su estado actual, el punto de replicación y cualquier error activo. Los posibles estados son:

Estado Meaning
CREATING Se está aprovisionando el grupo de conmutación por error.
INITIAL_REPLICATION El primer ciclo de replicación está en curso. La conmutación por error aún no está disponible.
ACTIVE La replicación está en estado estable. La conmutación por error está disponible.
FAILING_OVER Hay una conmutación por error en curso.
FAILOVER_FAILED, , CREATION_FAILED, DELETION_FAILED La operación no se completó. Compruebe los detalles de estado del grupo de conmutación por error para obtener orientación.

Seleccione el nombre de un grupo de conmutación por error para abrir su página de detalles. La replicación se ejecuta continuamente, pero el punto de replicación muestra la última vez que se copiaron todos los recursos dentro del ámbito. Es posible que algunos recursos individuales estén más actualizados, pero no todos los datos posteriores al punto de replicación pueden existir en el secundario y pueden perderse durante la conmutación por error.

Cuando se muestra un punto de replicación, todo lo que no está cubierto por un error se ha replicado hasta ese punto. Durante la replicación inicial, antes de que exista el primer punto de replicación, el grupo de conmutación por error aún puede mostrar errores de bloqueo, pero aún no mide la integridad. Los tipos de activos que la DR administrada no admite en absoluto no aparecen en la tabla del sistema system.replication.states. Consulte Limitaciones. Para verificar un activo específico, inspecciónalo en el secundario (véase Configurar replicación).

Para monitorizar las tendencias históricas del RPO y ver los errores que bloquean la replicación, consulte la tabla del sistema system.replication.states. Consulte Referencia de la tabla del sistema de replicación. Para obtener las clases de error más comunes y cómo resolverlas, consulte Referencia.

Conmutación por error y conmutación por recuperación

El mismo procedimiento abarca las conmutaciones por error planeadas (pruebas de recuperación ante desastres, mantenimiento programado) y conmutaciones por error no planeadas (una interrupción regional). Para conmutar por recuperación, repita el procedimiento con las regiones invertidas.

Cuando desencadena una conmutación por error, Azure Databricks:

  • Apunta la dirección URL estable, si está asociada, a la nueva región primaria.
  • Invierte la dirección de la replicación.
  • Pausa las programaciones de trabajos en la región que antes era principal.
  • Pasa el grupo de conmutación por error de FAILING_OVER a INITIAL_REPLICATION.

Para conmutar por error:

  1. Avise a su equipo de que se está iniciando una conmutación por error.

  2. Solo para una conmutación por error planeada:

    1. En el área de trabajo principal, finalice todos los clústeres en ejecución y detenga todos los almacenes de SQL.
    2. Confirme que las escrituras en la región principal se han detenido y, después, espere a que la replicación se ponga al día. Para comprobarlo, abra la página de detalles del grupo de conmutación por error y confirme que el punto de replicación está a unos segundos de la hora en la que detuvo las escrituras.

  3. En la consola de la cuenta, haga clic en Resistencia → grupos de conmutación por error y, a continuación, haga clic en el nombre del grupo de conmutación por error.

  4. Haga clic en Conmutación por error.

  5. Seleccione la nueva región primaria y confirme. La conmutación por error se completa en minutos.

  6. En el nuevo nodo principal, reinicie la carga de cómputo que se estaba ejecutando antes de la conmutación por error. Los clústeres y almacenes SQL replicados llegan a la nueva región principal en estado TERMINATED y STOPPED, respectivamente.

  7. Reanude manualmente las programaciones de trabajos que necesite en la nueva región principal. Las programaciones de la región que antes era principal ya están pausadas.

Los clientes conectados a través de la dirección URL estable siguen funcionando después de la conmutación por error. Redirija los clientes que todavía usan la URL original del área de trabajo a la URL estable o a la URL del área de trabajo de la nueva región principal.

Importante

En una conmutación por error no planeada, los datos escritos en la región principal después del último punto de replicación podrían perderse. Confirme que cualquier pérdida esté dentro de su objetivo de RPO.

Sugerencia

Pruebe la conmutación por error con regularidad, por ejemplo una vez por trimestre, para que su equipo conozca el procedimiento antes de una interrupción real.

Desmantelar la DR administrada

  1. En la consola de la cuenta, haga clic en Resistencia → grupos de conmutación por error y, a continuación, haga clic en el nombre del grupo de conmutación por error y elimínelo. No puede desactivar Mission Critical mientras haya un grupo de conmutación por error activo en el área de trabajo.
  2. Para dejar de facturar con la tarifa de Mission Critical, desactive Mission Critical en cada área de trabajo desde la pestaña Complementos.

Limitaciones

La recuperación ante desastres administrada tiene las siguientes limitaciones:

  • No replicados: volúmenes gestionados, secretos de Unity Catalog y espacio de trabajo, modelos de ML, endpoints de servicio de modelos, índices de búsqueda vectorial, compartidos Delta, paneles de IA/BI publicados (los borradores replican) y Spark Structured Streaming fuera de las canalizaciones de Lakeflow. Las tablas con soporte archivístico de Delta Lake (delta.timeUntilArchived) se marcan como Fallidas para replicar en la tabla del sistema, y estos fallos detienen el RPO hasta que eliminas el recurso del alcance del grupo de failover. La replicación de metadatos no está soportada para tablas externas no Delta Lake que usan metadatos de partición.
  • La replicación para vistas materializadas, tablas de streaming y pipelines de Lakeflow está en Private Preview. Póngase en contacto con el equipo de la cuenta de Azure Databricks para obtener más información.
  • Las tablas con filtros de fila o enmascaramiento de columnas y los recursos con etiquetas ABAC se marcan como No se pudo replicar en la tabla del sistema, y estos errores retrasan el RPO hasta que se retire el recurso del ámbito del grupo de conmutación por error. La replicación de estos recursos está en Vista Previa Privada. Póngase en contacto con el equipo de la cuenta de Azure Databricks para obtener más información.
  • Las operaciones de escritura en tablas administradas desde motores externos son difíciles de detectar. La DR administrada detecta cambios en las tablas administradas de Unity Catalog provocados por operaciones de escritura realizadas por los recursos de proceso de Azure Databricks. Es posible que no se detecten las escrituras realizadas en una tabla administrada replicada desde un motor externo (que no sea Azure Databricks) mediante API abiertas, como el catálogo REST de Iceberg, por lo que es posible que esas escrituras no se repliquen en la secundaria y puedan perderse durante la conmutación por error. Para las tablas que se repliquen con recuperación ante desastres administrada, la escritura se realiza a través del entorno de proceso de Azure Databricks.
  • Los catálogos secundarios dentro del ámbito son de solo lectura. La condición de solo lectura se aplica únicamente a las entidades replicadas. Puede seguir configurando su propia replicación para elementos protegibles fuera del ámbito de la DR administrada. Sin embargo, no se pueden ejecutar cargas de cómputo en el espacio de trabajo secundario mientras la recuperación ante desastres administrada esté habilitada, lo que limita la posibilidad de operar allí una canalización de replicación por cuenta propia.
  • Cambiar el nombre de un elemento protegible de Unity Catalog desencadena una eliminación y recreación en la región secundaria. En el caso de las tablas administradas, el cambio de nombre vuelve a replicar los datos de la tabla en el siguiente ciclo. Evite cambiar el nombre durante la replicación de estado estable.
  • UNDROP no se propaga a la región secundaria.
  • Para tablas sin marcas de tiempo en compromiso, el viaje en el tiempo por marca puede devolver la versión incorrecta. En estas tablas, Delta Lake toma la marca de tiempo de cada commit del tiempo de modificación del archivo de commit, y los archivos de commit replicados llevan el tiempo en que fueron copiados en lugar del tiempo de commit original. Como resultado, las consultas de viaje en el tiempo y las lecturas de datos de cambios por marca de tiempo pueden resolver a una versión diferente a la de la tabla fuente, sin generar errores. Esto afecta al secundario tan pronto como una tabla se replica, y al principal tras un failover o failback. El viaje en el tiempo por versión no se ve afectado. Para evitar esto, activa las marcas de tiempo en compromiso en estas tablas antes de configurar la replicación. Consulta los requisitos de configuración.
  • La inicialización inicial de los recursos del espacio de trabajo puede tardar hasta cinco días en los espacios de trabajo grandes.
  • El uso del firewall de almacenamiento del espacio de trabajo en las cuentas de almacenamiento del espacio de trabajo utilizadas con recuperación ante desastres administrada requiere configuración manual. Debe permitir las direcciones IP del plano de control pertinentes en el firewall de almacenamiento para que Azure Databricks pueda replicar datos. Vea Requisitos.

Referencia

Cuando no es posible replicar un recurso, el grupo de conmutación por error muestra una clase de error en la tabla del sistema system.replication.states, junto con un mensaje que identifica el recurso afectado. En las secciones siguientes se tratan las clases de error más comunes y cómo resolverlas. La replicación se recupera automáticamente después de corregir el problema subyacente.

DR_MISSING_DEPENDENCY

Un recurso hace referencia a una dependencia que no existe en la base de datos secundaria, por lo que el recurso no se puede replicar. La subclase identifica el tipo de dependencia que falta y aparece como DR_MISSING_DEPENDENCY.CATALOG, .SCHEMA, .TABLEo .RESOURCE. La resolución es la misma para todos ellos.

  1. Comprueba si el activo también está inoperativo en el sistema primario debido a la falta de la dependencia. Si es así, corrige o elimina el activo en el sistema primario.
  2. Si el activo es válido en el sistema primario, la dependencia o bien no se encuentra dentro del ámbito de replicación de ningún grupo de conmutación por error, o bien se encuentra dentro del ámbito de este u otro grupo de conmutación por error, pero no se ha podido replicar. Si la dependencia no se encuentra dentro del ámbito, edita el ámbito de replicación del grupo de conmutación por error para que también se replique. Si la dependencia ya se encuentra dentro del ámbito, comprueba system.replication.states el error que impide su replicación y resuelve dicho error.
DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

Managed DR decide dónde colocar cada activo replicado aplicando las asignaciones de almacenamiento del grupo de conmutación por error a la ubicación de almacenamiento de origen del activo. Una asignación coincide exactamente con una ubicación, o bien como un prefijo que también abarca las rutas secundarias. Este error significa que ningún mapeo cubre una ubicación de almacenamiento de origen, por lo que la recuperación ante desastres administrada no puede determinar dónde colocar el activo en el sistema secundario. En el caso de las tablas y los volúmenes externos, la ausencia de una asignación significa que se utiliza el mismo URI de ubicación tanto en el primario como en el secundario. El storage_location del mensaje es la ruta de origen sin asignar.

  1. En la consola de la cuenta, vaya a Resiliencia → Grupos de conmutación por error y edite el grupo de conmutación por error.
  2. En Asignaciones de almacenamiento, agregue o amplíe una asignación para que abarque la ubicación de origen en el mensaje. Para cubrir las rutas secundarias, asigne una ruta principal y añada el sufijo /* para que coincida el prefijo. Consulte asignaciones de almacenamiento.
  3. Confirmar que una ubicación externa en el metastore secundario ya cubre la ruta de destino del mapeo. El grupo de conmutación por error rechaza una asignación cuyo destino no se encuentre bajo una ubicación externa existente, por lo que debe crear primero dicha ubicación externa si no existe. Consulte Conexión al almacenamiento de objetos en la nube mediante el catálogo de Unity.
DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION

Una asignación de almacenamiento asignó un activo replicado a una ruta de destino en el sistema secundario, pero ninguna ubicación externa del metastore secundario cubre esa ruta, por lo que Unity Catalog no tiene dónde ubicar los datos del activo. El storage_location del mensaje es la ruta secundaria (de destino) no cubierta.

Esto suele significar una de las dos cosas: una ubicación externa que anteriormente abarcaba la ruta de acceso se ha quitado o restringido, o un recurso recién replicado se resuelve en una ruta de acceso secundaria que no cubre ninguna ubicación externa. El segundo caso se da, por ejemplo, cuando se crea una tabla externa en el sistema principal en una ruta de almacenamiento que no está cubierta por ninguna de las asignaciones de almacenamiento. La DR administrada vuelve a usar la ruta original de la tabla, que no está abarcada por ninguna ubicación externa del metastore secundario, por lo que los datos no tienen dónde almacenarse.

  1. Identifique la ruta secundaria no cubierta del storage_location del mensaje.
  2. Decida qué ubicación externa en el metastore secundario debe cubrir esa ruta de acceso: una ubicación externa existente que extienda o una nueva que cree.
  3. O bien se ajustan las asignaciones de almacenamiento del grupo de conmutación por error para que la ruta apunte a una ubicación externa que ya exista, o bien se crea la ubicación externa (con sus credenciales de almacenamiento) y se amplía la asignación para que apunte a ella. Consulte Conexión al almacenamiento de objetos en la nube mediante el catálogo de Unity.
DR_INTERNAL_ERROR

Se produjo un fallo en el sistema durante la replicación. No se requiere ninguna acción; el sistema se recupera automáticamente. Póngase en contacto con Azure Databricks soporte técnico si el problema no se resuelve por sí mismo.

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

La recuperación ante desastres administrada replica la vista junto con sus permisos, pero una vista que hace referencia a objetos de otros catálogos también requiere que su propietario tenga acceso a dichos objetos en el servidor secundario, ya que la vista se ejecuta con los privilegios del propietario. Este error significa que al propietario le falta ese acceso en el servidor secundario, por lo que debes concederlo sobre los objetos a los que se hace referencia allí.

  1. Busque los objetos a los que hace referencia la vista y el propietario de la vista. Los objetos a los que se hace referencia aparecen con su nombre completo catalog.schema.object en la definición; los permisos deben concederse al propietario, que también puede consultarse en el campo Owner de Catalog Explorer.

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

  2. En la base de datos secundaria, compruebe los privilegios actuales del propietario en cada objeto al que se hace referencia. La lectura de una tabla requiere USE CATALOG en su catálogo, USE SCHEMA en su esquema y SELECT en la tabla.

    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. Conceda al propietario de la vista los privilegios que faltan en cada objeto al que se hace referencia.

    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. Comprueba que todos los catálogos a los que hace referencia la vista estén incluidos en el ámbito de replicación de un grupo de conmutación por error, de modo que también existan en el secundario.

Para obtener más información, consulte Administrar privilegios en el catálogo de Unity.

DR_INVALID_CONFIGURATION.NETWORK_UNAUTHORIZED_ACCESS

Durante la replicación de datos de tabla entre regiones, el proceso sin servidor del área de trabajo secundaria lee los datos del almacenamiento de origen y el almacenamiento deniega la conexión de red: un firewall de almacenamiento o una regla de red lo bloquean, o falta o no se aprueba un punto de conexión privado necesario.

Compruebe que el almacenamiento de origen y el secundario permitan el acceso de red sin servidor de Azure Databricks, tal como se describe en Requisitos.

DR_INVALID_CONFIGURATION.MISSING_STORAGE_PRIVATE_ENDPOINT

DR administrado copia los datos de las tablas sobre endpoints privados cuando tu almacenamiento utiliza conectividad privada. Los endpoints privados en las cuentas de almacenamiento fuente y secundario deben coincidir. O bien ninguna cuenta tiene un punto final privado, o bien ambas cuentas tienen un punto final privado blob y un punto final privado dfs. Este error significa que no coinciden. El mensaje enumera los endpoints que faltan.

  1. Para cada cuenta de almacenamiento mencionada en el mensaje, crea los puntos de conexión faltantes blob y dfs privados para que ambos lados coincidan. Los espacios de trabajo principal y secundario necesitan puntos finales privados para ambas cuentas de almacenamiento. Consulte Configurar la conectividad privada con recursos Azure.
  2. Aprueba los nuevos endpoints privados en el portal de Azure. Consulta los requisitos de configuración.
DR_INVALID_CONFIGURATION.SERVERLESS_COMPUTE_PERMISSION

La recuperación ante desastres administrada usa la computación sin servidor en el espacio de trabajo secundario para copiar datos, y la computación sin servidor no está permitida allí. Esto suele significar que serverless está desactivado para la cuenta o el espacio de trabajo, o que el espacio de trabajo no cumple los requisitos.

  1. Confirme que el área de trabajo secundaria es apta. La computación sin servidor está disponible de forma predeterminada en los espacios de trabajo con Unity Catalog habilitado de una región admitida. Véase Conexión a la computación sin servidor.
  2. Compruebe si existe una desactivación a nivel de cuenta. En la consola de la cuenta, vaya a Configuración → Habilitación de funciones y compruebe si el interruptor de serverless aparece y está desactivado.
  3. Active la tecnología sin servidor en el ámbito que necesite. Para habilitar todos los área de trabajo elegibles, un administrador de la cuenta activa el conmutador sin servidor a nivel de cuenta. Para habilitar únicamente el espacio de trabajo secundario, deja desactivado el conmutador a nivel de cuenta y haz que un administrador del espacio de trabajo habilite la opción sin servidor desde la sección Vistas previas del espacio de trabajo.
  4. Si no hay ningún interruptor disponible, o serverless sigue sin funcionar después de habilitarlo, póngase en contacto con el equipo de cuentas de Azure Databricks.
DR_INVALID_CONFIGURATION.OVERLAPPING_EXTERNAL_LOCATIONS

Cuando la recuperación ante desastres administrada crea un objeto replicado en su ruta de destino asignada en el secundario, Unity Catalog rechaza la ruta porque se solapa con un almacenamiento que ya existe allí, como una ubicación externa existente, un elemento protegible sobrante de una configuración anterior o parcial, una ubicación administrada o el almacenamiento predeterminado (DBFS) del espacio de trabajo.

  1. Identifique lo que ocupa la ruta de acceso.

    En el Explorador de catálogos, revise las ubicaciones externas, las ubicaciones de almacenamiento administradas y las tablas y volúmenes externos para buscar el objeto cuya ruta cubre o superpone la ruta de acceso de destino.

  2. Si el objeto en conflicto no debe tener asignada la ruta de acceso, elimínelo. Una causa común es que quede una tabla externa o un volumen externo de una configuración anterior; elimínelo si ya no es necesario. Si es una ubicación externa que no debe cubrir la ruta de acceso, quite o vuelva a definirla.

  3. De lo contrario, reasigna la asignación de almacenamiento del grupo de conmutación por error a una ruta de destino dedicada que no se solape. Prefiera una subruta específica en lugar de la raíz amplia de un bucket y evite el almacenamiento predeterminado (DBFS) del espacio de trabajo.

DR_UNSUPPORTED_FEATURE

El recurso usa una característica que la recuperación ante desastres administrada no puede replicar. La subclase identifica la característica no admitida y aparece, por ejemplo, como DR_UNSUPPORTED_FEATURE.ABAC_POLICY. Hay dos maneras de resolver este error.

  1. Quite la característica no admitida del recurso en el área de trabajo principal.
  2. Si no puedes eliminar la función, considera la posibilidad de eliminar el activo del ámbito de replicación del grupo de conmutación por error.
DR_UNSUPPORTED_FEATURE.TABLE_ARCHIVED_FILES

La tabla tiene habilitada la compatibilidad con archivado de Delta Lake (delta.timeUntilArchived). La DR gestionada clona todos los archivos de datos, por lo que los objetos archivados deben restaurarse en una capa de almacenamiento caliente y la propiedad de la tabla debe desactivarse en el primario antes de que la replicación pueda continuar. Consulte Compatibilidad con archivos en Azure Databricks.

  1. Desactiva la política de archivo del ciclo de vida en la nube en la ubicación de almacenamiento de la tabla para que no se archiven archivos adicionales después de listarlos.

  2. Lista de archivos que deben restaurarse:

    SHOW ARCHIVED FILES FOR <table_name>;

  3. Restaura esos objetos en tu proveedor de nube y luego espera hasta que se complete la restauración. Consulte Restauración de archivos archivados.

  4. Desactive la propiedad de la tabla delta.timeUntilArchived. Esto solo actualiza los metadatos, por lo que Databricks ya no rastrea el archivado en la tabla:

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

  5. Confirma que una lectura completa tiene éxito, por ejemplo SELECT COUNT(*) FROM <table_name>;. Después de eso, la replicación puede clonar la tabla.

Ten en cuenta que quitar la propiedad no restaura objetos. La restauración de objetos es una operación de proveedor de nube que debe hacerse manualmente utilizando mecanismos de proveedor de nube.

Para conocer los conceptos de recuperación ante desastres y los procedimientos recomendados, consulte Recuperación ante desastres.

  • Se actualizó por última vez el