Recuperação de Desastres do Lakebase (DR)
A recuperação de desastres está em Private Preview. Durante a Prévia Privada, está disponível apenas para replicação entre regiões na AWS. Para habilitar a recuperação de desastres para sua conta, peça ao administrador do seu Workspace para entrar em contato com o representante da sua conta Databricks.
Durante a Prévia Privada, a recuperação de desastres não se destina ao uso em produção.
O Lakebase Disaster Recovery (DR) replica os dados do seu projeto para um Workspace secundário em uma região diferente, protegendo contra falhas de região completas, incluindo interrupções, em vez de uma única falha de compute ou falha de zona de disponibilidade (AZ). O Lakebase atualmente oferece replicação periódica, que sincroniza seus dados em outra região sem precisar executar compute adicional. O modo periódico é para casos de uso nos quais é preciso proteger contra interrupções regionais, mas seu caso de uso não é tão sensível à indisponibilidade regional (por exemplo, janelas de RPO na faixa de minutos). É preciso Trigger um failover manualmente caso queira promover um projeto secundário para que se torne um primário, embora seja possível optar por criar scripts para esse comportamento.
Esta página explica como funciona a Recuperação de Desastres do Lakebase. Para habilitá-lo e Trigger um failover ou failback, consulte Gerenciar recuperação de desastres.
Durante a Pré-visualização privada, é possível gerenciar a recuperação de desastres nas configurações do projeto na UI. As APIs de recuperação de desastres estão disponíveis, mas sujeitas a alterações.
Como a recuperação de desastres funciona
A recuperação de desastres emparelha o Workspace primário do seu projeto com um Workspace secundário em outra região, formando um grupo de replicação. O Lakebase replica periodicamente os dados confirmados do Primário para o Secundário. O compute secundário permanece parado até um failover, para que não se pague por um standby sempre ativo. A replicação acontece na camada de armazenamento, então o compute do Secundário não precisa ser executado para receber dados replicados.
O Lakebase expõe uma métrica de lag da replicação que mostra o quão atrasado o Secundário está em relação ao Primário. O lag informa quantos dados seriam perdidos em caso de failover imediato, e é assim que se confirma que a replicação foi totalmente sincronizada (RPO=0) antes de um failback planejado.
Recuperação de desastres vs. alta disponibilidade
A recuperação de desastres e a alta disponibilidade protegem contra diferentes domínios de falha, e a maioria das cargas de trabalho de produção usa ambos. A alta disponibilidade mantém o compute redundante em execução, para que uma falha de compute ou de zona de disponibilidade não deixe o banco de dados offline. A recuperação de desastres mantém uma cópia replicada de seus dados em outra região, para que seja possível retomar suas operações do Lakebase em caso de falha regional.
É possível combinar alta disponibilidade e recuperação de desastres para aplicações de produção e críticas para construir um modelo de implantação mais resiliente para seu projeto Lakebase.
Alta disponibilidade | Recuperação de desastres | |
|---|---|---|
Protege contra | Falha de compute ou zona de disponibilidade em uma região | Comprometimentos regionais, incluindo interrupções. |
Escopo | Entre zonas de disponibilidade em uma região. | Entre regiões |
Recurso redundante | Instâncias de compute em espera, já em execução em outras zonas | Uma cópia de dados replicada em um Workspace Secundário |
Compute em espera | Sempre em execução, pronto para assumir instantaneamente | Modo periódico: parado até o failover, para que não pague pelo compute em espera. |
Perda de dados no failover | Nenhum (RPO = 0), a replicação é síncrona | Os dados são reservados na região primária; os dados podem estar inconsistentes até serem reconciliados posteriormente por meio de Branch de recuperação. |
Trigger | Automático | Manual (é possível optar por automatizá-lo, com base nos seus requisitos) |
Impacto da aplicação | Reconectar à mesma string de conexão | Reconecte-se usando a string de conexão da nova região primária. |
Sua configuração de alta disponibilidade é copiada para o projeto secundário como parte do grupo de replicação, portanto, a alta disponibilidade é preservada após um failover. Não é necessário reconfigurá-lo no novo Primário.
Failover e failback
O failover transfere as gravações do Primário para o Secundário e promove o Secundário para ser o novo Primário. O Primário original para de aceitar gravações. Como cada região tem seus próprios Endpoint, o novo Primário tem uma string de conexão diferente. Após um failover, atualize seu aplicativo para usar a string de conexão do novo Primário, juntamente com um novo token de autenticação, antes de retomar o tráfego.
O failover é sempre manual. Como a replicação é periódica, os dados no secundário podem estar atrasados em relação ao primário, portanto, a qualquer momento, eles podem não ter as transações mais recentemente confirmadas. Promovê-lo é, portanto, uma decisão de negócios: o usuário está escolhendo retomar o serviço em uma cópia ligeiramente desatualizada e aceitar que as transações recentes sejam adiadas para uma Branch de recuperação até que ele as reconcilie. Lakebase não faz essa compensação para você, então um Administrador de Projeto Lakebase aciona cada failover.
O failback usa o mesmo mecanismo de failover, executado na direção oposta, assim que a região primária original se recuperar e se reunir ao grupo de replicação como um Secundário. Para atingir RPO=0 durante o failback, interrompa o tráfego de gravação no Primário atual primeiro, para que a replicação possa ser totalmente sincronizada antes de você fazer o failback.
Branch de recuperação
Se uma região ficar indisponível antes que todas as transações se repliquem para o Secundário, essas transações não replicadas são preservadas. O Lakebase preserva a linha do tempo divergente como uma branch de recuperação no Primary original. As Branch de recuperação permanecem ocultas até que a divergência seja detectada, e se tornam acessíveis após o failback, quando o Primary original voltar a ficar online. O Lakebase então exibe uma notificação para que você possa inspecionar a linha do tempo divergente. Você decide quando reconciliar os dados, e o Lakebase nunca faz merge automaticamente ou exclui uma branch de recuperação.
Para inspecionar e reconciliar uma branch de recuperação, consulte Inspecionar e reconciliar branches de recuperação.
O que não é compatível
A tabela a seguir lista os recursos e as configurações que estão limitados ou ainda não disponíveis durante a Prévia privada. Alguns estão planejados para um lançamento posterior, e outros estão fora do escopo da recuperação de desastres.
Recurso | Status |
|---|---|
CLI e API | As APIs de prévia estão disponíveis, mas sujeitas a alterações durante a Prévia Privada. |
Réplicas de leitura entre regiões. | Ainda não disponível. O compute secundário permanece parado no modo periódico e não pode atender a leituras até um failover. |
Switchover (failover controlado RPO=0) | Ainda não é compatível. É preciso planejar um failover controlado. |
Endpoint global | Ainda não é compatível. Você deve gerenciar a conexão com os endpoints regionais após um failover. |
Replicação na mesma região, entre Workspace | Não suportado. A primária e a secundária devem estar em regiões diferentes. |
PrivateLink | Ainda não é compatível. O tráfego de replicação entre os Workspaces Primário e Secundário trafega pela internet pública, criptografado em trânsito. |
Integrações do Lakehouse em failover
Tabelas sincronizadas e pipelines CDF do Lakebase são encerrados no failover e não são retomados automaticamente. Reconfigure-os manualmente após um failover. Os dados com os quais eles lidam se comportam de forma diferente:
- Tabelas sincronizadas (lakehouse para Lakebase). Os dados sincronizados são replicados para o projeto secundário, portanto, estão presentes no novo Primário após o failover. Apenas o pipeline precisa ser reconfigurado.
- Lakebase CDF (Lakebase para lakehouse). Os dados do Delta não são replicados, porque a recuperação de desastres não replica tabelas Delta.
Mais recursos
- Gerenciar recuperação de desastres para habilitar a recuperação de desastres e Trigger um failover
- Alta disponibilidade para failover automático na região
- Analise as branches do banco de dados para entender como as branches de recuperação se relacionam com as branches regulares.