Recuperação de desastres

A recuperação de desastres (DR) para Databricks replica workspaces, dados e configurações entre regiões da nuvem para que suas equipes continuem trabalhando quando uma interrupção regional deixa sua implantação principal offline. Um plano de DR completo cobre não apenas o Databricks, mas também as fontes de dados, ferramentas de ingestão, ferramentas de BI e programadores aos quais ele se conecta.

Esta página aborda os conceitos, estratégias, ferramentas e procedimentos de teste que você precisa para projetar e a execução de uma solução de DR entre regiões.

É iniciante em planejamento de recuperação de desastres? Começar com terminologia da indústria de recuperação de desastres para definições de RPO e RTO.

Garantias de alta disponibilidade intra-regional

O restante desta página aborda o DR entre regiões, mas o Databricks também oferece alta disponibilidade (HA) em uma única região. É fundamental compreender essas garantias primeiro. Eles determinam se é necessária uma estratégia de DR separada.

HA e DR resolvem problemas diferentes:

HA usa redundância de zona de disponibilidade (AZ) em uma região. Se uma zona falhar, os serviços continuarão em execução nas outras.
DR usa replicação entre regiões. Workspaces secundários do Databricks são operados em outra região, e dados e configurações são replicados para esses. O failover é então realizado durante uma interrupção regional.

Se você não precisar de DR multirregião, o HA do Databricks pode ser suficiente. HA evita a complexidade entre regiões, mas não protege contra uma falha total da região. Se para DR houver dependência exclusiva de HA, é importante verificar a separação e redundância da sua região da cloud.

Garantias de HA intrarregião cobrem o plano de controle e o plano de compute.

Disponibilidade do plano de controle do Databricks

O plano de controle do Databricks é resiliente a falhas de zona e se recupera automaticamente em aproximadamente 15 minutos de uma falha de zona. Testes regulares de falhas de zona validam isso.

Todos os serviços do plano de controle sem estado podem perder VMs individuais, ou todas as VMs em uma zona inteira, sem interromper o serviço. Os dados do workspace são armazenados em bancos de dados replicados em várias zonas na região. Contas de armazenamento que fornecem imagens do Databricks Runtime também são redundantes dentro da região, e todas as regiões possuem contas de armazenamento secundárias que assumem quando a principal está inoperante.

nota

The control plane guarantees above apply to Databricks-managed infrastructure. You are responsible for compute-plane zone redundancy, for example, choosing zone-redundant storage for the workspace root bucket and using instance pools that span availability zones.

A resiliência a falhas de zona suporta que no máximo uma zona esteja inoperante em uma região.

A resiliência da zona pode não estar ativada na sua região do Google Cloud. Para obter mais informações, consulte Nuvens e regiões do Databricks. Se você precisar de resiliência de zona em uma região sem suporte, entre em contato com sua equipe de conta do Databricks.

Disponibilidade do plano de compute

Disponibilidade do avião compute

A disponibilidade do workspace depende da disponibilidade do plano de controle.

Os dados do DBFS root não são afetados. Os dados do GCS são regionais por default, com redundância de dados entre as zonas.

Os nós de cluster são alocados em uma única AZ do provedor de compute do Google cloud. Se um nó for perdido, o gerenciador de clusters solicita nós de substituição do provedor de compute do Google Cloud na mesma AZ. A exceção é quando o nó do driver é perdido. Nesse caso, o gerenciador de cluster reinicia o Job e o cluster. Se a AZ que contém o cluster sofrer uma falha de zona, o gerenciador de cluster reinicia o job e o cluster em uma AZ diferente.

Terminologia

Utilize estas definições consistentemente ao discutir DR com a sua equipe.

Terminologia regional

Terminologia da região

Esta página usa as seguintes definições de região:

Região primária : A região onde são executadas cargas de trabalho diárias interativas e automatizadas de análise de dados.
Região secundária : A região onde as equipes de IT movem as cargas de trabalho temporariamente durante uma interrupção da região primária.
Armazenamento geo-redundante : Replicação assíncrona entre regiões do armazenamento persistente. Consulte a documentação da sua cloud:

Armazenamento georredundante entre regiões (Google Cloud).

importante

Do not rely on geo-redundant storage to duplicate Databricks root storage (such as the GCS bucket Databricks creates for each workspace) across regions. To replicate managed table data, use Delta Deep Clone, and for non-Delta data, convert to Delta first where possible.

Terminologia do status da implementação

Terminologia do status de implantação

Esta página utiliza as seguintes definições de status de implementação:

Implementação ativa (também conhecida como implantação a quente ): Usuários se conectam a ela e executam cargas de trabalho. Jobs e transmissões de dados em execuções aqui em programação.
Implantação passiva (às vezes chamada de implantação a frio ): nenhum processo é executado aqui. As equipes de IT a mantêm pronta automatizando a implantação de código, configuração e outros objetos Databricks nela. Uma implantação passiva se torna ativa *apenas* quando a implantação ativa cai.

importante

Um projeto pode incluir múltiplas implantações passivas em diferentes regiões para resiliência adicional.

A maioria das equipes opera uma implantação ativa por vez, a estratégia ativa-passiva. A estratégia ativo-ativo menos comum executa duas implementações ativas simultâneas.

Terminologia da indústria de recuperação de desastres

Terminologia das indústrias de recuperação de desastres

Defina estes dois termos da indústria com sua equipe:

Objetivo do ponto de recuperação (RPO): O período máximo de perda de dados que seu serviço pode tolerar durante um incidente grave. Veja RPO.

A Databricks não armazena seus dados do cliente principais. Que está no Google Cloud Storage ou em outros sistemas sob seu controle. O plano de controle do Databricks armazena alguns objetos (como jobs e notebooks), portanto, o RPO do Databricks é o período máximo em que as alterações nesses objetos podem ser perdidas. É sua responsabilidade definir o RPO para seus dados do cliente no Google Cloud Storage e em outras fontes de dados sob seu controle.
Objetivo de tempo de recuperação (RTO) : O tempo máximo no qual um processo de negócios deve ser restaurado após um desastre. Veja RTO.

Recuperação de desastres e corrupção de dados

Uma solução de DR não mitiga a corrupção de dados. Dados corrompidos na região primária são replicados para a região secundária e são corrompidos em ambas as regiões. Para mitigar esse tipo de falha, use a viagem do tempo do Delta, ferramentas semelhantes ou ferramentas de backup de dados.

Fluxo de trabalho típico de recuperação

Um cenário de DR do Databricks normalmente ocorre da seguinte forma:

Uma falha afeta um serviço crítico em sua região primária: uma fonte de dados, uma rede ou outra dependência da qual a implantação do Databricks depende.
Investiga-se com seu provedor de cloud.
Se a espera for inaceitável, decide realizar failover para sua região secundária.
Certifique-se de que o mesmo problema não afete a sua região secundária.
Failover (para passos detalhados, consulte Teste de failover):
1. Parar toda a atividade do workspace. Usuários param as cargas de trabalho e fazem backup das alterações recentes sempre que possível. Os jobs são desligados (se a interrupção já não os tiver falhado).
2. Execute o procedimento de recuperação da região secundária para atualizar o roteamento e redirecionar conexões e tráfego de rede.
3. Redirecionar sistemas downstream (ferramentas de BI, programadores, integrações de terceiros) para o workspace secundário e retomar suas conexões.
4. Após os testes, a região secundária deve ser declarada operacional. Os usuários log in na implantação agora ativa, e os jobs agendados ou atrasados são acionados novamente.
Após o problema na região primária ser mitigado, deve-se confirmar a correção.
Reverter (para obter detalhes, consulte Teste de restauração (reversão)):
1. Interromper todo o trabalho na região secundária.
2. Execute o procedimento de recuperação da região primária para redirecionar o roteamento de volta.
3. Replique quaisquer dados novos de volta para a região primária. Minimize o que deve ser replicado. Por exemplo, jobs somente leitura que foram executados na implantação secundária podem não exigir gravação de volta.
4. Teste a implementação da região primária.
5. Declarar a região primária ativa e retomar as cargas de trabalho de produção.

importante

Alguma perda de dados pode ocorrer durante estes passos. Defina quanta perda é aceitável para sua organização, e como você a mitiga.

Etapa 1: Entenda suas necessidades comerciais

Identifique quais serviços de dados são críticos e defina seus objetivos de RPO e RTO. Pesquisar a tolerância de cada sistema no mundo real.

DR, falha e retorno pós-falha acarretam custos e riscos reais, incluindo corrupção de dados, duplicação de dados (gravação em um local de armazenamento incorreto) e a realização de alterações por usuários na região errada.

Mapeie cada ponto de integração da Databricks que afetam o seu negócio e escolha as ferramentas e canais de comunicação que o seu plano utiliza.

Pontos de integração a mapear

Sua solução de DR precisa acomodar processos interativos, processos automatizados ou ambos?
Quais serviços de dados são utilizados? Alguns podem ser on-premises.
Como os dados de entrada chegam à nuvem?
Quem consome esses dados? Quais processos o consomem a jusante?
Existem integrações de terceiros que precisam estar cientes das alterações de DR?

Ferramentas e comunicação de planejamento

É possível predefinir a configuração e torná-la modular para acomodar soluções de DR de forma natural e de fácil manutenção?
Quais ferramentas de comunicação e canais notificam equipes internas e terceiros (integrações, consumidores downstream) sobre alterações de failover e failback de DR? Como confirmar o reconhecimento deles?
Quais serviços, se houver, são desligados até que a recuperação completa esteja estabelecida?

Etapa 2: escolha um processo que atenda às necessidades da sua empresa

Uma solução DIY deve replicar os dados corretos entre o plano de controle, o plano de compute e as fontes de dados. Workspaces redundantes mapeiam para planos de controle diferentes em regiões distintas, portanto, eles são mantidos em sincronia com uma solução baseada em script, seja uma ferramenta de sincronização ou um fluxo de trabalho de CI/CD. Para os próprios dados, a maioria das equipes usa Databricks Jobs (muitas vezes agendados) ou Delta Deep Clone para copiar tabelas entre regiões. Não é necessário sincronizar dados de dentro do plano de compute (como dos workers do Databricks Runtime).

Se você usar o recurso de VPC gerenciada pelo cliente (não disponível com todos os tipos de inscrição e implantação), implante redes de forma consistente em ambas as regiões usando ferramentas baseadas em padrão como Terraform.

Replicar as fontes de dados entre regiões conforme necessário.

As soluções de recuperação de desastres tipicamente envolvem dois (ou mais) workspace. Escolha entre as seguintes estratégias com base na duração da interrupção que deve ser tolerada, no esforço operacional e no custo para fazer fail back para a região primária.

Práticas recomendadas gerais

Práticas recomendadas gerais para um plano de DR bem-sucedido incluem:

Entenda quais processos são críticos para o negócio e devem ser executados em DR.
Identifique claramente quais serviços estão envolvidos, quais dados estão sendo processados, qual é o fluxo de dados e onde eles são armazenados.
Isole os serviços e os dados o máximo possível. Por exemplo, crie um contêiner de armazenamento em cloud especial para os dados de DR ou mova objetos do Databricks necessários durante um desastre para um workspace separado.
É responsável por manter a integridade entre as implantações primárias e secundárias de objetos que não estão armazenados no plano de controle do Databricks.
Para fontes de dados, utilize as ferramentas nativas do Google Cloud para replicar dados para as suas regiões de DR sempre que possível.

atenção

Don't store data in the root GCS bucket used for DBFS root access. DBFS root storage is unsupported for production customer data. Databricks also recommends against storing libraries, configuration files, or init scripts there.

Estratégia de soluções ativo-passivo

Esta seção se concentra na estratégia ativa-passiva porque é a mais comum, a mais simples e a mais econômica. Uma solução ativo-passiva sincroniza alterações de dados e objetos da sua implantação ativa para uma implantação passiva em uma região secundária. Durante um evento de DR, a implantação passiva se torna ativa.

Duas variantes comuns:

Unificado (em toda a organização) : Um conjunto de implementações ativas e passivas suporta toda a organização.
Por departamento ou projeto: Cada domínio mantém sua própria solução de DR com regiões primárias e secundárias adaptadas às suas necessidades.

Também é possível usar uma implantação passiva para cargas de trabalho somente leitura, como queries de usuário, que não modificam dados ou objetos do Databricks.

Estratégia de solução ativo-ativo

Estratégia de soluções ativo-ativo

Em uma solução ativo-ativo, todos os processos de dados são executados em ambas as regiões em paralelo o tempo todo. A sua equipe de operações deve marcar cada Job como concluído somente depois que ele for bem-sucedido em ambas as regiões. Objetos não podem ser alterados em produção e devem seguir uma promoção rigorosa de CI/CD do desenvolvimento/homologação para a produção.

Ativo-ativo é a estratégia mais complexa e custa mais porque os jobs são executados em ambas as regiões, mas oferece os menores RTO e RPO.

É possível implementar ativo-ativo em toda a empresa ou por departamento. Você não precisa de um workspace duplicado para cada carga de trabalho. Por exemplo, workspaces de desenvolvimento ou de staging são frequentemente mais fáceis de reconstruir de um pipeline de desenvolvimento do que manter em sincronia.

Escolha suas ferramentas

Existem duas abordagens principais para manter a sincronia dos dados entre workspaces em suas regiões primária e secundária:

Cliente de Sincronização que Copia do Primário para o Secundário : um cliente de sincronização transfere dados de produção e ativos da região primária para a região secundária. Normalmente, isso é executado de forma programada, e a frequência do agendamento depende do seu RTO e RPO alvo.
Ferramentas de CI/CD para implantação paralela : Para código de produção e ativos, use as ferramentas de CI/CD que implementam alterações em sistemas de produção simultaneamente em ambas as regiões. Por exemplo, ao migrar código e ativos de ambientes de staging/desenvolvimento para produção, um sistema de CI/CD os disponibiliza em ambas as regiões simultaneamente. A ideia central é tratar todos os artefatos em um workspace do Databricks como Infrastructure-as-Code. A maioria dos artefatos poderia ser co-implantada em workspaces primários e secundários, enquanto alguns artefatos podem precisar ser implantados apenas após um evento de DR. Para ferramentas, consulte Scripts, exemplos e protótipos de automação.

Dependendo das suas necessidades, é possível combinar as abordagens. Por exemplo, use CI/CD para código-fonte do notebook, mas use sincronização para configuração como pools e controles de acesso.

A tabela a seguir descreve como lidar com cada tipo de dados com cada opção de ferramenta.

Description	How to handle with CI/CD tooling	How to handle with sync tool
Source code: notebook source exports and source code for packaged libraries	Co-deploy both to primary and secondary.	Synchronize source code from primary to secondary.
Users and groups	Manage metadata as config in Git. Alternatively, use the same identity provider (IdP) for both workspaces. Co-deploy user and group data to primary and secondary deployments.	Use SCIM or other automation for both regions. Manual creation is not recommended, but if used must be done for both at the same time. If you use a manual setup, create a scheduled automated process to compare the list of users and groups between the two deployments.
Pool configurations	Can be templates in Git. Co-deploy to primary and secondary. However, `min_idle_instances` in secondary must be zero until the DR event.	Pools created with any `min_idle_instances` when they are synced to a secondary workspace using the API or CLI.
Job configurations	Use Databricks Asset Bundles with per-environment targets (for example, `prod` and `dr`) to deploy the same job definition to both regions. For the secondary deployment, set concurrency to zero so the job is staged but doesn't run. Change the concurrency value after the secondary deployment becomes active.	If the jobs run on existing `<interactive>` clusters for some reason, then the sync client needs to map to the corresponding `cluster_id` in the secondary workspace.
Access control lists (ACLs)	Can be templates in Git. Co-deploy to primary and secondary deployments for notebooks, folders, and clusters. However, hold the data for jobs until the DR event.	The Permissions API can set access controls for clusters, jobs, pools, notebooks, and folders. A sync client needs to map to corresponding object IDs for each object in the secondary workspace. Databricks recommends creating a map of object IDs from primary to secondary workspace while syncing those objects before replicating the access controls.
Libraries	Include in source code and cluster/job templates.	Sync custom libraries from centralized repositories, DBFS, or cloud storage (can be mounted).
Cluster init scripts	Include in the source code if you prefer.	For simpler synchronization, store init scripts in the primary workspace in a common folder or in a small set of folders if possible.
Mount points	Include in source code if created only through notebook-based jobs or Command API.	Use jobs. Note that the storage endpoints might change, given that workspaces would be in different regions. This depends a lot on your data DR strategy as well.
Table metadata	For Unity Catalog objects (catalogs, schemas, tables, volumes, and grants), co-deploy with the Databricks Terraform provider or Databricks Asset Bundles. For legacy Hive metastore tables, include create-table statements with source code if created through notebook-based jobs or the Command API.	For Unity Catalog objects, read source metadata from system tables or `information_schema` and replicate to the secondary workspace using the Databricks SDK. For legacy Hive metastore tables, compare metadata definitions between metastores using the Spark Catalog API or `SHOW CREATE TABLE` via a notebook or scripts. Underlying storage paths can be region-based and might differ between metastore instances.
Secrets	Include in source code if created only through Command API. Note that some secrets content might need to change between the primary and secondary.	Secrets are created in both workspaces via the API. Note that some secrets content might need to change between the primary and secondary.
Cluster configurations	Can be templates in Git. Co-deploy to primary and secondary deployments, although the ones in secondary deployment should be terminated until the DR event.	Clusters are created after they are synced to the secondary workspace using the API or CLI. Those can be explicitly terminated if you want, depending on auto-termination settings.
Notebook, job, and folder permissions	Can be templates in Git. Co-deploy to primary and secondary deployments.	Replicate using the Permissions API.

Escolha regiões e vários workspaces secundários

Escolha regiões e múltiplos espaços de trabalho secundários

É possível controlar quando a DR é acionada e para qual região secundária o failover é realizado. É também de responsabilidade estabilizar o ambiente de DR antes de retomar as operações normais. Isso geralmente significa criar vários workspaces do Databricks para produção e DR e, em seguida, escolher uma região secundária de failover.

Antes de selecionar sua região secundária, confirme se todos os recursos e serviços dos quais você depende (tipos de compute, produtos, integrações) estão disponíveis lá. Alguns serviços da Databricks estão disponíveis apenas em regiões específicas.

Etapa 3: Preparar o espaço de trabalho e fazer uma cópia única

Primeiro, configure um workspace secundário do Databricks (ou workspaces) e seu metastore de apoio na região secundária escolhida. O workspace secundário deve espelhar a account, a região e a configuração de identidade do principal antes que os dados ou os ativos possam ser replicados para ele.

Para um workspace de produção em execução fora do escopo do DR gerenciado, faça uma cópia única para sincronizar a implantação passiva com a implantação ativa. Esta cópia lida com:

Replicação de dados : Use uma solução de replicação na cloud ou Delta Deep Clone.
Geração de tokens : Automatize a replicação e as cargas de trabalho futuras com tokens gerados.
Replicação workspace : Replique usando os métodos em Passo 4: Prepare sua fonte de dados. Para obter orientações completas sobre a exportação de configurações, dados e ativos de AI/ML do workspace, consulte Exportar dados do workspace.
Validação do workspace : testar o workspace e o processo para confirmar que são executados com sucesso e produzem os resultados esperados.

Sincronizações subsequentes são mais rápidas do que a cópia inicial, e os logs das ferramentas registram o que mudou e quando.

Etapa 4: Prepare sua fonte de dados

Databricks pode processar uma grande variedade de fontes de dados usando processamento de lotes ou transmissão de dados.

GCS e BigQuery replicam de forma diferente. Compreenda a diferença antes de projetar as fontes de dados:

Para o BigQuery, os dados são replicados. Os dados corrompidos podem ser recuperados por até sete dias (supondo que não haja backups).
Para o GCS que usa o Delta Lake, a replicação depende do tipo de bucket, como simples, duplo ou múltiplo. Os dados corrompidos podem ser recuperados dependendo da vacuum retenção.

Processamento em lote de fontes de dados

processamento de lotes a partir da fonte de dados

Dados em lote geralmente residem em uma origem que pode ser replicada ou entregue para outra região.

Por exemplo, os dados são frequentemente feitos upload para o armazenamento em cloud em um cronograma. No modo DR, direcione esses uploads para o seu armazenamento de região secundária e atualize as cargas de trabalho para ler e gravar nesse armazenamento.

Transmissões de dados

Transmissão de dados

O processamento de uma transmissão de dados é um desafio maior. Os dados de transmissão podem ser ingeridos de várias fontes, processados e enviados para uma solução de transmissão:

Fila de mensagens, como Kafka ou Pub/Sub Lite
Banco de dados de captura de dados de alterações (CDC) transmissão
Processamento contínuo baseado em arquivos
Processamento agendado baseado em arquivos, também conhecido como acionar uma vez

Nesses casos, é preciso configurar as fontes de dados para lidar com o modo DR e usar a implantação secundária na região secundária.

Um gravador de transmissão armazena um ponto de verificação com informações sobre os dados que foram processados. Esse ponto de verificação pode conter um local de dados (geralmente armazenamento em nuvem) que precisa ser modificado para um novo local para garantir o reinício bem-sucedido da transmissão. Por exemplo, a subpasta source abaixo do ponto de verificação pode armazenar a pasta na nuvem baseada em arquivos.

Esse ponto de verificação deve ser replicado em tempo hábil. Considere a sincronização do intervalo do ponto de verificação com qualquer nova solução de replicação em nuvem.

A atualização do ponto de verificação é uma função do gravador e, portanto, aplica-se à ingestão ou ao processamento da transmissão de dados e ao armazenamento em outra fonte de transmissão.

Para cargas de trabalho de transmissão, certifique-se de que os pontos de verificação estejam configurados no armazenamento gerenciado pelo cliente para que possam ser replicados na região secundária para a retomada da carga de trabalho a partir do ponto da última falha. O senhor também pode optar por executar o processo de transmissão secundário em paralelo ao processo primário.

Etapa 5: Implemente e teste suas soluções

Teste sua configuração de DR regularmente. Um plano de recuperação de desastres não testado costuma falhar no momento em que é mais necessário. Algumas equipes alternam regiões ativas a cada poucos meses em um cronograma para validar hipóteses, exercitar processos e manter a equipe familiarizada com o runbook.

importante

Teste sua solução de DR em condições do mundo real em um programar regular.

Caso um teste revele um objeto ou padrão ausente, atualize o plano da seguinte forma: remova a dependência, replique-a para o workspace secundário ou disponibilize-a de outra maneira.

Teste as mudanças organizacionais e de configuração também. Seu plano de DR afeta seu pipeline de implantação, portanto a equipe deve saber o que manter sincronizado. Depois de configurar os workspaces de DR, confirme se sua infraestrutura, jobs, notebooks, bibliotecas e outros objetos do workspace estão disponíveis na região secundária.

Expanda seus processos de trabalho padrão e pipelines de configuração para implantar alterações em todos os workspaces. Gerenciar identidades de usuário em todos os workspaces, e configurar automação de Job e monitoramento para os novos workspaces.

Planeje e teste as alterações na ferramenta de configuração.

Alterações de configuração para o planejamento e o teste

Para cada um dos seguintes, deve-se preparar um plano para failover e validar todas as premissas.

Ingestão : compreender onde suas fontes de dados estão e onde essas fontes obtêm seus dados. Quando possível, parametrize a origem e use um padrão de configuração separado para a implantação secundária e região.
Mudanças na execução : Se você tiver um programador para acionar Jobs ou outras ações, você pode precisar de um programador separado que funcione com a implantação secundária ou suas fontes de dados.
Conectividade interativa : Considere como a configuração, a autenticação e as conexões de rede podem ser afetadas por interrupções regionais para qualquer uso de APIs REST, ferramentas CLI ou outros serviços, como JDBC/ODBC.
Mudanças de automação : para todas as ferramentas de automação.
Saídas : Para quaisquer ferramentas que geram dados de saída ou logs.
Alterações downstream : Para ferramentas de BI, dashboards, programadores e integrações de terceiros que leem ou escrevem no Databricks, planeje como redirecioná-los para o workspace secundário e notifique seus proprietários.

Testar failover

Failover de teste

Muitos cenários podem acionar DR: uma interrupção inesperada na rede da cloud, armazenamento na cloud, ou outro serviço principal em que não é possível desligar graciosamente; um desligamento ou interrupção planejado; ou até mesmo a alternância periódica entre regiões como parte do seu ciclo de teste.

Para testar o failover, conectar-se ao sistema e executar um desligamento. Certifique-se de que todos os jobs sejam concluídos e os clusters sejam encerrados.

Um cliente de sincronização (ou ferramentas de CI/CD) replica objetos e recursos relevantes do Databricks para o workspace secundário. Para ativar o workspace secundário, seu processo pode incluir alguns ou todos os seguintes:

execução de testes para confirmar que a plataforma está atualizada.
Desative o pool e o clustering na região primária para que, se o serviço com falha voltar a ficar on-line, a região primária não comece a processar novos dados.
Execute o processo de recuperação para suas fontes de dados (consulte abaixo).
começar o pool relevante (ou aumentar o min_idle_instances para um número relevante).
começar o agrupamento relevante (se não for encerrado).
Altere a execução concorrente do Job e execute o Job relevante. Essas execuções podem ser únicas ou periódicas.
Para qualquer ferramenta externa que use um URL ou nome de domínio para o seu Databricks workspace, atualize as configurações para account para o novo plano de controle. Por exemplo, atualizar URLs para APIs REST e conexões JDBC/ODBC. O URL voltado para o cliente do aplicativo da Web Databricks muda quando o plano de controle é alterado, portanto, notifique os usuários da sua organização sobre o novo URL.

Detalhes do processo de recuperação

Verifique a data dos dados sincronizados mais recentes. Consulte a terminologia das indústrias de recuperação de desastres. Os detalhes desse processo variam dependendo de como você sincroniza os dados e das necessidades específicas do seu negócio.
Estabilize sua fonte de dados e garanta que todos eles estejam disponíveis. Inclua todas as fontes externas de dados, como Google Cloud SQL, BigQuery, ou Pub/Sub, e seus arquivos Delta Lake, Parquet, ou outros.
Encontre o ponto de recuperação da transmissão. Configure o processo para reiniciar a partir daí e tenha um processo pronto para identificar e eliminar possíveis duplicatas (o Delta Lake facilita isso).
Conclua o processo de fluxo de dados e informe os usuários.

Testar restauração (failback)

Restauração de teste (failback)

O failback é mais fácil de controlar e pode ser feito em uma janela de manutenção. Planeje alguns ou todos os passos seguintes:

Obtenha a confirmação de que a região primária foi restaurada.
Desative pools e clusters na região secundária para que não comecem a processar novos dados.
Sincronize quaisquer ativos novos ou modificados no workspace secundário de volta à implantação principal. Dependendo do design dos seus scripts de failover, você poderá executar os mesmos scripts para sincronizar objetos da região secundária (DR) para a região primária (produção).
Sincronize todas as novas atualizações de dados com a implantação primária. O senhor pode usar as trilhas de auditoria de logs e tabelas Delta para garantir que não haja perda de dados. Observe que alguns gerenciar fonte de dados têm janelas de tempo limitadas para recuperação usando o Snapshot automatizado. Por exemplo, o Google BigQuery tem um limite de sete dias para a restauração de dados.
Desligar todas as cargas de trabalho na região de DR.
Altere o URL dos Jobs e usuários para a região primária, e redirecione as conexões downstream (ferramentas de BI, programadores, integrações de terceiros) de volta para ela.
execução de testes para confirmar que a plataforma está atualizada.
começar o pool relevante (ou aumentar o min_idle_instances para um número relevante).
começar o agrupamento relevante (se não for encerrado).
Altere a execução concorrente do Job e a execução relevante do Job. Essas execuções podem ser únicas ou periódicas.
Se necessário, configure a sua região secundária novamente para futura Recuperação de Desastres.

Scripts de automação, amostras e protótipos

Para pipelines de DR DIY, use o provedor Databricks Terraform para gerenciar ativos de workspace como código e co-implantar em regiões primárias e secundárias.

Garantias de alta disponibilidade intra-regional​

Disponibilidade do plano de controle do Databricks​

Disponibilidade do avião compute​

Terminologia​

Terminologia da região​

Terminologia do status de implantação​

Terminologia das indústrias de recuperação de desastres​