Recuperação de desastres gerenciada

A recuperação de desastre gerenciada (DR) replica sua implantação do Databricks para uma região secundária para que você possa se recuperar de uma interrupção regional em minutos. A Databricks gerencia o pipeline de replicação, o estado dos catálogos replicados no secundário e o processo de failover. Você não escreve ou mantém scripts de replicação.

Para a abordagem manual de recuperação de desastres, incluindo conceitos gerais de DR e melhores práticas, consulte Recuperação de desastres.

importante

DR gerenciada é condicionada. Solicite acesso por meio de sua equipe de conta da Databricks. Databricks habilita DR gerenciada em sua account após a aceitação.

O que é recuperação de desastres gerenciada?

O DR gerenciado está acima dos workspaces e metastores que você já opera. Você traz dois workspaces do Databricks, um em sua região primária e outro em sua região secundária, e um metastore em cada região. DR Gerenciada então:

• Replica as categorias selecionadas do primário para o secundário em uma programação contínua. Ambas as categorias são independentemente opcionais: metadados do Unity Catalog e dados de tabela gerenciados, e ativos de workspace como notebooks, jobs, SQL warehouses, clusters e ACLs.
• Fornece um URL estável opcional, uma única string de conexão que sempre aponta para o primário atual, para que os clientes continuem funcionando após o failover sem reconfiguração.
• Permite acionar o failover quando desejado, para um teste de recuperação de desastres ou uma interrupção real.

Os IDs de ativos do workspace são preservados entre regiões, portanto, as URLs que referenciam um ativo do workspace por ID ainda são resolvidas após o failover.

O que é replicado

O DR Gerenciado pode replicar o seguinte a cada ciclo de replicação. Ambas as categorias são opcionais, de modo que se pode ativar uma ou ambas:

• Metadados e dados do Unity Catalog : tabelas gerenciadas do Unity Catalog no Delta Lake com dados, tabelas e volumes externos (somente metadados), views, funções e todas as concessões de permissão. O modo de isolamento do catálogo é replicado. Se o catálogo de origem estiver aberto, a réplica estará aberta. Se a origem for isolada e vinculada ao workspace principal, a réplica será isolada e vinculada ao workspace secundário.
• Ativos do workspace : Cadernos, jobs, SQL warehouses, clusters, painéis AI/BI de rascunho, arquivos e pastas, e suas ACLs. SQL warehouses são replicados em estado STOPPED, clusters em estado TERMINATED. Agendamentos de Jobs no secundário estão em pausa.

Propriedade de objetos replicados

Quando o DR gerenciado cria um objeto protegível replicado (catálogo, esquema, tabela, view, função ou volume) no secundário, o proprietário inicial é a entidade de serviço do Databricks que executa a replicação, pois o Unity Catalog atribui a propriedade à identidade que cria o objeto. O DR gerenciado então transfere a propriedade da réplica para corresponder ao proprietário do objeto protegível correspondente no primário.

Se o proprietário de um ativo protegível no primário for um usuário que foi excluído da account, o DR gerenciado não poderá transferir a propriedade para uma entidade que não existe mais. Nesse caso, o ativo protegível de réplica mantém a entidade de serviço do Databricks como seu proprietário. Para resolver isso, atribua um proprietário válido ao ativo protegível no primário e permita que o DR o replique.

Requisitos

• Um Workspace no plano Enterprise nas regiões primária e secundária.

• O add-on Mission Critical do workspace está ativado em ambos os workspaces. Consulte Ativar Mission Critical em ambos os workspaces.

• Compute serverless habilitado em ambos os workspaces. Compute serverless está disponível por default na maioria dos workspaces habilitados para o Unity Catalog. Consulte Conectar-se ao compute serverless.

• Função de administrador account com **TODOS OS PRIVILÉGIOS** em cada local externo usado pelos catálogos que você planeja replicar.

• SSO no nível da account com **todas as workspaces** ativadas, e identidades sincronizadas com a account através do SCIM para que usuários, grupos e entidades de serviço existam em ambas as regiões.

• Para URLs estáveis: uma URL personalizada provisionamento para seu domínio Databricks (entre em contato com sua equipe de account) e OAuth em nível de account.

• Um workspace secundário e metastore do Unity Catalog na região secundária, na mesma account Databricks e na mesma cloud que o seu principal. O workspace secundário deve corresponder à rede do workspace primário, ao Private Link e à configuração de key gerenciada pelo cliente. O metastore secundário não deve conter catálogos que compartilham nomes com catálogos replicados. Para a replicação de ativos do workspace, a Databricks exclui quaisquer ativos existentes no escopo no workspace secundário após a conclusão da replicação inicial. Ativos fora do escopo não são afetados, portanto, o workspace secundário não precisa estar vazio.

• Uma localização externa correspondente e uma credencial de armazenamento na região secundária para cada uma referenciada por seus catálogos primários Managed DR não replica locais externos ou credenciais de armazenamento automaticamente; eles devem ser criados no secundário.

Como o compute serverless do workspace secundário lê do armazenamento de origem durante a replicação entre regiões, tanto o armazenamento de origem quanto o secundário devem permitir o acesso à rede serverless do Databricks em ambas as direções.

Se você restringir o acesso à rede do seu armazenamento de origem ou DBFS root, também permita os endereços IP do plano de controle da região secundária no firewall do armazenamento de origem e os endereços IP do plano de controle da região primária no firewall DBFS secundário. Para os endereços IP do plano de controle a serem permitidos em cada região, consulte IPs de entrada.

• Todos os privilégios em todos os locais externos referenciados pelos seus catálogos replicados, concedidos aos IAM roles utilizados pelo workspace secundário.

Ativar Missão crítica em ambos os workspaces

Ative o complemento Mission Critical em ambos os seus workspaces primário e secundário antes de criar um grupo de failover. O uso de compute em cada workspace onde você habilita o complemento é cobrado na taxa Mission Critical. Entre em contato com sua equipe de conta Databricks para a taxa atual.

1. No console da account, clique em Workspaces e clique no workspace.
2. Clique na **tab** Add-ons.
3. No cartão **Missão crítica**, ative o botão e confirme.

Repita para o workspace secundário.

Opcional: URL estável

A Databricks recomenda usar a URL estável. A URL estável sempre se resolve para o workspace primário atual, então os clientes que se conectam por ela não precisam ser reconfigurados após um failover. A URL original do workspace permanece válida para acesso direto a esse workspace, mas após um failover ela continua apontando para o primário antigo, agora o secundário. Aponte os seguintes clientes downstream para a URL estável em vez da URL original do workspace:

• A interface do usuário da Web do Databricks.
• Conexões JDBC e ODBC para SQL warehouses.
• Solicitações diretas da API REST.

URLs estáveis são compatíveis com Private Link de front-end (entrada). Com o Private Link de entrada, a URL estável usa sua URL personalizada com um ID de conexão estável em vez do formato padrão de URL de workspace.

Por exemplo, a URL estável assume o formato <my-custom-url>.databricks.com/?c=stable_connection_id. Consulte Configurar o Private Link de entrada para workspaces com recuperação de desastres gerenciada.

Configurar replicação

Um novo grupo de failover transiciona por CREATING → INITIAL_REPLICATION → ACTIVE. O primeiro ciclo de replicação copia todos os dados no escopo para o secundário. Para workspaces grandes, o bootstrap inicial de ativos do workspace pode levar até duas semanas. Esta espera é única. Após a conclusão da inicialização inicial, a replicação prossegue continuamente.

Durante a replicação, os catálogos secundários no escopo são somente leitura e o compute está indisponível no workspace secundário. Para executar consultas de validação sem gravar no secundário, a Databricks recomenda um workspace de monitoramento somente leitura separado na região secundária.

Para criar um grupo de failover:

1. No console da account, clique em **Resiliência**.

2. Se planeja usar um URL estável, clique na tab URLs estáveis e, em seguida, em Criar URL estável . Digite um nome, selecione o workspace primário atual e crie a URL estável. Direcione clientes downstream (JDBC, ODBC, a interface do usuário da web do Databricks, solicitações diretas de API) para a URL estável em vez da URL original do workspace.

3. Clique na guia Grupos de failover e, em seguida, clique em Criar grupo de failover .

4. Preencha o formulário:

   • Nome do grupo de failover: Um nome a ser escolhido para o grupo de failover.
   • Workspace principal : o seu workspace principal.
   • Workspace secundário : O workspace na região secundária.
   • Replicar ativos do workspace (opcional): Desativado por default. Ativar para replicar cadernos, jobs, SQL warehouses, clusters, dashboards, arquivos e pastas (e suas ACLs) do primário para o secundário. Requer que ambos os workspaces tenham o complemento Missão Crítica ativado. Caso a replicação de ativos do workspace seja ativada, a Databricks exclui quaisquer ativos existentes no escopo no local secundário quando a replicação inicial for concluída. Ativos fora do escopo não são afetados.
   • URL estável (opcional): o URL estável que você criou no passo 2.
   • Escopo da replicação : os catálogos a serem replicados. É preciso selecionar um workspace principal antes que este campo esteja disponível.
   • Mapeamentos de armazenamento: Para cada local externo que seus catálogos replicados usam na região primária, adicione uma entrada que mapeie seu caminho de armazenamento para o local externo correspondente que você criou na região secundária (consulte Requisitos). Você pode usar * como curinga para correspondência de prefixos.

5. Clique em **Criar grupo de failover**.

Por exemplo, um mapeamento de armazenamento da AWS pode mapear s3://primary-bucket/data/* para s3://secondary-bucket/data/*.

Recursos criados por DR gerenciado

Quando um grupo de failover é criado, o DR gerenciado provisiona recursos auxiliares do Unity Catalog que o pipeline de replicação usa para copiar dados entre regiões. Em ambos os metastores primário e secundário, o DR gerenciado cria:

• Uma conexão que aponta para o workspace na outra região.
• Um catálogo externo para cada catálogo replicado. O catálogo externo referencia o catálogo correspondente na outra região.

Esses recursos aparecem junto com seus próprios catálogos no Catalog Explorer. É possível identificá-los pelo comentário, que observa que a recuperação de desastres do Databricks os criou e os gerencia.

importante

Por default, somente um administrador de metastore pode modificar ou excluir esses recursos. Não exclua as conexões ou os catálogos externos que o DR gerenciado cria. A exclusão de um deles interrompe a replicação para o grupo de failover.

ID de workspace estável

Algumas ferramentas identificam um workspace pelo seu ID de workspace em vez de sua URL, incluindo o provedor Databricks Terraform e os Pacotes de Ativos Databricks. Cada URL estável tem um ID de workspace estável que se resolve para o primário atual, para que essas ferramentas continuem visando o workspace ativo após um failover. Use o ID de workspace estável sempre que uma ferramenta solicitar um ID de workspace, da mesma forma que você usaria um ID de workspace regular.

Para encontrar o ID de workspace estável, liste as URLs estáveis para sua account com a CLI do Databricks e leia o campo stable_workspace_id da URL estável relevante:

Bash

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

Implante com Databricks Asset Bundles e Terraform

Databricks Asset Bundles (DABs) e o provedor Databricks Terraform visam um workspace seja por sua URL de host de workspace, ou por uma combinação da URL personalizada da account Databricks e o ID de workspace. Para continuar implantando no primário atual após um failover, defina o host para sua URL personalizada — a parte do host da URL estável, não a URL original por workspace — e especifique o ID de workspace estável no campo workspace_id. Juntos, eles se resolvem para o primário atual, para que seus pipelines de CI/CD continuem implantando no workspace ativo após um failover, sem alteração de configuração.

• Novas implantações : use a URL personalizada e o ID de workspace estável da primeira implantação.
• Implantações existentes : importe o estado do seu projeto Terraform anterior para um novo projeto configurado com a URL personalizada e o ID de workspace estável, então remova o projeto anterior. Não repontue um projeto existente no local — a implantação não reconhece mais os recursos que criou em relação à URL original por workspace, então uma reimplementação os destrói e recria.
• DABs : habilite a replicação de ativos de workspace no grupo de failover. Um bundle armazena seu estado de implantação no workspace, e esse estado atinge o novo primário apenas como parte da replicação de ativos de workspace.

nota

Após um failover, a primeira reimplementação recria quaisquer recursos que o DR gerenciado não replica, porque eles não existem no novo primário. Recursos replicados são deixados no local. Consulte Limitações para o que o DR gerenciado replica e não replica.

Monitorar replicação

A **tab** **Grupos de Failover** exibe o estado atual, o ponto de replicação e quaisquer erros ativos de cada grupo de failover. Estados possíveis:

Status	Significado
CREATING	O grupo de failover está sendo provisionado.
INITIAL_REPLICATION	O primeiro ciclo de replicação está em andamento. Failover ainda não está disponível.
ACTIVE	A replicação está em estado estável. O failover está disponível.
FAILING_OVER	Um failover está em andamento.
FAILOVER_FAILED, CREATION_FAILED, DELETION_FAILED	A operação não foi concluída. Consulte os detalhes do estado do grupo de failover para obter orientação.

Status	Significado
CREATING	O grupo de failover está sendo provisionado.
INITIAL_REPLICATION	O primeiro ciclo de replicação está em andamento. Failover ainda não está disponível.
ACTIVE	A replicação está em estado estável. O failover está disponível.
FAILING_OVER	Um failover está em andamento.
FAILOVER_FAILED, CREATION_FAILED, DELETION_FAILED	A operação não foi concluída. Consulte os detalhes do estado do grupo de failover para obter orientação.

Selecione o nome de um grupo de failover para abrir sua página de detalhes. A replicação é executada continuamente, mas o ponto de replicação mostra a última vez que todos os recursos dentro do escopo foram copiados juntos. Recursos individuais podem estar mais atualizados, mas nem todos os dados após o ponto de replicação podem existir no secundário e podem ser perdidos durante o failover.

Para monitorar as tendências históricas de RPO e ver os erros que estão impedindo a replicação, consulte a tabela do sistema system.replication.states. Consulte Referência da tabela do sistema de replicação. Para as classes de erro mais comuns e como resolvê-las, consulte Referência.

Realizar failover e failback

O mesmo procedimento cobre failovers planejados (testes de recuperação de desastres, manutenção programada) e failovers não planejados (uma interrupção regional). Para fazer o failback, repita o procedimento com as regiões invertidas.

Ao acionar um failover, o Databricks:

• Aponta o URL estável, se anexado, para a nova região primária.
• Inverte a direção da replicação.
• Pausa as agendas de Jobs no primário anterior.
• Realiza a transição do grupo de failover por FAILING_OVER para INITIAL_REPLICATION.

Para realizar failover:

1. Notifique a equipe de que um failover está sendo iniciado.

2. Para um failover planejado somente:

   1. No workspace principal, encerre todos os clusters em execução e interrompa todos os SQL warehouses.
   2. Certifique-se de que as gravações no primário tenham parado, e depois aguarde a replicação se atualize. Para verificar, abra a página de detalhes do grupo de failover e confirme se o ponto de replicação esteja a poucos segundos do momento em que as gravações foram interrompidas.

3. No console da conta, clique em Resilience → Grupos de failover , em seguida, clique no nome do grupo de failover.

4. Clique em **Failover**.

5. Selecione a nova região primária e confirme. O failover é concluído em minutos.

6. No novo primário, inicie o compute que estava em execução antes do failover. Clusters replicados e SQL warehouses chegam no novo primário nos estados TERMINATED e STOPPED, respectivamente.

7. Retomar manualmente as programações de Job necessárias no novo primário. As programações do primário anterior já foram colocadas em pausa.

Clientes conectados através do URL estável continuam funcionando após o failover. Redirecione os clientes que ainda usam a URL original do workspace para a URL estável ou para a URL do novo workspace principal.

importante

Em uma falha não planejada, os dados gravados no primário após o último ponto de replicação poderão ser perdidos. Confirme se qualquer perda está dentro da sua meta de RPO.

dica

Teste o failover regularmente, como uma vez por trimestre, para que sua equipe esteja familiarizada com o procedimento antes de uma interrupção real.

Desativar DR gerenciado

1. No console da conta, clique em Resiliência → Grupos de failover , depois clique no nome do grupo de failover e exclua-o. Não é possível desativar o Mission Critical enquanto um grupo de failover estiver ativo no workspace.
2. Para interromper a cobrança na tarifa de Missão Crítica, desative a Missão Crítica em cada workspace na tab Add-ons .

Limitações

O DR Gerenciado tem as seguintes limitações:

• Não replicados: views materializadas, tabelas de streaming, Lakeflow pipelines, dados de volume gerenciados (os metadados replicam), segredos do Unity Catalog e do Workspace, modelos de ML, Endpoints de servindo modelo, índices de pesquisa vetorial, Delta shares, painéis de AI/BI publicados (os rascunhos replicam) e Spark Structured Streaming fora dos Lakeflow pipelines. Tabelas com filtros de linha ou máscaras de coluna e recursos com tags ABAC são sinalizadas como **Falha na replicação** na tabela do sistema, e essas falhas atrasam o RPO até que você remova o recurso do escopo do grupo de failover.
• Catálogos secundários no escopo são somente para leitura. Somente leitura aplica-se somente a entidades replicadas. Você ainda pode configurar sua própria replicação para itens protegíveis fora do escopo de DR gerenciado. No entanto, não é possível executar o compute no workspace secundário enquanto o DR gerenciado estiver habilitado, o que limita a operação de um pipeline de replicação faça você mesmo nele.
• A renomeação de um objeto protegível do Unity Catalog aciona uma exclusão e recriação no secundário. Para tabelas gerenciadas, a renomeação replica novamente os dados da tabela no próximo ciclo. Evite renomear durante a replicação em estado estável.
• UNDROP não é propagado para o secundário.
• Máximo 300 catálogos por account.
• Máximo de 100 grupos de failover por account.
• A inicialização de ativos do workspace pode levar até 2 semanas para workspaces grandes.

Referência

Quando um recurso não pode ser replicado, o grupo de failover exibe uma classe de erro na tabela do sistema system.replication.states, juntamente com uma mensagem que identifica o recurso afetado. As seções a seguir abordam as classes de erro mais comuns e como resolvê-las. A replicação se recupera automaticamente depois que você corrige o problema subjacente.

DR_MISSING_DEPENDENCY

Um ativo referencia uma dependência que não existe no secundário, portanto, o ativo não pode ser replicado. A subclasse identifica o tipo de dependência ausente e aparece como DR_MISSING_DEPENDENCY.CATALOG, .SCHEMA, .TABLE ou .RESOURCE. A resolução é a mesma para todos eles.

1. Verifique se o ativo também está quebrado no primário devido à dependência ausente. Se estiver, corrija ou remova o ativo no primário.
2. Se o ativo for válido no primário, a dependência não está no escopo de replicação de nenhum grupo de failover, ou está no escopo deste ou de outro grupo de failover, mas falhou ao replicar. Se a dependência não estiver no escopo, edite o escopo de replicação do grupo de failover para replicá-la também. Se a dependência já estiver no escopo, verifique system.replication.states para o erro que está bloqueando sua replicação e resolva esse erro.

DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

DR gerenciado decide onde colocar cada ativo replicado, aplicando os mapeamentos de armazenamento do grupo de failover ao local de armazenamento de origem do ativo. Um mapeamento corresponde a um local exatamente, ou como um prefixo que também cobre caminhos filho. Este erro significa que nenhum mapeamento cobre um local de armazenamento de origem, portanto, o DR gerenciado não pode determinar onde colocar o ativo no secundário. Para tabelas e volumes externos, um mapeamento ausente significa que o mesmo URI de localização é usado no primário e no secundário. O storage_location na mensagem é o caminho de origem não mapeado.

1. No account console, vá para Resiliência → Grupos de failover e edite o grupo de failover.
2. Em Mapeamentos de armazenamento , adicione ou amplie um mapeamento para que ele cubra o local de origem na mensagem. Para abranger caminhos filhos, mapeie um caminho pai e adicione o sufixo /* para correspondência de prefixo. Consulte mapeamentos de armazenamento.
3. Confirme se um local externo no metastore secundário já abrange o caminho de destino do mapeamento. O grupo de failover rejeita um mapeamento cujo destino não está sob um local externo existente, então crie esse local externo primeiro se ele não existir. Consulte Conectar-se ao armazenamento de objetos na nuvem usando o Unity Catalog.

DR_INVALID_CONFIGURATION.MISSING_EXTERNAL_LOCATION

Um mapeamento de armazenamento resolveu um ativo replicado para um caminho de destino no secundário, mas nenhuma localização externa no metastore secundário cobre esse caminho, então o Unity Catalog não tem onde colocar os dados do ativo. O storage_location na mensagem é o caminho secundário (de destino) não coberto.

Isso geralmente significa uma de duas coisas: uma localização externa que cobria o caminho anteriormente foi removida ou restringida, ou um ativo recém-replicado se resolve para um caminho secundário que nenhuma localização externa abrange. O segundo caso ocorre, por exemplo, quando você cria uma tabela externa no primário sob um caminho de armazenamento que nenhum dos seus mapeamentos de armazenamento abrange. O DR gerenciado então retorna ao caminho original da tabela, que nenhuma localização externa no metastore secundário abrange, portanto, os dados não têm onde serem armazenados.

1. Identifique o caminho secundário não coberto a partir do storage_location da mensagem.
2. Decida qual local externo no metastore secundário deve cobrir esse caminho: um local externo existente que você estende ou um novo que você cria.
3. Ajuste os mapeamentos de armazenamento do grupo de failover para que o caminho seja resolvido em uma localização externa já existente, ou crie a localização externa (com sua credencial de armazenamento) e estenda o mapeamento para apontar para ela. Consulte Conectar ao armazenamento de objetos em cloud usando o Unity Catalog.

DR_INTERNAL_ERROR

Ocorreu uma falha no sistema durante a replicação. Nenhuma ação é necessária; o sistema se recupera automaticamente. Entre em contato com o suporte da Databricks se o problema não se resolver sozinho.

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

O DR gerenciado replica a view junto com suas concessões, mas uma view que faz referência a objetos em outros catálogos também precisa que seu proprietário tenha acesso a esses objetos referenciados no secundário, porque a view é executada com os privilégios do proprietário. Esse erro significa que o proprietário não tem esse acesso no secundário, então você deve concedê-lo nos objetos referenciados lá.

1. Encontre os objetos que a view referencia e o proprietário da view. Objetos referenciados aparecem como nomes catalog.schema.object totalmente qualificados na definição; as concessões devem ir para o proprietário, que você também pode ler no campo Proprietário no Catalog Explorer.

   SQL

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

2. No secundário, verifique os privilégios atuais do proprietário em cada objeto referenciado. A leitura de uma tabela requer USE CATALOG em seu catálogo, USE SCHEMA em seu esquema e SELECT na tabela.

   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. Conceder ao proprietário da view quaisquer privilégios ausentes em cada objeto referenciado.

   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. Confirme que cada catálogo que a view referencia está incluído no escopo de replicação de um grupo de failover, para que também exista no secundário.

Para obter mais informações, consulte Gerenciar privilégios no Unity Catalog.

DR_INVALID_CONFIGURATION.NETWORK_UNAUTHORIZED_ACCESS

Durante a replicação de dados de tabela entre regiões, o compute serverless do workspace secundário lê dados do armazenamento de origem, e o armazenamento negou a conexão de rede: um firewall de armazenamento ou regra de rede a bloqueou, ou um endpoint privado necessário está ausente ou não aprovado.

Verifique se o seu armazenamento de origem e secundário permitem acesso à rede serverless do Databricks, conforme descrito em Requisitos.

DR_INVALID_CONFIGURATION.SERVERLESS_COMPUTE_PERMISSION

O DR gerenciado usa compute serverless no workspace secundário para copiar dados, e o compute serverless não é permitido lá. Isso geralmente significa que o serverless está desativado para a account ou workspace, ou que o workspace não é elegível.

1. Confirme se o workspace secundário é elegível. O compute serverless está disponível por default em workspaces habilitados para Unity Catalog em uma região compatível. Consulte Conectar-se ao compute serverless.
2. Verifique se há um cancelamento de assinatura em toda a account. No account console, vá para Configurações → Ativação de recurso e verifique se o alternador serverless está presente e desativado.
3. Ative o serverless para o escopo que você precisa. Para habilitar todos os workspaces elegíveis, um admin da account ativa a alternância serverless no nível da account. Para habilitar apenas o workspace secundário, deixe a alternância no nível da account desativada e faça com que um admin do workspace ative o serverless nas **Pré-visualizações** do workspace.
4. Se nenhum alternador estiver disponível, ou se o serverless ainda não funcionar depois de ativá-lo, entre em contato com sua equipe de conta do Databricks.

DR_INVALID_CONFIGURATION.OVERLAPPING_EXTERNAL_LOCATIONS

Quando o DR gerenciado cria um objeto replicado em seu caminho de destino mapeado no secundário, o Unity Catalog rejeita o caminho porque ele se sobrepõe a um armazenamento que já existe lá, como uma localização externa existente, um recurso protegível restante de uma configuração anterior ou parcial, uma localização gerenciada ou o armazenamento default (DBFS) do workspace.

1. Identifique o que ocupa o caminho.

   Consulte Resolver conflitos de caminho de armazenamento.

2. Se o objeto conflitante não deve possuir o caminho, remova-o. Uma causa comum é uma tabela externa ou volume externo remanescente de uma configuração anterior; exclua-o se não for mais necessário. Se for um local externo que não deve cobrir o caminho, remova-o ou redefina-o.

3. Caso contrário, redirecione o mapeamento de armazenamento do grupo de failover para um caminho de destino dedicado e não sobreposto. Prefira um subcaminho específico em vez de uma raiz de bucket ampla e evite o armazenamento default (DBFS) do workspace.

DR_UNSUPPORTED_FEATURE

O ativo usa um recurso que o DR gerenciado não pode replicar. A subclasse identifica o recurso não suportado e aparece, por exemplo, como DR_UNSUPPORTED_FEATURE.ABAC_POLICY. Há duas maneiras de resolver esse erro.

1. Remova o recurso não suportado do ativo no workspace primário.
2. Se você não conseguir remover o recurso, considere remover o ativo do escopo de replicação do grupo de failover.

Para conceitos e melhores práticas de DR, consulte Recuperação de desastres.