Recuperação gerida de desastres

A recuperação de desastres gerida (DR) replica a sua implementação do Azure Databricks para uma região secundária para que possa recuperar de uma falha regional em minutos. O Azure Databricks gere o pipeline de replicação, o estado dos catálogos replicados no secundário e o processo de failover. Não escreve nem mantém scripts de replicação.

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

Important

O DR gerido é de acesso restrito. Candidate-se ao acesso através da sua equipa de contas Azure Databricks. O Azure Databricks ativa o DR gerido na sua conta depois de ser aceite.

O que é a recuperação gerida em caso de desastres?

A DR gerida está por cima dos espaços de trabalho e metastores que já operas. Trazes dois espaços de trabalho do Azure Databricks, um na tua região principal e outro na tua região secundária, e uma metastore em cada região. DR gerido anteriormente:

  • Replica as categorias em que optas desde a primária até à secundária, num calendário contínuo. Ambas as categorias são opcionais de forma independente: metadados do Catálogo Unity e dados de tabelas geridas, e ativos de espaço de trabalho como cadernos, jobs, armazéns SQL, clusters e ACLs.
  • Fornece um URL estável opcional, uma única cadeia de ligação que aponta sempre para o primário atual, para que os clientes continuem a funcionar após o failover sem reconfiguração.
  • Permite-te ativar o failover quando quiseres, para um teste de DR ou uma falha real.

Os IDs dos recursos do espaço de trabalho são preservados entre regiões, pelo que os URLs que fazem referência a um recurso do espaço de trabalho pelo ID continuam a ser resolvidos após a comutação pós-falha.

O que é replicado

A DR gerida pode replicar o seguinte em cada ciclo de replicação. Ambas as categorias são opcionais, por isso pode ativar uma ou ambas: os metadados e dados do Catálogo Unity, bem como os ativos do espaço de trabalho.

Metadados e dados do Catálogo Unity

Object Notas
Tabelas geridas no Unity Catalog em Delta Lake Dados e metadados. Consulte Limitações.
Tabelas externas Só metadados. Consulte Limitações.
Volumes externos Apenas metadados.
Views
Funções
Permissões concedidas

O modo de isolamento do catálogo também é reproduzido. Se o catálogo fonte estiver aberto, a sua réplica está aberta. Se o catálogo de origem for isolado e associado ao workspace primário, a réplica é isolada e associada ao workspace secundário.

Recursos do espaço de trabalho

Os ativos do espaço de trabalho são replicados juntamente com as suas ACLs.

Object Notas
Notebooks
Jobs Os agendamentos de tarefas no sistema secundário estão suspensos.
Armazéns SQL Replicado no estado STOPPED.
Clusters Replicado no estado TERMINATED. Inclui também políticas de computação, perfis de instância e scripts globais de init.
Rascunho de painéis de IA/BI
Ficheiros
Pastas de Arquivos Não inclui pastas Git.
Queries Inclui consultas criadas e guardadas no editor SQL.
Libraries

Propriedade de objetos replicados

Quando a DR gerida cria um objeto protegível replicado (catálogo, esquema, tabela, vista, função ou volume) no ambiente secundário, o proprietário inicial é o principal de serviço do Azure Databricks que executa a replicação, porque o Unity Catalog atribui a propriedade à identidade que cria o objeto. O DR Gerido transfere então a propriedade da réplica para que corresponda à do securável correspondente na base de dados primária.

Se o titular de um seguro garantido no principal for um utilizador que foi eliminado da conta, a DR gerida não pode transferir a propriedade para um principal que já não existe. Neste caso, a réplica securável mantém o principal de serviço do Azure Databricks como seu proprietário. Para resolver isto, atribua um proprietário válido ao objeto protegível na instância primária e deixe que a DR o replique.

Requirements

Para configurar uma DR gerida, deve ter o seguinte:

  • Um espaço de trabalho no plano Premium tanto nas regiões primária como secundária.
  • A extensão Mission Critical ativada em ambos os espaços de trabalho. Veja Ativar Missão Crítica em ambos os espaços de trabalho.
  • Computação serverless ativada em ambos os espaços de trabalho. O processamento sem servidor está disponível por predefinição na maioria dos espaços de trabalho com o Unity Catalog ativado. Consulte como se conectar à computação sem servidor.
  • Função de administrador da conta com TODOS OS PRIVILÉGIOS sobre cada localização externa utilizada pelos catálogos que planeia replicar.

Pré-requisitos de configuração

Para usar DR gerido, certifique-se de que as seguintes definições e recursos estão configurados.

Categoria Detalhes
Espaço de trabalho secundário e metaarmazenamento
  • Um espaço de trabalho secundário e uma metastore do Unity Catalog na região secundária, na mesma conta do Azure Databricks e na mesma nuvem que o principal.
  • Note as seguintes ressalvas ao configurar o seu secundário:
    • O metastore secundário não deve conter catálogos que tenham nomes em comum com catálogos replicados.
    • Para a replicação de ativos de espaço de trabalho, o Azure Databricks elimina quaisquer ativos existentes dentro do âmbito no espaço secundário quando a replicação inicial termina. Os ativos fora do âmbito não são afetados, pelo que o espaço de trabalho secundário não precisa de estar vazio.
Identidade
  • SSO ao nível da conta com todos os espaços de trabalho ativados e identidades sincronizadas com a conta através do AIM ou SCIM, para que utilizadores, grupos e principais de serviço existam em ambas as regiões.
  • Para URLs estáveis: um URL personalizado provisionado para o seu domínio Azure Databricks (contacte a sua equipa de conta) e um OAuth ao nível da conta.
Armazenamento e acesso a dados
  • Um Azure Databricks Access Connector na região secundária com a função Storage Blob Data Contributor nas contas de armazenamento secundárias, adicionado como credencial de armazenamento no espaço de trabalho secundário.
  • Uma localização externa correspondente e uma credencial de armazenamento na região secundária por cada um dos elementos referenciados pelos seus catálogos primários. O DR gerido não replica automaticamente localizações externas ou credenciais de armazenamento. Tens de os criar no secundário.
Networking
  • Assegure que os seguintes objetos ao nível da conta estão associados tanto ao seu espaço de trabalho primário como secundário: Configuração de Conectividade de Rede (NCC), Política de Rede (saída sem servidor), Definições de acesso privado (PAS) e lista de acesso IP.
  • Tanto o armazenamento de origem como o armazenamento secundário devem permitir o acesso à rede serverless do Azure Databricks em ambas as direções.
  • Uma Configuração de Conectividade de Rede (NCC) na região secundária, atribuída ao espaço de trabalho secundário, para que a computação sem servidor possa aceder ao armazenamento através de pontos de extremidade privados. Consulte Configurar conectividade privada para recursos do Azure.
  • Se usar conectividade privada às contas de armazenamento que guardam os seus dados de origem ou replicados, tanto os espaços de trabalho primários como secundários precisam de endpoints privados para ambas as contas de armazenamento primária e secundária. Crie endpoints privados para os sub-recursos dfs e blob de cada conta. Aprove-os no portal do Azure.
Custo e governação
  • Associe a política de utilização sem servidor ao nível da conta (anteriormente, política orçamental sem servidor) aos espaços de trabalho principal e secundário.

Ativar o Mission Critical em ambos os espaços de trabalho

Ative o add-on Mission Critical tanto nos seus espaços de trabalho primários como secundários antes de criar um grupo de failover. A utilização de computação em cada espaço de trabalho onde ativar o suplemento é faturada à tarifa Mission Critical. Contacte a sua equipa de conta Azure Databricks para saber a taxa atual.

  1. No console da conta, clique em Espaços de Trabalho e depois clique no espaço de trabalho.
  2. Clique no separador de Complementos.
  3. Na carta de Missão Crítica , ativa a opção de alternar e confirma.

Repita para o espaço de trabalho secundário.

Opcional: URL estável

O Azure Databricks recomenda usar a URL estável. O URL estável aponta sempre para o espaço de trabalho primário atual, pelo que os clientes que se ligam através desta não precisam de ser reconfigurados após um failover. O URL original do espaço de trabalho mantém-se válido para acesso direto a esse espaço de trabalho, mas após uma comutação por falha continua a apontar para o antigo primário, agora secundário. Aponte os seguintes clientes dependentes para o URL estável em vez do URL original da área de trabalho:

  • A interface web do Azure Databricks.
  • Ligações JDBC e ODBC a armazéns de dados SQL.
  • Pedidos diretos à API REST.

URLs estáveis são suportados com o front-end (inbound) Private Link. Com o Private Link de entrada, o URL estável utiliza o seu URL personalizado com um identificador de ligação estável, em vez do formato de URL padrão da área de trabalho.

Por exemplo, a URL estável assume a forma <my-custom-url>.azuredatabricks.net/?w=stable_connection_id. Veja Configure inbound Private Link para espaços de trabalho com recuperação de desastres gerida.

Ligue os clientes à URL estável

Os clientes ligam-se através da URL estável da mesma forma que se ligam a uma URL de espaço de trabalho, com duas diferenças: utilizam o host da URL estável em vez da URL original do espaço de trabalho, e identificam o espaço de trabalho com o ID de ligação estável no parâmetro de consulta w. Autenticar com o OAuth ao nível da conta.

Ligações JDBC e ODBC a armazéns de dados SQL

Defina o nome de anfitrião do servidor para o anfitrião do URL estável, depois adicione ?w=stable_connection_id ao caminho HTTP do armazém:

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

Obtenha o ID do armazém a partir do caminho HTTP no separador Detalhes de Ligação do armazém (veja Obter detalhes de ligação para um recurso de computação do Azure Databricks). Utilize a mesma porta e definições do controlador que utilizaria com o URL original do espaço de trabalho.

Requisições diretas à API REST

Envie pedidos para o host da URL estável e adicione o w=stable_connection_id parâmetro de consulta ao pedido. Por exemplo, para listar clusters:

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

Configurar replicação

Um novo grupo de failover transita por CREATING → INITIAL_REPLICATION → ACTIVE. O primeiro ciclo de replicação copia todos os dados abrangidos para o sistema secundário. Para espaços de trabalho grandes, o bootstrap inicial do asset do espaço de trabalho pode demorar até cinco dias. Esta espera ocorre apenas uma vez. Após a conclusão do bootstrap inicial, a replicação corre de forma contínua.

Durante a replicação, os catálogos secundários dentro do âmbito são apenas de leitura e a computação não está disponível no espaço de trabalho secundário. Para executar consultas de validação sem escrever na instância secundária, o Azure Databricks recomenda um espaço de trabalho de monitorização só de leitura separado na região secundária.

Para criar um grupo de failover:

  1. Na consola da conta, clique em Resiliência.
  2. Se tenciona usar um URL estável, clique no separador URLs estáveis e, em seguida, em Criar URL estável. Insira um nome, selecione o espaço de trabalho principal atual e crie a URL estável. Aponte os clientes downstream (JDBC, ODBC, a interface web do Azure Databricks, pedidos diretos à API) para o URL estável em vez do URL original do espaço de trabalho.
  3. Clique no separador Grupos de failover , depois Criar grupo de failover.
  4. Preencha o formulário:
    • Nome do grupo de failover: O nome que escolhe para o grupo de failover.
    • Espaço de trabalho primário: O espaço de trabalho que é o seu espaço principal.
    • Espaço de trabalho secundário: O espaço de trabalho na região secundária.
    • Duplicar recursos do espaço de trabalho (opcional): Desativado por predefinição. Ative esta opção para replicar blocos de notas, tarefas, armazéns de SQL, clusters, painéis, ficheiros e pastas (e as respetivas ACLs) da principal para a secundária. Requer que ambos os espaços de trabalho tenham o add-on Mission Critical ativado. Se ativares a replicação de ativos de workspace, o Azure Databricks elimina quaisquer ativos existentes dentro do âmbito secundário quando a replicação inicial termina. Os ativos fora do âmbito não são afetados.
    • URL estável (opcional): O URL estável que criaste no passo 2.
    • Âmbito de replicação: Os catálogos a replicar. Deve selecionar um espaço de trabalho principal antes de este campo estar disponível.
    • Mapeamentos de armazenamento: Para cada localização externa que os seus catálogos replicados usam na região primária, adicione uma entrada que mapeie o seu caminho de armazenamento para a localização externa correspondente que criou na região secundária (ver Requisitos). Podes usar * como coringa para emparelhar prefixos.
  5. Clique em Criar grupo de failover.

Por exemplo, um mapeamento de armazenamento do Azure pode mapear abfss://data@primary.dfs.core.windows.net/* para abfss://data@secondary.dfs.core.windows.net/*.

Recursos criados pela DR gerida

Ao criar um grupo de failover, a DR gerida aprovisiona recursos auxiliares do Unity Catalog que o processo de replicação utiliza para copiar dados entre regiões. Quer nas metastores primárias quer nas secundárias, a DR gerida cria:

  • Uma conexão que aponta para o espaço de trabalho na outra região.
  • Um catálogo estrangeiro para cada catálogo replicado. O catálogo estrangeiro faz referência ao catálogo correspondente na outra região.

Estes recursos aparecem juntamente com os seus próprios catálogos no Explorador de Catálogos. Pode identificá-los pelo comentário, que refere que o Azure Databricks de recuperação de desastres os criou e gere.

Important

Por defeito, apenas um administrador da metastore pode modificar ou eliminar estes recursos. Não elimine as conexões nem os catálogos externos que o managed DR cria. Eliminar qualquer um deles quebra a replicação do grupo de failover.

ID de espaço de trabalho estável

Algumas ferramentas identificam um espaço de trabalho pelo seu ID de espaço de trabalho em vez do seu URL, incluindo o fornecedor Databricks Terraform e os Databricks Asset Bundles. Cada URL estável tem um ID estável do espaço de trabalho que aponta para o principal atual, pelo que estas ferramentas continuam a apontar para o espaço de trabalho ativo após um failover. Use o ID de espaço de trabalho estável sempre que uma ferramenta peça um ID de espaço de trabalho, da mesma forma que usaria um ID de espaço de trabalho normal.

Para encontrar o ID do workspace estável, liste os URL estáveis da sua conta com a CLI do Databricks e leia o campo stable_workspace_id do URL estável relevante:

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

Implementar com Databricks Asset Bundles e Terraform

Os Databricks Asset Bundles (DABs) e o fornecedor Databricks Terraform direcionam um espaço de trabalho quer pela URL do seu anfitrião do espaço de trabalho, quer por uma combinação do URL personalizado da conta Azure Databricks e do ID do espaço de trabalho. Para continuar a fazer implementações no primário atual após um failover, defina o host como o seu URL personalizado — a parte do host do URL estável, não o URL original de cada workspace — e especifique o ID do workspace estável no campo workspace_id. Juntos, resolvem para o principal atual, por isso os teus pipelines CI/CD continuam a ser implementados para o workspace ativo após um failover, sem qualquer alteração de configuração.

  • Novas implementações: use o URL personalizado e o ID estável do espaço de trabalho da primeira implementação.
  • Implementações existentes: importa o estado do teu projeto anterior do Terraform para um novo projeto configurado com o URL personalizado e o ID do espaço de trabalho estável, depois remove o projeto anterior. Não redirecione diretamente um projeto existente — a implantação já não reconhece os recursos que criou com base no URL original por espaço de trabalho, pelo que uma nova implantação os destrói e recria.
  • DABs: ative a replicação de ativos do espaço de trabalho no grupo de ativação pós-falha. Um pacote armazena o estado da sua implementação no espaço de trabalho, e esse estado só chega ao novo nó primário como parte da replicação dos recursos do espaço de trabalho.

Note

Após um failover, o primeiro redeploy recria quaisquer recursos que o DR gerido não replice, porque não existem no novo primário. Os recursos replicados são deixados no local. Veja Limitações para o que a DR gerida replica ou não.

Monitorizar a replicação

O separador Grupos de ativação pós-falha mostra o estado atual de cada grupo de ativação pós-falha, o ponto de replicação e quaisquer erros ativos. Estados possíveis:

State Meaning
CREATING O grupo de failover está a ser provisionado.
INITIAL_REPLICATION O primeiro ciclo de replicação está em andamento. O failover ainda não está disponível.
ACTIVE A replicação está em regime estacionário. O failover está disponível.
FAILING_OVER Está em curso um failover.
FAILOVER_FAILED, CREATION_FAILED, DELETION_FAILED A operação não foi concluída. Verifique os detalhes do estado do grupo de failover para obter orientação.

Selecione o nome de um grupo de failover para abrir a página de detalhes. A replicação é executada continuamente, mas o ponto de replicação indica a última vez em que todos os recursos abrangidos pelo âmbito foram copiados em conjunto. Os 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.

Quando um ponto de replicação é mostrado, tudo o que não está coberto por um erro foi replicado até esse ponto. Durante a replicação inicial, antes de existir o primeiro ponto de replicação, o grupo de failover ainda pode mostrar erros de bloqueio, mas ainda não mede a completude. Os tipos de ativos que a DR gerida não suporta de todo não aparecem na system.replication.states tabela do sistema. Consulte Limitações. Para verificar um ativo específico, inspecione-o no secundário (ver Configurar replicação).

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

Comutação por falha e retorno por falha

O mesmo procedimento abrange comutações planeadas (testes de recuperação após desastre, manutenção programada) e comutações não planeadas (uma falha regional). Para reverter, repita o procedimento com as regiões invertidas.

Quando desencadeias um failover, Azure Databricks:

  • Aponta a URL estável, se anexada, para a nova região primária.
  • Inverte a direção da replicação.
  • Pausa os horários de trabalho na antiga primária.
  • Transita o grupo de failover de FAILING_OVER para INITIAL_REPLICATION.

Para fazer fail-over:

  1. Avise a sua equipa de que está a iniciar um failover.

  2. Apenas para um failover planeado:

    1. Na área de trabalho principal, termine todos os clusters em execução e pare todos os armazéns de dados SQL.
    2. Confirme que as operações de escrita no primário foram interrompidas e, em seguida, aguarde que a replicação fique sincronizada. Para verificar, abra a página de detalhes do grupo de failover e confirme que o ponto de replicação está a poucos segundos da hora a que interrompeu as operações de escrita.

  3. Na consola da conta, clique em Resiliência → Grupos de failover e, em seguida, clique no nome do grupo de failover.

  4. Clique em Fail over.

  5. Selecione a nova região principal e confirme. O failover termina em minutos.

  6. No novo primário, inicia o cálculo que estava a correr antes do failover. Os clusters replicados e os armazéns de dados SQL chegam ao novo primário nos estados TERMINATED e STOPPED, respetivamente.

  7. Retoma manualmente os horários de trabalho de que precisas no novo primário. Os calendários das antigas primárias já estão suspensos.

Os clientes ligados através do URL estável continuam a funcionar após o failover. Redirecione os clientes que ainda utilizam o URL original da área de trabalho para o URL estável ou para o URL da nova área de trabalho principal.

Important

Num failover não planeado, os dados escritos no primário após o último ponto de replicação podem ser perdidos. Confirme que qualquer perda se enquadra no seu objetivo de RPO.

Tip

Teste o failover regularmente, por exemplo, uma vez por trimestre, para que a sua equipa esteja familiarizada com o procedimento antes de uma falha real.

Desmontar DR gerida

  1. Na consola da conta, clique em Resiliência → Grupos de ativação pós-falha e, em seguida, clique no nome do grupo de ativação pós-falha e elimine-o. Não pode desligar o Mission Critical enquanto um grupo de failover estiver ativo no workspace.
  2. Para parar a faturação à tarifa Mission Critical, desative o Mission Critical em cada espaço de trabalho no separador Add-ons.

Limitations

A DR gerida tem as seguintes limitações:

  • Não replicados: vistas materializadas, tabelas de streaming, pipelines Lakeflow, volumes geridos, segredos do Unity Catalog e workspace, modelos de ML, endpoints de serviço de modelos, índices de pesquisa vetorial, partilhas Delta, dashboards de IA/BI publicados (os rascunhos replicam) e Spark Structured Streaming fora dos pipelines Lakeflow. Tabelas com filtros de linha ou máscaras de colunas, recursos marcados com ABAC e tabelas com suporte de arquivamento Delta Lake (delta.timeUntilArchived) são sinalizadas como Falha na replicação na tabela do sistema, e estas falhas atrasam o cumprimento do RPO até que o recurso seja removido do âmbito do grupo de failover. A replicação de metadados não é suportada para tabelas externas não Delta Lake que utilizam metadados de partição.
  • As operações de escrita em tabelas geridas realizadas por motores externos têm capacidade de deteção limitada. O DR gerido deteta alterações nas tabelas geridas do Unity Catalog a partir de escritas feitas pelo Azure Databricks compute. As escritas efetuadas numa tabela gerida replicada por um motor externo (que não seja o Azure Databricks), através de APIs abertas, como o Iceberg REST Catalog, podem não ser detetadas, pelo que essas escritas podem não ser replicadas para o sistema secundário e podem perder-se durante o failover. Para tabelas que replicas com DR gerido, escreve através do Azure Databricks compute.
  • Os catálogos secundários dentro do âmbito são apenas de leitura. Apenas leitura aplica-se apenas a entidades replicadas. Ainda podes configurar a tua própria replicação para seguráveis fora do âmbito da DR gerida. No entanto, não é possível executar cargas de trabalho de computação no espaço de trabalho secundário enquanto a recuperação após desastre (DR) gerida estiver ativada, o que limita a possibilidade de operar nesse local um pipeline de replicação autogerido.
  • Mudar o nome de um objeto protegível do Unity Catalog aciona uma eliminação e uma recriação no secundário. Para tabelas geridas, a renomeação re-replica os dados da tabela no ciclo seguinte. Evite mudar de nome durante a replicação em regime estacionário.
  • UNDROP não é propagado para o secundário.
  • O bootstrap inicial do recurso do espaço de trabalho pode demorar até cinco dias para espaços de trabalho grandes.
  • A utilização do firewall de armazenamento do espaço de trabalho nas contas de armazenamento do espaço de trabalho utilizadas com recuperação após desastre gerida requer configuração manual. Deve permitir que os endereços IP relevantes do plano de controlo estejam no firewall de armazenamento para que o Azure Databricks possa replicar os dados. Consulte Requisitos.

Reference

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

DR_MISSING_DEPENDENCY

Um ativo faz referência a uma dependência que não existe no secundário, pelo que o ativo não pode ser replicado. A subclasse identifica o tipo de dependência em falta 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á avariado no primário devido à falta de dependência. Se for o caso, corrija ou remova o ativo no principal.
  2. Se o ativo for válido na instância primária, a dependência ou não está abrangida pelo âmbito de replicação de nenhum grupo de failover, ou está abrangida pelo âmbito deste ou de outro grupo de failover, mas a replicação falhou. Se a dependência não estiver dentro do âmbito, edite o âmbito de replicação do grupo de failover para também a replicar. Se a dependência já estiver no âmbito, consulte system.replication.states para identificar o erro que está a impedir a sua replicação e resolva esse erro.
DR_INVALID_CONFIGURATION.MISSING_LOCATION_MAPPING

A DR gerida decide onde colocar cada ativo replicado aplicando os mapeamentos de armazenamento do grupo de failover à localização de armazenamento de origem do ativo. Um mapeamento corresponde exatamente a um local ou a um prefixo que também abrange os caminhos subordinados. Este erro significa que nenhum mapeamento cobre uma localização de armazenamento de origem, pelo que a DR gerida não consegue determinar onde no secundário colocar o ativo. Para tabelas e volumes externos, a ausência de mapeamento significa que o mesmo URI de localização é utilizado na instância primária e na secundária. O storage_location na mensagem é o caminho de origem não mapeado.

  1. Na consola da conta, vá a Resiliência → Grupos de ativação pós-falha e edite o grupo de ativação pós-falha.
  2. Em Mapeamentos de Armazenamento, adicione ou alarga um mapeamento para que cubra a localização de origem na mensagem. Para abranger caminhos subordinados, mapeie um caminho principal e adicione o sufixo /* para correspondência por prefixo. Ver mapeamentos de armazenamento.
  3. Confirme que uma localização externa 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 uma localização externa existente, por isso crie essa localização externa primeiro se esta 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 resolvia um ativo replicado para um caminho alvo no secundário, mas nenhuma localização externa na metastore secundária cobre esse caminho, pelo que o Unity Catalog não tem onde colocar os dados do ativo. O storage_location na mensagem é o caminho secundário (alvo ) descoberto.

Isto normalmente significa uma de duas situações: uma localização externa que anteriormente abrangia o caminho foi removida ou reduzida, ou um recurso que foi replicado recentemente corresponde a um caminho secundário que não é abrangido por nenhuma localização externa. O segundo caso acontece, por exemplo, quando cria uma tabela externa na instância principal num caminho de armazenamento que não é abrangido por nenhum dos seus mapeamentos de armazenamento. A DR gerida recorre então ao caminho original da tabela, que nenhuma localização externa do metastore secundário abrange, pelo que os dados não têm onde ser colocados.

  1. Identifique o caminho secundário não coberto no storage_location da mensagem.
  2. Decide qual a localização externa na metastore secundária que deve cobrir esse caminho: uma localização externa existente que estendes, ou uma nova que crias.
  3. Ajuste os mapeamentos de armazenamento do grupo de failover de modo que o caminho seja resolvido numa localização externa já existente, ou crie a localização externa (com a respetiva credencial de armazenamento) e estenda o mapeamento para apontar para essa localização. Consulte Conectar-se ao armazenamento de objetos na nuvem usando o Unity Catalog.
DR_INTERNAL_ERROR

Ocorreu uma falha do lado do sistema durante a replicação. Não é necessária qualquer ação; O sistema recupera automaticamente. Contacte o suporte do Azure Databricks se o problema não se resolver sozinho.

DR_INVALID_CONFIGURATION.CROSS_CATALOG_VIEW_PERMISSION

A DR gerida replica a vista juntamente com as suas concessões, mas uma vista que referencia objetos noutros catálogos também necessita que o seu proprietário tenha acesso a esses objetos referenciados no secundário, porque a vista funciona com os privilégios do proprietário. Este erro significa que o proprietário não tem esse acesso na instância secundária, por isso deve concedê-lo aí sobre os objetos referenciados.

  1. Localize os objetos a que a vista faz referência e o proprietário da vista. Os objetos referenciados aparecem como nomes catalog.schema.object totalmente qualificados na definição; as permissões devem ser concedidas ao proprietário, que também pode consultar no campo Proprietário no Explorador de Catálogos.

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

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

    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. Atribua ao proprietário da vista todos os privilégios em falta em cada objeto referenciado.

    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 referenciado pela vista está incluído no âmbito 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 Catálogo Unity.

DR_INVALID_CONFIGURATION.NETWORK_UNAUTHORIZED_ACCESS

Durante a replicação de dados de tabelas entre regiões, a computação sem servidor do espaço de trabalho secundário acede aos dados no armazenamento de origem, mas o armazenamento recusou a ligação de rede: uma firewall de armazenamento ou uma regra de rede bloqueou-a, ou falta um endpoint privado necessário, ou este não está aprovado.

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

DR_INVALID_CONFIGURATION.SERVERLESS_COMPUTE_PERMISSION

A DR gerida utiliza computação serverless no espaço de trabalho secundário para copiar dados, e a computação serverless não é permitida nesse espaço de trabalho. Isto normalmente significa que o modo sem servidor está desativado para a conta ou para o espaço de trabalho, ou que o espaço de trabalho não é elegível.

  1. Confirme que o espaço de trabalho secundário é elegível. A computação sem servidor está disponível por predefinição em espaços de trabalho com o Unity Catalog ativado numa região suportada. Consulte como se conectar à computação sem servidor.
  2. Verifique se existe uma opção de exclusão para toda a conta. Na consola da conta, vai a Definições → Ativação de Funcionalidades e verifica se a opção serverless está presente ou desligada.
  3. Ativa o serverless para o âmbito que precisas. Para ativar todos os espaços de trabalho elegíveis, um administrador de conta ativa a opção serverless ao nível da conta. Para ativar apenas o espaço de trabalho secundário, deixe desativado o controlo ao nível da conta e peça a um administrador do espaço de trabalho para ativar o modo serverless em Pré-visualizações do espaço de trabalho.
  4. Se não houver nenhum interruptor disponível, ou se a funcionalidade sem servidor ainda não funcionar depois de a ativar, contacte a sua equipa de gestão de conta da Azure Databricks.
DR_INVALID_CONFIGURATION.OVERLAPPING_EXTERNAL_LOCATIONS

Quando a DR gerida cria um objeto replicado no respetivo caminho de destino mapeado no sistema secundário, o Unity Catalog rejeita o caminho porque este se sobrepõe a um armazenamento que já existe nesse local, como uma localização externa existente, um objeto protegível remanescente de uma configuração anterior ou parcial, uma localização gerida ou o armazenamento predefinido da área de trabalho (DBFS).

  1. Identifique o que ocupa o caminho.

    No Explorador de Catálogos, reveja as suas localizações externas, localizações de armazenamento geridas e tabelas e volumes externos para encontrar o objeto cujo caminho cobre ou sobrepõe o caminho de destino.

  2. Se o objeto em conflito não for o proprietário do caminho, remova-o. Uma causa comum é uma tabela externa ou volume externo remanescente de uma configuração anterior; Deixa de o usar se já não for necessário. Se for uma localização externa que não deve cobrir o caminho, remova-a ou redefina-a.

  3. Caso contrário, redirecione o mapeamento de armazenamento do grupo de ativação pós-falha para um caminho de destino dedicado, sem sobreposição. Prefira um subcaminho específico em vez de uma raiz ampla do bucket e evite o armazenamento predefinido da área de trabalho (DBFS).

DR_UNSUPPORTED_FEATURE

O ativo usa uma funcionalidade que a DR gerida não consegue replicar. A subclasse identifica a característica não suportada e aparece, por exemplo, como DR_UNSUPPORTED_FEATURE.ABAC_POLICY. Existem duas formas de resolver este erro.

  1. Remova a função não suportada do ativo no espaço de trabalho primário.
  2. Se não conseguir remover a funcionalidade, considere remover o ativo do âmbito de replicação do grupo de failover.
DR_UNSUPPORTED_FEATURE.TABLE_ARCHIVED_FILES

A tabela tem o suporte de arquivamento do Delta Lake ativado (delta.timeUntilArchived). O DR gerido clona todos os ficheiros de dados, pelo que os objetos arquivados devem ser restaurados numa camada de armazenamento ativa e a propriedade da tabela deve deixar de estar definida no primário antes de a replicação poder continuar. Ver Suporte arquivístico em Azure Databricks.

  1. Desative a política de arquivamento do ciclo de vida da cloud na localização de armazenamento da tabela para que ficheiros adicionais não sejam arquivados depois de os listar.

  2. Listar ficheiros que precisam de restauro:

    SHOW ARCHIVED FILES FOR <table_name>;

  3. Restaure esses objetos no seu fornecedor de cloud e depois espere até a restauração terminar. Ver Restaurar ficheiros arquivados.

  4. Remova a propriedade da tabela delta.timeUntilArchived. Isto apenas atualiza os metadados para que o Databricks deixe de registar o arquivamento na tabela:

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

  5. Confirme que uma leitura completa é bem-sucedida, por exemplo SELECT COUNT(*) FROM <table_name>;. Depois disso, a replicação pode clonar a tabela.

Tenha em atenção que anular a definição da propriedade não restaura os objetos. Restaurar objetos é uma operação do fornecedor de serviços cloud que deve ser feita manualmente usando mecanismos do fornecedor de serviços cloud.

Para conceitos e melhores práticas de DR, veja Recuperação de Desastres.

  • Última atualização a