Recuperação de desastres gerenciada

info

Visualização

Esse recurso está em Prévia Pública.

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.

Tudo o que não está listado na seção anterior não é replicado. Consulte Limitações para obter detalhes.

Requisitos

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

• 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.

• 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.

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/*.

Utilize o URL estável

O URL estável sempre resolve para o workspace primário atual, assim os clientes que se conectam por meio dele não precisam ser reconfigurados após um failover. Direcione os seguintes clientes downstream para o URL estável em vez do 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 o Link Privado front-end (de entrada), mas o formato da URL difere do padrão.

O URL original do workspace continua funcionando, mas ele não sobrevive ao failover. A Databricks recomenda migrar os clientes para o URL estável.

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.

Selecione o nome de um grupo de failover para abrir a página de detalhes. O ponto de replicação mostra quando todos os recursos no escopo foram copiados pela última vez. Os dados gravados após o ponto de replicação podem não existir no secundário e podem ser perdidos durante o failover.

Para tendências históricas de RPO e erros de replicação por ativo, consulte a tabela do sistema system.replication.states. Consulte Referência de tabelas do sistema de replicação.

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.

Erros comuns de replicação

Erros de replicação aparecem na página de detalhes do grupo de failover na seção **Resiliência** do account console e na system.replication.states tabela do sistema. A seguir, os erros mais comuns são.

Erro	Resolução
Localização externa ausente	Crie o local externo ausente no metastore secundário, ou atualize os mapeamentos de armazenamento do grupo de failover para incluir o caminho.
Erro de configuração de rede	Verificar a configuração de conectividade de rede do workspace secundário, incluindo quaisquer configurações de conectividade de rede necessárias e endpoints privados aprovados.
Falta de dependência	Uma view no grupo de failover depende de um catálogo que não está no grupo de failover. Adicionar o catálogo de dependências, ou remover a view dependente.
Limite de solicitação excedido	O sistema realiza novas tentativas automaticamente. Entre em contato com o suporte da Databricks se o erro persistir.
Origem ausente	Informativo. O ativo não existe mais no principal; nenhuma ação é necessária.

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 replicado: visualizações materializadas, tabelas de transmissão, pipelines declarativos do Lakeflow Spark, dados de volume gerenciado (os metadados são replicados), Unity Catalog e segredos do workspace, modelos de ML, endpoints de servindo modelo, índices de pesquisa vetorial, compartilhamentos Delta, dashboards de AI/BI publicados (os rascunhos são replicados) e transmissão estructurada do Spark fora dos pipelines declarativos do Lakeflow Spark. Tabelas com filtros de linha ou máscaras de coluna e recursos com tag ABAC são sinalizadas com falha de replicação na tabela do sistema, e essas falhas impedem o RPO até que o recurso seja removido 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.

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